This Week’s Security Mess, Explained for Developers: A 30-Minute Patch Checklist

Last week's security news was loud: PHP2Shell, HTTP2Shell, Plex2Shell, a CVSS 10 GitLab bug, a certificate authority quitting, and a poisoned AI library. Headlines tell you what happened. This post is the developer version: what to actually check on your laptop, servers, containers and CI, with the commands to do it in about 30 minutes.

If you want the full news story of the week, I've covered every item, with fixed versions and context, in the ByteMuni cybersecurity weekly recap for October 19–26, 2026. Here, I want to focus on the hands-on part, because that's what usually gets skipped.

Why does a "news week" like this matter to developers?

Because almost none of last week's problems were in code that developers wrote themselves. They were in:

• runtimes (PHP, Ruby)
• libraries we never chose directly (Brotli, Onigmo, Pillow)
• packages we trust (LiteLLM)
• platforms we deploy to (Railway)
• tokens we forgot we issued (GitHub tokens abused in the Gheist campaign)
• certificates we never think about (eMudhra)

Your app's own code can be perfect and you can still be exposed. Security in 2026 is mostly about knowing what you depend on and updating it quickly. Rapid7's latest quarterly report says the average gap between a high-severity bug going public and being exploited is now about three days. "We'll patch next sprint" doesn't work anymore.

So here's a practical checklist, ordered by how urgent each item is.

Step 1: Is your PHP actually patched?

PHP2Shell (CVE-2026-109618 and CVE-2026-109619) can allow code execution without logging in. The fixed releases are 8.5.12, 8.4.27, 8.3.36 and 8.2.35.

The common mistake is checking the wrong PHP. The command-line PHP and the PHP that serves your website (PHP-FPM or an Apache module) can be different installs:

# CLI version
php -v

# FPM version (binary name varies by distro, e.g. php-fpm8.3)
php-fpm -v

# What the web server really runs: create a temporary file, open it, then DELETE it
echo '<?php echo PHP_VERSION;' | sudo tee /var/www/html/v.php
# visit https://your-site/v.php, then:
sudo rm /var/www/html/v.php

Things to keep in mind:

• WordPress and plugin auto-updates do not update PHP. They update PHP code, not the PHP runtime underneath.
• Distribution packages use their own version numbers. Debian or Ubuntu may backport the fix without changing to 8.x.y, so check your distro's security tracker instead of comparing version strings.
• Docker images such as php:8.3-fpm need a fresh pull and rebuild. A running container never updates itself.
• On PHP 8.1 or older, you're past routine upstream support. Plan the upgrade now.

Step 2: Do you have a vulnerable Brotli hiding somewhere?

HTTP2Shell (CVE-2026-111497) is a bug in the Brotli decompression library. It's the most "hidden dependency" problem of the week, because Brotli is built into many runtimes, so it shows up in places you wouldn't expect.

# Node.js: fixed in 22.23.4, 24.22.1, 26.12.1
node -v

# Bun: fixed in 1.4.4
bun --version

# Python packages: fixed in Brotli 1.2.1 and brotlicffi 1.2.1.0
pip show brotli brotlicffi 2>/dev/null | grep -E "Name|Version"

# Debian/Ubuntu system library
dpkg -l | grep -i brotli

The trap here is containers. Updating your laptop doesn't fix a Docker image built two months ago. After updating base images, rebuild without the cache so the fixed layers are really used:

docker build --pull --no-cache -t my-app:patched .

If you run Envoy as a proxy or service mesh sidecar, check its security advisory too.

Step 3: Did you install the poisoned LiteLLM?

LiteLLM 1.107.0 was a malicious release. It added a file called cook.pth. Python automatically runs .pth files in site-packages at startup, so the malware ran even if your code never imported LiteLLM. It stole cloud tokens, keys, AI tool credentials, browser data and environment variables, and left a backdoor that checked for new commands every hour.

Check every environment you use, including virtualenvs, CI runners and Docker images:

# Which version is installed?
pip show litellm 2>/dev/null | grep Version

# Look for the malicious startup file in site-packages
python -c "import site; print('\n'.join(site.getsitepackages()))" |
while read -r d; do ls "$d" 2>/dev/null | grep -i "cook.pth" && echo "FOUND in $d"; done

If you find 1.107.0 or cook.pth:

1. Treat that machine or container as compromised.
2. From a clean machine, rotate every credential it could reach: cloud keys, API keys, database passwords, GitHub tokens.
3. Reinstall with a pinned safe version: pip install "litellm==1.106.2".

This is a good moment to start pinning dependencies with hashes in production (pip install --require-hashes -r requirements.txt), so a surprise new release can't slip in.

Step 4: Are your secrets still secret?

Two of last week's stories were about leaked secrets, not bugs.

If you deploy on Railway

Railway disclosed that an attacker may have accessed customers' encrypted environment variables, and decrypted some of them. Railway asked users to rotate all environment variables, review service logs, and recreate CLI and CI credentials. Do this even if you haven't been emailed.

If you use GitHub Actions

The Gheist campaign used stolen GitHub tokens to push branches named ci-sync- followed by six random characters. Each added a workflow that printed the repo's secrets into the Actions log in base32, so GitHub's masking didn't hide them. Then the attacker downloaded the log and deleted the run. GitHub's new approval hold blocked it in public repos, but not in private repos or GitHub Enterprise Server.

A quick check for a repo you have cloned:

git ls-remote --heads origin | grep -E 'refs/heads/ci-sync-[0-9a-z]{6}$'

No output is a good sign, but the attacker may have deleted the branch, so also check your organisation's audit log. If you find one, rotate every secret that repo could read. Deleting the branch doesn't undo the leak.

Longer term:

• Put production secrets behind GitHub environments with required reviewers.
• Switch cloud deploys to OIDC with trust limited to specific environments or branches.
• Replace old personal access tokens with fine-grained, short-lived ones or GitHub Apps.

Step 5: Is your self-hosted tooling up to date?

Several tools developers often self-host had serious issues:

• GitLab (CVE-2026-110264, CVSS 10): an integer overflow in regex compilation could allow unauthenticated code execution. Upgrade to 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 or 18.11.13. Check your version with sudo gitlab-rake gitlab:env:info. GitLab.com is already protected.
• Ruby: the root cause was in Onigmo, Ruby's regex engine. Ruby released 4.0.9, 3.4.12 and 3.3.13. Check with ruby -v.
• Plex Media Server (Plex2Shell): four chained bugs are being actively exploited to install cryptominers. Update to 1.43.3.10861 or later, and don't expose it to the internet if you don't need to.
• MeshCentral: the developer warned of an active attack and urged an update to 1.3.1.
• Collabora Online CODE for Nextcloud and Arista VeloCloud Orchestrator: both actively exploited and added to CISA's Known Exploited Vulnerabilities list. Collabora's fix is in 26.4.303.
• Pillow: if your Python app processes uploaded images, update to 13.0.0.

Home labs count too. A forgotten Plex box or old GitLab instance on your home network is just as attractive to attackers as a company server.

Step 6: Does your system still trust a broken certificate authority?

Eight intermediate CA certificates from eMudhra were found to use absurdly weak private keys, small enough to recover in under a second. Browsers and Apple blocked them, and eMudhra is leaving the TLS certificate business.

Browsers update themselves. Your code often doesn't. Python's certifi bundle, used by requests and many other libraries, has been updated to remove the eMudhra root:

pip install -U certifi

# Should print 0 after updating
grep -c "emSign" "$(python -c 'import certifi; print(certifi.where())')"

pip, uv, conda, pixi and sigstore also shipped updates. Old Docker images, embedded devices and servers that never update their CA store are where this lingers.

Step 7: What about the bugs with no patch yet?

Two issues still had no released fix at the time of writing.

Linux KSMBD

Two CVSS 9.0 remote code execution flaws in KSMBD, the kernel's built-in SMB server, were published before fixes existed. The good news: KSMBD isn't enabled by default on most distributions. Check:

lsmod | grep ksmbd

# If it's loaded and you don't need it:
sudo systemctl disable --now ksmbd 2>/dev/null
sudo modprobe -r ksmbd
echo "blacklist ksmbd" | sudo tee /etc/modprobe.d/disable-ksmbd.conf

If you do need it, make sure port 445 isn't reachable from the internet.

Tailscale SSH

The "Tailworm" research describes how, in a lab, one compromised device could use Tailscale SSH port forwarding to gain root on other servers. Tailscale says it's working on fixes. Until then, use narrow SSH rules (one source to one destination), avoid allowing root, and disable Tailscale SSH on machines that don't need it (tailscale set --ssh=false, after making sure you have another way in).

What about AI agents and AI tools?

Last week also showed how AI is changing security on both sides:

• CrowdStrike documented attackers using AI coding agents to run real intrusions, lowering the skill needed to attack.
• A malicious AGENTS.md file was used to trick an AI coding agent into installing a rogue npm package. Instruction files that agents trust are now an attack surface.
• A hospital had to notify thousands of patients after an employee uploaded patient data to an unapproved AI tool.

Practical habits for developers using AI tools:

• Review what your coding agent is about to install or run, especially new packages.
• Don't let agents auto-approve shell commands in folders containing downloaded files.
• Never paste secrets, customer data or production logs into AI tools your company hasn't approved.
• Give agent tools the minimum permissions and tokens they need.

How do you know if you were already hit?

Patching closes the door, but it doesn't tell you whether someone already walked through it. A few quick signs worth checking on servers that were exposed before you patched:

• Unexpected CPU usage: Plex2Shell attackers dropped cryptominers. Look for processes you don't recognise using a lot of CPU (top or htop).
• New files in web directories: after a PHP code-execution bug, attackers often leave a small PHP "web shell". Look for recently changed .php files, for example find /var/www -name "*.php" -mtime -10, and review anything unfamiliar.
• New users, SSH keys or cron jobs: check /etc/passwd, ~/.ssh/authorized_keys and crontab -l for each user.
• Unusual outbound connections: ss -tunp shows active connections and which process owns them. A web server talking to an unknown IP on a strange port deserves a look.
• Cloud and API usage spikes: stolen keys often show up as unexpected bills, new cloud instances, or AI API usage you can't explain. Check billing dashboards and provider audit logs.

If anything looks wrong, don't just delete the suspicious file. Take a snapshot for investigation, rotate credentials from a clean machine, and rebuild the server from a known-good image.

How can you make next week less stressful?

Checklists help once. Habits help every week:

1. Keep an inventory. Know which runtimes, base images and self-hosted tools you run. An SBOM (software bill of materials) generated in CI makes "are we affected?" a search instead of a guess.
2. Automate dependency updates. Tools like Dependabot or Renovate open PRs for you. Merge security updates fast.
3. Rebuild images regularly, even when your code doesn't change, so base-image fixes actually land.
4. Pin and verify. Lock files with hashes stop surprise releases like LiteLLM 1.107.0 from slipping in.
5. Make secrets short-lived. OIDC, short-lived tokens and regular rotation turn a leak into an inconvenience instead of a breach.
6. Subscribe to advisories for what you run: PHP, Node.js, GitLab, your Linux distro, CISA's KEV catalog. Or read a weekly recap.
7. Practise patching without downtime. If updating PHP or Node means a scary maintenance window, fix that process before the next emergency.

Your 30-minute checklist

• PHP runtime (CLI and FPM) on 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35, or your distro's patched package
• Node.js, Bun and Python Brotli packages updated; Docker images rebuilt with --pull --no-cache
• No LiteLLM 1.107.0 or cook.pth anywhere; pinned to 1.106.2
• Railway environment variables rotated, if you use Railway
• No ci-sync-* branches; production secrets behind environment reviewers
• GitLab, Ruby, Plex, MeshCentral, Collabora and Pillow updated where used
• certifi and other CA bundles updated
• KSMBD disabled if unused; Tailscale SSH rules narrowed

For the full story behind each item (who found it, what's being exploited and what's still unpatched), read the complete cybersecurity weekly recap on ByteMuni.

Stay patched, and rotate that secret you've been meaning to rotate.