Security

Security Incidents and Planned Work

How named vulnerabilities and incident classes map onto the architecture, what the current release addresses, the PHP2Shell analysis, and the work still planned. The claims and their labels are on Security.

The CVE and Incident Map

Each row maps a published vulnerability or incident to what an attacker needs on a conventional host and what changes inside a Drupflare site. The verdicts are Inferred from the architecture above. No exploit was run against a Drupflare site. The verdict words are defined under How to Read the Claims.

Classes Addressed in v1.0.4

The map above is about published incidents. This table is about attack classes a code-execution foothold could use, with the verdict before and after the v1.0.4 work. Each "after" names its evidence and its residual.

PHP2Shell

PHP2Shell is the name given to two critical remote code execution vulnerabilities in PHP, CVE-2026-109618 and CVE-2026-109619, published on 2026-10-21 and fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. This section says what the advisories require, what the shipping interpreter does about each requirement. The result: the published PHP2Shell chains do not work against a Drupflare site, and the map marks both removed. The reason is the lifecycle described below. The sandbox does not account for it: WebAssembly does not stop corruption inside the module.

What the Advisories Say

CVE-2026-109618, "RCE via OOM corruption" (GHSA-w8hw-w9fx-j79w): "PHP uses longjmp() for out-of-memory (OOM) errors to exit the current context and abort handling of the request", and "does not properly account for the early exit and leaves the request memory in an invalid state". Request shutdown then reads that state. The validated exploit is against Apache mod_php, where body parsing at request startup can exhaust memory_limit and shutdown still runs. For PHP-FPM the advisory says "no complete FPM exploit has been demonstrated".

CVE-2026-109619, "RCE via stale global state" (GHSA-6wmf-4rv5-p3rp): state owned by one request survives after its memory is freed, and a later operation on the same worker reads it before normal initialization resets it. The exploit needs a producer, which is a fatal error, timeout or OOM that skips a reset, and a consumer that runs before initialization. The confirmed consumers are INI diagnostics raised while settings are applied and session upload progress. The confirmed producer on PHP 8.5 is fatal_error_backtraces.

Both are CVSS v4 9.2, unauthenticated and network reachable. PHP's announcement says "there are no complete mitigations, updating is the only safe choice" and names PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed as at risk (php.net). It does not address embedded SAPIs. Wiz reports working exploits on standard SAPIs against WordPress, Drupal and Joomla, including one against Drupal that uses the fatal-error backtrace state (Wiz).

What the Shipping Interpreter Does

The two settings PHP lists as interim mitigations are off at boot, and the analysis below does not depend on them. session.upload_progress.enabled is a per-directory setting that ini_set cannot change, so boot is the only place it could be set. fatal_error_backtraces is a default and not a ceiling, because user code can set it back.

What Follows and What Does Not

These are Inferred from the table.

Where the published chain breaks in this runtime:

flowchart TD
    A["Request startup: body parsing exhausts memory_limit"] --> B["longjmp out of the request"]
    B --> C["Request shutdown reads the invalid state"]
    D["This runtime: pib_run inside one retained request"] --> E["No request startup or shutdown per run"]
    E --> F["Allocator does not enforce memory_limit"]

• The CVE-2026-109618 chain that was demonstrated starts at request startup and ends in request shutdown. This runtime runs code through pib_run inside one retained request and performs neither per request. Its allocator does not enforce memory_limit, so the longjmp() the advisory describes has no limit to fire on, and allocation failure ends the instance through exit(1) instead of leaving partial state behind.
• The CVE-2026-109619 consumers run before a request's normal initialization: per-request INI application and the upload-progress handler inside multipart startup. Neither happens per request here. A producer does leave state behind, but request memory is never freed between runs, so a stale pointer aims at live memory and not at reclaimed memory.

Neither published chain has a path in this runtime, which is the decision recorded in the map. The interpreter was rebuilt at 8.5.12 on 2026-10-23 (UTC) and pinned in this repository the same day. The 8.5.2 build contained the vulnerable code, and PHP says updating is the only complete mitigation. A retained request can also keep per-extension state across a fatal error that a request shutdown would reset. That is a logic hazard, of the kind documented in State That Survives Between Requests, and not a use-after-free, because request memory is never freed between runs. What would reverse the decision is a working chain against this runtime. The public write-ups use standard SAPIs and report none.

Visitor State That Outlived the Request

Found and fixed on 2026-11-02 while driving simplesamlphp_auth and access_unpublished to Verified. The container and its services live across requests in the persistent interpreter, so a service that keeps per-request state in a static keeps the previous visitor's value. Three carriers turned up, and each is now reset by name in RequestResetter or DrupflareServiceProvider in the drupflare module.

• SimpleSAMLphp. SimpleSAML\Session holds the current session in a static, SessionHandler caches the session id of the first cookie it read, and the simplesamlphp_auth manager keeps a Simple that captured that session. After one IdP login, a request that carried no cookie to /saml_login was logged in as the previous visitor (measured, on the rig). The fix is RequestResetter::resetSimpleSaml(). Its regression test fails 3 assertions with the call removed.
• access_unpublished. TokenGetter keeps the token it read in a static, so one visitor's token unlocked an unpublished node for the next anonymous visitor. The fix is clearAccessUnpublishedToken().
• strata. CaptureScope cached its settings for the life of the container. The fix is the named seed strata.capture_scope.

A site that uses none of these modules was not affected. Sites that do need the new driver, and it reaches a deployed site with the release. Nobody has checked whether either leak was ever exploited. Resetting by name does not cover a fourth carrier nobody has found, so a generic reset of resettable services stays open work (see the roadmap).

A Request That Ran Its PHP Twice

Found and fixed on 2026-11-02, in the host and not in the interpreter. The object's park driver parsed a request's printed output from its first {. When that brace belonged to a log line printed before the result, such as SimpleSAMLphp's %date{M j H:i:s} debug lines, the parse failed and the driver ran the whole request again from the top. A park that the interpreter refused did the same thing, because finishing the refused chain discarded the final JSON. The first run's side effects were already committed, so the second run met a consumed SAML state or a saved node.

The blast radius was every render on every site, since the park arms on all of them. One create-node POST through a refused park made two nodes in the measured arm (measured, rows 2 to 4 for one POST), and mail and outbound HTTP in the first run repeat the same way. Since the fix a request runs once on every shape tested: a refused park finishes without the park and its JSON survives, and a reply that does not parse is a render failure that fillOne() already handles, never a second run. tests/integration/park-double-run.spec.ts counts entries into the program (7 of 8 cases fail on the unfixed code) and tests/unit/ops/json-reply.spec.ts holds the brace case. A deployed check is written down and has not run.

Cron That Could Not Fetch

Found and fixed on 2026-11-02 while running strata's cron against a local object store. Cron units ran through the runner that has no park, so an outbound request that was not already cached went to the deferred transport and answered "endpoint answered 0". The security advisories unit queued its feed fetch and was refused on every firing: 0 of 8 runs completed, against 8 of 8 with the parked runner (measured, eight paired runs a side, 18 firings each). The announcements feed read 15 of 16 and now reads 16 of 16. Whole-run fetch totals match (83 and 85), no park was refused in either arm, and the largest isolate estimate moved 1.2 MB (118.18 and 119.41 MB). No firing in the fixed arm took longer than 379 ms.

The update module's cron failed on every firing for a second reason. The cron boot never calls the kernel's request step, so $base_url and the other request globals were unset and Crypt::hmacBase64() received NULL. Release data never refreshed by cron on any site. With the globals set in src/site/php/kernel-boot.php, one firing stored release data for drupal, admin_toolbar, ctools, pathauto and token, wrote update.last_check and drained the fetch queue from 5 rows to 0. The control stored none and left the queue at 5. The cron queue unit also skips update_fetch_tasks, which has no worker plugin and drains inside the module's own hook.

tests/integration/cron-wire.spec.ts covers the parked runner and the globals (the globals case fails on the unfixed code), and tests/unit/ops/cron-chain.spec.ts covers the queue filter. A deployed run has not happened, and some release-history URLs are still requested twice in a firing, which is unattributed.

Planned Work

Items marked shipped are in v1.0.4 and measured as stated above. Everything else is not built.