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.
What runs PHP at Digital Samba
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.
Did anyone get in?
Amazon reported attack attempts from 17 October,
before a fix existed, so we reviewed every service from that date until it was patched:
- Traffic: this attack depends on oversized or cut-off uploads. Those stayed at their normal
level throughout.
- PHP's error logs: as a second check, we looked for the trace an attack leaves: PHP running
out of memory before any of the website's code has started, or the PHP worker crashing. We
found none, including on the Embedded API and the account centre.
- The servers: no new scripts, scheduled tasks, unexpected processes or outbound connections.
Timeline
- 20 Oct: CERT-EU advisory.
- 21 Oct: PHP fixes released; BSI warning. Every host swept, new base images built, legacy
services cut off from the internet.
- 22 Oct: white-label platform patched.
- 23 Oct: Digital Samba Embedded patched.
- 24 Oct: dedicated Embedded deployments patched.
- 26 Oct: the US agency CISA
lists both flaws as exploited.
- 27 Oct: closure sweep: every PHP service verified fixed or contained.
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.
What we're changing
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.
- Treat a critical, unauthenticated flaw as exploited from day one, under a rule agreed in
advance.
- Ship runtime-only fixes on a fast path: automated smoke tests and a rolling replacement,
without waiting for a release or a window.
- Act on the early warning: map our exposure and take anything non-essential off the
internet before the patch exists.
- Extend central logging across more of our services.
These decisions are now written down, so the next incident starts from them.
Lessons for other teams
- Check what serves requests, not what's installed. In one image,
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.
- Read the changelog, not the version number. Distributions backport fixes without changing
the version, so only the patch in the changelog proves it.
- Own your base images. The community image we built on hadn't shipped a fix, so we rebuilt
its recipe ourselves the same evening. The build now fails unless every PHP package is on the
fixed version.
- A green pipeline is not a deploy. One test deploy reported success while still running the
old image. Verify inside the running container.
- A security rebuild exposes what the cache was hiding. Rebuilding forced a months-old cached
step to run again, and it had quietly broken upstream. Reproduce on the second failure; don't
keep retrying.
- Contain what you can't patch, and test the block from both outside and inside.
How we worked: AI on both sides
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.
