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

Update, October 24, 2026

The first confirmed break-in has been reported. Palo Alto Networks' Unit 42 says attackers got into a government organization in Europe and reached password data within two hours. If your server is not updated, update it now.

• A real break-in, step by step. 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 says 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 says 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, and its brief does not say which of the two flaws was used. (Unit 42)
• Signs of an AI-driven attacker. Unit 42 says it "observed attackers using agentic AI attack platforms" after the break-in, meaning AI tools that carry out attack steps on their own. It says the commands used, run as short tasks one after another with quick changes of approach after failures, are "strong indicators of an agentic attacker." (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 as of late Friday there were "confirmed compromises and post-exploit activity," and also that there "haven't been any signs of mass-exploitation." Attack attempts are still widespread. A confirmed break-in shows these attacks can work on a real system, 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 the attackers Unit 42 describes went straight for passwords and login secrets. 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)
• Still not on CISA's list. Neither original flaw is in CISA's Known Exploited Vulnerabilities catalog as of its October 23 version, published at 3:30 PM ET. Not being on that list does not make an unpatched server 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 has since reported one; see the October 24 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 yet on CISA's list of exploited flaws. As of 3:55 PM ET on October 22, neither flaw is 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.