A request has a lifetime
A web worker processes a request using temporary memory. Once that request ends, the runtime must stop using references to that memory before releasing it. Error paths are particularly important: cleanup still needs to leave the worker in a valid state.
CVE-2026-109618 concerns an out-of-memory interruption while some request data is only partly initialised. CVE-2026-109619 concerns stale internal references that can be used when a worker handles a later request. The official advisories explain the affected paths and build-specific conditions.
Sources: PHP: RCE via OOM corruption · PHP: RCE via stale global state.
A mechanism is not a universal exploit
A memory-safety weakness establishes a dangerous condition. A working exploit also depends on reachable code, build details, configuration and the way requests reach the worker. PHP’s published mod_php demonstration establishes a concrete risk. It does not establish identical reliability against every PHP handler.
The defensive decision is to identify and patch affected runtimes using the project and vendor instructions. Administrators should not send exploit traffic to a production site to prove that it needs an update.
Sources: PHP: RCE via OOM corruption · PHP official security announcement.
Why backports change the answer
Distribution maintainers can apply a security fix to an older PHP source release and publish a new package revision. For example, Ubuntu records a fix in the PHP 8.3 package for Ubuntu 24.04 at 8.3.6-0ubuntu0.24.04.13. Reading only 8.3.6 loses the revision and the distribution context.
The Bytova tool uses exact verified package matches. It deliberately avoids pretending to implement every distribution’s package ordering rules. A package not in its small snapshot is unverified and needs a vendor lookup.
Sources: Ubuntu package status: CVE-2026-109618 · Ubuntu package status: CVE-2026-109619.
A version check is a decision aid
The browser checker and Python utility share one dated advisory dataset and cross-language test fixtures. They separate application logic from the source record. Unknown providers, future releases, pre-release builds and stale safety data do not receive a positive fixed classification.
Even a correctly matched installed package does not prove the website uses it. Confirm the web handler, worker replacement, every container and the application health checks. The tools do not search for compromise, inspect your logs or certify a system.
Make the result reviewable
Keep a concise record: what was running, which official source applied, what package was installed, who approved the change, when processes were replaced, what was tested and what remains uncertain. An accurate unresolved result is more useful than an unsupported claim of safety.