Two PHP Engine Bugs Hit the KEV List — Your Webmail Is the Exposed Part

What CISA actually said

On 26 October, CISA added two PHP flaws to its Known Exploited Vulnerabilities catalog and refreshed its earlier PHP alert ("Critical Vulnerabilities in PHP Require Immediate Patching," from 21 October):

• CVE-2026-109618 — a memory corruption vulnerability
• CVE-2026-109619 — a "stale internal request-state" vulnerability

KEV means one thing that the word "critical" alone does not: these are being used in the wild right now. TechCrunch's Zack Whittaker reported the same, that attackers are exploiting these PHP bugs. That's the whole trigger here — not a theoretical CVSS score, but observed exploitation.

What CISA did not give you is the part a sysadmin actually needs: affected PHP branches, fixed versions, or how the attack is delivered. So before you touch anything, confirm which PHP version your servers run and cross-check it against the upstream PHP release notes and the CISA PHP alert. Don't patch on vibes.

Why this lands on a mail server at all

PHP isn't obviously a mail component, so it's easy to shrug this off. Don't. The thing that makes KEV scary — "publicly exposed assets that grant total control," in CISA's own framing of BOD 26-04 — describes webmail exactly. Webmail is the one PHP app you deliberately expose to the whole internet.

If you run iRedMail, you ship Roundcube, and Roundcube is PHP running under PHP-FPM. PostfixAdmin is PHP. phpMyAdmin, if you left it bolted to your mail database, is PHP. Any of these sitting behind nginx or Apache is a request away from the engine these CVEs live in.

The important mental shift: the bug is in the interpreter, not in Roundcube. Patching Roundcube does nothing. Updating a plugin does nothing. The fix is in your distribution's php / php-fpm package, and it only takes effect once the FPM pool (or Apache, if you still use mod_php) is restarted. I've seen people apply the update and forget the restart, then wonder why they're still exposed — long-lived FPM workers keep running the old code in memory until you cycle them.

The request-state bug is the one that should worry multi-user webmail

Memory corruption is the familiar shape: crafted input, code execution as the FPM user — usually www-data or similar. On a consolidated mail box that user can often read Roundcube's config, which means your database credentials, which means your mail store's metadata. Nasty, but familiar.

The "stale internal request-state" bug is the more interesting one for us. PHP-FPM reuses worker processes across requests by design. A flaw where internal state survives from one request into the next is precisely the failure mode you least want on a shared webmail host: user A's request leaving residue for user B. On a single-tenant admin panel that's bad; on webmail serving hundreds of mailboxes it's a confidentiality problem, not just an availability one. CISA's one-line label doesn't confirm that's the impact — but that's the risk the name points at, and I'd treat it accordingly.

Who can relax

If your webmail is Zimbra, its web client runs on Java/Jetty, not PHP — so your core mailbox front end isn't in scope for these two CVEs. Same logic for anything that isn't actually serving PHP to the internet. The exposure is about what's reachable, not what's installed. A PHP package sitting on a box with no public PHP endpoint is a lower priority than a patched-but-unrestarted webmail server.

So the honest Monday-morning version: find every host that answers PHP requests from outside, confirm its PHP version, apply the distro update when it lands for your branch, and restart the FPM pools. Then check your webmail access logs around the dates in these advisories — KEV status means someone may already have tried.

Sources

• CISA Advisories — CISA Adds Two Known Exploited Vulnerabilities to Catalog
• TechCrunch — US government says hackers are now exploiting critical PHP web bugs