PHP's fix for two critical flaws is out. Update now.

Update, October 29, 2026

Two new developments. CISA now lists a Linux kernel flaw as exploited and says it can be chained with the PHP flaws to take full control of a server. And Palo Alto Networks says its own firewalls' management pages are being attacked through the PHP flaws and has released fixes. Update PHP first. If you run your own Linux server, also install the kernel update and reboot. If you run Palo Alto firewalls, install the hotfix and keep the management page off the internet.

• CISA lists a Linux kernel flaw as exploited, and says it chains with PHP2Shell. On October 28, CISA added CVE-2026-46300, a Linux kernel flaw that Red Hat and others call "Fragnesia," to its Known Exploited Vulnerabilities (KEV) catalog, "based on evidence of active exploitation." The catalog entry for it says: "This vulnerability can be chained with CVE-2026-109618 and CVE-2026-109619 to implant PHP webshells and run commands as root." A webshell is a small file that gives an attacker a remote control panel on your server, and root means full control of the machine. That sentence is in CISA's catalog entry, not in the short alert text. CISA's deadline for federal agencies is October 31, and the entry is marked "Forensic triage required per BOD 26-04: Yes," the same flag as the two PHP flaws, which means agencies must check whether they were broken into before patching. It lists known use in ransomware campaigns as "Unknown." (CISA alert, CISA KEV catalog)
• What the kernel flaw is. Red Hat describes it as a flaw in a part of the Linux kernel that handles encrypted network traffic (ESP-in-TCP). A "low-privileged local attacker" can use it to write bytes into the cached copy of read-only system files and "gain root privileges." Red Hat rates it Important rather than Critical because it needs local access first. That is why the chain matters: the PHP flaws can give an attacker that first foothold on a web server. Red Hat says RHEL 8, 9 and 10 and products built on its kernel are affected, and published kernel updates in May, for example RHSA-2026:20051 on May 21 for RHEL 8.6 extended support, which says the system must be rebooted for the update to take effect. Other Linux distributions have their own updates. (Red Hat, Red Hat security bulletin, Red Hat advisory RHSA-2026:20051)
• A security firm says an attacker used the chain on firewalls. Dream, a security firm, reported on October 26 that it found artifacts of a campaign in which an attacker chained both PHP flaws with this kernel flaw to take root control of 25 servers in the United States, Japan, Taiwan and South Korea. Dream says the devices were firewalls running "specific versions of a large vendor's firewall software." Dream says it is not naming the vendor or versions, and that the vendor has been notified. SecurityWeek reports the attacks took place on October 23 and 24. Dream says the attacker went further on a few of the servers, which belonged to a US government-affiliated organization, setting up a tunnel into its internal network and then going after its Active Directory, the system that controls logins. Dream counts three servers there, two firewalls and a firewall management server. SecurityWeek's summary says two. Dream says it cannot tell how far the later attacks got. Dream says the signs point to a Chinese-nexus operation but it does not name a group. This is Dream's account, which we have not independently confirmed. CISA's catalog entry separately says the kernel flaw is exploited and can be chained with the PHP flaws, but it does not mention Dream's campaign. (Dream, SecurityWeek, The Hacker News)
• Palo Alto Networks says its management pages are being attacked. Palo Alto's own advisory for the two PHP flaws now says: "Active exploitation has been observed targeting the Palo Alto Networks management interface exposed to the internet." The Hacker News reports Palo Alto added this on October 28, and the advisory page now shows an update dated October 29. It rates the issue 9.2, Critical. It affects PAN-OS on PA-Series and VM-Series firewalls and on Panorama, and says "no special configuration is required to be affected." It also says the issue "strictly affects the management web interface, which includes the HTTPS web UI and XML API service," and that a data-plane interface is affected only if a management profile is attached to it. Palo Alto lists Cloud NGFW and Prisma Access as not affected, and says GlobalProtect and the captive portal are not impacted. (Palo Alto Networks advisory, The Hacker News)
• Palo Alto's fixes. Palo Alto says the risk "is highest on PAN-OS when you allow access to the management interface from external IP addresses on the internet." Its advisory lists a fixed hotfix for each supported PAN-OS maintenance release. The newest ones for each line are 12.2.4-h1, 12.1.10-h3, 11.2.16-h1, 11.1.16-h4 and 10.2.18-h13. As of October 31, the advisory shows every hotfix as released. Its October 29 timeline entry reads "Removed ETAs for 11.1.7-h12 as the version is released." For the 11.1 line, the advisory lists either the hotfix for your release or 11.1.16-h4 or later. Older unsupported versions have to move to a supported fixed version. Palo Alto says the same hotfix also covers the Brotli flaw, with one exception: 11.2.10-h16 has only the PHP fix and 11.2.10-h17 has both. (Palo Alto Networks advisory)
• Palo Alto's mitigation. "The security risk posed by this issue on PAN-OS and Panorama is minimized by restricting access to the management interface to only trusted internal IP addresses according to our recommended best practice deployment guidelines." Palo Alto also lists threat signatures for customers with a Threat Prevention subscription, but says they protect against this issue only if management traffic is routed through a data-plane port, decrypted and inspected, so they are not a substitute for the hotfix. (Palo Alto Networks advisory)
• Are the Dream and Palo Alto reports about the same attacks? Not confirmed. Dream does not name its vendor. The Hacker News wrote that the timing of Palo Alto's update "suggests that these events may be related," and said it had contacted both companies for comment. We found no confirmation from Dream or Palo Alto, as of the morning of October 29, that the two are connected, and we are not saying they are. Palo Alto's advisory does not mention Dream. (The Hacker News, Dream, Palo Alto Networks advisory)
• This is not the retracted Unit 42 claim. Our October 26 update explains that Palo Alto's Unit 42 retracted, on October 25, its earlier report of a break-in at a European government entity. That retraction still stands on its page. The new statement is different: it comes from Palo Alto's product security advisory and is about attacks on the management page of its own firewalls, not about that case. (Palo Alto Networks advisory, Unit 42)

What to do

PHP first: the fixed versions have not changed. Update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or newer, or your host's patched build, then restart every PHP worker. php.net lists no newer releases as of October 29. If you run your own Linux server, also install your distribution's kernel update and reboot, because a kernel update does not take effect until the machine restarts. If a managed host runs the server, ask them to confirm both. If you or your IT provider run Palo Alto firewalls or Panorama, install the hotfix for your PAN-OS version from Palo Alto's advisory, and make sure the management interface cannot be reached from the internet; Palo Alto says to limit it to trusted internal addresses. If any web server, firewall or Panorama that was reachable from the internet was not updated, treat it as possibly compromised until someone has checked. Dream's report lists signs to look for: a very small PHP file in a folder the web server serves, the system file /etc/pam.d/su changed so that root needs no password, and a service or boot script that opens an SSH tunnel to an outside address. The absence of these signs does not prove a server is clean. EverThread does not test for these flaws. Our scans check your home page from the outside and cannot see your kernel, your firewalls or whether anyone got in. (Dream, Palo Alto Networks advisory, Red Hat)

Update, October 27, 2026

CISA has added both PHP2Shell flaws to its list of flaws known to be exploited. It orders federal agencies to patch by October 29 and to check for break-ins, not only patch. If your server is not updated, update now, then check it for signs of a break-in. We are also correcting earlier updates that said neither flaw was on CISA's list.

• CISA now lists both flaws as exploited. On October 26, CISA added CVE-2026-109618 and CVE-2026-109619 to its Known Exploited Vulnerabilities (KEV) catalog and updated its PHP alert. CISA says a flaw must have "evidence of exploitation" to be added to the catalog. It says "these types of vulnerabilities are a frequent attack vector for malicious cyber actors and pose significant risks to the federal enterprise." BleepingComputer notes CISA has not yet shared details about the attacks it knows of. (CISA, BleepingComputer)
• A deadline for federal agencies. Under its Binding Operational Directive 26-04, CISA requires US federal civilian agencies to fix both flaws by October 29, 2026. That rule applies only to federal agencies, but CISA says it "encourages all organizations to adopt risk-based vulnerability management and prioritize remediation of KEV Catalog vulnerabilities." (CISA KEV catalog, CISA, The Hacker News)
• CISA says check for a break-in, not just patch. CISA's catalog entries for both flaws are marked "Forensic triage required per BOD 26-04: Yes." CISA says that directive sets "basic expectations for when agencies must check whether threat actors compromised the system before the patch was applied." In plain words: updating PHP closes the hole, but it does not tell you whether someone already got in. The same catalog entries list known use in ransomware campaigns as "Unknown." (CISA KEV catalog, CISA)
• CISA's advice. CISA tells organizations to find every system running any version of PHP, noting that PHP is often a component of other software, and to patch internet-facing systems first. It says those that cannot update right away, or that still run PHP 8.1 or earlier, should take their PHP-based systems offline until they are patched. It says a web application firewall "may provide some protection" until then, and to watch for PHP worker processes launching shells or downloading tools. (CISA PHP alert)
• Tens of millions of services still on an affected version. The Hacker News reports that, according to Censys, more than 32.51 million PHP services are still running an affected version. That is Censys's count of services, not a count of hacked servers, and it measures something different from the other counts on this page. (The Hacker News)
• Correction: we said neither flaw was on CISA's list. That is no longer true. Our October 23 and October 26 updates said neither flaw was in the KEV catalog. That was true when we wrote it, based on the version dated October 23. CISA added both on October 26. We have marked those items below. (CISA KEV catalog)

What to do

The fix has not changed. Update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or newer, or your host's patched build, then restart every PHP worker. On Windows, use the new -1 builds described in the October 26 afternoon update below. On PHP 8.1 or older, make sure your host has installed a backported fix. If you cannot update right away, CISA says to take the PHP-based system offline until it is patched. After updating, ask your host or developer to check for signs of a break-in going back to at least October 17, the earliest attack attempt Amazon has reported, including PHP worker processes that started a shell or downloaded tools, as CISA describes. If you find signs of a break-in, the FBI says to isolate the affected systems, keep your web server and PHP logs, and report it to your local FBI field office or at ic3.gov. EverThread does not test for these flaws. Our scans flag an out of date PHP version only when a site shows it in its X-Powered-By or Server headers. Many hosts hide the version, and a hidden version gets no warning, so no warning does not mean a site is safe. Our scans cannot prove a server is patched or tell whether it was attacked.

Update, October 26, 2026, afternoon

A public exploit has now beaten a standard PHP server in an open challenge, and most PHP servers that show their version are still not updated. If yours is one of them, update now.

• An open challenge, beaten in under a day. GovInfoSecurity reports that on Sunday, October 25, researcher Jaydip Modhwadia, who goes by "KillaBoi" on GitHub, used the PHP2Shell flaws to break into a standard PHP 8.4.26 server that researcher James Pavur had set up as a public "Steal My Bitcoin" challenge. It took about 19 hours from when Pavur set it up, and Modhwadia collected the prize, bitcoin worth about $2,000. This was a deliberately exposed challenge server inviting anyone to try, not a business. (GovInfoSecurity)
• A different setup from this morning's case. Alon Gal, CTO of the threat intelligence firm Hudson Rock, said the exploit worked "around Nginx's 1MB request limit," GovInfoSecurity reports. That means the challenge server sat behind the Nginx web server, not the Apache mod_php setup of the decoy server in this morning's update. (GovInfoSecurity)
• "Game over, patch this urgently." Security researcher Matthew Hickey said the exploit "is very much public. It does require a few server-side conditions but they exist in production environments so it's game over, patch this urgently," GovInfoSecurity reports. Modhwadia has published his exploit script. We do not link to it. (GovInfoSecurity)
• Most servers still show an unpatched version. OX Security said on October 26 that five days after the fix, 93.6% of the PHP instances it could measure on Shodan, a search engine for internet-connected devices, were still on unpatched versions. It says about 1.33 million affected hosts run end of life PHP branches. OX counts only servers that publicly show their PHP version and leaves out hosts that hide it. A version number also cannot prove patch status, since some hosts fix older versions without changing the number; see "A version number is not proof" below. (OX Security)
• PHP on Windows: get the new build. On October 26, PHP also rebuilt its official Windows packages, now numbered 8.5.12-1, 8.4.27-1, 8.3.36-1 and 8.2.35-1, to fix a separate flaw in the Brotli compression code they include, CVE-2026-111497. The new builds keep the PHP2Shell fixes. If you run PHP on Windows, install the -1 build. Details are in our Brotli notice. (php.net)

What to do

The fix has not changed. Update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or newer, or your host's patched build, then restart every PHP worker. On Windows, use the new -1 builds. On PHP 8.1 or older, make sure your host has installed a backported fix. If your server was not updated right away, ask your host or developer to check for signs of a break-in going back to at least October 17, the earliest attack attempt Amazon has reported. EverThread does not test for these flaws. Our scans flag an out of date PHP version only when a site shows it in its X-Powered-By or Server headers. Many hosts hide the version, and a hidden version gets no warning, so no warning does not mean a site is safe. Our scans cannot prove a server is patched or tell whether it was attacked.

Update, October 26, 2026

A working attack has now been caught in the wild. Attackers took over a researcher's decoy server running unpatched PHP through these flaws, BleepingComputer reports. Every unpatched server faces an attack that has now worked outside a lab. Update now. We are also correcting our October 24 update: Palo Alto Networks has withdrawn the break-in it had linked to these flaws.

• Confirmed code execution on a decoy server. BleepingComputer reported on October 26 that the two PHP2Shell flaws, CVE-2026-109618 and CVE-2026-109619, "have been successfully exploited in the wild." Adel Karimi, detection and response lead at Perplexity, says his honeypots, decoy servers set up to attract attackers, recorded "confirmed RCE," meaning the attacker ran their own commands, on an Apache mod_php server running PHP 8.4.26. That is one release behind the fixed 8.4.27. PHP has said the risk is highest for mod_php. This was a decoy server, not a real business or organization. (BleepingComputer)
• It appears to use a public exploit. Karimi says a memory address used in the attack was worked out with "the public exploit's offsets," which points to an exploit that anyone can already get. Expel researcher Marcus Hutchins called it "by far the highest quality confirmation of in-the-wild php2shell exploitation I've seen so far." (BleepingComputer)
• Until now, no known compromises. BleepingComputer says that until Karimi's findings, Dataminr's threat research team described the activity as "limited to scanning, fingerprinting, and use of non-working exploits, with no known compromises." (BleepingComputer)
• Suspected North Korea-linked scanning. The Hacker News reported on October 25 that security firm CYFIRMA found a campaign it links, with moderate confidence, to the North Korea-linked Lazarus Group ecosystem. CYFIRMA says it is slowly scanning a list of 216 unpatched or partly protected PHP hosts in several countries, including online transaction platforms, and that "Exploitation is the next step." CYFIRMA has not reported a break-in from this campaign. (The Hacker News)
• Correction: Unit 42 has withdrawn its break-in report. Our October 24 update said Palo Alto Networks' Unit 42 had reported the first confirmed break-in through these flaws, at a government organization in Europe. On October 25, Unit 42 retracted its October 23 update. It says what its researchers saw was an attack on that organization "executed in the context of a vulnerable PHP application," and that "We are unable to confirm that initial access is associated with the specific PHP2Shell CVEs." TechCrunch has also removed its reference to Palo Alto Networks. Unit 42's estimate of "over 22.6 million exposed instances potentially vulnerable" to the flaws is still on its page. We have marked the October 24 update below. Separate from this retraction: on October 28 Palo Alto Networks' own security advisory began reporting active exploitation of the management interface on its firewalls through these flaws. See the October 29 update above. (Unit 42, The Hacker News, TechCrunch)
• Was not on CISA's list when we wrote this; now it is. Correction: when we wrote this, neither flaw was in CISA's Known Exploited Vulnerabilities catalog, as of the version dated October 23, checked October 26. That changed later on October 26: CISA added both flaws. See the October 27 update above. Not being on that list never meant an unpatched server was safe. (CISA KEV catalog)

What to do

The fix has not changed. Update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or newer, or your host's patched build, then restart every PHP worker. php.net lists no newer releases as of October 26. On PHP 8.1 or older, make sure your host has installed a backported fix. If your server was not updated right away, ask your host or developer to check for signs of a break-in going back to at least October 17, the earliest attack attempt Amazon has reported. If you find signs of a break-in, the FBI says to isolate the affected systems, keep your web server and PHP logs, and report it to your local FBI field office or at ic3.gov. EverThread does not test for these flaws. Our scans flag an out of date PHP version only when a site shows it in its X-Powered-By or Server headers. Many hosts hide the version, and a hidden version gets no warning, so no warning does not mean a site is safe. Our scans cannot prove a server is patched or tell whether it was attacked.

Update, October 24, 2026

Correction, October 26, 2026: On October 25, Unit 42 retracted the break-in described in this update. It says it cannot confirm the attackers got in through these PHP flaws. The original items are kept below for the record and marked. See the October 26 update above. As first published, this update said Unit 42 had reported attackers getting into a government organization in Europe and reaching password data within two hours.

• Retracted by Unit 42 on October 25. On October 23, Palo Alto Networks' threat research team, Unit 42, updated its threat brief on the two PHP flaws, CVE-2026-109618 and CVE-2026-109619. It said that in one case the attackers "targeted a government entity in Europe and within two hours of the initial exploitation they had successfully accessed password hashes and multi-factor authentication secrets." Unit 42 said they also set up a tunnel into the organization's Active Directory, the system that controls logins on a Windows network, and tried to gain Domain Admin, the highest level of control over that network. Unit 42 did not name the organization. On October 25, Unit 42 retracted this and said it is "unable to confirm that initial access is associated with the specific PHP2Shell CVEs." (Unit 42, The Hacker News)
• Also retracted: signs of an AI-driven attacker. Unit 42 said it "observed attackers using agentic AI attack platforms" after the attack, meaning AI tools that carry out attack steps on their own. It said the commands used, run as short tasks one after another with quick changes of approach after failures, are "strong indicators of an agentic attacker." This was part of the October 23 update that Unit 42 retracted on October 25. (Unit 42)
• Over 22.6 million potentially vulnerable. Unit 42 says Palo Alto Networks' Cortex Xpanse has identified "over 22.6 million exposed instances potentially vulnerable" to the two flaws, based on its own data. That is Palo Alto Networks' own estimate of exposure, not a count of servers known to be unpatched or hacked, so it measures something different from the Censys and VirusTotal counts in the October 22 update. (Unit 42)
• Not mass break-ins, yet. TechCrunch reported on October 24 that there "haven't been any signs of mass-exploitation." Its first version also described "confirmed compromises and post-exploit activity," citing Palo Alto Networks among others. TechCrunch has since removed its reference to Palo Alto Networks after the retraction, and now cites Trail of Bits as saying there are working exploits. Attack attempts are still widespread, and every unpatched server is still exposed. (TechCrunch)

What to do

Update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or newer, or your host's patched build, then restart every PHP worker. These minimum versions have not changed. On PHP 8.1 or older, make sure your host has installed a backported fix. If your server was not updated right away, ask your host or developer to check for signs of a break-in going back to at least October 17, the earliest attack attempt Amazon has reported. After updating, change admin passwords and keys, because Sansec says an unpatched server can leak passwords and keys from its memory. If you find signs of a break-in, the FBI says to isolate the affected systems, keep your web server and PHP logs, and report it to your local FBI field office or at ic3.gov. EverThread does not test for these flaws. Our scans can flag an out of date or end of life PHP version when a site shows it, but many hosts hide the version, so no warning does not mean a site is safe. Our scans cannot prove a server is patched or tell whether it was attacked.

Update, October 23, 2026, afternoon

The FBI now says to update PHP immediately, or take the system offline if you cannot. Changing a setting does not fix the two original flaws. Only the update does.

• The FBI has issued a public warning. On October 23, the FBI's Internet Crime Complaint Center (IC3) published a public service announcement about the two flaws, CVE-2026-109618 and CVE-2026-109619. It says they "could allow malicious cyber actors to remotely execute code" and that security updates "should be applied immediately." It adds: "If you are a business owner or website operator, check whether your systems are affected." (FBI IC3)
• What the FBI says to do. If an immediate update is not feasible, take the system offline "until it can be fully mitigated." Find every place PHP runs, starting with systems that face the internet and vendor products that bundle their own PHP. Watch web servers for PHP processes that unexpectedly launch command shells or download files. If you find signs of a break-in, isolate the affected systems, keep your web server and PHP logs, and report it to your local FBI field office or at ic3.gov. (FBI IC3)
• Only patching fixes the original flaws. Datadog Security Labs says it independently reproduced the flaws, and that "Only patching fixes these vulnerabilities." It says mitigations going around, such as setting session.upload_progress.enabled=0, "don't fully protect you." Datadog also says a successful attack does not necessarily crash PHP or return an error. (Datadog Security Labs)
• Not on CISA's list as of October 23. Added October 26. Neither original flaw was in CISA's Known Exploited Vulnerabilities catalog as of its October 23 version, published at 3:30 PM ET. CISA added both on October 26; see the October 27 update above. Not being on that list never meant an unpatched server was safe. (CISA KEV catalog)

About this morning's update

This morning's update covers a new, separate issue, CVE-2026-115560. PHP says turning off session.upload_progress.enabled fully protects against that one issue. It does not fix the two original flaws. For those, PHP says there are no complete mitigations, and Datadog says patching is the only complete fix. If you turned the setting off, keep it off, and install the update too. (php.net, Datadog Security Labs)

What to do

Update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or newer, or your host's patched build, then restart every PHP worker. These minimum versions have not changed. If you cannot update right away, the FBI, CISA and the NSA all say to take the system offline until it is fixed. On shared hosting, ask your host to confirm the fix is installed. EverThread does not test for these flaws. Our scans can flag an out of date PHP version when a site shows it, but they cannot prove a server is patched or tell whether it was attacked.

Update, October 23, 2026

PHP has warned about a new, separate flaw. It is unlikely to affect most sites. The two original flaws are still the urgent problem, so keep updating.

• The new issue, CVE-2026-115560, needs an unusual setup. On October 23, PHP published an informational advisory about "an unlikely RCE vector" through a PHP feature called session upload progress. PHP says it can only happen when an app sets session.serialize_handler to php_binary or php_serialize in its configuration, then switches it to php with ini_set() before calling session_start(), while session upload progress is still turned on. PHP says "this setup is unlikely in practice," and apps that never change that setting while running can leave the feature on. (php.net)
• No emergency release for it. PHP is fixing it in its next regular bugfix release and will publish a full advisory for CVE-2026-115560 then. The Hacker News reports that the October 21 updates do not fix it, that PHP has not yet said which versions are affected or how severe it is, and that no attacks on this new issue have been reported. (php.net, The Hacker News)
• As of this update, attacks on the original two flaws continued, with no confirmed break-ins. Unit 42 reported one on October 23 but retracted it on October 25. On October 26, BleepingComputer reported a confirmed successful attack on a researcher's decoy server; see the October 26 update above. Sophos and Arctic Wolf say some attempts tried to install Potassium, a botnet built from the Mirai malware that can flood other systems with traffic. Sophos says the attempt it saw was blocked and failed, and Arctic Wolf says it could not confirm that the malware was downloaded or run. Wordfence, Sophos and Previdian each say they have not seen a confirmed successful break-in through these flaws yet. (Sophos, Arctic Wolf, Wordfence, Previdian)
• That can change quickly. VulnCheck told The Register it has built an exploit that runs code on a server using PHP's recommended production settings, even with a key memory protection called ASLR turned on. It has shared it only with its own customers. Wordfence adds that not seeing a confirmed break-in "is not evidence that an unpatched server is safe." (The Register, Wordfence)

What to do

If you have not already, update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or your host's patched build, for the original flaws. For the new issue, PHP suggests setting session.upload_progress.enabled=0 until its next regular release. Set it in php.ini, a PHP-FPM pool or the server configuration, then restart every PHP worker. PHP says not to rely on ini_set() or .user.ini for this. If you turned this setting off after PHP's October 21 advisory, keep it off and nothing more is needed for this new issue. You still need the update for the two original flaws. On shared hosting, ask your host. EverThread does not test for this new issue, and our PHP version warning cannot tell whether this setting is on. (php.net, PHP advisory GHSA-6wmf-4rv5-p3rp)

Update, October 22, 2026, afternoon

There are now fixes for older PHP versions, and experts disagree on how easy real attacks are. Update anyway.

• Fixes now exist for PHP 8.1, 8.0 and 7.4. These versions are still end of life, but PHP says "the PHP security team provided minimal source-backports for PHP 7.4, PHP 8.0, and PHP 8.1 to help people building from source or without access to an LTS vendor." PHP does not give these backports new version numbers. (php.net)
• Big hosting control panels have patched older PHP too. cPanel ships fixed ea-php74 7.4.33-19, ea-php80 8.0.30-12 and ea-php81 8.1.34-5 packages. Plesk's fixed 8.1, 8.0 and 7.4 builds for Linux are dated October 21, 2026. DirectAdmin added patches for 8.1, 8.0 and 7.4 and says the "PHP version is the same." In each case the PHP version number does not change, so ask your host to confirm the fix is installed. (cPanel, Plesk, DirectAdmin)
• A working attack has been shown. CrowdStrike says it "verified end-to-end that a single anonymous POST request can cause an Apache mod_php worker to launch a shell process and execute an attacker-specified command, with no authentication, no session, and no vulnerable application code involved." (CrowdStrike)
• But it may be harder in the real world. Red Hat gives both flaws a score of 8.1 out of 10 for its own products and says that on its standard setup, which uses PHP-FPM rather than mod_php, running code is "difficult in practice." SecurityWeek reports that watchTowr has seen mass exploitation attempts, but none of the circulating proof of concept exploits achieve code execution. Sansec now says "mass exploitation is less likely than we first expected" because an attack needs specific knowledge of the target server and specific conditions on it. Sansec adds that a researcher who tested the public proof of concept exploits found they "do not work against a default PHP installation," and that most need the target site to already have a separate serious flaw, a local file inclusion bug. Sansec still says: "Update PHP anyway." (Red Hat, SecurityWeek, Sansec)
• Many servers may never be fixed. Cisco Talos estimates that a significant share of PHP systems, about 50%, will not receive a patch. (Cisco Talos)
• The NSA has weighed in. In an October 21 press release, the US National Security Agency said "Cyber actors are likely to weaponize PHP2Shell vulnerabilities." It recommends replacing end of life PHP and, "If an immediate update is not feasible," taking the system offline "until it can be fully mitigated." The NSA did not say attacks are already succeeding. (NSA)
• Japan's government took pages offline as a precaution. Japan's Finance Ministry temporarily suspended some PHP content on October 21 and began restoring it on October 22. The Tokyo Metropolitan Government paused some services and says no damage to the Tokyo government or local municipalities has been found. The Japan Meteorological Agency paused some data pages, said this was a precaution and not because of a cyber attack, and kept its weather and tsunami warnings online. Japan's Chief Cabinet Secretary said no damage to government websites from the flaws has been reported. (Finance Ministry, Tokyo Metropolitan Government, Japan Meteorological Agency, The Mainichi)
• Not on CISA's list of exploited flaws as of October 22. Added October 26. As of 3:55 PM ET on October 22, neither flaw was in CISA's Known Exploited Vulnerabilities catalog, whose latest version was published October 21 at 10:04 AM ET. CISA adds a flaw to that list when it has reliable evidence of exploitation. Not being on it does not make an unpatched server safe. (CISA KEV catalog)

Update, October 22, 2026

Attackers are now going after this flaw at scale.

• Amazon says PHP2Shell "is now being broadly exploited in the wild." Its honeypots caught a first exploitation attempt on October 17, four days before the flaws were made public, and more proof of concept exploits appeared within hours of the October 21 release. Amazon says it is not yet clear whether those attempts would have worked on real systems. (AWS Security Blog)
• Cloudflare CEO Matthew Prince said Cloudflare saw "thousands of attempts" in the 10 hours before the announcement, then "tens of thousands in the 45 minutes post announcement, hundreds of thousands within 2 hours, and millions now." (SecurityWeek)
• Not every attempt is a break-in. Security firm watchTowr says many of the exploits being sprayed "either don't work at all, test for timing-based differences, or crash the target." But unpatched servers are being hit over and over, and it only takes one attempt that works.
• Censys counted approximately 1.57 million internet-facing hosts reporting a PHP version that was not patched as of October 21. VulnCheck says at least 1 million run end of life PHP versions. (SecurityWeek)
• Amazon advises investigating from at least October 17, not from the day the fix came out. If your site was not updated right away, ask your host or developer to check for signs of a break-in going back to that date.
• Governments and companies around the world pulled their websites offline to install the fix before they could be attacked, The Guardian reports. The UK's National Cyber Security Centre sent 50,000 alerts to affected organisations and said it had no reports of successful hacks from the flaw so far. (The Guardian)
• Even security companies took action. Wordfence, the WordPress security company, took its website, plugin servers and Wordfence Central offline on October 21 from 8:33 AM to 11:44 AM ET while it put protections against PHP2Shell in place. (Wordfence status page)
• VirusTotal tracks more than 5.1 million PHP hosts exposed online, according to BleepingComputer. That counts PHP servers reachable from the internet, not only unpatched ones, so it measures something different from the Censys count above. (BleepingComputer)

What to do (same advice, more urgent now)

• Update PHP to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or your hosting company's patched build.
• Restart PHP (PHP-FPM or Apache) so the fixed version is actually running.
• If you cannot confirm you are patched, ask your hosting company today.
• PHP 8.1 and older are end of life. PHP has published minimal source fixes for 7.4, 8.0 and 8.1, and cPanel, Plesk and DirectAdmin ship patched builds, but these keep the old version number. Ask your host to confirm the fix is installed, and plan your move to PHP 8.2 or newer.
• The US cyber agency CISA says organizations that cannot update immediately, or that still run PHP 8.1 or earlier, "should take PHP-based systems offline until they can be patched or updated."

If your site is hosted on Plesk

Plesk has patched the PHP it ships: 8.5.12, 8.4.27, 8.3.36 and 8.2.35. On Plesk for Linux, the end of life PHP 8.1.34, 8.0.30 and 7.4.33 packages keep the same version number, and Plesk says builds dated October 21, 2026 include the fix. The Plesk control panel runs on PHP too and needs its own update: Plesk Obsidian 18.0.81 Update 4 or 18.0.80 Update 11. Ask your host to confirm both.

If your site is hosted on cPanel

cPanel's October 22 notice lists fixed EasyApache 4 PHP packages: ea-php85 8.5.12, ea-php84 8.4.27, ea-php83 8.3.36 and ea-php82 8.2.35, plus the ea-php81, ea-php80 and ea-php74 builds above. It also lists fixed releases of cPanel & WHM itself: 11.110.0.153, 11.134.0.66, 11.136.0.50 and 11.138.0.18 (WP Squared 11.138.1.17). Server admins refresh the package data, then run /scripts/update-packages. To confirm the fix, cPanel says to look for CVE-2026-109618 in the package changelog, for example rpm -q --changelog ea-php81-php-cli | grep -m1 CVE-2026-109618 (cPanel gives a zgrep command for Ubuntu). cPanel servers on CloudLinux use CloudLinux's own packages, and for PHP older than 7.4 cPanel points to TuxCare's Extended Lifecycle Support. On shared hosting, ask your host to confirm. (cPanel)

A version number is not proof

A version number your server shows cannot prove whether it is patched. Some hosts fix older versions without changing the number, as Plesk, cPanel and DirectAdmin did for PHP 8.1, 8.0 and 7.4. EverThread's PHP warning reads that number, so it cannot confirm your patch status either way. It still flags PHP 8.1 and older because they are end of life, even if your host has added a fix. Only your host can confirm your patch status.