In December 2021, Log4Shell gave the security industry a shocking Christmas present. Five years later, the security scene makes Log4Shell look like a relaxing afternoon.

October 2026 brought us PHP2Shell, Node2Shell, and a poisoned LiteLLM release. Well, also a GitLab CVE, and an NGINX CVE, and an OpenCode CVE—you get the picture. Actually, we had more high and critical CVEs in October 2026 than we had in the whole of 2021.

Docker Security Dispatch 8

Welcome to Docker Security Dispatch 8, reviewing October 2026. This month: two shells, a compromised release pipeline, the growing gap between exploitation and patching, and some Docker commands to help us survive the next security apocalypse.

Plus, some discount codes for books, a meetup in the Black Forest, my adventures at BaselOne, and a trip to J-Fall! 🐳

Key takeaways

  • October brought 17,013 CVEs, including 8,059 High and Critical findings.
  • Patch PHP and Node.js; investigate and rotate exposed credentials after LiteLLM compromise.
  • Rebuild, redeploy, verify—and limit what a compromised workload can reach.

In This Issue

🎁 Discounts: Books Before the Bugs

Time to get some security books?

Prefer paper? Docker and Kubernetes Security is also available in paperback on Amazon.

Books in the woods of the Black Forest

Unfortunately, purchasing a security book does not automatically patch your production containers. I've checked. 😅

🌋 The CVE Avalanche: October 2026 vs. 2021

Remember Log4Shell?

CVE-2021-44228 affected Apache Log4j, a widely used Java logging library, and could allow remote code execution (RCE).

It wasn't just about patching one library. Organizations had to find Log4j buried inside applications, dependencies, and products they didn't even realize contained it.

Then people started to talk about SBOMs. And Docker added the docker sbom command. The command has since been removed and replaced with:

docker scout sbom --format list <image> 

Now, consider October 2026.

CVE publication trends

According to CRACI's CVE publication statistics, the numbers were:1

Period Published CVEs High + Critical CVEs
Entire 2021 19,862 4,324
October 2025 4,235 1,706
October 2026 17,013 8,059

Of October's findings, 6,536 were High and 1,523 were Critical, for a combined 8,059. That's nearly twice as many High and Critical CVEs as in all of 2021, using CRACI's recorded severity scores. Many older records lack scores, so this isn't a like-for-like measure of risk.

Every time a CVE is published, the defenders are notified as well as the attackers. Then it's a race.

⏱️ Time to Patch: A Race Against Time

How long does it take to patch a vulnerability?

A patch has to travel a long way before it protects production: identify the affected application, update its dependencies, rebuild, test, deploy, and verify.

For example, with PHP2Shell, first update the PHP base image:2

FROM dhi.io/php:8.4.27-fpm 

Then rebuild and redeploy (assuming you use Compose):

docker compose build --pull --no-cache docker compose up -d --force-recreate 

Then verify:

docker compose exec <service> php -v # or docker scout sbom <image> --format list | grep -i php 

Each step takes time. An attacker only needs a reachable weakness.

Time to patch measures the defender's remediation work. Time to exploit measures when attackers start exploiting a vulnerability relative to patch availability. Google's M-Trends 2026 research shows how far that window has shifted:

Year Mean time to exploit
2018 63 days
2024 −1 day
2025 −7 days (estimated)

A negative value means exploitation began, on average, before a patch was released, for the vulnerabilities studied.3

Even immediate patching can leave us behind. Prepare to contain an attacker as well as patch the bug.

🐚 PHP2Shell and Node2Shell: Two Shells in One Day

The 21st of October was a particularly interesting Wednesday for software engineers. We had RCE risks in two different ecosystems.

These RCE exploits were not the first and will not be the last. And, as the trend suggests, we will see more of these nice CVEs in the near future. And, as the time to exploit suggests, we are already vulnerable before there is a published patch. So, what to do?

We can try and reduce the blast radius with minimal images, rootless execution, and fewer tools. No shell doesn't mean no RCE; the runtime still needs its patch.

If you still have not patched your PHP, check this walkthrough:

how-to-fix-php2shell

For Node2Shell, update the Node.js runtime too. On the 24.x branch, the fix released on the 21st of October was 24.22.1:

FROM node:24.22.1 

Rebuild the image with no cache, redeploy, and check the version:4

docker compose exec <service> node --version 

We will get back to reducing the blast radius.

☠️ LiteLLM: When the Release Pipeline Is the Attacker

On the 21st of October, LiteLLM's release pipeline shipped credential-stealing malware in litellm==1.107.0 and official images tagged v1.107.0, latest, main-latest, and main-stable.5 Remember Issue 6's malicious package with valid provenance? Here we go again.

If affected code ran: isolate, investigate, revoke or rotate accessible credentials, and rebuild from verified clean inputs. Work from a clean environment: starting Python or pip in the affected one could retrigger the malware. Check digests and exposure windows in the full incident report; cached artifacts remain dangerous after registry removal.6

🐳 Docker News

  • Sandboxes, v0.48–v0.50.1: Kits v3 gained capability groups, bundled skills, Git identity and SSH signing; later releases added persistent kit volumes, configurable host mounts, cloud inspection, and tighter host/credential protections.7 v0.50.1 fixes sandbox startup.8 Even the sandbox needs maintenance.
  • Desktop security: 4.97.0 fixes CVE-2026-99999, where malformed IPv4 checksum metadata could corrupt the VM network stack, and CVE-2026-114409, which exposed third-party credentials in logs/diagnostics. Update and sanitize retained diagnostic copies.9
  • eMudhra: Compromised CA keys could enable service impersonation. Docker refreshed sandbox templates, but updating sbx alone doesn't fix existing sandboxes: refresh their images or CA stores and restart applications.10
  • DHI's busy week: Following PHP2Shell/eMudhra, Docker ran 16,567 package and image builds in 48 hours. The rebuild report explains the trust-store updates.11 That's a lot of coffee for a build system.

🛡️ What Can We Actually Do? Big Picture.

We cannot manually review 17,000 CVEs every month.

Fortunately, we don't need to.

Start with what your application actually ships and what attackers can reach.

1. Find the Actionable CVEs

Docker Scout can narrow the vulnerability list to fixable High and Critical findings:12

docker scout cves \ --only-fixed \ --only-severity critical,high \ <image> 

To look specifically for vulnerabilities listed in CISA's Known Exploited Vulnerabilities catalog:

docker scout cves \ --only-cisa-kev \ <image> 

The first view hides findings without fixes; the second highlights known exploitation. Neither is your complete risk inventory.

2. Rebuild, Don't Just Update the Dockerfile

After updating your vulnerable dependencies and base image:

docker build --pull --no-cache \ -t <image> . 

Then scan the resulting image, run your tests, deploy it, and verify the runtime in production.

A patched Dockerfile sitting in Git does nothing for an old container still running in production.

3. Reduce the Damage Before the Next CVE

My Security Immediate Plan (SIP) covers agent isolation, dependency cooldowns, hardened builds, attestations, and vulnerability gates. For prevention, run your coding agent in a sandbox:

sbx policy init deny-all sbx policy ls sbx run --clone opencode . 

Sandboxing keeps the AI agent and malicious packages away from your host files, except for the ones you mounted into it. Secrets are injected into the requests without the agent having access to them. And exfiltration of the secrets can be blocked using network policies.

🐳 Community Spotlight

The Docker community has been very busy over the past month as well. I think we owe it to the awesome Mexican food:

Faeka Ansari shares her first Docker Captains Summit experience in Mexico: handwritten welcome letters, community connections, and why agent permissions belong outside the agent. Come for the Caribbean sunrise, stay for the security boundaries. Check if you can spot my face in the article.

Nick Janetakis takes us through Docker Captain's Summit in Mexico, with friendships, behind-the-scenes moments, and enough group photos to test a camera's horizontal scaling.

Back at the terminal, Ajeet Raina at Collabnix walks through What's New in Docker Sandboxes Kits v3 (v0.48.0), building a mixin with bundled skills, Git identity, and scoped SSH signing. Even the agent needs to learn that borrowing your keys doesn't mean borrowing the whole house.

And Matteo Bisi brings an OVHcloud CLI Supply Chain Compromise user playbook: check exposure, isolate, rotate credentials, and verify what you rebuild. The source was clean; the release binaries weren't. Apparently, reading the recipe doesn't tell you who poisoned the coffee.

Docker's The CVE That Did Not Exist, by Ajeet Singh Raina and Pratik Singh, follows a review bot inventing a vulnerability and recommending drastic remediation. We already have 17,000 CVEs. Please stop generating DLC.

Çiğdem Kadakoğlu explores Docker Sandboxes: Local vs Cloud, explaining where your agents run, what sbx move actually transfers, and why your secrets and network policies don't automatically follow. Well, this article is in Turkish, but we're working on an English piece on sbx cloud, and it's only fitting since she was writing on the plane. ✈️

Written something the Docker security community should read? Send it my way for DSD 9. Practical lessons, experiments, and stories welcome. Bonus points if the coffee survives. ☕

🎙️ Recent Work

☕ SIP for Java: Coming to JAVAPRO

I teamed up with Catherine Edelveis to write SIP: Security Immediate Plan for Java, a collaborative piece that will be published in JAVAPRO.

Five practical controls, from AI agents and Maven/Gradle inputs to hardened images and release checks—with a Spring Boot example.

sip-for-java

🐳 Hackdockerfest in Freiburg: Worms, Python, and AI Agents

On the 27th of October, Docker Freiburg and Black Forest teamed up with the Python User Group Freiburg for Hackdockerfest at JobRad. I helped organize the evening and presented the Security Immediate Plan for Python.

Docker Captain Marco Franzon covered SBX and AI Agent Activity Tracking and shared his token-consumption tracking resources.

Check the resources here.

A group selfie with smiling attendees seated on wooden tiers at JobRad.

🇨🇭 BaselOne: Securing Java in Asgard

On the 15th of October at BaselOne, the Commandos defended Java in Asgard—here's the practical Spring Boot companion article.

🇳🇱 Coming Up: J-Fall 2026!

I'll be at J-Fall in Ede, the 11th–12th of November as a room host—find the red fedora and say hello! 🎩

Until Next Time

Two shells, a poisoned release, and 17,000 CVEs. Hopefully, we won't get a third shell in November; otherwise we will have to learn how to use the three seashells!

Also, remember, remember: tomorrow is the 5th of November, so harden your images before that Guy gets into your containers.

  1. CRACI. CVE Publication Trends. Publication-date statistics, October 2026. ↩

  2. NCSC-NL. PHP2Shell Operational Information. ↩

  3. Google Cloud. FinOps for SecOps: How to Optimize the Agentic SOC for Value. Cites M-Trends 2026 mean time-to-exploit figures; the 2025 figure is an estimate. ↩

  4. Node.js Project. Security releases of the 21st of October 2026. ↩

  5. LiteLLM. The Attack Chain Behind the v1.107.0 Release. ↩

  6. LiteLLM. Incident report for the 21st of October 2026. Affected artifacts, exposure windows, and remediation guidance. ↩

  7. Docker Docs. Docker Sandboxes Release Notes. ↩

  8. Docker. Sandboxes v0.50.1 Release. ↩

  9. Docker Docs. Docker Desktop 4.97.0 Release Notes. ↩

  10. Docker Docs. Docker Sandboxes Response to eMudhra CA Compromise. ↩

  11. Docker. PHP2Shell and eMudhra Patched. ↩

  12. Docker Docs. Docker Scout CVE Command Reference. ↩