PHP2Shell Explained: The PHP Flaw Found With AI, and What to Do About It

On October 21, 2026, the team behind PHP released emergency updates for two critical security flaws that are now called PHP2Shell. PHP is the programming language behind a very large part of the web, including WordPress, so a flaw in PHP itself matters far beyond one plugin or one website.

The flaws can let an attacker run their own code on a web server without logging in. They were found with the help of AI tools, and within hours of the news spreading, security companies were reporting waves of automated attacks. What many headlines skip is how many of those attempts have actually worked, and the honest answer right now is that nobody has shown it at scale.

This guide covers what happened, what is confirmed and what is not, how to check and fix your own site, and what AI-assisted hacking could mean in the months ahead. It is a fast-moving story. This page was last updated on October 24, 2026, and we will keep correcting it as better information arrives.

If you only have two minutes, do this: find out which PHP version your website uses, compare it with the table below, and ask your host to confirm the patch if you are not sure.

PHP2Shell is a nickname for two separate bugs in the PHP engine, the part of the software that reads and runs PHP code. PHP rated both 9.2 out of 10 on the CVSS v4.0 scale, which is the top end of critical. The security firm watchTowr rated them 10.0, but that was its own score, not PHP's.

The first flaw, CVE-2026-109618, is about running out of memory. When PHP cannot get the memory it needs partway through starting a request, it stops abruptly and then cleans up using data that was only half prepared. Researchers at Rapid7 explain that a specially built upload request can push PHP into that state even when the request looks small enough to be allowed.

The second flaw, CVE-2026-109619, is about leftovers. A PHP worker handles many requests one after another. Sometimes a request ends badly, for example with a fatal error or a timeout, and a piece of memory is released but a pointer to it is left behind. The next request on the same worker can then use that stale pointer. Security people call this a use-after-free.

The worst case is the one in the nickname. An attacker gets a shell, which means they can run commands on your server. From there they could read files, steal stored passwords and keys, or plant a backdoor. Wiz, one of the companies that found the flaws, said an attacker could read passwords, tokens and API keys out of a PHP process's memory.

The weak spot is old. Reports say the flaws affect nearly every PHP version back to 5.4, and that signs of the memory problem were spotted in a 2024 security audit but not fixed, because nobody found a way to turn it into code execution at the time. Apache's mod_php setup is considered the highest risk, since one request can trigger the problem before your own site code even starts. PHP-FPM, php-cgi, FrankenPHP and LiteSpeed setups are affected too.

These are the versions that contain the fix. If you run any of these or newer, you are covered for these two flaws.

• Many Linux systems and hosts fix problems without changing the version number. This is called backporting, so a version string like 8.1.30 does not tell you whether you are safe.
• Check the package changelog for the two CVE numbers instead of trusting the version alone.

Three groups found pieces of this independently, all around August, and all used AI. A California firm called Calif found the first problem on August 1 while taking part in an OpenAI project called Patch the Planet, using OpenAI's GPT-5.6 Sol model. The security company Wiz, which Google owns, found it on August 19 using several AI models plus its own tool. OpenAI then looked into it separately and found more. Fortune reports that they worked with the PHP Foundation and other companies on the fix.

Greg Brockman, OpenAI's president, said the bug had been in PHP for 14 years, and that a limited version of it had been seen in 2024 but was not considered important then. That is the part worth sitting with. People reviewed this code for over a decade and the dangerous path stayed hidden. AI tools, which can read huge amounts of code and test ideas quickly, connected the dots.

Wiz called it an AI inflection point in its own blog post. That is a company describing its own work, so read the wording with some caution. The underlying point still stands, and OpenAI made it too: the same abilities that help defenders find flaws before attackers do can also help attackers.

One note on sourcing. The AI details come from news reports and company blog posts, not from PHP's own advisory, so treat them as reported rather than independently verified.

Times are in UTC. The order matters, because it shows how little time defenders had.

This is where most coverage gets sloppy, so here it is as plainly as we can put it, based on what the sources say as of October 24.

• Confirmed: the two flaws are real, PHP rated them critical, and fixes exist for the supported branches.
• Confirmed: attack attempts have been recorded. Cloudflare, Amazon and watchTowr all report them, and several public proof-of-concept exploits exist.
• Not confirmed: that attackers have broken into sites at scale. Rapid7 has not observed exploitation in the wild, and The Hacker News reported that no source had confirmed a successful break-in of a specific server. CISA said on October 21 that it had not observed exploitation.
• Disputed: how easy it is. Rapid7 found that each public exploit works only for a particular mix of operating system, PHP version and web server. Sansec found they do not work against a default PHP install, and most need a separate bug in the target site. Rapid7 still expects a more portable technique to appear quickly.
• Misread: the 70% figure. About 69% of websites with a known server-side language use PHP, according to the figure cited on Wikipedia's incident page. That is PHP's popularity, not the number of vulnerable sites. Palo Alto Networks' early estimate was about 22.6 million potentially vulnerable instances, which is also an early figure.

Find the row that looks like your setup.

Do these in order. Most people finish the first five steps in well under an hour.

• Step 1: Find your PHP version. In WordPress, open Tools, then Site Health, then the Info tab, then Server. Hosting panels such as cPanel usually show it on a PHP version or PHP selector page. If you run your own server, remember that php -v only describes the command line copy of PHP. The copy that serves your site, such as PHP-FPM or Apache, can be a different build.
• Step 2: Compare it with the table above. If you are on a fixed version or newer, you are covered for these two flaws. If not, or if you are unsure, keep going.
• Step 3: Check for backported fixes. On Debian or Ubuntu, you can search the package notes for the CVE numbers with a command like apt changelog php8.3-cli | grep -E "CVE-2026-109618|CVE-2026-109619", using your own package name. On Red Hat style systems, rpm -q php-cli --changelog does the same job.
• Step 4: Update, then restart. Install the update from your host or package manager, then restart PHP-FPM, Apache and any long-running workers. A patch does nothing until the old processes are replaced. With containers, rebuild the image and redeploy, because patching a running container leaves the image itself vulnerable.
• Step 5: On shared hosting, ask your host. Send a short message asking whether the PHP2Shell patch for CVE-2026-109618 and CVE-2026-109619 is applied on your server. cPanel and CloudLinux have released backported fixes, so a good host may already be covered. If your host cannot give a clear answer, treat that as a warning sign.
• Step 6: If you cannot patch yet, use stopgaps, knowing they are incomplete. PHP's maintainers said updating is the only safe choice. Security firms list these temporary measures: turn off session upload progress (session.upload_progress.enabled=0) in server-level settings rather than in site code, then restart; on PHP 8.5 set fatal_error_backtraces=0; keep post_max_size low and limit request sizes at your web server or proxy; and if your site never accepts uploads, block multipart/form-data requests before they reach PHP. Some guidance also suggests memory_limit=-1, but that one is debated because it can raise memory use, so only use it on your host's advice.
• Step 7: Think about taking the site offline if you cannot patch soon and you hold sensitive data. The NSA, CERT-EU and the UK's NCSC advised that sites which cannot be updated promptly should go offline until they can. Sansec, writing about online stores, said that was not necessary for them. It depends on your risk.
• Step 8: Retest after patching. The fix adds a hard memory limit, so review memory_limit and post_max_size, then test your forms, checkout and file uploads.
• Step 9: Move off old versions. PHP 7.4, 8.0 and 8.1 get no normal updates, and PHP 8.2 security support ends on December 31, 2026. Plan a move to 8.3 or newer. Test plugins and themes on a staging copy first and keep a way to roll back.
• Step 10: Look for signs of trouble, especially if you were exposed for days. Researchers point to unusual multipart upload requests followed by memory limit errors or repeated HTTP 500 errors, very large PHPSESSID cookies, and PHP workers restarting for no clear reason. Rapid7 also notes that finding nothing in your logs does not prove you are safe.
• Step 11: If you think you were hit, assume secrets were exposed. Change passwords, rotate API keys and tokens, turn on two-factor sign-in and restore from a clean backup. Because the flaws can reveal data from PHP's memory, rotating secrets is sensible even when you cannot prove anything was taken.

PHP2Shell is a story about AI helping to find a bug. The bigger worry is AI helping to use bugs. Reporting over the past few weeks, mostly from Reuters and Fortune, describes several incidents. Some details are still estimates, and we have marked them that way.

• A campaign that began on September 25 used autonomous AI agents to try to break into more than 1,200 websites and reportedly compromised about 100 companies, according to Reuters. Researchers estimated the cost at roughly 5,000 dollars of AI usage, or about 50 dollars per successful breach. The attacker has not been publicly identified in the reporting we read.
• Several South Korean banks were breached in October. Reuters reported the attackers were likely based in China, and the Wall Street Journal reported that data on an estimated 68,000 people was stolen. Reuters also reported that the attackers used a state-developed AI tool built on open models together with commercial AI coding tools. The attribution is described as likely, not confirmed, and the 68,000 figure is an estimate.
• Hugging Face was attacked by an autonomous agent in July. In the week of October 18, an AI agent attacked the coding tool OpenCode nonstop for 48 hours and compromised accounts for about 1.4% of its users, and some people lost up to 1,700 dollars, according to Fortune.

Jessica Ji, a senior research analyst at Georgetown's Center for Security and Emerging Technology, told Fortune that AI tools have gotten meaningfully better over the past year at tasks like analyzing large volumes of code. Varun Chandrasekaran, a professor at the University of Illinois, said the low cost of AI agents fundamentally changes the economics of exploitation. TJ Sayers of the Center for Internet Security said AI helps turn complex exploit chains into practical attacks.

Put those together and the picture is simple. Attacks used to be limited by human time and skill. A lot of the searching, testing and retrying can now be handed to software that works all night for a small fee. That does not make every attacker a genius. It makes mediocre attackers faster and more persistent.

Nobody can predict this exactly, and anyone who sounds certain is guessing. Based on what has already happened, these are the developments we think are most worth planning for. The last two are our own judgment, not reported facts.

• The patching window keeps shrinking. Security firms recorded attack attempts within hours of the news, and Amazon says it saw one days earlier. For a small site, waiting for a monthly maintenance day is no longer a safe plan. Automatic updates, or a host that patches for you, are the realistic answer.
• Unsupported software becomes a permanent target. PHP 7.4, 8.0 and 8.1 will not get normal fixes. As finding flaws gets cheaper, attackers have more reason to hunt in software that will never be patched.
• Public exploits will get better. Rapid7 and Sansec both say today's exploits are unreliable, and Rapid7 expects a more portable technique to appear quickly. The gap between attempts and real breaches may close.
• More old bugs will surface. The PHP flaw hid in code for more than a decade. Other widely used open-source projects hold code of a similar age that people have reviewed but never searched this thoroughly. We would expect more finds like this one. That is good news when defenders find them first, and a problem when the fix takes weeks to reach everyone.
• Defenders get the same help. This bug was found by researchers using AI before it was publicly used, and Linux distributions received patches ahead of the release. Faster discovery on the defending side is real too.

These are our reading of the evidence, not predictions.

None of this is exotic. These habits protect you against the next flaw as well as this one.

• If you need to rotate secrets, the Secure Token Generator and Password Generator on this site create strong random values in your browser, and the TOTP Generator helps with two-factor codes.
• The Security Headers Analyzer and SSL/TLS Checker cover everyday site hygiene. None of our tools detects PHP2Shell, and we do not claim they do.