Cybersecurity Special Report October 2026

Critical PHP flaws and eMudhra certificate compromise

Two critical PHP vulnerabilities and the compromise of eight certificate authority keys have triggered urgent security action across web infrastructure, browsers and software platforms.

This special bulletin focuses on both incidents, what security teams need to know, and the action organisations should be taking now.

Critical PHP flaws patched following early disclosure and exploitation

PHP has released emergency security updates for two critical remote code execution vulnerabilities, CVE-2026-109618 and CVE-2026-109619. Both carry a CVSS v4.0 score of 9.2 and can allow unauthenticated attackers to execute code on vulnerable servers.

Details of the vulnerabilities began circulating publicly before PHP released its security updates, prompting an accelerated response from the PHP security team.

The PHP security team subsequently released fixes on 21 October in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35.

The urgency is increased by evidence that attacks began before public disclosure. Amazon Threat Intelligence observed an exploitation attempt on 17 October and has since reported broader exploitation in the wild.

The flaws sit within the PHP runtime itself. PHP installations serving web requests are at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed, with mod_php considered the highest-risk configuration.

Because the vulnerabilities exist within PHP itself rather than an individual application or framework, organisations should not assume application-level controls remove the underlying exposure.

What organisations should do

• Identify PHP across your environment, prioritising internet-facing systems.
• Update affected PHP installations to the latest fixed release, prioritising internet-facing systems.
• Continue to monitor PHP and relevant vendor guidance for any further patches or remediation as this remains an active and developing issue.
• Treat PHP 8.1 and earlier as a particular priority. These branches are outside normal PHP support and do not receive normal upstream releases, although source backports have been published for PHP 7.4, 8.0 and 8.1.
• Consider isolating internet-facing systems that cannot be fixed immediately until a fix has been applied and verified.
• Investigate potentially exposed systems rather than relying on patch status alone. Exploitation attempts were observed before the public patches became available.

Eight compromised eMudhra CA keys trigger widespread trust changes

A separate incident has led major technology providers to block certificates associated with eight compromised intermediate certificate authority keys belonging to eMudhra.

Six of the affected intermediates were intended for TLS certificates and two for code signing. Because the private keys were compromised, they could potentially be used to create fraudulent certificates that appear trusted, creating a route to impersonate servers or intercept and modify traffic.

Google, Mozilla, Apple and Microsoft have moved to block or distrust the affected certificates. The Go project issued patched releases that block trust in the affected intermediates.

Subsequent reporting indicates this was not a conventional theft of private keys. The private keys had been generated with insufficient cryptographic randomness, making it possible to recover them from the corresponding public certificates.

The potential consequences of compromised intermediate CA keys are serious, but there is currently an important distinction between that potential risk and evidence of actual abuse. eMudhra says none of the affected intermediate CAs issued end-entity certificates, while Cloudflare says its security review has not identified active exploitation affecting its services.

The remaining concern is systems that do not rapidly consume certificate revocation information. Other clients and applications may require software or trust-store updates before they stop trusting the affected intermediates.

What organisations should do

• Check that relevant browser, operating system and application certificate protections are current, including updates where required.
• Check applications with bundled or custom trust stores, rather than assuming browser-level revocation protects the whole environment.
• Update Go applications where applicable to versions containing the relevant security changes.
• Review relevant supplier guidance for operating systems, applications and container images that may contain affected certificate stores.