On 21 October 2026 the PHP project published two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, both rated 9.2 under CVSS v4.0. In plain terms: an attacker with no account could send a specially crafted request to any website that runs on PHP and make the server run their own code. The flaw sits in how PHP reads an incoming request, before the website's own code even starts, so no particular page or feature had to be vulnerable. Every way PHP serves web requests was affected: PHP-FPM, mod_php and CGI.
Europe's security agencies moved first. CERT-EU told organisations on 20 October to prepare to patch immediately, and on 21 October Germany's BSI issued a level 3 (orange) warning for web servers running PHP.
Our white-label platform was patched within about 36 hours, Digital Samba Embedded on 23 October, and every production service by 24 October. We then reviewed our logs and servers for the whole exposure window and found no sign that anyone had used the flaw against us.
On Digital Samba Embedded: the API and dashboard backend, the account centre and file storage. Beyond it: the web application of our white-label platform, the dedicated Embedded deployments we run for self-hosted customers, and our learning-platform integration. The parts that carry your meetings (media servers, recording, realtime messaging and the in-meeting apps) are not PHP and were not affected.
Amazon reported attack attempts from 17 October, before a fix existed, so we reviewed every service from that date until it was patched:
Embedded took longest. Its fix went through our normal release path and a maintenance window, chosen so a restart wouldn't cut meetings short. CERT-EU's advice for anything not yet patched was to consider isolating it; we did that for the legacy services, but isolating the API would have taken Embedded down for every customer.
Looking back, we missed an obvious shortcut. The Embedded API runs as several identical containers behind a load balancer, so we could have replaced them one at a time, with no window and no interruption.
We are a small DevOps team running a lot of services, and we expect advisories like this to come more often, and not only for PHP. Acting fast isn't enough on its own: we use each incident to help us respond better and faster to the next one.
These decisions are now written down, so the next incident starts from them.
php -v reported 8.4 while
the process answering requests ran 7.2. Our own sweep script fell into a version of this trap
until we fixed it; nothing slipped through because every fix was verified on the running process.More and more flaws like this will be found with the help of AI. For a small team, the only realistic way to close them quickly is to use the same kind of tool, and that irony is not lost on us.
While we waited for fixed packages and base images to appear in upstream registries, we used an AI agent for the read-only reconnaissance: sweeping every host and container for what was actually serving PHP, reading the vendors' changelogs, and preparing our build file changes.
When the fixes landed, that work went straight into our normal build pipelines, and the agent carried out the rollout steps, each one only after an engineer's explicit go. Every decision was ours. It worked from counts and patterns in our logs, never customer data itself, and a redaction hook kept secrets out of its view.
The agent helped make our small team fast. The approvals, the verification habits and a second look from outside made it safe.
Questions about this vulnerability or how we handle security? Email our support team at support@digitalsamba.com.