PHP: Twenty-Nine Years Of Leaving The Door Open

PHP2Shell, This Week

On 21st October 2026 the PHP project shipped four releases at once, 8.5.12, 8.4.27, 8.3.36 and 8.2.35, to fix two critical flaws in the interpreter itself¹. Not in WordPress. Not in a plugin. In PHP.

Both are rated 9.2 on CVSS 4.0. Both allow remote code execution with no login. The researchers who found them put the reach plainly: “Every PHP version released in the last decade is affected by at least one of these vulnerabilities, going back to version 5.4.”²

The PHP project’s own advisory says the rest:

And it was being used before anyone was told. Amazon’s honeypot network recorded an attempt on 17th October, four days before disclosure³. watchTowr saw it in the wild on the 21st, and working proofs of concept were public within hours of the patch⁴.

Both bugs are memory-safety bugs. One is in how the interpreter cleans up after running out of memory. The other is a use-after-free: memory owned by one request is freed and then read again, and the next request on the same worker can see it⁵⁶. Hold on to that second one. It comes back later.

None of this is new. That is the point of the post. PHP2Shell is not an accident that happened to a careful language. It is the latest page in a record nearly thirty years long, and every number in it is public.

One Process Holds Everything

I spent November 2014 to April 2017 as a third-line Linux engineer on Pulsant’s cloud and hosting platform. Part of that job was configuring PHP-FPM environments for e-commerce customers and tuning them to go fast.

PHP breaches were common. Not occasionally. Common. And they came down to two causes: poor deployment, and no separation between the front end and the back end.

The language makes the second one the default. A typical PHP site is one process. The page template, the business logic and the SQL all live in the same request handler, often in the same file. That process runs as one operating system user. It can read the database password, because the password is in a file next to the code. And it can usually write to its own web root, because that is how uploads and updates work.

That is not my opinion of how PHP gets deployed. It is what PHP and WordPress document.

Read that last row again. The vendor tells you what least privilege would look like, then tells you not to do it, because updates change the schema.

Compare the split version. The front end renders pages and holds no secrets. The back end is a separate service with its own user, a narrow API, and no write access to its own code. The database account can do what the back end needs and nothing else. OWASP’s guidance says the same thing in its own words: “The application’s backend database should be isolated from other servers”, on “a dedicated internal network segment”¹². PHP’s own manual says applications “should never connect to the database as its owner or a superuser”¹³.

None of that is exotic. It is what a proper process looks like. The reason it matters here is simple. In the split model, a bug in the front end gets an attacker a front end. In the usual PHP model, a bug anywhere gets them the templates, the code, the credentials and the data, in one go.

PHP-FPM helps, and PHP’s own install guide now marks it as the recommended way to run PHP under Apache⁸. Its pools can start workers “with different uid/gid/chroot/environment”¹⁴. But a pool per site is still one site per process, holding everything that site has. It is a better wall between customers. It is not a wall inside the application.

Keep that picture in mind through every section below. Each bug in the record lands on that process.

Twenty-Nine Years Of CVEs

The National Vulnerability Database lists every CVE filed against the PHP interpreter under one product identifier, cpe:2.3:a:php:php. Ask it, and it answers 757¹⁵.

That count is the interpreter only. No WordPress, no Drupal, no plugins, no frameworks. Just the program that runs your PHP.

Two spikes stand out. The first is March 2007, when a former member of the PHP security team ran the Month of PHP Bugs, disclosing flaws in the Zend Engine, the PHP core and its extensions “on a day by day basis”¹⁶. He had founded the PHP Security Response Team, then left it, and said why: “I dislike the ways bugs are handled”¹⁷. When the founder of a project’s security team walks out and publishes a bug a day, that tells you how the inside was going.

The second spike is 2016: 120 CVEs, 65 of them memory corruption. More on that below.

The memory figure is a floor, not an estimate. NVD tags a good number of older bugs as “Other” rather than with a weakness type, including some of the use-after-frees in the next section. The real figure is higher. I am using the one I can show.

The Engine Is Written In C

This is where the memory-safety argument has to be made carefully, because a PHP developer will quite rightly point out that their code never calls malloc. PHP scripts do not manage memory by hand. You cannot write a buffer overflow in PHP the way you can in C.

You do not need to. The interpreter running your script is written in C, and its extensions are written in C. Every byte of untrusted input your site receives, every header, every upload, every form field, every cookie, is parsed by that C before your code sees it. When that C is wrong, your careful PHP does not matter. PHP2Shell proved it: the advisory says the attack can fire “before any application code runs”¹.

The record shows what that C has got wrong:

Those are the classes the security agencies mean when they talk about memory safety. In November 2022 the NSA advised organisations “to consider making a strategic shift from programming languages that provide little or no inherent memory protection, such as C/C++, to a memory safe language when possible”¹⁸. In December 2023 CISA, with the UK’s National Cyber Security Centre among the co-authors, put a number on it: “two-thirds of reported vulnerabilities in memory unsafe programming languages still relate to memory issues”¹⁹.

Neither document names PHP. They do not need to. They name the language PHP is built from.

The worst repeated example is unserialize(), the function that turns a stored string back into PHP objects. It has had the same class of bug, in the same place, more than once:

The PHP manual knows. Its page for the function carries the warning: “Do not pass untrusted user input to unserialize() regardless of the options value of allowed_classes.”²³ That is a language telling you one of its own built-in functions is not safe to use on the thing most web code handles all day.

Then there is PHP-FPM, the process manager PHP’s own install guide recommends over mod_php. In October 2019, CVE-2019-11043 showed that “in certain configurations of FPM setup it is possible to cause FPM module to write past allocated buffers … opening the possibility of remote code execution”²⁴. The configuration in question was a common nginx setup. It was fixed on 24th October 2019²⁵. CISA later added it to its catalogue of vulnerabilities known to be exploited, flagged as used in ransomware campaigns²⁶.

The PHP Foundation did commission a proper security audit of the interpreter’s source, and credit to it for that. The results, published on 10th April 2025, found 27 issues, 17 of them with security implications²⁷. That is good practice and it should be normal. It is also 17 more, in an audit of a codebase that had already had nearly three decades of public bug reports.

The Language Made The Same Mistakes One Floor Up

The C is one layer. The language on top made the same kind of mistake in its design: trusting input it had no business trusting, and taking years to stop.

register_globals deserves its own line. For years, any parameter in the request, ?admin=1 say, became a variable in your script, and if your code checked $admin before setting it, the attacker had set it for you. The PHP manual itself called switching it off “the most controversial change in PHP”²⁹. Ten years from default-off to gone. That is how long the project tolerated a feature it knew was dangerous, because removing it would break sites.

The phar case is the same pattern a layer down. In 2018 Sam Thomas showed at Black Hat that ordinary file operations on a phar:// path would unserialise attacker-supplied metadata, bringing the unserialize() problem to functions nobody thought of as dangerous³⁶. PHP 8.0, in late 2020, stopped doing it automatically, “to fix potential security vulnerabilities due to object instantiation, autoloading, etc.”³⁴.

Then type juggling. PHP’s == converts types before comparing, so strings that look like numbers get compared as numbers. The RFC that fixed part of it in PHP 8.0 put it plainly: “This results in many surprising comparison results, the most notable of which is that 0 == “foobar” returns true.”³⁵

That fix was real. It was also partial. Here is the same check run in the official php:7.4-cli and php:8.5-cli containers, the second being 8.5.12, the release patched for PHP2Shell this week, with the two outputs side by side:

$ php -r 'var_dump(0 == "foobar");'
bool(true)            # 7.4.33
bool(false)           # 8.5.12

$ php -r 'var_dump("0e462097431906509019562988736854" == "0e830400451993494058024219903391");'
bool(true)            # 7.4.33
bool(true)            # 8.5.12

Two different strings, equal. Both start 0e followed by digits, so PHP reads both as zero times ten to the power of something, and zero equals zero. Both are the shape of an MD5 hash. Compare a stored password hash with == instead of === or hash_equals(), and any input whose hash happens to start that way matches. It has been documented for years. It still works in the newest release.

That is the language in one example. A fix that went in, half of the problem left behind, and the safe version needing you to know a different operator exists.

A Shell, Nearly Every Year

The question worth asking of any platform is not how many bugs it has had. It is how often somebody could take the whole server without a password and without anyone clicking anything.

NVD scores every CVE. Filter the 757 for the score that means exactly that, network attack, no privileges, no user interaction, high impact on confidentiality and integrity, and you get 172¹⁵.

172 across 23 of the 28 years that have any PHP CVE at all. Only five are blank. 2016 alone has 65.

A severity score is a rating, not a break-in. So the second half of the picture is the CISA Known Exploited Vulnerabilities catalogue, which only lists flaws with confirmed exploitation in the wild²⁶. Of its 1,754 entries as of 21st October 2026, 81 are PHP itself or applications written in PHP:

2026 is already the worst year for PHP in the catalogue, and PHP2Shell is not in it yet. Three of this year’s are in WordPress core itself: two added on 21st July, and a remote file inclusion on 25th September.

And the catalogue under-counts PHP badly. It is built around US federal systems and needs a CVE plus confirmed exploitation. It holds 3 WordPress plugin entries. The WordPress plugin ecosystem logged 11,334 vulnerabilities in 2025 alone³⁷. The 81 is the part somebody official wrote down.

WordPress Multiplies It

WordPress is 39.6% of all websites, and 58.3% of the sites whose content management system can be identified³⁸. PHP is the server-side language of 69.3% of the sites where that can be seen³⁹. So whatever PHP’s record is, WordPress takes it to a very large part of the web, and then adds its own.

Core is not the main problem. The plugins are.

Wordfence, with its own database, counted 8,223 for 2024, a 68% rise on 2023, and found “Roughly 35% of the vulnerabilities disclosed in 2024 remain unpatched in 2025”⁴¹. Different databases, different totals, same shape.

Sit with the 2025 numbers for a moment. Nearly half of the vulnerabilities had no fix from the developer by the time they were made public. And for the ones attackers actually go after, the median gap from disclosure to mass exploitation is five hours. Most people do not check their plugin updates every five hours. Most people cannot.

The plugin model is the multiplier. A site’s security depends on the least careful author of anything installed on it, and Wordfence found “over one third of developers are unreachable or unresponsive” when told about a flaw⁴¹. Patchstack counted 1,614 plugins and themes pulled from the repository in 2024 for security issues nobody fixed⁴⁰. And because of the one-process model, every plugin runs with the full rights of the site.

The incidents are a long list. These are the ones with primary sources behind them:

I have been careful with the 2016 row. Wordfence showed the firm’s site was running a slider version that was trivially exploitable. It did not show that was how the documents were taken, and I am not going to claim more than the evidence does.

How The Malware Stays

Getting in is half of it. Staying in is the other half, and PHP makes that easy for a reason that goes straight back to the one-process picture.

The interpreter will run any .php file it can reach. The web root is usually writable by the same user that runs the code. So once an attacker has any way to write a file, an upload form, a plugin bug, a file manager, they can write a script that runs every time somebody requests it. That is a web shell: a small file, sitting in your site, taking commands.

CISA has said for years which languages these are mostly written in: “The most commonly observed web shells are written in languages that are widely supported, such as PHP and ASP.”⁵⁰ The NSA and the Australian Signals Directorate’s joint guidance calls them “a long-standing, pervasive threat that continues to evade many security tools”, and difficult to detect because they are “easily modified by attackers and often employ encryption, encoding, and obfuscation”⁵¹.

The clean-up numbers show how often they are there:

So in the most recent clean-up year, half the hacked sites still had a way back in sitting on disk. Restore the database, patch the plugin, and the attacker walks back through the file they left.

There is no clever fix for this. There is the boring, proper one, and the NSA wrote it down: “web applications should not have permission to write directly to a web accessible directory or modify web accessible code”⁵¹. That single sentence is the split-tier model from the start of this post, said by an intelligence agency.

WordPress’s hardening guide, for what it is worth, never mentions stopping PHP from running in the uploads directory at all¹¹. That is why the table cites OWASP and the NSA instead.

Notice what is not in that table. PHP’s own hardening settings. The manual is honest about them. disable_functions “can be circumvented and should not be considered a sufficient security measure for shared hosting environments”, and open_basedir “is just an extra safety net, that is in no way comprehensive, and can therefore not be relied upon when security is needed”⁵⁵. When a language’s own documentation tells you its security knobs are not security boundaries, believe it. As such, the boundary has to come from outside the process.

Even php.net Got Broken Into

If the project’s own infrastructure were solid, you could argue the record is down to a hard problem handled well. It has been broken into twice.

The 2021 one is the one that matters. Somebody pushed code into the language’s own source tree, impersonating the people who maintain it. It was caught. The project’s answer is worth quoting because it is the right one, said plainly: “maintaining our own git infrastructure is an unnecessary security risk”, and the repositories moved to GitHub⁵⁷.

Credit where it is due: that was a good decision, made fast, and explained in the open. But look at what it admits. For years, the canonical source of a language running most of the web lived on self-run infrastructure that the project itself decided was a risk it should not be carrying.

Half The Web Runs A Version Nobody Patches

All of the above assumes the site is up to date. A great many are not.

php.net currently supports four branches. 8.2 gets security fixes only, until 31st December 2026. 8.3, 8.4 and 8.5 are the rest⁵⁸. Everything older is end of life: 8.1 since 31st December 2025, 8.0 since November 2023, 7.4 since November 2022⁵⁹.

Now the measured share of what is actually running:

PHP 7.4 alone, out of support for nearly four years, is about a fifth of all PHP sites that show their version. WordPress’s own requirements page asks for PHP 8.3, then says WordPress “also works with PHP 7.4+”, while noting those versions “have reached their official End Of Life”⁶³. A vendor that still runs on a dead version is a vendor that has decided not to make you move.

Two honest caveats. W3Techs only sees the version on sites that advertise it. And some Linux distributions backport fixes into old PHP builds, so “unsupported by php.net” is not always “unpatched”. But PHP2Shell is the test of that. The project did publish source patches for 7.4, 8.0 and 8.1 this time¹, and someone still has to build them, ship them and install them. On a shared host running a version nobody owns, that someone is nobody.

I Gave Up On It. You Should Look At Leaving Too.

I used to write PHP. After Pulsant I gave up on the language, because of the issues it caused and the work those issues made. Not one bad incident. Years of the same two causes, on site after site, and the clean-up landing on whoever was on shift.

So I will say it plainly. If the choice is yours, look at leaving it. Better tools exist for this now, and Go is the one I would point you at first.

Not because it is fashionable. Because it removes, by default, most of what this post has been counting:

Compiled matters twice. It is faster: Go programs “are compiled ahead of time to native machine code”, with no virtual machine underneath, and one of its stated design goals is “to approach the performance of C for comparable programs”⁶⁶. And it is more secure, because there is no interpreter in the request path parsing code at run time, and no C engine of 757 CVEs standing between the network and your program. PHP, left to itself, does the opposite. Without OPcache it loads, parses and compiles every script on every request, needlessly, thousands of times a minute on a busy site. OPcache exists to stop that, “removing the need for PHP to load and parse scripts on each request”⁶⁴. But it is not on out of the box. Up to and including 8.4 it is a separate shared extension that somebody has to load with zend_extension and configure. Only PHP 8.5 builds it in: “The Opcache extension is now always built into the PHP binary and is always loaded”⁷⁰. The project’s own RFC for that change says “running PHP in production without OPcache is generally considered a mistake”⁷¹. W3Techs puts 8.5 on 4.5% of PHP 8 sites⁶⁰, so for nearly everything running today the fix for compiling every script on every request is still an add-on somebody had to remember. And even loaded, what it caches is bytecode for the C interpreter to run. Go does the compiling once, before the program ever sees a request.

Faster and more secure, provided it is coded properly. That last clause is the whole of the next few paragraphs.

Go’s template package puts its design in one line: it generates “HTML output safe against code injection”, and “The escaping is contextual, so actions can appear within JavaScript, CSS, and URI contexts.”⁶⁷ Its database guide is just as plain: “You can avoid an SQL injection risk by providing SQL parameter values as sql package function arguments.”⁶⁸ Those are the defaults. In PHP they are things you have to know to go and get.

The row I would underline is the dropped file. Half the hacked sites Sucuri cleaned in 2023 still had a backdoor on disk⁵³, and that only works because the interpreter will run any script it can reach. A compiled service does not go looking for scripts. There is nowt for a dropped file to plug into.

Now the honest part, because a language is not a cure. Go is more memory safe, not perfectly so. Its own memory model says a data race on a slice, a map or an interface value “can in turn lead to arbitrary memory corruption”⁷², and Go ships the tool to catch it. Build with -race, or run go test -race, and the binary is compiled with a detector that reports a race the moment one happens. It catches races at run time rather than at compile time, and “can’t find races in code paths that are not executed”, so it belongs in every test run and under a realistic load⁷³. PHP has nothing like it. Keeping one request’s memory away from the next is left entirely to the engine, and PHP2Shell is that engine getting it wrong: memory freed by one request, read by the next on the same worker⁶. Outside that, Go stops the memory-corruption class this post has been counting, and makes the safe way the easy way for two more. It does not stop a broken login check, a missing permission test or a query built by gluing strings together if you insist on doing that. Go publishes its own security advisories too, through its vulnerability database⁶⁹. And a Go service run as root out of a writable directory is still badly deployed.

What it changes is the default. PHP’s default is one process holding everything. Go’s default is a program that does one job, which is the split from the start of this post with most of the work already done. If Go does not suit your team, Rust is the other way out. Both compile ahead of time to native code. Rust runs “with no runtime or garbage collector”⁷⁴, and Go’s compiler and runtime have been “implemented in Go and assembler, without C” since Go 1.5⁷⁵.

C# and Java are on the agencies’ memory-safe list too¹⁸, but they are not a way out of the problem this post started with. Each runs on a virtual machine written in C++. OpenJDK’s HotSpot is “around 3000 C/C++ header and source files, comprising more than 1.2 million lines of code”⁷⁶, and .NET’s garbage collector and JIT compiler are C++ source in the CoreCLR tree⁷⁷. That is the same shape as PHP: a large native engine between the network and your code. And Java loads code into a running application by design. Its standard class loader exists “to load classes and resources from a search path of URLs referring to both JAR files and directories”⁷⁸, and Log4Shell turned that into remote code execution: an attacker who controlled a log message “can execute arbitrary code loaded from LDAP servers”⁷⁹. It went straight into CISA’s catalogue²⁶. It is the same door as PHP’s, with more ceremony in front of it.

So pick Go or Rust. Move the back end first, one endpoint at a time, and leave the PHP front end holding nothing worth stealing until it can go as well.

If You Are Still Deploying It This Way, Can You Call Yourself A Professional?

There is enough evidence above that this has stopped being an opinion. So here is the question, put directly. If you are still deploying PHP as one process that holds the code, the credentials and a writable web root, can you call yourself a professional?

It depends on which of three people you are. And knowing which one is not something that happens to you. Making sure you know is the job.

You have a real constraint, and you have written it down. A product the business depends on only exists in PHP. A migration is costed and in next year’s budget. Fine. That is professional, provided the reason is on paper with a date next to it, the runtime user cannot write the code, uploads cannot execute, the database account is cut down, and you patched PHP2Shell this week. You are running a known risk on purpose, with the walls you can put round it.

You have never been told. Nobody showed you the record, and the tutorial you learnt from put everything in one directory. That is a gap, and everybody has gaps. It stops being a gap the moment you have read this far.

You know, and you build it anyway. You have seen the numbers, or enough of them. You know the database password sits in the web root and the web root is writable. You deploy it like that because it is quicker, because the client will not pay for better, and because nobody has made you justify it. That is the case this question is aimed at. The failing is not the gap in your knowledge. It is building across a gap you have already seen and never went back to close.

Everybody was there once. Staying there by choice is the part that is not defensible.

The Door Was Always Open

What strikes me reading this record is not that PHP has bugs. Every language does. It is how little of it was ever a surprise.

The project knew register_globals was dangerous in 2002 and removed it in 2012. Its manual tells you not to trust unserialize(), not to trust disable_functions, not to trust open_basedir. Its own documentation says a script under mod_php can reach the database without a password. The agencies have been saying for years that the language it is built from is where two-thirds of the memory bugs come from. Every warning is there, in writing, from the people who should know.

And it kept winning anyway, because it was cheap. Cheap to host, cheap to learn, cheap to sell to a customer who wanted a website by Friday. One directory, one process, one password in a file, and a site that worked. What it was priced at was a shared hosting plan. What it cost was never on the invoice: the clean-ups, the backdoors left on disk, the customers’ card numbers lifted by malicious PHP, the five-hour window between disclosure and the attack.

That is the bit I have no patience for. Not the bugs. The decision, made over and over by people who knew better, that the cheap way was good enough because nobody was checking. A standard is the thing you keep when nobody is checking. The split between front end and back end, the read-only code, the cut-down database account: none of it is new, none of it is expensive, and all of it would have turned a good many of the incidents above into nowt worth writing about.

PHP2Shell is not the end of this record. It is just this week’s entry. The language will patch it, the hosts will roll out the update eventually, and the version share will drift up the way it always does, slowly. What decides whether the next one costs you is not PHP. It is whether you built the walls it never gave you, or moved to something that comes with them.