https://x.com/i/article/2113093470856572928
AI digs up a bottom-layer PHP vulnerability that has been hidden for more than a decade, and cybersecurity will never go back to the old days.
Last night may have been a nightmare for cybersecurity.
It was also a sleepless night for many engineers.
All I can say is that our whole era and society, under the acceleration of AI, are becoming frazzled.
Here is what happened.
It started the day before yesterday, that is, late at night on October 20 around 11 p.m., when a post suddenly appeared on Hacker News.
The title was terrifying: two PHP remote code execution vulnerabilities rated CVSS 10.0 were about to be made public.
The poster wrote that apart from "source: trust me, bro," he had no evidence at all, and even attached the vulnerability numbers.
However, posts like this can be seen by the hundred every day online, and nobody took it seriously.
But this one was confirmed a few hours later by a security company called watchTowr. Their exact words were: "We were supposed to wait until Thursday."
That was awkward, because the vulnerabilities were serious, the information had already leaked, and people with bad intentions could start exploiting them. But PHP's official security update was still being packaged, originally scheduled for the night of the 22nd. Suddenly there was a two-day gap, and if the vulnerabilities were exploited and systems breached within those two days, the consequences would be unthinkable.
After another hour or so, the PHP official team hurriedly issued a notice: the security update originally planned for October 22 was forced to move up to 10 p.m. on the 21st (Beijing time), compressing the time as much as possible.
As a result, right after the official notice went out, something even more absurd happened.
A security firm involved in discovering the two vulnerabilities, called Calif, accidentally posted an attack demonstration video online, which fully demonstrated that this world is a giant makeshift operation.
In the video, they showed how to use these vulnerabilities to successfully run attack verification programs against multiple targets. Although the video was deleted quickly, someone had already saved it and began spreading it widely in the community.
Now it was even worse.
Before, everyone only knew there were two serious vulnerabilities and didn't even know how to attack them. Now there was an attack demonstration video, and it was practically a step-by-step tutorial.
Then, under the crazy acceleration of AI, security researchers began reproducing the flaws faster, and all kinds of code online claiming to exploit the vulnerabilities began to appear.
At this point, there were only 16 hours left before the patch that could fix the security holes would be officially available for everyone to download.
Sixteen hours of life-or-death time. In the past, malicious actors might not have been able to launch large-scale attacks in such a short window, but now we are in the AI era, and 16 hours seems like too long for people accelerated by AI.
Even more absurd, at 3:41 p.m. on the 21st, a company making container images released a patched image more than six hours ahead of the agreed time. The PHP Foundation exploded: "It ignored weeks of coordinated work among multiple parties."
Because these days, people who know what they're doing can feed the old and new versions of the code to AI for a brute-force comparison and immediately figure out where the vulnerability is. They use AI to study the patch, use AI to reverse-engineer the vulnerability, and then use AI to develop attack programs.
But many ordinary website administrators still had no update package they could directly install, which meant attackers effectively had x-ray vision and got a head start.
So, chaos broke out.
On the 21st, one by one, the Netherlands' digital identity system, its parliamentary website, and even the National Cyber Security Centre's own website went offline.
Finland's government IT service provider also shut down a batch of services. BambooHR, an American HR software company, shut down its service outright and warned customers that payroll-related operations might be affected. Japan's niconico and pixiv entered emergency maintenance.
Because there are simply too many PHP websites in Japan, even Sanae Takaichi went on X to suggest preventive shutdowns until the PHP update was pushed at 10 p.m.
A vulnerability in a programming language made Sanae Takaichi post in the middle of the night and made several governments proactively pull the plug. Frankly, I have never seen a scene like this.
And so the world stumbled through those more than ten hours.
No one knows what the dark side underwater gained during those ten-plus hours.
At 10 p.m., the PHP security update went live. For these two serious vulnerabilities, there were no complete mitigation measures, so updating was the only safe option.
At the same time, OpenAI came forward to claim that these two epic-level PHP security vulnerabilities were discovered with GPT assistance.
And this vulnerability wasn't found by some new model. It was found a few months ago using GPT-5.6 Sol, so you can imagine: if the unreleased, stronger internal models of these large model companies were used to scan, then the various network infrastructures around the world might really all have problems...
At the same time, OpenAI also urgently released a skill to help you check whether your website would be affected.
I hope everyone pays close attention: if your website uses PHP and you didn't know about this news, please update immediately, the moment you see this, and also share it with your friends.
I know many people will say, it's just one vulnerability, why make such a fuss?
I think to understand why this became such a big deal and why the global reaction was so extreme, you first need to know what PHP is.
I'm not an expert, so I can only describe it as best I can in the language I know.
First, we probably all know that when you open a web page in your browser, the server has to compute on the spot what this page should display, such as who you are, what's in your shopping cart, how many comments are under this article, and so on. The program that does this work is called the backend.
PHP is one of the most commonly used languages for writing backends.
However, because it's so old, many companies' new products or new technology stacks no longer use it much. Interestingly, within the programmer community, PHP has long been a target of mockery. The joke "PHP is the best language in the world" has been around for more than a decade, and many people think it belongs to the last century.
But globally, websites built with PHP still account for 70%. Even in China, which has many Java sites, based on October 2026 data, more than half of websites are still built with PHP.
Everyone mocks it, but honestly, everyone also depends on it.
The forums you've registered on, the payment page of a small shop, the service websites of many local governments, the reimbursement system inside companies, and the admin panels of routers and NAS devices likely all run on PHP.
It's like the old water pipes under the city. Usually no one thinks about them, but once one bursts, the whole street gets flooded with filth.
This time, PHP itself burst.
The vulnerability has a name: PHP2Shell. A shell is a server's command line. If you get it, you can basically consider yourself to have gained control of that server, so the name is extremely direct: from PHP, straight to your server.
It has two numbers, CVE-2026-109618 and CVE-2026-109619.
You can think of a CVE as the vulnerability's ID number, unified globally.
Severity is scored using CVSS, out of 10 points. The earliest leaked version was rated the full 10, but the final score was actually 9.2.
To explain these two vulnerabilities clearly, we first have to talk about a concept that everyone has recently been feeling the pain of:
Memory.
When a program runs, it constantly "borrows" memory from the system to store temporary data, then "returns" it after use. PHP's interpreter is written in C. C runs fast, but the borrowing and returning are still entirely up to the programmer to keep track of. The system doesn't care.
So if this bookkeeping goes wrong, trouble follows.
The first vulnerability, CVE-2026-109619, has the technical name "use-after-free."
For example, you run a hotel. The first guest comes to store luggage, and the attendant puts their things into locker number 18 and writes it down in a logbook.
Later the guest leaves, the locker is emptied, and it's reassigned to a second person.
Here's the problem: the attendant forgot to erase the original entry in the logbook.
The second person has just put their things in, and the attendant, holding the old record, goes to open locker 18, thinking the luggage inside belongs to the first person.
Now there's trouble. He might see the second person's belongings, or even damage what's inside.
PHP's issue occurs in a similar way: memory that was already returned gets reused to store new data, but PHP still keeps a reference pointing to the old location.
So it thinks it's handling the previous data, but it's actually touching another piece of data. If an attacker can carefully manipulate this process, they have a chance to read or tamper with data they shouldn't touch, and even go further to take control of the server.
This is called use-after-free.
At a mild level, it can let someone read other users' passwords, tokens, and API keys from the server's memory. At a more serious level, after carefully arranging the memory, an attacker can make your server directly execute their own code, and the consequences would be unthinkable.
The second flaw: emergency evacuation when memory runs short. This is CVE-2026-109618.
This one is more interesting. Let's use the hotel analogy again.
Suppose the hotel has a luggage storage area. Every time a guest comes to store luggage, the attendant must first increase the count in the logbook by 1, and then put the luggage into a locker.
The first nine items go smoothly. When it comes to the tenth item, the attendant has just changed the count from 9 to 10 and is about to put the luggage away.
Suddenly, the power goes out. The luggage hasn't been put in yet, so the whole system is forced to halt.
Then something even more absurd happens. The hotel starts an emergency cleanup procedure, and the cleanup staff look at the logbook: today a total of 10 pieces of luggage were stored.
So they check each one according to the number in the logbook.
The problem is, the tenth piece of luggage was never actually put in. That spot may still contain all sorts of old junk.
Cleaning staff don't know or care about any of that. They just follow the logbook and handle it as ordinary luggage.
Now the whole system may be at risk.
The second PHP vulnerability this time works on a similar principle.
When it organizes data, it first increments the count by 1, then stores the actual data. If memory runs out precisely between these two steps, PHP urgently aborts the operation.
But the cleanup code that runs afterward still processes the data according to the count that was already incremented.
As a result, memory that was never properly initialized can be treated as normal data.
If an attacker can carefully engineer this situation, they get a chance to take further control of the server.
And the most frightening part is that under certain server configurations, this can happen even before the website's own application code starts running.
No matter how careful you were with your own website, you may not even get a chance to act.
Does this matter to ordinary people? Of course it does. Your own computer and phone won't be affected, but the websites you've used might be. If some unmaintained small site gets hacked, the accounts, passwords, phone numbers, and all the other information you left there could leak along with it.
This is also why many engineers have been saying these past couple of days that C, where memory is entirely managed by humans, was bound to produce this kind of problem sooner or later, and that memory-safe languages like Rust refuse to let you make these mistakes at compile time. That's why OpenAI specifically sponsored the Rust Foundation this time, and it's not without reason.
Back to these two vulnerabilities. Looking back through history, we find they are not new at all.
In 2004, German security researcher Stefan Esser discovered PHP's first remote vulnerability related to the memory limit. At the time, the methods for exploiting this kind of attack were never made public and only circulated secretly among a few security firms.
That particular problem was fixed, but its siblings are still around.
In 2024, the PHP Foundation received funding from Germany's Sovereign Tech Agency and, coordinated through OSTIF, commissioned French security firm Quarkslab to conduct an external security audit of PHP, the first in many years.
While fixing one of the issues, a core developer hired by the foundation found a similar vulnerability. He theoretically believed it could be exploited, but honestly, he couldn't find a concrete attack path.
The fix then dragged on. The security team went back and forth between several approaches, stopping and starting again. Later, the PHP Foundation admitted in its retrospective that this was a "structural failure" caused by the security team's decision-making process and insufficient staffing.
Then we arrive at 2026.
In May this year, the security firm Calif, mentioned at the beginning, launched a series called "AI Vulnerability Discovery Month." One article used Claude to uncover a memory vulnerability in PHP that was 21 years old.
Then AI kept accelerating, unstoppable.
On July 30, Calif began auditing PHP as part of OpenAI's security program "Patch the Planet."
In just two days, by August 1, they found the first entry point capable of triggering "memory exhaustion."
On August 11, Calif reported the vulnerability to PHP. That same day, OpenAI's own researchers independently reported the same issue.
On August 15, PHP confirmed that the attack demonstration Calif submitted did work.
On August 24 and September 18, the security firms Wiz and OpenAI successively reported more attack paths.
Because these two vulnerabilities were so severe and involved PHP's core, partners around the world began organizing a coordinated fix. Cloud providers, system distributors, and security firms all needed to prepare in advance, because publicly disclosing the vulnerability before then could actually give attackers an opening.
This is a stark contrast: in 2024, a core developer searched for a long time without finding how to exploit the vulnerability. In 2026, from the start of the audit to finding the first entry point took only two days.
And what's even more absurd is this.
The entire internet stands on a pile of code that nobody pays for and few people carefully examine.
This time is no different. The PHP Foundation itself admits that this memory issue showed signs back in 2024, and one important reason it has dragged on until today is a shortage of people. At the end of the retrospective, they were almost pleading, hoping companies, hosting providers, and governments would sponsor them.
Someone on Hacker News dug up the sponsorship page of the Debian maintainer responsible for packaging PHP and complained: under $700 a month?
Meanwhile, the servers of the whole world are truly just waiting for these people to get up in the middle of the night and push releases.
But if these foundational software packages are this fragile, why has the internet mostly held up all these years?
The reason is quite simple, much like the REA reverse engineering that went viral a while ago.
Because finding vulnerabilities is too expensive.
Just as many people are unwilling to reverse engineer commercial software, the protection of much commercial software comes from others not understanding it and not wanting to spend the time studying it.
The number of people in the world who can find and exploit memory vulnerabilities in places like PHP's core or OpenSSL may be only a few hundred.
Their time is expensive, and a single vulnerability can take months to grind out. So many landmines can be quietly buried for twenty years simply because no one is willing to bother with them. The cost is too high.
But AI has wiped out all the "expensiveness" of the past.
Anthropic announced this month that from November last year to early October this year, its models identified 29,439 candidate vulnerability leads across open-source projects.
OpenAI's long article tonight also says that these two PHP bugs are just one of several major vulnerabilities they have found and are fixing, and that over the next few months "similar discoveries will increase dramatically."
PHP2Shell is not the end, just the beginning. This kind of thing will only become more frequent in the future, without a doubt.
But the core bottleneck now emerges, much like in mathematics. Proofs and discoveries in mathematics are getting faster and faster, but the real bottleneck has moved to verification. The 700-plus papers OpenAI released not long ago would take mathematicians around the world at least several months, perhaps a full year, to verify.
Cybersecurity is the same. Discovering this PHP vulnerability took only two days.
But fixing it took a full two months.
Vulnerabilities will be found more and more, but there are nowhere near enough people who can fix these foundational flaws.
This is like the old saying:
"A thief can work for a thousand days, but how can defense hold out for a thousand days?"
This reminds me of a story.
In 1871, Carroll, author of "Alice's Adventures in Wonderland," published the sequel "Through the Looking-Glass." In it, there is a Red Queen who pulls Alice along as they run desperately. After running for a long time, Alice finds that the scenery around them hasn't changed at all.
The Red Queen tells her: "Here, you have to run as fast as you can just to stay in the same place."
This seems to be the predicament AI is bringing to society today.
It's not just security. Scientific discovery is accelerating, code writing is accelerating, software copying is accelerating, attacks are accelerating, and defense is accelerating too. Good things and bad things are all accelerating wildly together.
And each of us is in this Red Queen's race.
The cost of stopping is the old websites no one remembers, the back-end systems set up fifteen years ago and never logged into since, the company systems still running PHP 5. In a slow world they can sit safely for many years, but in a fast world they are sitting ducks.
Trust me, this world surely has countless unmaintained old PHP projects, and right now, they are all targets.
That humans can't outrun AI is no longer up for debate.
But throughout this whole story, at every critical decision point, the ones standing there are still people.
Some with good intentions, some with malicious ones.
Now this all-powerful tool has been handed to everyone.
Will justice triumph over evil?
AI can give humanity power beyond what was once unimaginable overnight, but it cannot give humanity the restraint to match that power overnight.
When the speed of technological progress
far outstrips the speed at which human nature matures,
are we heading toward a better world, or accelerating toward our own abyss?
To be honest, I don't know anymore.
That's all. Since you've read this far, if you think it was worthwhile, feel free to like, comment, and repost. That helps us a great deal~
Thanks for reading my article. See you next time.