72 hours of vulnerabilities: what to patch, what to rotate and which certificates to replace

Between Monday 19 and Thursday 22 October 2026, eight incidents hit very common infrastructure: two critical PHP bugs, a Node.js security release with ten CVEs, an unauthenticated RCE in GitLab rated CVSS 10.0, a breach of Railway’s environment variables, a malicious LiteLLM release on PyPI and Docker Hub, PingCAP’s notice about TiDB Cloud, the revocation of 404,607 GoDaddy certificates and the distrust of eight eMudhra intermediate CAs.

As headlines, that is eight stories. For whoever runs the servers, it is three jobs: update, rotate secrets and check certificates. This post sorts them that way, with the fixed versions and the commands to check.

Summary: who has to do what

1. Update runtimes and servers

PHP: php2shell

On 20 October a Hacker News post leaked the identifiers of two critical PHP bugs before the embargo ended, and the project moved disclosure forward to 21 October at 14:00 UTC. CVE-2026-109618 is memory corruption when PHP runs out of memory halfway through processing a request; CVE-2026-109619 is a use-after-free between requests on the same worker. Both are exploitable without authentication, affect every installation that serves PHP over the web and are worse under mod_php, where Rapid7 says they are exploitable before any application code runs. Wiz demonstrated RCE against WordPress, Drupal and Joomla. Fixed versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35; if you use your Linux distribution’s packages, check your vendor’s advisory, since many patched earlier. If you cannot upgrade today, the official temporary mitigation is session.upload_progress.enabled=0 in php.ini or the FPM pool (ini_set and .user.ini do not work) followed by restarting every worker. If you would rather hand off the upgrade: PHP security patch.

Node.js: Brotli and TLS hostnames

On 21 October Node.js published ten CVEs for the 26.x, 24.x and 22.x lines. The four rated high:

• CVE-2026-111497: out-of-bounds write in the Brotli decompressor, with possible RCE. Express 5 and fetch() decompress Brotli automatically, so it is enough for your server to receive, or your code to download, a crafted compressed response.
• CVE-2026-106069 and CVE-2026-105483: the TLS certificate hostname check can be bypassed. A Node client could accept a valid certificate issued for a different domain.
• CVE-2026-105482: dns.resolve truncates names that contain a NUL character.

Fixed versions: v26.12.1, v24.22.1 and v22.23.4. Node 20 and 25 are end-of-life and get no patch: if you are still on them, the fix is a major-version upgrade. No exploitation has been reported. If you are on 20 or 25 and would rather not do the jump yourself, see Node.js security patch.

node --version
# in Docker, the base image is what counts:
docker run --rm your-image node --version

NGINX: a busy year

NGINX has had several batches of advisories in 2026. In May came CVE-2026-42945, “NGINX Rift”: DepthFirst’s AI platform found it in about six hours, and the bug dated back to version 0.6.27, released in 2008. nginx.org rates it medium; the Cloud Security Alliance and Help Net Security rate it critical (9.2), and VulnCheck saw exploitation attempts from 16 May. It was fixed in 1.31.0 and 1.30.1.

The October batch adds five more CVEs: CVE-2026-15176, 93479, 95101 (HTTP/3 request smuggling), 97629 (TLS session forgery that skips client certificate verification) and 97205. They are fixed in 1.31.7+ and 1.30.6+. Until you upgrade, nginx.org suggests avoiding $request_filename and alias (15176) and using named captures instead of unnamed ones in regex location blocks (93479). The upgrade and a review of that configuration are covered in NGINX security patch.

nginx -v

GitLab self-managed: CVSS 10.0

On 21 October GitLab published CVE-2026-110264: an integer overflow when compiling a crafted regular expression lets an unauthenticated user run code on the server. It affects CE and EE from version 7.0, released in 2014. GitLab.com and GitLab Dedicated are already patched; self-managed instances must move to 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 or 18.11.13, depending on the branch. As of 22 October there is no known exploitation.

Nine days earlier, on 12 October, GitLab had already patched another 10.0 (CVE-2026-97229, also involving regular expressions in CI/CD) in 19.2.8, 19.3.5 and 19.4.2, and that one has a public PoC. If you skipped it, the new versions on those branches include that fix too. To have us do the upgrade: update GitLab self-managed.

Why so many old bugs are surfacing

Two of the bugs on this list had been around for more than a decade: GitLab’s since 2014 and NGINX Rift since 2008. For NGINX we know how it was found: an AI tool took about six hours. FIRST (Forum of Incident Response and Security Teams) expects 2026 to close at around 66,000 CVEs, and attributes part of the rise to AI tools hunting for flaws on their own. The same source notes that another part is bookkeeping (databases cataloguing more and backfilling old records) and that the share of CVEs actually exploited has stayed steady. For a small team, that means the list of advisories to read is growing faster than the list of emergencies, and that a version inventory pays off: it tells you in a minute whether an advisory applies to you.

2. Rotate secrets, in order

Three incidents on the list expose credentials rather than code:

• Railway detected anomalous activity on 21 October in the systems that store its customers’ environment variables. A third party was able to access encrypted variables and in some cases decrypt them. Railway paused all deployments and asks customers to rotate credentials. It has not said how many customers are affected or how the attackers got in.
• LiteLLM 1.107.0, published on 21 October to PyPI and Docker Hub, contains a credential stealer and a remote loader that fires when any Python process on the host starts, not only LiteLLM. The attackers published it with GitHub CLI OAuth tokens stolen from three engineers. The GitHub tag does not contain the malicious code, which only lives in the published packages. It is the second time this year.
• PingCAP reports that between 9 September and 7 October someone used stolen service-account credentials to enter internal systems and copy data and source code: account and project metadata, SQL editor text, billing records and encrypted API key values. There is no evidence of impact on data stored in TiDB. The FulcrumSec group claims 10.6 TB; PingCAP has not confirmed it.

Order matters, because rotating a key on a host that is still compromised just hands the attacker the new key.

1. Contain. For LiteLLM 1.107.0, stop the service and rebuild the host or container from a clean image with the version pinned to 1.106.2 (litellm==1.106.2 in requirements.txt, or the exact image tag, never latest). The loader runs with any Python process, so removing the package alone is not enough.
2. Take inventory. List what lived on that host or in those variables: LLM provider keys, cloud credentials, database passwords, CI tokens, webhooks, payment gateway keys. On Railway, the list is the variables of each service and environment.
3. Start with what opens the most. First, broad-permission credentials (cloud IAM or root accounts, CI/CD and GitHub tokens, database users), then third-party APIs.
4. Issue, deploy, revoke. Create the new credential, deploy it and revoke the old one. With Railway deployments paused, revoking before you can update the variable leaves the service down until they resume; for payment or cloud keys, a short outage costs less than leaving a leaked key alive.
5. Check how the old key was used. Review the provider’s access logs (CloudTrail, the API dashboard, database logs) from the day of the incident.

If your services keep credentials in a secrets manager instead of hand-typed variables, step 4 gets much shorter. It is one of the things we review in cloud and DevOps projects and when designing APIs that depend on third-party keys. If you would rather we handle the rotation, see exposed API keys and secret rotation.

3. Certificates: GoDaddy and eMudhra

GoDaddy revoked 404,607 TLS certificates from its GoDaddy and Starfield hierarchies on 21 October because the policy OIDs and CPS URI in those certificates did not match its published CPS (Mozilla Bug 2082703). No keys were stolen; the problem is that a site with one of those certificates can stop loading if it does not install the replacement.

eMudhra, an Indian CA, generated eight TLS intermediate CA certificates with weak keys in April 2025 because of a flaw in its key generation ceremony, and those keys were recovered from the public certificates. Chrome blocked them, Apple on 19 October and Microsoft on 20 October; Go and Node.js shipped explicit distrust (Node’s 21 October release already rejects those chains). There are no confirmed attacks on users.

To see who issued your certificate and when it expires:

echo | openssl s_client -connect yourdomain.com:443 -servername yourdomain.com 2>/dev/null \
  | openssl x509 -noout -issuer -enddate -serial

• If the issuer contains GoDaddy or Starfield, log into your GoDaddy account, check whether that certificate has a replacement issued and install it on every server, load balancer and CDN that has the old one.
• If your site chains to one of the eMudhra intermediates, Chrome, Safari and Windows no longer accept it and you need a certificate from another CA. To see the full chain, intermediates included, look for eMudhra in the i: (issuer) lines of this output:

echo | openssl s_client -connect yourdomain.com:443 -servername yourdomain.com -showcerts 2>/dev/null \
  | grep -E '^ *[0-9]+ s:|^ *i:'

• The case most people miss is outbound: a Node or Go service of yours that calls an API signed by those intermediates will start failing with a TLS error after you upgrade. If certificate errors appear on outbound calls after the Node patch, run the same command against the domain you are calling.

If you would rather not do it yourself

At Soamee we do this work for the projects we maintain: version inventory for PHP, Node, NGINX and GitLab; immediate mitigation where an upgrade is not yet possible; upgrade and verification; a review for signs of compromise; secret rotation in the order above and certificate replacement. Nobody can make a server impossible to breach, so we do not promise that. What you get is a record of which version you run, what was changed and what is still pending.

If you run servers or deployments and are not sure whether any of these eight advisories affects you, tell us in a free consultation or write to us via contact.

Sources

• PHP: php.net · Rapid7 · Huntress · NCSC
• Node.js: October 2026 Security Releases
• NGINX: nginx security advisories · CSA Research Note on CVE-2026-42945 · Help Net Security, 18 May 2026
• GitLab: Critical Patch Release 19.5.1 · The Hacker News on CVE-2026-97229
• Railway: The CyberSec Guru
• LiteLLM: Wiz
• PingCAP: Security update, October 2026
• GoDaddy: CyberPress
• eMudhra: The Hacker News
• 2026 CVE forecast: Help Net Security, 15 June 2026