Security & Development

Two critical PHP vulnerabilities: security awareness, not language wars

Two critical PHP vulnerabilities call for fast updates, not language wars. What AI, Rust and Go have to do with the bigger question: how do we build and operate secure software?

G Unit SolutionsOctober 22, 20268 min read

On October 21, 2026, the PHP project disclosed two critical vulnerabilities and released fixes. Both can allow remote code execution without prior authentication. If you operate PHP applications, take the announcement seriously and update.

What does not follow is that PHP is fundamentally unsuitable, or that moving to Rust, Go or another language automatically solves the security problem. The more useful question is this: how do we build, review and operate software when even long-established code can contain dangerous flaws?

Update first, debate later

The PHP project's security announcement lists these fixed releases:

PHP 8.2.35
PHP 8.3.36
PHP 8.4.27
PHP 8.5.12

Update to the fixed release for your supported branch, or a newer release containing these fixes. Distributions and LTS vendors may backport the patches into packages with older upstream version numbers. Check your vendor's security announcement and the installed package revision, not only the PHP version string.

The PHP project directs its warning at all installations serving web requests. These include Apache with mod_php, PHP-FPM, php-cgi, FrankenPHP and LiteSpeed. It considers the risk highest for mod_php: a demonstrated exploit can reach the vulnerable path before application code runs. Requiring a login in your application is therefore not sufficient protection.

Only an update containing the complete fixes reliably addresses these vulnerabilities. The published configuration measures reduce particular attack paths, but do not make an unpatched installation safe. A WAF rule or a switch to PHP-FPM is not a replacement for the update.

PHP 8.1 and older branches no longer receive regular security updates from the PHP project. For this exceptional situation, the team provided minimal source backports for PHP 7.4, 8.0 and 8.1. This does not restart their support. Confirm patch availability with your vendor and plan a move to a supported branch.

What the two vulnerabilities mean

CVE-2026-109618: corrupted state after memory exhaustion

A memory allocation failure can interrupt PHP while internal request data is only partially initialized. During cleanup, the runtime may then treat that invalid state as valid data. This can lead to execution of attacker-controlled code.

The CVE-2026-109618 advisory describes confirmed exploitation against mod_php. Other server integrations have different conditions and lifecycles. That does not establish a general all-clear for PHP-FPM or other integrations.

CVE-2026-109619: stale state between requests

A PHP worker typically handles several requests in sequence. Some internal state can continue pointing to memory from an earlier request after that memory has been freed. If a later request accesses that state before normal initialization resets it, a use-after-free can occur.

The CVE-2026-109619 advisory describes confirmed paths to code execution in mod_php and PHP-FPM. The exact conditions depend on the affected state, configuration and, for some paths, application behavior.

Both flaws are in the PHP runtime. Treating them as blanket evidence of poor application code or careless operators would be wrong. Operators still own the response: identifying affected systems, deploying fixes and verifying that the updated runtime is actually in use.

PHP is not the only language with security vulnerabilities

Other ecosystems have also faced serious security problems. Two concrete examples show why language wars miss the point:

Rust, CVE-2024-24576: The standard library did not sufficiently escape arguments when invoking Windows batch files. Passing untrusted input as arguments could allow arbitrary shell commands to execute. The official advisory rates that particular use as critical. Other platforms and other uses were not affected. The fix shipped in Rust 1.77.2.
Go, CVE-2025-22871: The net/http package accepted invalid line endings when reading chunk sizes. In combination with a frontend server with a particular conflicting interpretation, this could permit request smuggling. Fixes shipped in Go 1.23.8 and 1.24.2.

These examples are not a leaderboard or evidence of equivalent risk. A CVE records a reported vulnerability, not a language's security. Impact, preconditions and deployment exposure need separate assessment.

Language choice still matters. Rust's memory safety prevents many classes of memory bugs in safe Rust. That is a real advantage. It does not automatically prevent mistakes in shell argument handling, authorization or protocols. Garbage collection does not replace correct HTTP processing either.

The useful conclusion is not that every language is equally unsafe. It is that no language removes our responsibility for the whole system. The runtime, libraries, native extensions, interfaces, configuration and operations all belong in that assessment.

AI will bring more of these problems to light

Our expectation is that AI-assisted code analysis, test development, fuzzing and investigation of error paths will uncover overlooked vulnerabilities more often. That is an outlook on security work, not a claim about how these two PHP vulnerabilities were discovered.

More published findings do not automatically mean that software has suddenly become worse. They can also mean that existing code is being examined more closely. A disclosed and fixed vulnerability is progress compared with the same flaw remaining unknown.

That does not make the work easier. Attackers can use AI tools too. And an AI-generated report is not automatically correct: a plausible warning is not yet a reproducible security finding. Unverified reports can burden maintainers and bury important findings in noise.

We need both better tools and people who validate their output. Identifying affected versions, checking preconditions, reproducing a failure and testing a fix remain essential. Responsible reporting and coordinated disclosure matter more than producing the most headlines.

Security awareness has to change everyday work

“We take security seriously” only helps when it becomes repeatable work. For a small team, that does not start with a huge program. It starts with clear answers to practical questions.

1. Do we know what is actually running?

Inventory PHP runtimes, extensions, frameworks, packages, containers and frontend services, including versions and owners. Web processes, command-line jobs and background workers can use different runtimes. php -v alone does not establish which version handles a web request.

2. Can we actually deploy an urgent update?

Decide who reviews security announcements, assesses exposure and authorizes urgent patches. Test critical flows, deploy corrected packages or rebuilt images, and replace running workers through a controlled rollout. Then verify the runtime actually serving requests. A downloaded package is not yet a fixed production server.

3. Do we check more than dependencies?

composer audit is useful for known vulnerabilities in Composer packages. It does not replace checks on the PHP runtime, extensions or operating system security announcements. Combine dependency checks with maintained runtimes, code review and tests for authentication, authorization and integrations.

4. Do we test the unpleasant paths too?

Do not test only successful requests. Malformed uploads, unusual inputs, interrupted processing and cleanup failures belong in an isolated test environment. Fuzzing and AI can help find cases worth investigating. Do not run these tests uncontrolled against production. Once a bug is confirmed, a regression test should protect the fix.

5. Do we limit the damage of a successful attack?

A web process does not automatically need broad filesystem permissions, every credential or access to every internal service. Separate responsibilities, limit privileges and keep secrets out of environments that do not need them. This does not fix a runtime vulnerability, but it can limit the consequences.

6. Can we respond to suspected compromise?

Maintain useful logs, monitoring and a documented incident process. An absence of suspicious log entries is not proof that a system is safe. If there are signs of compromise, patching alone is not enough: investigate affected systems, assess exposed credentials and rotate them where necessary. Tested recovery procedures belong in that preparation too.

Fewer language wars, more secure systems

The right response to these PHP vulnerabilities is neither dismissal nor ridicule. It is to update, assess exposure, learn from the failure modes and improve how we develop and operate software.

If you use PHP, run a supported and maintained stack. If you use Rust or Go, do the same. A rewrite does not automatically remove risks in interfaces, permissions and operations. A new language is not a substitute for a security culture.

If you cannot confidently identify your PHP runtimes or explain how quickly you can deploy a critical fix, start there. Our PHP modernization and application management services help establish that technical and operational foundation.

Sources and reference date

As of October 22, 2026. The PHP versions above are the fixed releases for these two vulnerabilities, not a permanent recommendation for the latest version. For current actions, consult the original advisories and your package or hosting provider's guidance.

Connected work

5 links