php2shell: What it is and why you don’t need to panic

Last updated: Oct. 27, 2026 [09:00 AM, UTC]

php2shell is the nickname for two security holes found in PHP. Their official names are CVE-2026-109618 and CVE-2026-109619 (CVE is the public catalog security researchers use to track vulnerabilities).

About 69% of websites with a known server-side language run on PHP, the language behind logins, contact forms, and checkout carts. The scripting language also powers popular content management systems (CMSs) such as WordPress, Magento, Drupal, and Joomla.

This helps explain why php2shell became big news, as PHP powers a wide range of websites, from personal blogs and small-business sites to online stores, news sites, and community forums.

If you’re an end user, you don’t need to panic, as this bug won’t affect you. The fix for php2shell mainly falls to website operators and hosting providers, since it runs on their servers.

How does php2shell cause damage?

Every time someone visits a website, their browser sends the server a request – think of it like an order slip handed to the kitchen. Normally, PHP reads the slip and prepares the page, just like a chef cooks the meal you ordered.

An attacker exploiting php2shell sends a deliberately malicious order slip that overwhelms PHP while it’s still reading it. In the confusion, PHP doesn’t tidy up properly, and the attacker can use that leftover mess to slip in their own instructions. From there, they can run their own code on your server.

Once that happens, they can do anything your site can do: change your pages, create admin accounts for themselves, read your database (including customer details), or knock the site offline.

What makes this worrying is that attackers don’t need a password, an account, or even a particular page to target. On servers that run PHP through Apache’s mod_php module, one of the most common custom setups on the web, php2shell can work through almost any page on your site. Other popular setups, such as PHP-FPM, are also at risk, though attacks there depend more on how a site is configured.

If it’s all automated with AI agents, attackers can send these requests to thousands of sites at once and see which ones are still unpatched.

If you’re just visiting websites, you can’t trigger this by accident, and browsing an unpatched site won’t hack your computer. The risk is to the site and the data stored on it.

How the php2shell bugs unfolded

The earliest signs of the problem date back years, but researchers found the first flaw almost three months before most people heard of it. 

The table shows how related events unfolded in the latest update on the bug’s development up until Oct. 23, 2026.

Date	What happened
2020	A related out-of-memory PHP bug was reported.
2024	While fixing an issue from an external security audit, a PHP developer spotted the first signs of the problem. With no proven attack and no agreement on how to fix it, the issue was left unpatched.
Aug. 1, 2026	Researchers at the security firm Calif, working under OpenAI’s Patch the Planet initiative, found the first PHP flaw.
Aug. 11, 2026	Calif reported the first bug to PHP.
Aug. 14-15, 2026	Calif shared a working exploit. PHP developers confirmed the next day.
Aug. 19–24, 2026	Wiz Research independently found both flaws in AI-assisted tools. Within two days, its researchers showed they could run code remotely on Drupal, WordPress, and Joomla sites. They reported the flaws to PHP on Aug. 24.
Aug. 21, 2026	Calif reported a second bug.
Sept. 21, 2026	PHP acknowledged the Wiz reports and started the coordinated fix.
Oct. 17, 2026	Amazon’s MadPot honeypots (decoy servers) recorded an attempt to exploit php2shell before any public announcement was made.
Oct. 20, 2026	– The CVE numbers leaked online before any technical details were released. Calif accidentally published a video of its exploit and then pulled it.  – A Hacker News post claiming to disclose the vulnerability was also taken down.  – watchTowr later confirmed the leak.
Oct. 21, 2026	– Cloudflare turned on WAF protection for firewall customers. – Patchstack reported exploitation from hosting partners. Cloudflare’s CTO reported early attacks. – Hostinger applied security protections to mitigate this vulnerability. After a thorough investigation, our security engineers found no viable path to exploitation in our environment at this time. – Chainguard published patched builds before the official release, so people can diff the code. – Government and other sites went offline as a precaution: Overheid.nl, Finnish government services, French Interior Ministry, Wikimedia Phabricator, and Dutch sites including the NCSC. – watchTowr reported exploitation seen in its honeypots. – Pre-announcement: a security release was scheduled for Oct 21 at 14:00 UTC. The release moved up from Oct 22 after the CVE IDs leaked on Oct 20. – GitHub advisories were published, then PHP released patched versions 8.5.12, 8.4.27, 8.3.36, and 8.2.35.
Oct. 22, 2026	– Cloudflare reported millions of attack attempts. – Hostinger rolled out patched PHP versions across the entire platform’s infrastructure. – Wordfence (WordPress security plugin) reported 74,000+ blocked exploit attempts.
Oct. 23, 2026	– PHP published an advisory for a third bug, CVE-2026-115560, in the session upload progress feature. PHP said remote code execution (RCE) through it is unlikely. No fix was available yet, so PHP recommended turning the feature off in the meantime. – Hostinger confirmed that every managed hosting plan was already protected, since the feature had been switched off on Oct 21. – As of Oct 26, CVE-2026-115560 was not in CISA’s Known Exploited Vulnerabilities (KEV) catalog, meaning there was no confirmed evidence of attacks using it.

Are these php2shell attacks actually happening?

As of Oct. 26, 2026, no successful php2shell break-in has been publicly confirmed. Attackers are trying, though, and the gap between attempts and confirmed compromises is wide.

Amazon’s MadPot honeypots recorded one exploitation attempt on Oct. 17 from an anonymized IP address. AWS says it’s unclear how the actor got exploit information before disclosure. 

On Oct. 21, AWS identified several proof-of-concept exploits starting at about 02:00 UTC, roughly 12 hours before PHP’s scheduled 14:00 UTC release, and further attempts on other infrastructure until 08:00 UTC.

Attempts to exploit Cloudflare’s servers climbed from thousands before the announcement to millions by the end of the day, and attackers began tweaking their payloads to slip past its protections.

Most of these numbers come from firewalls and honeypots, so they count attacks that were blocked or deliberately lured, not sites that were breached.

A reported compromise didn’t hold up either. Unit 42 linked an attack on a European government agency to php2shell, then retracted the link on Oct. 25 because it couldn’t confirm that the attackers gained access through these CVEs.

These facts gave us no reason to panic, but there’s also no reason to postpone updating your PHP to the patched version. Attackers are actively probing sites, so if the update is yours to run, do it today.

How to be safe from the php2shell bugs?

If you’re on shared or managed hosting, protecting the server is your host’s responsibility, so you’re probably already covered. To be sure, check your host’s status page or announcements, or send their support team a quick message asking whether the php2shell fix is in place.

If you manage PHP yourself, for example on a virtual private server (VPS), you’ll need to update to one of the patched releases (PHP 8.5.12, 8.4.27, 8.3.36, or 8.2.35) yourself, then restart PHP to ensure the fix takes effect.

If you’re on a managed Hostinger hosting plan

If you’re on any of our managed web hosting plans, you’re all set. We already run patched builds of every PHP version we offer on web, cloud, managed WordPress, and legacy cPanel hosting. Even if your site runs an older PHP version, it’s protected.

When checking which PHP version your site uses in the Hostinger dashboard, you may still see an older PHP version listed as active. That’s normal. What’s important is ensuring the Build Date is listed as October 21, 2026, or later. 

Watch the video below if you’d like a visual walkthrough:

If you’re running a VPS

On a VPS, including cPanel VPS plans, you manage PHP yourself, so the update is in your hands. That applies to anything on your server that runs on PHP – web apps, APIs, admin tools like phpMyAdmin, and webmail all count, even the ones you set up once and forgot about. 

If you’re on Hostinger’s VPS, our step-by-step guide walks you through the process and includes a temporary workaround if you can’t update right away.

There’s no official patch for PHP 8.1 or older, so moving to a newer version is the only solution. Before you do, check that your theme, plugins, and apps support it, and test the change on a staging copy first if you can.

We highly recommend keeping PHP up to date, as older versions miss many security fixes. PHP 8.2 stops receiving security fixes on December 31, 2026, so PHP 8.3 or newer is a good target.

If you can’t update PHP right away, use a firewall to buy time

Firewall rules are part of how we protected sites on our managed hosting plans: they block requests that match the php2shell attack. 

If you manage your own server, you can get similar protection from a service like Cloudflare, which switched on php2shell protection for every site using its firewall, including on its free plan.

But a firewall only buys you time. It isn’t the fix, for two reasons:

• Attackers adapt. Firewall rules block attack patterns they recognize, and Cloudflare has seen attackers tweaking their requests to slip past its rules. Even Cloudflare calls its protection an extra layer of defense and tells site owners to patch PHP.
• It only protects traffic that goes through it. If an attacker can reach your server directly, the firewall never sees them.

PHP’s own security advisory says updating is the only safe choice. Use a firewall to stay protected while you patch, not instead of patching.

Updating your CMS or plugins won’t fix php2shell

If your site runs on WordPress, Joomla, Drupal, Magento, or another PHP-based CMS, your first instinct might be to hit “update all” on your core software, plugins, themes, or extensions. 

That’s a great habit, but it won’t protect you from this attack. php2shell sits underneath your website’s software.

All of these platforms, along with every plugin, theme, module, or extension you add to them, are written in and run by PHP. So even a fully updated site is still exposed if the PHP version underneath hasn’t been patched. The most direct version of the attack runs before your CMS even starts, which means login pages and security plugins never get a chance to step in.

The fix has to happen wherever your PHP is sourced: on your server, with your hosting provider, or in your container image (if your site runs in Docker or a similar setup).

What to do about the third PHP flaw, disclosed on Oct. 23

If you’re on one of our managed hosting plans, you don’t need to do anything. We’ve already protected our servers against this third flaw, CVE-2026-115560, along with the php2shell fixes we rolled out on Oct. 21.

If you manage PHP yourself, for example on a VPS, updating PHP won’t protect you from this one. The Oct. 21 releases don’t include a fix for it, and the official patch will be included in PHP’s next regular release. 

Until then, set session.upload_progress.enabled = Off in php.ini or your PHP-FPM pool config, then restart all PHP workers so the change takes effect. If you already did this on October 21, you’re covered.

Turning this setting off is unlikely to break anything. It only controls a rarely used feature that tracks file upload progress, and WordPress doesn’t use it. If you run a custom app that does show upload progress bars this way, that display will stop working until you turn the setting back on after the next PHP release.

What’s next

The two php2shell flaws have been fixed in the Oct. 21 PHP releases. The related third flaw, CVE-2026-115560, will get its official fix in PHP’s next regular release, and the setting described above keeps you protected until then.

This article reflects publicly available information as of Oct. 26, 2026. Security guidance can change quickly, so check PHP’s official advisories and your hosting provider for the latest updates.

If you’re a Hostinger customer, keep an eye on our live status page for updates. Our Customer Success team is also available 24/7 via live chat to answer questions about your website.