What you need to know
- CISA has listed both PHP flaws as known exploited vulnerabilities.
- Verify the fix in each running service and keep interim mitigation separate from completed remediation.
- Review earlier activity as a parallel task, with the available evidence and its limits recorded.
An update closes exposure; a review examines what came before
CISA added two PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619, to its Known Exploited Vulnerabilities Catalog on October 26. For organizations operating affected web services, the immediate software update and the investigation of earlier activity now belong in the same response plan.
PHP released fixes on October 21. Amazon separately reports seeing an exploitation attempt in its MadPot honeypot telemetry dating to October 17. Amazon says it remains unclear whether the observed attempts would have succeeded against real-world systems. That distinction matters: the telemetry establishes a reason to look back, rather than proof that any particular customer was compromised.
The runtime inventory needs to reach the running service
The PHP project identifies 8.5.12, 8.4.27, 8.3.36 and 8.2.35 as the fixed source releases. Its advisory covers installations serving web requests, including PHP-FPM and Apache with mod_php. It also directs users of distribution and long-term-support packages to their vendors for updates; a vendor-backported fix can require a different package-level check.
A practical inventory therefore follows each public service to the PHP runtime actually handling its requests. Our editorial recommendation is to record the service owner, deployed package or image, vendor fix status and evidence that the updated runtime is running. Updating a development machine or rebuilding an image does not, by itself, establish the state of every production instance.
PHP warns that configuration measures reduce particular attack paths without completely resolving both flaws. Teams using interim controls should keep the software update open as unfinished work and follow the current vendor advisory for their deployment.
Begin the investigation before the announcement date
Amazon recommends examining activity from at least October 17. Its guidance includes reviewing web-server logs and investigating unexpected process execution or file changes. These are defensive review directions, not a finding that every unusual event is malicious.
The operational consequence is a separate evidence trail. An update record answers when a service received the fix. An investigation record answers which historical data was available, what was examined and what remains unknown. A clean result from a limited log window cannot establish what happened outside that window. Preserve that limit in the incident record so later decisions do not inherit false certainty.
The longer task is sustaining the machinery behind the fix
The PHP Foundation says work on the underlying memory-handling issue stalled over compatibility trade-offs, decision-making and limited engineering resources. It describes changes to its security processes and additional dedicated staff. That account makes the episode relevant beyond a single emergency release.
Our view is that companies depending on a shared runtime should include upstream maintenance in their resilience planning. Knowing who distributes a fix, who validates it internally and who can coordinate an urgent rollout makes a future response more concrete. The immediate milestone is a verified update; the broader investment is a repeatable route from a maintainer’s release to every service that depends on it.
