ilert is not affected by the PHP remote code execution vulnerabilities (CVE-2026-109618, CVE-2026-109619)

In short: ilert is not affected by CVE-2026-109618 or CVE-2026-109619. No ilert system runs PHP, so customers don't need to do anything.

‍

On October 21, 2026, the PHP project published two critical security advisories. Both let an unauthenticated attacker run code on a server that runs PHP, just by sending crafted HTTP requests. Since then, a number of customers have asked us whether ilert is affected. It isn't, and here is why.

What the vulnerabilities are

• CVE-2026-109618, RCE via OOM corruption (GHSA-w8hw-w9fx-j79w). When PHP runs out of memory in certain contexts, it leaves request memory in an invalid state, which is then read during request shutdown. An attacker can force the out-of-memory condition with crafted multipart requests, before any application code runs.
• CVE-2026-109619, RCE via stale global state (GHSA-6wmf-4rv5-p3rp). A PHP worker can hold on to error, session or extension state from one request after that request's memory has been freed. A later request handled by the same worker then uses the stale state.

‍

Both were confirmed against Apache with mod_php. PHP-FPM and other setups are susceptible depending on their configuration. All PHP versions before 8.2.35, 8.3.36, 8.4.27 and 8.5.12 are affected. Since PHP runs a large share of the web, including most WordPress sites, the impact is broad.

Why ilert is not affected

We don't use PHP anywhere at ilert. That covers the ilert platform for alerting, on-call and incident management, our status pages, the ilert API and our mobile apps. Our services are built on Java, Rust and TypeScript. Our website runs on Webflow, a hosted platform, not on PHP servers that we operate.

‍

There is no PHP runtime in our infrastructure that an attacker could reach. There is nothing to patch on our side, and nothing you need to do as an ilert customer.

If you run PHP yourself

If your own systems run PHP, treat this as urgent:

• Update to PHP 8.2.35, 8.3.36, 8.4.27, 8.5.12 or later. According to the PHP project, updating is the only complete mitigation.
• Restart every PHP worker after the update.
• If you can't update right away, the advisories list interim mitigations, such as disabling session upload progress and, on PHP 8.5, fatal error backtraces. They reduce the risk but don't remove it.
• Check the less obvious places too: WordPress and other CMS installs, internal admin tools, and containers built on older base images.

Questions

If you have any questions, contact us at support@ilert.com or reach out to your account manager. You can read more about how we secure ilert in our Trust Center.