跪拜 Guibai
← Back to the summary

PHP's Two 9.2-Severity RCE Flaws Turn Unauthenticated Requests Into Server Code Execution

PHP is genuinely in the spotlight this time, though in a rather frightening way.

PHP is pragmatic; there's no argument about that. For years its position has been a little awkward: a huge number of websites and web applications still depend on it, while the technical community talks about it less and less. Every so often someone declares PHP dead, in a tone that suggests the language should be retired within a couple of years.

Then yesterday it really got its moment, in a way nobody expected.

This time it wasn't a framework releasing a new version, nor a big company announcing it was fully embracing PHP. Instead, PHP itself exposed two serious security vulnerabilities. How serious? Japanese Prime Minister Sanae Takaichi personally urged relevant organizations on X to prepare and apply fixes as soon as possible, and the U.S. National Security Agency (NSA) issued a security advisory recommending that organizations unable to fix things promptly consider taking systems offline.

Several European cybersecurity agencies then issued joint warnings, and some government websites, public services, and commercial platforms went into emergency maintenance or even temporary shutdowns.

When the news reached China, it spread wildly across video accounts, official accounts, and platforms like Zhihu and Xiaohongshu.

I've even started to hesitate before scrolling short dramas, because I'm afraid of running into a melodramatic script like this:

Company: We're in the AI era now, so we don't need web engineers!

PHP developer: Heaven is against me, I've been laid off, boohoo.

National Cybersecurity Agency: What! PHP has exposed a fatal weakness? How many of our sites use PHP! Can't AI fix it!

Company: Help, help! Save me!

There's no choice. At this point, wake up everyone who knows PHP!

What! You! You actually know PHP!

Just thinking about it cracks me up.

Jokes aside, this really is not an ordinary security update.

On October 21, the PHP project disclosed two critical vulnerabilities, numbered CVE-2026-109618 and CVE-2026-109619, both with severity scores of 9.2 out of 10.

What's worse, they may allow attackers to execute code directly on the server without logging in or knowing any account passwords.

This is completely different from a page erroring out or an API returning an exception. After a successful attack, the programs running on the server, the data it can access, and even the entire site's running state can be affected.

What exactly are these two vulnerabilities, why did they make so many organizations act as if a major enemy was coming, and what role did AI play? Set the technical terms aside for now; let's start with two examples from daily life.

A warehouse manager who made a mistake because the warehouse was too busy

First, CVE-2026-109618.

Its technical description includes a term: OOM, Out Of Memory. Simply put, the system ran out of memory.

If you're not a developer, this may seem odd: isn't running out of memory just a program crash? At most the site stutters or throws an error. How does that become a vulnerability that lets someone attack a server?

For that, we need to start with a warehouse manager.

The warehouse manager gets an especially troublesome order

Imagine you run a warehouse. Normally when someone places an order, the manager takes the goods out according to the order, packs them, and finally hands the package to a courier.

To improve efficiency, the manager prepares some tools and record forms in advance: first register the order information, then prepare the goods list, and finally fill in the shipping records.

Under normal conditions, this process runs smoothly.

But one day, someone sends an especially complex order.

This order is packed with all kinds of additional information. Just sorting it out consumes a lot of paper, folders, and workspace.

The manager works for a while and finds that office supplies and desk space are almost used up.

So the manager decides to abandon the order and stop processing.

Here's the problem: although the manager stops what he's doing, some records created earlier are not yet fully prepared.

Some forms are half-filled; some folders have already been registered in the system but are not truly ready.

If he simply stops work and cleans everything up, there's naturally no problem.

But if, when finishing, he inspects and organizes these half-finished items according to the normal order process, things can go badly wrong.

For example, the system thinks a form has been filled in and operates according to its contents, only to find that the things in it don't exist at all, or even mistakes another record for its own.

If this kind of error happens in a program that manages a core process, it's no longer just an order-processing failure.

This is exactly where PHP's problem lies

PHP also has layers of preparation when handling HTTP requests.

When a browser sends a request, PHP doesn't immediately execute the site's business code. It first has to receive the request, parse the request headers and body, handle forms and file uploads, and prepare various internal data for later execution.

A significant portion of this work requires allocating memory.

Normally PHP has a memory limit. When it reaches the limit, it should stop processing to avoid continuing to consume memory.

The problem in this vulnerability is that if memory exhaustion occurs during certain special processing phases, PHP may jump out of the current flow too early without properly handling the internal data that has not finished initializing.

When the request ends and PHP starts cleaning up, it may treat this incomplete state data as normal data.

This corresponds to the warehouse situation above: the manager ended the order early because the desk space was insufficient, but during cleanup still inspected half-finished records by the standard of a normal order.

So how does an attacker make PHP run out of memory?

It doesn't necessarily require sending an absurdly large file. The official analysis mentions that certain crafted multipart requests (common in forms and file uploads) can trigger the problem, such as when the request contains too much additional information, or when certain input structures force PHP to allocate more memory than expected.

In other words, a request that doesn't look large can consume a lot of memory after being parsed internally by PHP.

Of course, merely exhausting PHP's memory is not enough to execute arbitrary code. The danger is that it combines with a flaw in internal state handling, giving an attacker a chance to continue exploiting it.

Once internal state is mishandled, the program can suffer memory corruption. On this basis, an attacker can divert the execution flow, and an ordinary request has the opportunity to become code execution on the server.

That is remote code execution (RCE).

So the focus of the first vulnerability is not "not enough memory," but rather that when PHP runs out of memory, its exception handling and cleanup are not handled properly, leaving an opening for attackers to affect program execution.

A workstation that wasn't cleaned up

The second vulnerability is CVE-2026-109619.

The first vulnerability can be described as "forced to interrupt before things were ready"; the second is "the previous employee has already left, and what he left behind is still being used by the next employee."

The previous employee clocked out, but the workstation wasn't cleaned up

Same warehouse.

A warehouse has many employees sharing one work system. To save time, employees don't have to completely shut down the system after finishing one order; the same employee will process several orders in a row.

After each order is processed, the system cleans up the materials used for that order and prepares for the next one.

The normal flow is like this:

  1. Employee A receives an order and creates records specific to this order.
  2. The order is completed and the system cleans up those records.
  3. Employee B receives the next order and starts using their own records.

There is a premise here: after the previous order ends, all references pointing to old records should be cleaned up.

But suppose Employee A's order is suddenly interrupted due to some error. The system destroys A's records but forgets to delete the markers in the public registry that point to these records.

At this time, Employee B starts processing his own order.

Before the new records are ready, the system first checks the public registry and finds A's old markers still there.

The system thinks the record is still valid and uses the old marker to access content that has already been cleaned up.

What's worse, the space that originally stored the old record may have been allocated to another purpose. What is read from the old address is no longer the original content.

If this erroneous data continues to affect program execution, the consequences are hard to say.

PHP also has such "old markers"

When PHP handles web requests, it uses some internal state to record information about the current request, such as error handling state, session-related state, and the state of objects and extensions.

In certain operation modes, after PHP processes one request, it does not exit the entire process; the same worker process goes on to process the next request.

Therefore, at the end of each request, PHP must clean up the data specific to that request and reset all internal state that may still point to this data.

This time, the problem occurs under specific circumstances: a previous request had a fatal error, or something else went wrong during the cleanup phase, causing some internal state to not be reset correctly.

The memory occupied by the request has already been released, but PHP internally still retains references to that memory.

Then the same worker process starts processing the next request. Before normal initialization is complete, some operations may access these stale references early.

This is a typical Use After Free.

The name is awkward, but the meaning is straightforward: the memory has already been released, and the program is still using it.

Why does it become a vulnerability? Because the program cannot guarantee that the released memory remains unchanged; it may be reallocated or overwritten by other data. If the program still treats this memory as the original data, it may read wrong content or perform operations that should not be performed.

Taken further, this kind of memory error can develop into remote code execution.

One point to clarify: this does not mean that the next person to visit the site can directly see all of the previous user's data. The vulnerability concerns the lifecycle management of PHP's internal state, not the leakage of the previous person's $_POST or other variables intact to the next person.

The real problem is that PHP retains references to internal state that has become invalid, and may use it when it should not.

What exactly is the difference between the two vulnerabilities?

Putting the earlier examples side by side makes it clear.

CVE-2026-109618 CVE-2026-109619
Everyday analogy The workspace ran out, the administrator interrupted work early, and then mishandled half-finished records The previous order had ended, but the system still kept markers pointing to old records
Core problem When memory is exhausted, the abnormal exit and cleanup path does not correctly handle internal state After a request ends, some internal state still points to freed memory
Key timing During request processing, especially when exceptions like memory exhaustion occur In the specific phase after a previous request ends and before the next request's normal initialization completes
Possible consequence Memory corruption, potentially escalating to remote code execution Use after free, potentially escalating to remote code execution

The symptoms are different, but the root is the same: neither is a business logic error, but rather problems in the PHP runtime's handling of memory and request state.

This is also why their scope of impact deserves attention.

An ordinary business vulnerability may only affect a certain page, a certain API, or a certain type of business operation.

The PHP runtime, however, is below the site's business code. As long as the application runs on an affected version under relevant conditions, the problem can appear before business code starts executing, or in low-level flows shared by multiple requests.

This does not mean every PHP site can be easily broken into. Actual exploitation still depends on conditions such as the runtime environment, server configuration, extensions, and request handling methods.

But once an attack succeeds, what the attacker obtains is code execution capability under the permissions of the web server process. For a site that can connect to a database, read configuration files, and call other services, this is already dangerous enough.

So the official rating of both vulnerabilities as critical is really not an overreaction.

There have been vulnerabilities before. Why is everyone so nervous this time?

Software vulnerabilities have always existed, and PHP has not had serious problems for the first time. The fact that even Japan's prime minister and the U.S. National Security Agency have come out to warn people, I think, has two reasons.

This time, it hit the bottom layer of the runtime

The consequences of both vulnerabilities are severe: attackers don't need to log in, can trigger them with network requests, and ultimately execute code on the server.

At the same time, PHP's application surface is too broad. It's not only in projects written by developers themselves, but also hidden in various content management systems, e-commerce, blogs, forums, and a large number of legacy business systems.

Many websites may not have had major changes for years, but they have been running stably.

What is affected is a large expanse of internet infrastructure still running PHP, not some niche product.

For governments, large enterprises, and cloud service providers, once this kind of vulnerability is exploited at scale, it involves user data, business continuity, and public services.

This is why relevant agencies ask to fix it as soon as possible, and if it really cannot be fixed, consider shutting down services exposed to the public internet first.

Previously, attacking a small website was not cost-effective; now that calculation is changing

In the past, there was a long distance from discovering a vulnerability to actually using it.

You had to understand the target software's implementation, analyze the cause of the vulnerability, determine which versions were affected, then study how to trigger the vulnerability reliably, and finally deal with compatibility issues in different environments.

This work consumes experience and time.

Large enterprises and government agencies can afford security teams; small websites don't have this condition.

Small companies may have no dedicated security staff. The website is placed on an ordinary cloud server, and the PHP version has not been touched for years.

In the past, attackers were not necessarily willing to spend so much time on such a small site. To put it bluntly, the cost could be higher than the gain.

This does not mean small websites were safe before, nor that no one attacked them. Automated scanning, mass exploitation, and credential stuffing have long existed; only the threshold and cost were different.

And AI is changing part of that cost.

AI may turn "patch release" into the starting gun for another race

There is another thing worth noting in this incident: AI is not only used to write business code; it is also beginning to participate in the discovery, analysis, and fixing of vulnerabilities.

According to Google Cloud, AI models participated in the discovery and validation of these two vulnerabilities. That is to say, AI has truly entered professional security research.

The problem is that the same capability can also be used to attack.

The fix itself also reveals clues about the vulnerability

Fixing a vulnerability usually requires changing the original code.

Suppose a version mishandles something. In the new version, developers adjust exception handling, add state cleanup, or change the memory management process.

For ordinary users, this is just a security update.

For security researchers, the code changes expose where the original problem was.

By comparing the source code before and after the fix, one can infer little by little:

This kind of analysis is not new. Security researchers have long done patch analysis and even used it to verify whether a fix is effective.

The change is that AI can take over some of the tedious work.

Previously, it took a long time to read the code of an unfamiliar project, sort out function call relationships, and then infer the cause of the vulnerability step by step.

Now AI can help read code, compare patches, summarize differences, suggest testing ideas, and even help researchers write verification programs.

Don't think that casually asking AI a question can stably break into any server. Actual exploitation still requires technical judgment, experimental verification, and understanding of the target environment.

But the part of the work that originally had a high threshold can indeed become faster and cheaper.

After a patch is released, both defenders and attackers can act faster

Before a vulnerability is fixed, usually not many people know the details. The development team releases a patch to let users fix it as soon as possible.

Once the patch is public, everyone can start studying what changed this time.

Security researchers analyze the patch to confirm whether the vulnerability is really closed; administrators upgrade versions; attackers may also reverse-engineer the old version's problem and think about how to hit systems that have not updated.

If attackers use AI to lower the cost of analysis and testing, the time from patch disclosure to a usable attack method will be shorter.

So a patch release is, in a sense, also the starting point for attackers to focus on old versions.

Of course, don't understand it as every patch release giving all attackers an immediate ready-made attack tool. Vulnerability complexity, target environment, patch quality, and protective measures all affect the outcome.

But for systems that have not been updated for a long time and are directly exposed to the public internet, this change is worth being alert to.

Security departments need to inventory assets, test patches, and arrange upgrades as soon as possible; small companies with insufficient resources may not even be able to say clearly which PHP versions they are running.

Once attack costs drop, systems that were previously ignored because they were "too troublesome and not worth it" will gradually enter attackers' field of vision.

This is why people outside the PHP community are nervous too. What national cybersecurity agencies and large platforms have to face is the speed at which the entire internet infrastructure responds to this kind of risk.

In the future, timely updates may matter more than before

We often hear a saying: as long as a project runs normally, don't casually upgrade dependencies.

This is not wrong. Production environments need to control change risk; you can't just put a new version into production without testing as soon as it is released.

But "don't casually upgrade" does not mean "never upgrade."

Security updates especially need a clear handling mechanism. When a serious vulnerability is found, first confirm as soon as possible whether your environment is affected, then arrange testing and upgrading. Don't wait until the website has problems to deal with it.

The fixed versions provided by the official PHP project this time:

For specific versions and scope of application, see the official PHP security announcement and the CVE-2026-109618 and CVE-2026-109619 advisories.

If you are still using PHP 8.1 or earlier, pay special attention: these versions are no longer within upstream's regular support scope. Some operating systems or commercial distributions will backport patches, but you can't judge whether it is fixed just by the version number; you need to confirm the security announcement of the corresponding vendor.

Upgrading PHP is not just a matter of changing a command. For Docker projects, confirm that the image has been updated and rebuild and deploy; for PHP-FPM projects, confirm that the running worker processes have actually loaded the fixed version; for managed hosting platforms, confirm whether the runtime there has been updated.

If it can't be fixed for now, do temporary isolation or restrict public access based on risk assessment. Don't expect that adjusting some configuration parameter will let you avoid it.

These things sound trivial, but in security issues, what is really easy to overturn is often not how difficult the technology is, but that no one is responsible for confirming whether it has been done.

For developers, this is also a small conceptual change: upgrading is no longer just for new features and performance, but also for maintaining the system's ability to run safely.

Whether you use PHP, Go, Java, Python, or another language, there is no way to guarantee that underlying dependencies will never have security problems.

The difference is only whether, when a problem is discovered, you have the ability to know in time and fix it in time.

Finally

Looking back, this incident doesn't have to be read as PHP being finished.

Any software that is complex enough and widely used enough may hide undiscovered flaws. Two critical vulnerabilities do not mean PHP has lost its value, and even less do they mean all PHP websites will be breached immediately.

But it reminds us of one thing: software security, besides writing correct code, also includes continuous maintenance and timely updates, and acting as soon as possible after a vulnerability is disclosed.

And the emergence of AI may make this offense-defense race run faster.

We certainly hope AI helps us find and fix problems faster; but we also have to admit that the same tools may lower the threshold for attackers.

Scenes like this will probably become more and more common: a vulnerability is disclosed, a patch is released, and the whole industry rushes to confirm whether it has been hit.

Of course, if you ask me, at the speed of internet development, there will probably always be a buffer overflow, IDOR, SQL injection, or something else that ends our entire online world.