TL;DR: What is the PHP vulnerability everyone is searching for?
On 20 October 2026, the PHP security team announced an emergency release for two critical vulnerabilities in PHP, the language behind WordPress, WooCommerce, Magento, Laravel and most of the web. PHP rated both flaws 9.2 out of 10 (CVSS v4.0), and the fix came out on 21 October 2026: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP confirms both bugs allow unauthenticated remote code execution, which means an attacker can take over the server without logging in. PHP says there are no complete mitigations, so update today, and ask your host when they install it. PHP 8.1 and older get no official release. On 23 October PHP flagged a third, narrower issue, CVE-2026-115560: set session.upload_progress.enabled=0 until its next regular release.
Last updated 4 Nov 2026, 14:30 CET. A successful break-in on an unpatched server is confirmed, and CISA lists both flaws as exploited. Nothing new has come out since 28 October: on 4 November php.net still shows no regular release with the fix for the third issue (CVE-2026-115560), so keep session.upload_progress.enabled=0 until it ships. This was our last scheduled update.
Update 28 Oct, 23:00 CET: The first successful break-in is confirmed, and CISA now lists both flaws as exploited. On 26 October BleepingComputer reported that Adel Karimi, detection and response lead at Perplexity, recorded confirmed remote code execution on a honeypot running Apache mod_php with PHP 8.4.26, an unpatched version. He adds that the test used a deliberately favourable single-worker setup, so it doesn't measure how reliable the exploit is on other setups. The same day CISA added CVE-2026-109618 and CVE-2026-109619 to its Known Exploited Vulnerabilities catalog, with a 29 October deadline for US federal agencies. Also on 26 October PHP published rebuilt Windows packages (8.5.12-1, 8.4.27-1, 8.3.36-1 and 8.2.35-1) with Brotli 1.2.1, which fixes CVE-2026-111497, a separate flaw that only reaches Windows builds through cURL when automatic response decompression is switched on. CVE-2026-115560 still has no fix: by 28 October PHP had not shipped its next regular release, so keep session.upload_progress.enabled=0.
Update 24 Oct, 14:17 CEST: PHP has flagged a third issue. In an informational advisory on 23 October at 10:12 UTC, PHP asks everyone to set session.upload_progress.enabled=0 until its next regular bugfix release, to close "an unlikely RCE vector" now tracked as CVE-2026-115560. It only reaches apps that switch the session serialize handler at runtime with ini_set() before session_start(). The 21 October releases don't fix it, and if you already set this switch as a mitigation on 21 October, keep it. The attacks so far keep failing. Sophos saw attackers try and fail to install a Mirai botnet variant called Potassium, Cloudflare counted millions of attempts by early 22 October, and Censys still counted 34.4 million vulnerable PHP services on 23 October, as The Hacker News reported. SOCRadar found a "one-click" exploit for PHP 8.4.26 on Apache mod_php on an attacker's server, with no sign of shell access on the sites that attacker screened. NCSC-NL wrote at 15:45 on 23 October that it has one report of possible abuse abroad, not confirmed as successful, and that large-scale abuse looks less likely than first thought because exploitation is complicated. CISA's catalogue of 23 October still doesn't list the flaws as exploited. Patch, and set the upload progress switch to 0 today.
Update 24 Oct, 14:17 CEST: PHP has flagged a third issue. In an informational advisory on 23 October at 10:12 UTC, PHP asks everyone to set session.upload_progress.enabled=0 until its next regular bugfix release, to close "an unlikely RCE vector" now tracked as CVE-2026-115560. It only reaches apps that switch the session serialize handler at runtime with ini_set() before session_start(). The 21 October releases don't fix it, and if you already set this switch as a mitigation on 21 October, keep it. The attacks so far keep failing. Sophos saw attackers try and fail to install a Mirai botnet variant called Potassium, Cloudflare counted millions of attempts by early 22 October, and Censys still counted 34.4 million vulnerable PHP services on 23 October, as The Hacker News reported. SOCRadar found a "one-click" exploit for PHP 8.4.26 on Apache mod_php on an attacker's server, with no sign of shell access on the sites that attacker screened. NCSC-NL wrote at 15:45 on 23 October that it has one report of possible abuse abroad, not confirmed as successful, and that large-scale abuse looks less likely than first thought because exploitation is complicated. CISA's catalogue of 23 October still doesn't list the flaws as exploited. Patch, and set the upload progress switch to 0 today.
Update 22 Oct, 14:25 CEST: Attackers are trying, and nobody has confirmed a successful break-in yet. Amazon's threat intelligence team says its honeypots caught a first attempt on 17 October, four days before the disclosure, then more attempts from several groups from 02:00 UTC on 21 October, and it now calls php2shell "broadly exploited in the wild", while adding that it can't tell whether any attempt would have worked on a real server. The Dutch National Cyber Security Centre (NCSC-NL) wrote at 13:00 on 22 October that it has no signals of successful exploitation and that none of the circulating proof-of-concept exploits it tested worked yet. Sansec's 22 October update says mass exploitation looks less likely than it expected on release day, because a researcher found the public exploits don't work on a default PHP install. The US agency CISA told everyone on 21 October to patch at once and to take systems offline if they can't update, and neither CVE is on its Known Exploited Vulnerabilities list as of its 21 October catalogue. On the hosting side, Hostinger says the fix is on all its hosting servers except VPS, GoDaddy has finished Managed WordPress and Windows hosting, and cPanel and CloudLinux shipped patched PHP builds for the servers they run. My advice stays the same: patch today, and if a server was exposed, check its logs back to 17 October, as Amazon recommends.
Update 21 Oct, 15:50 CEST: PHP has released the fix. The patched versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35, and PHP's security advisory confirms that both flaws allow unauthenticated remote code execution: CVE-2026-109618 comes from out-of-memory handling while PHP parses multipart requests (such as file uploads), and CVE-2026-109619 from internal data that survives after its memory has been freed. Every PHP setup that serves web requests is affected, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed, and PHP rates the risk highest for mod_php. In PHP's words: "There are no complete mitigations, updating is the only safe choice." PHP 8.1 and older get no official release; the security team published minimal source backports for 7.4, 8.0 and 8.1 and points users to their Linux distribution or long-term support vendor.
A critical PHP vulnerability pair is the reason "PHP" and "PHP vulnerability" shot up Google Trends in the US overnight, with thousands of searches and a +300% jump. If your startup runs a WordPress site, a WooCommerce shop, a Laravel app or any PHP admin panel, this one is about you, and today is the day to act. It wasn’t the only security fire that day: a Railway breach and a poisoned LiteLLM release also put founders’ API keys at risk.
Here is what PHP confirmed, what is still unconfirmed, and the exact steps I would take today as a founder with PHP sites. Many Ubuntu and Debian servers got their patched PHP from one volunteer, and we tell Ondřej Surý's story and what it means for your stack.
What did PHP announce on 20 October 2026?
On 20 October 2026, the PHP project posted an advance notice of a critical security release on php.net. The notice is short, and every word counts:
- the release was scheduled for Wednesday 21 October 2026 at 14:00 UTC;
- it fixes two critical vulnerabilities, both rated CVSS v4.0 9.2;
- PHP tells all users to "prepare now so they can upgrade as soon as the release is available";
- PHP reserves the right to release earlier if details of either flaw become public or if attacks appear;
- full details, affected versions and fixed versions come with the release.
CVSS stands for Common Vulnerability Scoring System, the standard 0 to 10 scale for how dangerous a security flaw is. Anything from 9.0 up counts as critical. The current PHP releases, 8.5.11, 8.4.26, 8.3.35 and 8.2.34, came out on 24 September 2026, so every server running PHP today is waiting for this fix. Vendors can rate a bug lower than their users would: Google called the Android SMS of Death a non-security issue, even though one invisible text can drop emergency calls.
Why is everyone searching for the PHP vulnerability right now?
The story leaked. According to BleepingComputer, a Hacker News post on 20 October claimed two PHP remote code execution flaws were coming, and the security firm watchTowr then confirmed it. watchTowr CEO Benjamin Harris told BleepingComputer the bugs were under embargo until Thursday 22 October. PHP moved the release forward to Wednesday.
An embargo is the quiet period that lets hosting companies and Linux distributions prepare patched builds before the public hears about a bug. As Beazley Security put it, the leak broke that window. So attackers now know a critical bug exists, and many hosts had less time to prepare.
CVE stands for Common Vulnerabilities and Exposures, the public ID for each bug. Some researchers call the attack chain php2shell, and Sansec says a screenshot of an exploit tool with that name leaked alongside the advisory.
Is the PHP vulnerability already being exploited?
Here is where things stood on 22 October. Amazon saw a first attempt on its honeypots on 17 October and calls php2shell broadly exploited in the wild. watchTowr lists both flaws as exploited, with active attempts. Cloudflare switched on firewall rules for every plan, the free plan included, at 03:02 UTC on 21 October and reports attack traffic with changing payloads. On the other side, CISA said on 21 October that it had not observed exploitation, Huntress saw none on its partners' systems, and NCSC-NL found on 22 October that none of the public exploits it tested worked yet. So the attempts were real, and no successful break-in was public at that point. That changed on 26 October, with a confirmed break-in on a PHP 8.4.26 honeypot and CISA's listing of both flaws as exploited (see the update at the top).
On release day Sansec expected mass attacks within minutes, because attackers compare the patched code with the old code to find the bug. By 22 October it had revised that view: mass exploitation looks less likely than it expected, since a researcher found the public exploits need a separate file-inclusion bug to work on a default install. Don't relax because of it. Code posing as an exploit is circulating, Tenable warns some of it may carry malware, and attackers keep looking for a version that works, so never run it against your own site and patch anyway.
The European angle is real too. Sansec's timeline says several Dutch sites went offline as a precaution on 21 October, including the tech site Tweakers, the Dutch House of Representatives (Tweede Kamer) and the national cyber security centre NCSC. If public institutions in the Netherlands take their sites down for a few hours, a founder can spend one afternoon on updates. By the evening of 21 October the list had grown to Pokémon HOME, Cygames games, Wikimedia's tools and government sites across Europe, and we track who went offline over the PHP issue, and when your startup should do the same.
Which PHP versions are affected, and which get a fix?
PHP's advisory lists every version before the fixed releases as affected. Here is the version to install for each branch:
And here is how long each branch keeps getting security fixes, from PHP's supported versions page:
Researchers say the flaws reach back to PHP 5. Sansec writes that servers on PHP 8.1 or older will not get an official fix. That's a big group. W3Techs data from 21 October 2026 shows PHP runs on 69.3% of websites whose server-side language it can detect, and 34.8% of PHP sites still run PHP 7, 5 or 4. Add the PHP 8.0 and 8.1 sites, and by my count nearly half of all PHP websites (about 48%) run a branch with no official support.
What does the PHP vulnerability mean for your startup?
Most founders don't think of themselves as PHP users. You probably are. WordPress, WooCommerce, Magento, Laravel, Drupal, Joomla, phpBB, many CRMs and plenty of agency-built landing pages all run on PHP. Here's how I'd handle the next 24 hours:
- Make a list today. Write down every website, shop, blog, staging site, forum and internal tool you run, plus the host for each one. Old marketing microsites and forgotten staging copies are the ones attackers find first.
- Check the PHP version of each. Your hosting panel shows it, or run php -v on the server. Anything on 8.1 or older goes to the top of the list.
- Message your host now. Ask one question: when will you install the PHP security release from 21 October? Many managed WordPress hosts and cloud platforms update PHP for you, but only you know if your cheap shared plan from 2019 does.
- Update today. If you manage your own server, install 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or your Linux distribution's patched package, and restart every PHP worker. Take a full backup of files and database first.
- Put a firewall in front. A web application firewall (WAF) filters bad requests before they reach PHP. Sansec reports that Cloudflare's emergency rules cover free plans too. Treat it as a stopgap; PHP core developer Gina Peter Banyard told Sansec that patching PHP is the only real fix.
- Plan your way off old PHP. If a site runs PHP 7 or 8.1 and nobody can update it, decide this week: migrate it, rebuild it, or switch it off. An unpatched site on your domain puts your customers' data and your Google rankings at risk.
We covered a similar wake-up call three days ago, when Rank Math PRO shipped malware to WordPress sites. And if you build with AI coding tools, read how the OpenCode breach exposed saved API keys. The lesson is the same in both: the tools under your product are part of your security, whether you wrote them or not.
Outages and breaches hit small teams hardest, because there's no security department to call. Yesterday's Revolut outage after a Google Cloud power failure showed the same thing from another side. Build a short list of your critical vendors into your back-office stack, and keep it next to your password manager.
Are you getting customers from ChatGPT yet?
More and more traffic is coming from Perplexity, ChatGPT, Grok and other AI tools.
👉 Rank on ChatGPT
What happens next?
PHP has published the release and the full advisory, and hosts are rolling out the fix: cPanel's EasyApache 4 and CloudLinux shipped patched builds on 21 and 22 October, Hostinger finished its hosting servers except VPS, and AWS updated Elastic Beanstalk and Amazon Linux. Two of the things we were watching have happened: CISA added both CVEs to its Known Exploited Vulnerabilities list on 26 October, and a successful break-in on an unpatched honeypot was confirmed the same week. What's left is PHP's next regular release with the fix for CVE-2026-115560, which had not shipped by 4 November. Until it does, keep session.upload_progress.enabled=0, and check the php.net news page for the release.
Not every founder runs their own server. If you have one small business website and no developer, follow the Fe/male Switch Foundation's no-developer plan for small business websites. If you build or look after sites for clients, femaleswitch.com has a 24-hour plan for freelancers with a message you can send them. Engineering teams whose portals and download pages hold CAD files can follow CADChain's PHP checklist for engineering teams.
For the bigger picture, we track security incidents every month in our cybersecurity news for October 2026, and WordPress-specific updates in our WordPress news for October 2026. A secure site is also part of trust: here are 5 website features that make customers trust your business faster.
- A no-developer plan for small business websites (Fe/male Switch Foundation)
- A 24-hour plan for freelancers who look after client sites (Fe/male Switch)
- What engineering teams must patch to protect portals and CAD files (CADChain)
- PHP issue: why Pokémon, Wikimedia and government sites went offline, and when to go dark (mean.ceo)
FAQ: the critical PHP vulnerability
What is the PHP vulnerability of October 2026?
PHP announced two critical security flaws on 20 October 2026, both rated CVSS v4.0 9.2, and fixed them on 21 October 2026 in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. They are CVE-2026-109618 and CVE-2026-109619, and both allow unauthenticated remote code execution.
Which PHP version fixes the vulnerability?
PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, released on 21 October 2026. PHP 8.1 and older get no official release, only minimal source backports for 7.4, 8.0 and 8.1.
Which PHP versions are affected?
Every version before 8.5.12, 8.4.27, 8.3.36 and 8.2.35, according to PHP's advisory, on every setup that serves web requests: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. Researchers say the bugs reach back to PHP 5.
Is WordPress affected by the PHP vulnerability?
WordPress runs on PHP, so WordPress sites depend on the PHP version installed on their server. Updating WordPress itself won't fix it. Your host or server admin needs to install the fixed PHP release.
How do I check my PHP version?
Look in your hosting control panel under PHP settings, check Tools and then Site Health in the WordPress admin, or run php -v on the server.
Is the PHP vulnerability being exploited?
Yes. Attempts started on 17 October, when Amazon saw the first one. On 26 October two things confirmed real attacks: Perplexity's Adel Karimi documented a successful remote code execution on a honeypot running PHP 8.4.26 with Apache mod_php, and CISA added both flaws to its Known Exploited Vulnerabilities catalog. Patch today.
What is CVE-2026-115560?
A third PHP issue that PHP flagged on 23 October 2026 in an informational advisory. PHP calls it an unlikely remote code execution vector that only affects apps changing the session serialize handler at runtime. The 21 October releases don't fix it, so set session.upload_progress.enabled=0 until PHP's next regular bugfix release. By 4 November that release had not shipped.
About the Author
Violetta Bonenkamp, also known as MeanCEO, is an experienced startup founder with an impressive educational background including an MBA and four other higher education degrees. She has over 20 years of work experience across multiple countries, including 5 years as a solopreneur and serial entrepreneur. Throughout her startup experience she has applied for multiple startup grants at the EU level, in the Netherlands and Malta, and her startups received quite a few of those. She’s been living, studying and working in many countries around the globe and her extensive multicultural experience has influenced her immensely.
