PHP2Shell on Shared Hosting: Check Your Host, Then Rotate Secrets

PHP2Shell is a pair of remote code execution flaws in the PHP interpreter, so on shared hosting a WordPress or Joomla update leaves you exactly as exposed as before. If attackers reached your server before your host patched, the passwords and keys that server could read are the loss that matters.

Does a WordPress or Joomla update close PHP2Shell?

No. PHP2Shell is a flaw in PHP itself: the interpreter that runs WordPress, Joomla and every plugin on top of them. A CMS or plugin update never touches it. The two bugs are described as present in PHP’s code since about 2012, meaning they went unreported for roughly 14 years.

Researchers, including a team at Wiz, found them in August with help from OpenAI and Google models. According to the sponsored analysis that laid out the timeline, the disclosure was made jointly with OpenAI. PHP shipped fixed releases for its supported branches on October 21. Governments and companies took sites offline while they waited for those builds.

On shared hosting you do not pick the PHP build. Your host does, usually through a control panel. Your WordPress dashboard can show every plugin green while the interpreter underneath is weeks out of date.

Older branches are the hard case. PHP 8.1 and earlier received no official builds. Some operating-system and hosting vendors backport security fixes into old branches, so a version number alone proves neither vulnerability nor safety. Only your host can tell you which one you have.

How big is the PHP2Shell exposure on shared hosting?

Large. PHP is commonly cited as the language behind about 69% of the web. As of October 27, Censys counted 32.5 million internet-facing PHP services on potentially vulnerable versions, plus more than 60 million that report no version at all.

Those 60 million are unknowns, not confirmed victims, and any host that suppresses its version string falls into that group. Cleanup will also be slow because PHP ships inside appliances and hosting control panels that customers cannot patch themselves. If your panel bundles its own PHP, you wait on the panel vendor as well as your host.

CISA added both flaws to its Known Exploited Vulnerabilities catalog on October 26. KEV deadlines bind US federal civilian agencies only. For a business, the listing confirms real attacks, and your host’s written answer becomes the record you show a client, auditor or cyber insurer who asks what you did about it.

What should you ask your hosting provider this week?

Open a ticket and ask for four answers in writing:

• The exact PHP version and build date serving each of your sites. PHP-FPM, the Apache module and command-line PHP can be different builds on the same account.
• Whether the control panel ships its own PHP, and who patches that copy. Treat the panel as part of your attack surface, as the shared hosting control panel risk we covered earlier showed.
• Whether the October 21 fixes were applied or backported, with a reference to the host’s or OS vendor’s advisory, not just “we keep PHP updated.”
• Whether their logs show exploitation attempts against your account since October 17.

You can check the version yourself in the panel’s PHP selector, or by uploading a phpinfo page, reading the version string and deleting the file immediately. A forgotten phpinfo page leaks configuration paths and modules to anyone scanning your site.

Why the October 21 patch did not end the risk

Attackers started first. Amazon observed an exploitation attempt on October 17. watchTowr saw exploitation in the wild on October 21, the day the patch shipped, and Cloudflare reported attack traffic climbing quickly after disclosure, though it published no figures.

Normal remediation is far slower. Verizon’s 2026 Data Breach Investigations Report puts the median time to fix a known exploited vulnerability at 43 days. Qualys measures a mean of 21.2 days, with 63% of critical vulnerabilities still open after a week. With about 195 new CVEs published every day, no hosting company wins a pure patching race.

Patching also only closes the door. It does not remove a web shell already planted, delete an extra admin account, end active sessions or invalidate credentials already copied off the server. If your host patched after October 17, treat the gap as possible exposure.

Rotate these secrets, in this order

Anything the PHP process could read is at risk. In the words of the sponsored analysis, “a shell on a PHP server grants the attacker access to whatever that server can read, from environment variables to cloud keys in config files.” PHP2Shell can also leak worker memory, which may hold passwords, tokens and API keys that never touch a file.

Code execution usually starts with the privileges of the web server or PHP user, not root. On a typical site that is enough. WordPress keeps the database name, user, password and authentication salts in wp-config.php. Joomla keeps database credentials, its secret and often the SMTP password in configuration.php. Many plugins store payment, SMTP or backup keys too.

Once the server is confirmed clean, rotate from a clean computer:

1. Database password, then update wp-config.php or configuration.php.
2. WordPress salts or the Joomla secret, which logs every session out.
3. Hosting panel, FTP and SFTP passwords. Delete accounts nobody uses.
4. Mailbox passwords. A reset does not remove a forwarding rule (see what a host password reset still leaves in place), so audit forwards too.
5. Payment gateway, SMTP, cloud storage, backup and deploy keys.
6. The admin user list in the CMS. Remove anyone you do not recognize.

Credentials come first because, as the piece puts it, “Attackers aren’t looking for the most direct path; they’re looking for the easiest path.” Its example is an October LiteLLM incident: a master key exposed in a public repository led to an unscoped GitHub organization-owner token, then two more maintainer tokens, a subverted release workflow and published credential-stealing artifacts.

Contain the damage while you wait for a fixed PHP

From our engagements: when one compromised site turns into five on a shared account, the cause is rarely clever. It is one panel user hosting several sites, one database user shared across all of them, and a wp-config.php.bak sitting in the web root. Check for all three today.

If the panel offers no newer PHP build, plan a move. A branch with no official build stays vulnerable until you migrate to a supported release or to a host that can show it backports fixes. Meanwhile, shrink what a compromise can reach:

• Give each site its own database user with rights only to its own database.
• Ask the host to run each site in its own PHP-FPM pool under a separate system user, or in its own container.
• Stop reusing the panel password anywhere else, and remove dormant FTP and database accounts.
• Restrict outbound connections from the server if the host allows it, so stolen data has a harder time leaving the server.

A website firewall can filter known attack traffic during the transition, and file-integrity monitoring such as antivirus website protection will flag a new web shell. Neither replaces the update. Separation has limits too: if the compromised system holds your data, the attacker is already where they wanted to be.

A migration costs a few days of work. An incident costs every secret on the box plus the cleanup.

What is still unconfirmed about PHP2Shell?

The blast-radius analysis behind much of this timeline was published as a BleepingComputer post sponsored and written by Token Security, which sells AI-agent and non-human identity security. Its dates are specific; its prescription matches its product.

What the source leaves out:

• CVE identifiers and CVSS scores. Use CISA’s KEV entry and the PHP project’s advisory for identifiers and indicators of compromise.
• Affected version ranges and the bug class.
• A verifiable name for the second research group, so we leave it out.

What nobody has published yet:

• Any attacker attribution.
• Cloudflare’s traffic counts.
• Whether exploitation depends on a specific server configuration.

Earlier PHP flaws did: CVE-2019-11043 depended on certain nginx and PHP-FPM setups, and CVE-2024-4577 hit PHP-CGI on Windows under particular conditions. Until PHP2Shell’s conditions are documented, do not assume your setup is the safe one.

FAQ

Does updating WordPress fix PHP2Shell?

No. PHP2Shell is in the PHP interpreter your host runs, not in WordPress or its plugins. Only an updated or backported PHP build closes it.

Which PHP versions did not get a PHP2Shell patch?

PHP 8.1 and older received no official builds. Some hosts and OS vendors backport fixes, so ask yours for an advisory reference.

Can a PHP2Shell attack read my wp-config.php password?

Yes. Code running as the PHP user can read wp-config.php, including the database password and salts, and the flaws can also leak passwords and keys from worker memory.

Is PHP2Shell on the CISA Known Exploited Vulnerabilities list?

Yes. CISA added both flaws on October 26. The deadlines bind US federal civilian agencies; for everyone else the listing confirms active attacks.

Does a website firewall replace a PHP update?

No. A firewall can filter known attack traffic while you upgrade, but it does not change the vulnerable interpreter.

If your host patched late or you found an account you cannot explain, get the server confirmed clean before you rotate anything, so the new passwords do not land on a box that is still compromised. SiteGuarding’s website protection packages cover cleanup, firewall filtering and ongoing monitoring.