{"slug": "docker-security-dispatch-issue-3-zurich-worms-and-the-ai-frontier", "title": "Docker Security Dispatch — Issue 3: Zurich, Worms, and the AI Frontier 🏔️", "summary": "Docker Security Dispatch Issue 3 reports on major supply chain incidents including the TanStack and Nx Console compromise, the persistence of the Mini Shai-Hulud npm worm, and a kernel-level container breakout vulnerability CVE-2026-31431. The issue also covers a talk at DevOpsDays Zurich advocating that SBOMs are receipts, not shields, and recommends using Docker Sandboxes for untrusted code.", "body_md": "Welcome to the third issue of **Docker Security Dispatch**, written on the beautiful island of Mallorca. May was the month to conquer SBOMs and move beyond them. It was a rollercoaster of supply chain incidents, security research, and operational AI news.\n\nWe had a major supply chain cascade through **TanStack** and **Nx Console**, the long tail of Mini Shai-Hulud kept showing up in developer environments, Docker had to respond to a kernel-level container breakout class, and I brought the Commandos on stage at **DevOpsDays Zurich**.\n\nNot a quiet month, then.\n\nOn **May 6**, I was at **DevOpsDays Zurich 2026** with my talk: **Beyond SBOMs: The Future of Container Supply Chain Security**:\n\nThe main point was simple: an SBOM is a receipt, not a shield.\n\nI had a checklist at the end of the talk, which was photographed a few times, so here it is in text form:\n\n`--ignore-scripts`\n\n.If you want more context, some Swiss German, or perhaps a discount code, watch the full talk.\n\nThe largest supply chain story of May was the chain from the **TanStack npm compromise** to the **Nx Console compromise**. Quick context if, like me, you don't spend every day inside the frontend tooling universe:\n\nThe short version: attackers abused CI/CD trust boundaries, poisoned a package-manager cache, waited for a privileged release workflow, and ended up publishing malicious packages and extension releases. The uncomfortable part is that some of the malicious packages still looked like they came from a legitimate publishing path, because the attacker got hold of valid short-lived credentials during the build.\n\nTo learn more, read the postmortems:\n\nIn Issue 2, I wrote about **Mini Shai-Hulud**, the NPM supply chain worm that arrived on my birthday. The worm even ended up in my Zurich talk's slides and raised some copyright concerns!\n\n**Context**. *Shai Hulud* is the giant sandworm from the Dune universe. The phrase \"shai hulud\" can be read through Arabic as \"شيء خلود\" (shay' khulud), meaning \"eternal thing\". In my slides, a Persian poet is riding the worm, because Hafez was known as *Lissan al-Gaib* (\"the tongue of the unseen\") long before Paul Atreides took the name in Dune.\n\nThe real lesson was persistence in the developer inner loop.\n\nMini Shai-Hulud abused the **Bun runtime** to step around Node-focused security tooling. More importantly, it planted hooks in places developers trust:\n\n`.vscode/tasks.json`\n\nwith `\"runOn\": \"folderOpen\"`\n\n`.claude/settings.json`\n\nwith `SessionStart`\n\nThat means removing `node_modules`\n\nis not enough. If the repository itself has been modified, the infection can come back when someone opens the folder or starts an AI coding session.\n\nSo the practical reminder for June:\n\n```\nrg -n \"runOn|folderOpen|SessionStart|bun|curl|wget\" .vscode .claude package.json .github\n```\n\nAnd for untrusted repositories or AI-agent work, keep using isolation. Docker Sandboxes are a very natural fit here because the agent can inspect, build, and run code without turning your host machine into the place where every experiment gets to execute freely.\n\n```\nsbx run claude\n```\n\nThey say to kill the Shai-Hulud, put it in a box of sand and pour water on it. I still like that line.\n\nFunny enough, I had already written about a small Shai Hulud before Mini Shai-Hulud was a thing. My JAVAPRO article **\"The Whispering JAR: Java Security Lessons Hidden in a Fantasy Tale\"** features a tiny Shai Hulud and covers mitigation practices that map surprisingly well to defending against Mini Shai-Hulud. I should probably start fortune-telling.\n\nThe article is also featured in JAVAPRO's special edition. You can download the PDF edition from JAVAPRO here:\n\nMay was not only about JavaScript packages and IDEs. The container runtime layer had its own moment with **CVE-2026-31431**, also called **Copy Fail**.\n\nHere is the Python-developer version.\n\nLinux has kernel features that user programs can call into, a little like importing a standard-library module. One of those features is `AF_ALG`\n\n, an interface that lets programs ask the kernel to do cryptographic operations. Think: \"please encrypt this buffer for me.\"\n\nCopy Fail was a bug in how the kernel handled one of those crypto operations when the input and output memory overlapped. If you have ever written Python like this:\n\n```\nbuffer = bytearray(b\"important data\")\nview = memoryview(buffer)\n\n# Imagine a buggy low-level function reading and writing overlapping slices.\ncrypto_operation(input=view[0:8], output=view[4:12])\n```\n\nThen you already understand the shape of the problem: the code thinks it is copying or transforming bytes safely, but the read side and write side point into memory in a way the function did not handle correctly.\n\nIn the kernel, that kind of mistake is much more serious than a corrupted Python `bytearray`\n\n. The kernel manages shared caches and host resources. Under the wrong conditions, a low-privileged local attacker could use the bug to write where they should not be able to write. In container terms, that raises the scary question: can a process inside a container influence the host?\n\nDocker published mitigations in Docker Engine, first tightening the default seccomp profile and then adding stronger AppArmor and SELinux coverage for the `alg`\n\nsocket family.\n\nAppArmor and SELinux are covered in my book **Docker and Kubernetes Security**. They are Linux Security Modules that let you write policies to restrict what a process can do.\n\nThe interesting part is not only the CVE. It is the mitigation story.\n\nContainer security works because layers overlap:\n\nWhen one layer has a bad day, the others still matter. Your castle needs outer walls, inner walls, guards, and a moat. Check out the first chapter of **Black Forest Shadow**:\n\nBy the way, **Black Forest Shadow** is available to [read online](https://dockersecurity.io/black-forest-shadow) for free now. You can still get the PDF in the [shop](https://dockersecurity.io/shop) or order the physical book on Amazon or from your local bookstore.\n\nMay also brought a happier topic: **Operational AI with Docker** is out. I wrote a short review about my experience as a technical reviewer and why the book is worth reading if you care about Docker, MCP, agents, and local AI workflows.\n\nThe security angle is simple: AI workloads bring more moving parts into the supply chain: model files, MCP servers, agent plugins, local tools, and permissions. The old question was \"what is in my container?\" The new question is closer to \"what can this agent reach, execute, remember, and publish?\"\n\nJune takes me to **EnterJS** in Mannheim with **Defense Against the Dark Arts: NPM Attack**, which now feels less like a clever title and more like a monthly incident response exercise.\n\nThen in July, I will be back at **WeAreDevelopers World Congress** in Berlin with two talks:\n\nLast year at WeAreDevelopers, more than 100 people queued for 40 seats at my Docker workshop. This year, the Commandos return with a much darker threat model and a much better battle plan.\n\nLook out for worms, check your caches, and keep building those walls. Also, have fun this summer!", "url": "https://wpnews.pro/news/docker-security-dispatch-issue-3-zurich-worms-and-the-ai-frontier", "canonical_source": "https://dev.to/docker/docker-security-dispatch-issue-3-zurich-worms-and-the-ai-frontier-3pep", "published_at": "2026-06-22 07:00:00+00:00", "updated_at": "2026-06-22 07:10:21.330041+00:00", "lang": "en", "topics": ["ai-safety", "developer-tools", "ai-agents"], "entities": ["Docker", "TanStack", "Nx Console", "DevOpsDays Zurich", "Bun", "CVE-2026-31431", "Mini Shai-Hulud", "JAVAPRO"], "alternates": {"html": "https://wpnews.pro/news/docker-security-dispatch-issue-3-zurich-worms-and-the-ai-frontier", "markdown": "https://wpnews.pro/news/docker-security-dispatch-issue-3-zurich-worms-and-the-ai-frontier.md", "text": "https://wpnews.pro/news/docker-security-dispatch-issue-3-zurich-worms-and-the-ai-frontier.txt", "jsonld": "https://wpnews.pro/news/docker-security-dispatch-issue-3-zurich-worms-and-the-ai-frontier.jsonld"}}