What happened
NCSC-NL maintains a public repository of operational information about CVE-2026-109618 and CVE-2026-109619, two critical PHP vulnerabilities tracked by CERT-EU. The repository says PHP published fixes on 21 October 2026 in versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP describes both flaws as capable of unauthenticated remote code execution. The first involves out-of-memory corruption during request cleanup; the second involves stale request-owned global state reused by a later request on the same worker.
The stated exposure includes PHP installations serving web requests through PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. PHP considers mod_php the highest-risk configuration because an unauthenticated request can trigger exploitation before application code runs. The repository notes that PHP 8.1 and older are no longer supported by the PHP project, though distributions and long-term-support vendors may provide backported packages. PHP also published minimal source backports for versions 7.4, 8.0 and 8.1.
The repository’s software inventory covered 948 products in its 4 November 2026 snapshot: 215 were listed as vulnerable, 185 fixed, 93 under investigation, 240 runtime-dependent, 214 not affected and one unassessed or unknown. Its latest software-status updates are timestamped 4 November at 08:15 CET and include vendor confirmations and product-specific information. The list is not limited to conventional websites: it includes products that embed or depend on PHP, including appliances, network devices and management interfaces. Some administrators may not be able to update the PHP runtime directly and must wait for the product vendor.
NCSC-NL recommends identifying PHP-based applications and runtime versions, prioritizing internet-facing systems and web-serving SAPIs, then updating to a fixed version or applying a vendor-provided backport. Operators are advised to check third-party images, appliances and embedded runtimes separately, and to apply vendor updates when available. The repository says temporary measures for systems that cannot be patched immediately include disabling session.upload_progress, restarting workers, and reviewing PHP guidance on memory_limit, post_max_size and PHP 8.5 fatal_error_backtraces. It explicitly says these measures are not complete fixes.
There is also a related issue outside the repository’s tracked software list. PHP’s 23 October informational advisory recommends setting session.upload_progress.enabled=0 until the next regular bugfix release to protect against an unlikely RCE vector, CVE-2026-115560. The repository says PHP plans a full advisory with the next release and does not track this CVE separately in its product inventory. It advises keeping the setting disabled after updating unless the application needs the feature and never changes session.serialize_handler at runtime.
What the archive adds
This is a new operational fact on a known story. The 22 October PHP security advisory covered the two critical flaws and affected PHP versions; CERT-EU’s advisory added a third vulnerability, and CISA’s alert urged immediate patching. NCSC-NL’s inventory adds a product-by-product status view and a dated count across 948 products.
Trend signal
No supplied SITE_PATTERNS thesis genuinely fits this update. The source documents vulnerability status and mitigation across PHP-dependent products, not a material shift in agent systems, agent security boundaries or AI-building workflows.
Why now
The repository says it is updated as the situation develops. Its current inventory snapshot is dated 4 November 2026, and its latest listed software updates carry that date. The timing therefore reflects a refreshed status record, not a newly announced PHP fix: the principal fixed releases were published on 21 October.
Connections to other events
The repository connects the two tracked vulnerabilities to CVE-2026-115560, a separate, unlikely RCE vector for which PHP issued an informational advisory on 23 October. It also directs readers to PHP and CERT-EU advisories and to observations from TU Delft. These links reinforce that patch status, temporary configuration guidance and exploit observations are separate evidence streams; the source does not say that the inventory itself establishes exploitation or compromise.
Why it matters
For teams operating PHP-backed services, the inventory makes the response problem broader than upgrading an application’s declared runtime. PHP may be bundled in a container image, appliance, network device or management interface, and a team may depend on a vendor to ship a patched build. The 215 vulnerable entries and 93 under investigation make asset ownership and runtime discovery concrete priorities, while the 240 runtime-dependent entries caution against treating a product-level label as a universal result for every deployment.
The source’s practical distinction is between a fix and an interim mitigation. A supported fixed PHP release or vendor backport is the recommended remediation; configuration changes and worker restarts are temporary steps, not proof that the vulnerability is closed. Teams should therefore record the product, embedded PHP version, vendor status and verification date, then revisit unknown or runtime-dependent cases as vendors update their information. This is operational security work rather than a change to AI tooling, but the same discipline applies to any software supply chain that includes runtimes outside a team’s direct control.
Limits and uncertainty
The repository is an operational inventory, not a census of all deployed PHP systems. Its 948 tracked products and status categories do not establish how many internet-facing instances exist, whether a particular deployment is exploitable, or how many systems have been compromised. The excerpt supplies aggregate counts but no denominator for the products potentially in scope beyond the tracked list. “Fixed” may reflect product or vendor status and does not prove that every customer has installed the update. Some entries are runtime-dependent or still under investigation, and the repository says embedded products may require vendor updates. The supplied material also gives no overall exploitation rate or incident count. Temporary mitigations are expressly not complete fixes.
Skill to build now
Build a small PHP-runtime inventory for the services your team owns this week. Include direct applications, container images, third-party appliances and management interfaces; record the runtime version, exposure, vendor, patch or backport status, and the date each status was checked. Prioritize internet-facing systems and web-serving SAPIs, then verify that an update actually reached the deployed artifact. For products you cannot patch directly, assign an owner to track the vendor advisory rather than treating an unknown runtime as safe.
Reader takeaway
Treat PHP exposure as an asset-discovery and vendor-tracking problem as much as a package-upgrade task. NCSC-NL’s latest snapshot shows a substantial set of tracked products still marked vulnerable or unresolved, while its own guidance distinguishes temporary mitigations from a complete fix. Check the deployed runtime and the product that carries it, not just the application’s dependency file.
Open question
How quickly will vendors resolve the 93 products under investigation and the 240 whose status depends on the runtime in a customer deployment?