Four of the most-used stacks on the internet got hit in the same week. PHP, Node.js, GitLab and LiteLLM all shipped critical fixes or suffered a serious incident between Oct 12 and Oct 22, 2026.
If you run a PHP site, a Node.js backend, a self-hosted GitLab or anything that talks to LLMs through LiteLLM, this guide gives you the short version: what broke, am I affected, and what to run.
That's how my Friday felt. Let's go one by one.
1. PHP2Shell: PHP vulnerability CVE-2026-109618 and CVE-2026-109619
Severity: CVSS v4.0 9.2 (both). Impact: unauthenticated remote code execution.
The bugs are in PHP core, not in WordPress or any plugin. Wiz Research, who reported them, says even a bare "Hello World" on a vulnerable version can be exposed, and showed working chains against stock WordPress, Drupal and Joomla images. The trigger is a request that hits memory_limit at the wrong moment, leaving stale memory for the next request on the same worker.
Fixed in (released Oct 21):
| Branch | Fixed version |
|---|---|
| 8.5 | 8.5.12 |
| 8.4 | 8.4.27 |
| 8.3 | 8.3.36 |
| 8.2 | 8.2.35 |
PHP 8.1 and older get no patch. You need a branch upgrade. (PHP 8.2 security support also ends Dec 31, 2026, so plan that move now.)
Is it being exploited? Several vendors, including Patchstack, Cloudflare and Aikido, reported attack attempts around the release, and public PoCs are circulating. Assume scanners are already hitting you.
Fix it:
php -v # host
docker run --rm php:8.4-cli php -v # after a fresh pull: want 8.4.27+
- Upgrade to the version in the table, then rebuild your Docker images. A patched host does not fix a stale container.
- On shared hosting, ask your provider to confirm they've patched.
- Can't patch today? Put a WAF in front. Several CDNs shipped stopgap rules. Treat it as a bridge, not a fix.
- Watch logs for memory-limit errors followed by bursts of HTTP 500s and oddly large
PHPSESSIDcookies.
2. Node.js security release: Brotli RCE (CVE-2026-111497) and 9 more
Severity: 4 high, 3 medium, 3 low. Headline: an out-of-bounds write in the Brotli decoder that Node.js says allows remote code execution. Imperva researchers reportedly turned it into real code execution.
Fixed in (released Oct 21): 22.23.4, 24.22.1, 26.12.1.
The four high-severity ones:
| CVE | Problem |
|---|---|
| CVE-2026-111497 | Brotli decoder out-of-bounds write |
| CVE-2026-105482 |
dns.resolve cuts names at a NUL character |
| CVE-2026-106069 | TLS hostname bypass using odd IP formats like 0127.0.0.1
|
| CVE-2026-105483 | TLS hostname bypass using fullwidth digits (24.x, 26.x) |
Am I exposed? (per Konfirmity's reading of the fix commits, not official Node.js guidance)
- You decompress Brotli data you don't control (
Content-Encoding: brbodies,zlib.brotliDecompress). The built-infetchalso asks for Brotli by default. - You validate user-supplied hostnames with string checks, then call
dns.resolve. - You open TLS connections to addresses users can influence (webhooks, link previews). Fix it:
node -p "[process.version, 'undici ' + process.versions.undici].join('\n')"
docker run --rm node:24 node --version # want v24.22.1+
- Upgrade, then rebuild images and any single-executable apps (they embed their own Node).
- Using the
undicinpm package directly? Upgrade it separately. - Node 20 and older are end-of-life: no fix is coming. Move to 22 or 24.
- On AWS, don't assume. Lambda container images and pinned runtimes never update themselves.
3. GitLab critical RCE: patched on Oct 12? You're still vulnerable
Severity: CVSS 10.0, twice in ten days. Unauthenticated remote code execution on self-managed GitLab.
- Oct 12, CVE-2026-97229: fixed in 19.4.2 / 19.3.5 / 19.2.8. Rapid7 reproduced code execution within a day.
- Oct 21, CVE-2026-110264: a separate regex-engine overflow. Those Oct 12 versions do not fix it. Upgrade to:
| You run | Go to |
|---|---|
| 19.5 | 19.5.1 |
| 19.4 | 19.4.3 |
| 19.3 | 19.3.6 |
| 19.2 / 19.1 / 19.0 / 18.11 | 19.2.9 / 19.1.9 / 19.0.10 / 18.11.13 (critical fix only) |
| 18.10 and older | No fix. Move to a supported version |
Good to know before you start:
- Only 19.4.3 and 19.3.6 include database migrations, so a single-node instance is down until they finish.
- 19.3.6, 19.4.3 and 19.5.1 also fix 11 other bugs, including SAML/LDAP account takeover. The older backports only carry the critical fix.
- GitLab.com and Dedicated are already patched. There is no official workaround for self-managed.
- GitLab published Sigma detection rules (TLDR repo). If you find a hit, rotate CI/CD variables, runner tokens and deploy keys held on that server.
4. LiteLLM supply chain attack: the poisoned 1.107.0 release
This one is not a CVE. Someone hijacked the release pipeline and published malware under the real package name.
What happened (Oct 21, UTC):
- A malicious
litellm==1.107.0hit PyPI at about 11:39 (all 7 wheels) and was pulled at 13:23. - Docker tags
1.107.0,latest,main-latestandmain-stablewere bad from about 11:46 to 14:20. - LiteLLM says the attacker used three engineers' GitHub accounts, likely via stolen GitHub CLI OAuth tokens. Enterprise private releases were not affected.
What the malware does: a credential stealer that runs at Python startup (so it fires even if you never import
litellm) plus a loader that fetches more code hourly. It goes after cloud keys, SSH keys, env vars, browser data, AI provider keys and the LiteLLM proxy database. This is the project's second compromise this year, per Help Net Security.
Step 1: Am I affected?
Run this on every dev machine, CI runner and server that might have pulled LiteLLM:
# Installed version in the current environment
pip list 2>/dev/null | grep -i '^litellm '
# Any copy of 1.107.0 anywhere on disk (venvs, site-packages)
find / -type d -name 'litellm-1.107.0*' 2>/dev/null
# Docker images
docker images --format '{{.Repository}}:{{.Tag}} {{.ID}}' | grep -i litellm
# Lockfiles and requirements in your repos
grep -rn "litellm" --include='requirements*.txt' --include='poetry.lock' \
--include='uv.lock' --include='Pipfile.lock' .
You're affected if any of these show 1.107.0, or a litellm Docker image you pulled on Oct 21.
Step 2: If yes, treat it as a breach
- Don't just downgrade. Rebuild the machine, container or runner from a clean base.
- Rotate every secret that environment could reach: cloud credentials, SSH keys, LLM provider API keys, database URLs, GitHub tokens.
- Check logs and egress for traffic to the
litellm[.]dev"healthcheck" address reported by researchers. - Reinstall the clean version, 1.106.2, in a fresh environment. ### Step 3: If no, stay that way
pip install litellm==1.106.2 --require-hashes -r requirements.txt
Pin exact versions with hashes, and wait a few days before adopting brand-new releases of critical dependencies.
Also this week
- Plex2Shell: four chained Plex Media Server bugs, reported as actively exploited.
- eMudhra CA keys: weak randomness in eight subordinate CA keys. Chrome, Android and Node.js now distrust the affected chains. If your certificates chain through eMudhra, plan a migration.
- Arista VeloCloud Orchestrator (CVE-2026-114625): critical SQL injection, CVSS 3.1 of 9.9.
- Microsoft Patch Tuesday: a record of roughly 1,400 CVEs, plus one exploited Windows Shell zero-day.
Quick FAQ
Which PHP versions fix PHP2Shell?
8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1 and older get no fix.
Which Node.js versions fix the Brotli RCE (CVE-2026-111497)?
22.23.4, 24.22.1 and 26.12.1. Node 20 and older are end-of-life and unpatched.
I patched GitLab on Oct 12. Am I safe?
No. CVE-2026-110264 needs 19.4.3, 19.3.6 or 19.5.1.
Which LiteLLM version was malicious?
1.107.0 (PyPI wheels and Docker images). Go back to 1.106.2 and rotate your secrets.
The 30-second checklist
- Find every runtime: servers, containers, CI images, forgotten staging boxes.
- Upgrade and rebuild images.
- Move off end-of-life PHP, Node and GitLab versions.
- Pin dependencies with hashes.
- If LiteLLM 1.107.0 ever ran, rotate secrets first, ask questions later. Did this week hit your stack? Tell me in the comments what you patched, and I'll keep this post updated as new details land.
Top comments (0)