The PHP2Shell vulnerability is a set of critical flaws in PHP, the software that runs a large share of company websites, WordPress sites and client portals. If your site runs on PHP and has not been updated to a fixed release, treat it as exposed and get written confirmation from whoever manages it today. Where a fix cannot be applied quickly, taking the site offline for a short time is a sound business decision, not an overreaction.
This brief is for leaders who do not manage servers themselves. It covers how to confirm exposure, what to ask your hosting provider or developer, how to decide between patching and going offline, and how to check whether the site was already compromised.
What the PHP2Shell vulnerability is, in plain terms
PHP is a programming language that runs on a web server and builds pages as visitors request them. WordPress, Drupal and Joomla are built on PHP, and so are many custom client portals, booking systems and contact forms. Many executives have never heard of it, which is exactly why this matters: most company websites run PHP without anyone in leadership knowing.
PHP2Shell is the name given to vulnerabilities in PHP itself, not in a plugin or theme. That distinction is important. Updating your WordPress plugins does not fix this PHP vulnerability. The PHP software on the server must be updated.
The name describes the outcome. A shell is the ability to run commands on a computer. The technical references linked from the National Vulnerability Database entry point to remote code execution, meaning an attacker on the internet can make your server run their own instructions. In practical terms, a successful attacker could read files, take database contents and stored passwords, alter your pages, or use your server to attack others. CISA's alert is titled plainly: critical vulnerabilities in PHP require immediate patching.
Why governments took websites offline
Reuters reported that a European Union agency warned website operators they might need to take sites offline while the PHP project prepared patches, and that government websites went dark. The reasoning is simple. When attacks are expected and a fix is not yet installed, removing the site from the internet is the only control that is certain to work.
The usual head start for defenders also shrank. Infosecurity Magazine reported that an exploitation attempt was detected four days before the vulnerability was disclosed, and that details leaked ahead of the scheduled security patches. When attackers have the information before or at the same moment as defenders, waiting for a convenient maintenance window is not a safe plan.
The same logic applies to any company website.
Is my website affected by PHP2Shell?
Your site is likely exposed if three things are true: it runs PHP, the PHP version has not been updated to a fixed release, and it is reachable from the internet. Most company websites meet the third condition by design. The first two are what you need to confirm.
Clues that your site runs on PHP
- It was built on WordPress, Drupal, Joomla or a similar content management system.
- Page addresses end in .php, or the login page is at /wp-admin or /wp-login.php.
- It is on a shared Linux hosting plan set up by an agency or freelancer.
- It includes a client portal, document upload, booking tool or payment form built by a local web firm.
Do not stop at the main website. Ask about old campaign microsites, staging copies, intranet sites, recruiting pages and any portal a vendor hosts on your behalf. Forgotten sites are often the ones running the oldest software.
What not to rely on
The site looking normal tells you nothing. Neither does being told it is in the cloud, or a quick online scan. The only reliable answer is the PHP version actually running on each server, confirmed by the person who manages it, in writing.
Which PHP versions are fixed, and where the patch information comes from
Take patch information only from authoritative sources: the PHP project's own security release announcements, the CISA alert, and the National Vulnerability Database entries for the PHP2Shell CVEs. This article deliberately does not list version numbers. Fixes in fast-moving events are sometimes revised, and a version list copied from a blog can go stale within a day.
Two details trip people up:
- Version labels can mislead. Some Linux distributions apply a security fix to an older version without changing the main version number. Ask your vendor to confirm the PHP2Shell patch by advisory reference, not just by version string.
- Unsupported versions may get no fix at all. If your site runs a PHP branch that is past its end of support, there may be no patched release for it. Upgrading may then require code changes, which takes longer and is the most common reason to consider taking a site offline.
Questions to ask your hosting provider or web vendor today
Send these in writing and ask for a written reply. The right-hand column tells you when to push further.
| Question | A good enough answer | An answer that needs follow-up | |---|---|---| | Which of our sites and applications run PHP? | A complete list, including staging and old sites | "Just the main site, I think" | | What PHP version is each running right now? | Exact version, date updated, and confirmation it includes the PHP2Shell patch | "The latest" or "it auto-updates" | | If not patched yet, when, and what protects us until then? | A specific time today or tomorrow, plus interim measures | "In the next maintenance window" | | Have you checked for signs of compromise? | Yes, with what was checked and what was found | "We haven't seen any alerts" | | Which passwords and keys on the server should we change? | A specific list: database, API keys, admin accounts | "That isn't necessary" | | Who can take the site offline, and how fast? | A named person and a maintenance page within the hour | No clear owner |
Pay close attention to who is responsible for what. On some hosting plans the provider updates PHP; on others it falls to you or your developer. Emergencies go wrong in the gap between those two assumptions. If your vendors cannot answer quickly, that is a finding in itself, and it belongs in your vendor risk management.
Patch now or take the site offline: how to decide
The default is to patch now. Taking a site offline is for situations where patching cannot happen quickly.
Take the site offline, or restrict access, when:
- There is no fixed release for your PHP version and an upgrade needs code changes.
- Your vendor cannot confirm a patch time or cannot be reached.
- The site holds sensitive data: a client portal, uploaded documents, logins or payment details.
- You have found signs of compromise.
Keeping the site online while patching is reasonable when the PHP security update is going in within hours, the site holds no sensitive data, and someone is watching for problems.
There are options between fully online and fully offline:
- Replace the site with a simple maintenance page served as a static file.
- Limit a client portal to known office addresses or a VPN until it is patched.
- Switch off non-essential PHP features such as old forms or unused plugins.
- Publish a static copy of a marketing site while the server is upgraded.
For a brochure site, a day offline usually costs less than cleaning up a compromised server. For a client portal, pair the decision with a short, factual message to the clients who use it.
Signs a site was already exploited
Because exploitation attempts were reported before disclosure, applying the PHP2Shell patch does not prove the site was never touched. Ask your vendor to check for:
- Administrator or user accounts no one recognizes.
- New or recently changed PHP files, especially in folders meant for uploads or images.
- Unfamiliar scheduled tasks on the server.
- Pages that redirect visitors elsewhere or show spam links.
- Unusual outbound traffic, unexplained CPU spikes or repeated crashes of PHP processes.
- Odd requests in the web server logs around the disclosure dates.
- Browser or search engine warnings that the site is unsafe.
If you find something
- Preserve evidence first. Save logs and a copy of the affected files before anyone deletes anything.
- Isolate the site. Take it offline or restrict access.
- Change every credential the server could reach. That includes database passwords, API keys, email sending accounts, payment integration keys and administrator passwords.
- Rebuild rather than clean in place. Restore from a known-good source onto a patched server. Cleaning a compromised server by hand often misses something.
- Assess what data was exposed. Bring in legal counsel early, and check your cyber insurance policy's notification requirements.
- Follow your incident response plan. If you do not have one, this event is the reason to write it.
Why AI turned an old PHP flaw into a crisis within days
CNN's explainer described PHP2Shell as a threat that had been known for 22 years and that AI made a crisis in two days. Reuters likewise described it as an AI-discovered flaw. That matters for every future patch decision you make.
AI tools can read very large amounts of code quickly and find weaknesses that people overlooked for years. The same tools help attackers. Once a fix is published, comparing the old and new code reveals what was fixed, and turning that into a working attack used to take skilled people days or weeks. With AI assistance, that work is much faster.
The practical consequence: the time between a fix being released and attacks arriving should now be assumed to be days or less. A monthly patch cycle for internet-facing websites is no longer adequate for critical flaws. Plan on applying critical web patches within days, decide in advance who can authorize emergency action, and keep PHP on currently supported versions so that a fix exists when you need it.
Who owns website patching at your company
In many companies, the honest answer is nobody. Marketing owns the website, an agency built it, a host runs the server, and internal IT assumes it is out of scope. That arrangement works until an emergency, when everyone waits for someone else.
Fix it with six steps:
- Name an accountable owner. One executive who answers for the website's security, and one technical owner who does the work.
- Keep an inventory. Every web property, its platform, PHP version, host, vendor and the data it handles.
- Put patch timelines in contracts. Define how many hours a vendor has to apply critical security patches, how they notify you, and that confirmation comes in writing. If you are reviewing providers, see our website hosting and maintenance service.
- Pre-authorize emergency decisions. Decide now who can take a site offline without calling a meeting.
- Get regular version reports. A short monthly or quarterly report of software versions turns patching from guesswork into routine.
- Retire what you do not need. Every old microsite is another server to patch.
If no one on your leadership team has the time or background to own this, a fractional CISO can set up the ownership, inventory and vendor terms, then oversee them.
What to do before the week is out
Confirm which of your sites run PHP, get the running version in writing, and make sure each one has the PHP2Shell patch from the official sources. If a site cannot be patched quickly or holds sensitive data, restrict or take it offline until it can. Have someone look for signs of compromise, because patching does not undo an earlier break-in. Then fix ownership, so the next emergency is handled by a named person with a plan rather than by a chain of assumptions.
If you want help assessing your exposure, start with the free cybersecurity assessment. A few quick questions show which areas need attention first.
For the field guide version of what I publish here each week, pick up a copy of Exposed: Inside Risks and the New Architecture of AI Defense on Amazon.
NightFortress works with executives, founders and leadership teams in Northern Virginia and the DC metro area to assess exposure, govern risk, and build security programs that match the actual threat landscape. Contact us to start a conversation.
The information in this article is for educational and informational purposes only. It is not intended as legal, compliance, or professional cybersecurity advice for any specific organization. Consult qualified professionals before making security or compliance decisions.