Emergency PHP Patching. PHP2Shell, handled.

PHP2Shell affects any website that runs on an unpatched PHP version: WordPress, Drupal, Joomla and custom PHP apps. We get your server onto a fixed release, confirm it took, and check whether anyone got in first.

Why it matters

This one lives below your website

Most website security work happens inside the CMS: plugins, themes, passwords. PHP2Shell is different. The two flaws are in PHP, the engine underneath WordPress, Drupal, Joomla and most custom business sites, and they can be attacked without a login.

That means a security plugin can't fix it and a CMS update won't either. The PHP security advisory is plain about it: update PHP to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, restart every PHP worker, and treat any configuration change as a stopgap.

For many owners the hard part isn't the update. It's knowing which PHP version the site really runs, who controls it, and whether an old site can move to a supported version without breaking. That's the work we take off your plate.

What we do

From exposed to patched and checked

The same order of work whether you're on shared hosting, a managed host or your own server.

Confirm the setup

We identify the PHP version and how it runs (PHP-FPM, Apache mod_php, LiteSpeed and so on), and who controls updates: your host, a control panel or your own server.

Get onto a fixed release

We update PHP through the host, the control panel or the vendor's packages. If the site is on PHP 8.1 or older, we test it on the nearest supported version first so the upgrade doesn't break it.

Restart and verify

We restart PHP workers and confirm the web server, not just the command line, is running a fixed build. On Linux that means checking the vendor package, because patched packages often keep the old version number.

Look for signs of compromise

We check logs and the file system for the warning signs researchers have described, and for new or changed PHP files in upload, cache and temporary folders.

Report and next steps

You get a plain-English summary of what we found and changed, plus a plan for anything still on an end-of-life version.

Who does what

It depends on how you're hosted

Hosting type	Who updates PHP	What we do
Shopify, Wix, Squarespace	The platform	Nothing to patch in the store itself. We check any separate PHP sites or apps you run.
Shared hosting	The host; you choose the version in the panel	We pick the right version, test the site on it and confirm the host has patched.
Managed WordPress hosting	The host	We confirm the patch and run the compromise checks.
Your own VPS or server	You or your developer	We update, restart and verify, with access you give us.
Agency- or vendor-run site	Your vendor	We give you the questions to ask, or work with them directly.

Included

What the work covers

✓

PHP version and setup check

✓

Update to a fixed PHP release

✓

Worker restart and verification

✓

Compatibility test for old sites

✓

Log review for warning signs

✓

Scan for new or changed PHP files

✓

Secrets rotation if anything looks wrong

✓

Hardening after the patch

✓

Plain-English written summary

✓

Upgrade plan for end-of-life PHP

What we need

Access, or an introduction to your host

To patch PHP we need one of three things: a login to your hosting control panel, server access (SSH) for your own VPS, or permission to work with your host's support team on your behalf. If your site is run by another agency, we can work with them.

If we find signs of a break-in, we stop and tell you before changing anything else, so evidence isn't lost. Our website security team handles cleanup and recovery.

Read first

PHP2Shell guides

Blog

FAQ

Common questions

Can't I just update WordPress or my plugins?

No. PHP2Shell is in PHP itself. WordPress, plugins and themes run on top of PHP, so updating them doesn't change the PHP version on the server.

My host says they've patched. Do I need anything else?

Confirm the version the web server is running, not just what the host announced, and check for signs of compromise from before the patch. We can do both.

My site is on PHP 7.4 and breaks on PHP 8. What are my options?

Fix the code that breaks on PHP 8, or rebuild the site on a supported stack. A stopgap backport package from your host or Linux vendor can buy time, but it isn't a long-term answer.

Do you work with Drupal, Joomla and custom PHP sites?

Yes. The PHP update is the same; the compatibility testing differs by platform and version, and we cover all three plus custom PHP applications.

Should we rebuild instead of patching?

Patch first, always. Then, if the site is on end-of-life PHP or an old theme and plugins, a rebuild may cost less than keeping it alive. See our headless development work for one route.