PHP2Shell: Why Updating WordPress Won't Fix the PHP Under Your Website

This week, reports surfaced of a critical PHP flaw being called PHP2Shell, along with an emergency fix from the PHP project.

If your business website runs on WordPress, Drupal, Joomla, or a custom web app, there is a good chance PHP is running underneath it. And here is the part most business owners don't realize: clicking "Update" in your WordPress dashboard does not update PHP.

In our October 22 post we covered flaws in WordPress itself. This one is different. It sits a layer lower, on the server, where most site owners never look. In this post we explain what PHP is in plain terms, who is actually responsible for updating it, why mass exploitation can hurt you even if you're patched, and a five-step checklist your team can work through this week.

A Quick Note on the Facts

Details on PHP2Shell are still developing, and early reporting varies. The authoritative source for affected versions and fixed releases is the PHP project itself. Check the official PHP releases page and the PHP 8 changelog rather than relying on social media summaries. The steps below make sense no matter how the final details shake out.

PHP Is the Engine. WordPress Is the Car.

The simplest way we explain this to clients across Northeast Ohio is with a car analogy.

• PHP is the engine. It is the programming language running on the web server that actually executes your site's code.
• WordPress, your theme, and your plugins are the car. The body, the dashboard, the seats, the features you see and use every day.

When you update WordPress or a plugin, you're swapping out parts of the car. You're not touching the engine. A car with brand new seats and a recalled engine is still a car with a recalled engine.

That's why a site can show "everything up to date" in the WordPress dashboard while still running a PHP version with known security holes.

Why This Matters: Old PHP Flaws Get Exploited Quickly

We don't need to speculate about how attackers treat serious PHP flaws. There is a recent, well-documented example.

In June 2024, a critical vulnerability tracked as CVE-2024-4577 was disclosed in PHP running in CGI mode on Windows servers. It allowed attackers to run commands on vulnerable servers remotely (NVD). Exploitation attempts began shortly after disclosure, and CISA added it to its Known Exploited Vulnerabilities catalog, which flags it as known to be used in ransomware campaigns.

The lesson: once a critical PHP flaw becomes public, the window between "announced" and "actively attacked" can be very short. Planning to get to it next month is not a plan.

Pain Point #1: Nobody Is Sure Who Owns PHP Updates

This is the most common gap we find. The business assumes the host handles it. The host assumes the agency handles it. The agency assumes the business approved staying on the old version. Meanwhile, nobody does it.

Who is responsible depends on how your site is hosted.

Shared or Managed Hosting

On shared hosting and many managed WordPress plans, the host controls the server and usually patches PHP within each version line. But many hosts let you choose which PHP version your site runs in the control panel. If your site is pinned to an old version, the host may leave it there until they force a retirement.

Bottom line: the host often patches, but you may own the version choice.

Agency-Managed Sites

If a web agency or freelancer built and maintains your site, PHP may or may not be in their scope. Many website maintenance plans cover WordPress core, plugin, and theme updates only. The server layer belongs to whoever holds the hosting account.

Bottom line: read your maintenance agreement. If PHP isn't named, assume it isn't covered.

VPS, Dedicated, or On-Premises Servers

If your site runs on a virtual private server, a dedicated server, or hardware in your own building, you (or your IT provider) own PHP. Nobody else is going to patch it. This is common for manufacturers, colleges, and professional firms running internal portals or custom applications.

Bottom line: your team or your IT partner owns it completely.

Pain Point #2: Unsupported PHP Gets No Fixes

Each PHP version has a defined support lifecycle. Once security support ends, the PHP project stops releasing security fixes for that version. Period.

According to the PHP project's supported versions and end-of-life pages:

• All PHP 7.x versions are past end of life.
• PHP 8.0 is past end of life.
• PHP 8.1 reached the end of security support at the end of 2025.

If your site runs any of these, an emergency fix from the PHP project won't reach you. Upgrading to a supported version is the only real fix.

Some hosts and Linux distributions offer "backported" security patches for older PHP versions. These can be legitimate, but they only count if your provider confirms in writing that the specific flaw is patched in the exact build you're running. A verbal "we've got it covered" isn't enough.

Pain Point #3: Mass Exploitation Hurts Even Patched Sites

Here's what many owners miss. When a PHP flaw is exploited at scale, the damage spreads beyond the sites that were actually vulnerable.

• Shared server neighbors. On shared hosting, a compromised site on the same server can drag down performance or trigger account suspensions that affect others.
• Emergency host maintenance. Hosts often push urgent PHP upgrades or take servers offline to patch. If your site depends on an old version, it may break without warning.
• Traffic floods. Automated scanners hammer every PHP site they can find, eating bandwidth and slowing pages, even when the attacks fail.
• Blocklisting. If your server or shared IP is caught sending malware or spam, browsers may show warnings to your visitors and email providers may start rejecting your company's mail.

During past waves of mass exploitation, reports have described rapid jumps in exploit attempts and disruption at some public sector websites. Being patched protects your data. Being prepared protects your operations.

Your PHP2Shell Checklist for This Week

You don't need to be technical to start. Work through these five steps, or hand this list to whoever manages your site.

1. Find Your PHP Version

• WordPress sites: go to Tools > Site Health > Info, then expand the Server section. The PHP version is listed there (WordPress Site Health).
• Hosting control panel: look for a "PHP version," "PHP selector," or "PHP configuration" setting.
• Not sure? Ask your host, agency, or IT provider for the exact version number, including the minor release (for example, 8.2.x rather than just "8").

2. Ask Your Host or Agency in Writing

Email beats a phone call because it creates a record. Sample questions:

• "What exact PHP version and build is our site running today?"
• "Is our current version patched against the PHP2Shell flaw? If you rely on a backported fix, please confirm that in writing."
• "Who is responsible for PHP version upgrades on our account: you, our agency, or us?"
• "When was PHP last updated on our server?"
• "Do you have a staging environment where we can test an upgrade?"

3. Plan a Tested Upgrade off Unsupported PHP

If you're on 7.x, 8.0, or 8.1, schedule the move now. Do it carefully:

• Use a staging copy of the site to test the new PHP version first.
• Check compatibility of your theme, plugins, and any custom code. Older plugins are the most common source of breakage.
• Have a rollback plan so you can switch back quickly if something fails in production.
• Test the critical paths: contact forms, patient or client portals, online payments, and logins.

4. Harden the PHP Layer

Patching closes known holes. Hardening limits the damage from the next one. Ask your technical team about:

• A web application firewall (WAF) using the OWASP Core Rule Set to filter common attack patterns before they reach PHP.
• Tight file permissions so the web server can't write to files it doesn't need to change.
• disable_functions in the PHP configuration to turn off dangerous functions your site doesn't use, such as ones that execute system commands.
• Avoid CGI mode unless your setup specifically requires it. CVE-2024-4577 targeted PHP-CGI on Windows.
• expose_php = Off so your server doesn't advertise its PHP version to scanners (PHP manual).
• display_errors = Off in production so error messages don't leak file paths and details to attackers.
• Logging turned on and actually reviewed, so unusual activity gets noticed.
• Remove phpinfo() pages and old test files left over from development. They hand attackers a map of your server.

5. Verify Backups and Test a Restore

A backup you've never restored is a hope, not a plan. Confirm that:

• Backups include both site files and the database.
• At least one copy is stored off the server your website runs on.
• You have tested a full restore recently and know how long it takes.

If the worst happens, a clean, verified backup is what turns a crisis into an inconvenience.

How LNS Helps Northeast Ohio Businesses Close the Gap

The PHP problem is really an ownership problem. Too many vendors, each covering one slice, and the server layer falls through the cracks. That's exactly the gap we built Local Network Solutions to eliminate.

We cover all six critical IT pillars under one roof and one SLA. For a situation like PHP2Shell, that means:

• Cybersecurity: 24/7 anomaly detection, proactive monitoring, and rapid incident response, so suspicious activity gets caught before data is compromised.
• Backup & Disaster Recovery: daily verified backups, rapid recovery, and tested recovery playbooks, so a restore is a routine procedure, not a gamble.
• Network Infrastructure: firewalls, network architecture, and performance monitoring that give you visibility into what's hitting your systems.
• IT Infrastructure: end-to-end server support, from setup through troubleshooting, including the servers your web apps run on.

Most importantly, you get one unified team. No finger-pointing between your host, your agency, and your IT provider. When we own it, we own it.

We've spent more than 10 years serving Northeast Ohio and protected more than 500 businesses across manufacturing, healthcare, higher education, professional services, and financial services. We're independent, locally owned, and 100% focused on our region, from Cleveland and Akron to Canton and Youngstown.

Don't Wait for the Scanners to Find You

Critical PHP flaws don't stay quiet for long. The businesses that come through these events cleanly are the ones that already know their PHP version, know who owns updates, and have a tested backup ready to go.

If you're not sure where your site stands, let's find out together. Schedule Your Consultation with our team today. Email us at [email protected] or call (216) 658-6988. We'll help you identify your PHP version, clarify who owns what, and build a plan to upgrade and harden it.

Complete IT Infrastructure. Zero Gaps. Zero Excuses.