The technical concern is substantial: the UK National Cyber Security Centre says the vulnerabilities can enable unauthenticated remote code execution under certain conditions. PHP security updates are available.
Two flaws, different request-handling failures
The vulnerabilities involve related memory-safety problems, but they are not interchangeable:
- CVE-2026-109618 — memory corruption: An out-of-memory condition can interrupt initialization of internal request data. Cleanup code may subsequently handle incomplete data as though it were valid.
- CVE-2026-109619 — stale internal request state: Internal state can retain references to freed request memory. A subsequent request handled by the same worker may encounter that stale state before normal initialization replaces it.
Those distinctions come from the NCSC’s technical summary. Both concern PHP’s handling of requests rather than a defect in one particular website application.
Configuration affects exposure—not the need to investigate
Red Hat’s assessment adds an important qualification for administrators: practical exploitability depends on how PHP is deployed.
For CVE-2026-109618, Red Hat describes remote code execution through crafted HTTP requests against default mod_php configurations and through application-stage paths in PHP-FPM. It says reliable exploitation requires precise heap manipulation and timing; standard Red Hat Enterprise Linux deployments using PHP-FPM make exploitation more difficult because workers exit on early initialization failures. That is a deployment-specific distinction, not a blanket exemption for PHP-FPM.
There is another patch-management trap: an older-looking package version is not necessarily an unpatched package. Red Hat explains that it backports fixes without always moving packages to newer upstream version numbers. Administrators should use their vendor’s security status and package guidance rather than make the decision from a version banner alone.
What administrators should prioritize
The NCSC recommends a response that extends beyond standalone PHP installations:
- Inventory PHP across the environment, including third-party products and appliances that bundle it.
- Prioritize internet-facing systems, then address internal deployments.
- Apply vendor-supported security updates and move unsupported installations to a supported release.
- If patching is blocked, use approved temporary mitigations; consider taking systems offline if adequate protection cannot be applied promptly.
- Assess possible compromise when systems cannot be updated or disabled immediately, including looking for attacker-installed backdoors.
The practical lesson is straightforward: finding the obvious web server is the start of discovery, not the finish line.
Federal requirements versus broader guidance
CISA’s notice cites Binding Operational Directive 26-04, “Prioritizing Security Updates Based on Risk.” It directs Federal Civilian Executive Branch agencies to prioritize high-risk vulnerabilities, particularly KEV-listed flaws on publicly exposed assets where exploitation grants total control, and establishes expectations for checking for compromise.
The directive applies to those federal agencies; it is not a universal private-sector patch deadline. CISA nevertheless encourages all organizations to prioritize KEV vulnerabilities.
For enterprise teams, the useful response is to combine that prioritization signal with deployment-specific evidence: locate PHP, establish exposure, verify the vendor’s fix, and investigate systems where compromise is a concern. Configuration nuance should sharpen the response—not become an excuse to postpone it.