PHP2Shell: what small defense contractors should do today

On October 21, 2026, the PHP project released emergency updates for two critical vulnerabilities, now widely called PHP2Shell. Both are rated 9.2 out of 10, and both can let an attacker run their own code on a web server without logging in. Details leaked before the fixes were ready, and security vendors and hosting providers are already reporting attempts to exploit them.

If you are a small defense contractor, this probably affects you even if you have never heard of PHP. Here is what it is, how to tell if you are exposed, and what to do today.

What happened, in plain English

PHP is the language behind a large share of the web: WordPress, most shared hosting, cPanel, many contact forms, client portals and small business apps. The two flaws are in how PHP cleans up memory between web requests:

• CVE-2026-109618: when PHP runs out of memory at the wrong moment, it can leave request data half-built and later treat it as valid.
• CVE-2026-109619: data from one request can survive after its memory is released, and a later request on the same server process can reuse it.

In both cases, a carefully crafted request can turn that confusion into control of the server. The PHP project says every PHP installation that serves web requests is at risk, including PHP-FPM, Apache with mod_php (the highest risk), php-cgi, FrankenPHP and LiteSpeed.

Why this matters for a defense contractor

A compromised web server is rarely just a website problem:

• Your contract information may be close by. Proposals, contact lists, invoices or shared files often live on the same hosting account, or on systems the web server can reach. That is Federal Contract Information (FCI).
• Passwords and keys can leak. Researchers have shown the same class of bug can expose memory, which may contain passwords, session tokens and API keys for your email, CRM or payment tools.
• It is part of what you affirm. FAR 52.204-21 requires you to "identify, report, and correct information and information system flaws in a timely manner." If you affirmed CMMC Level 1 in SPRS, you told the government you do this. A critical, actively targeted flaw on a system you own is exactly the case that requirement is about.

Step 1: find out if you run PHP

Make a quick list of anything web-facing you own or pay for: your company website, WordPress or other CMS, hosting control panel, client or vendor portals, webmail, timekeeping or ticketing tools you host yourself.

Then ask one question of each provider or IT person: "Does this run PHP, and has it been updated for the October 21 PHP security release?"

• Managed hosting or SaaS: your provider has to patch. Ask them to confirm in writing, and keep their answer.
• Your own server or VPS: check the version the web server actually runs, not only php -v on the command line. A simple way is a temporary phpinfo() page that you delete right after, or your hosting panel's PHP settings page. Servers often have more than one PHP version installed.

Step 2: update today

The fixed versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Update to the one for your branch, then restart PHP and the web server so every worker loads the new version.

If you run PHP 8.1 or older, the PHP project no longer ships fixes. Check whether your Linux distribution or hosting vendor provides a patched build; if not, plan the upgrade now and use the steps below in the meantime.

Step 3: if you cannot update right away

The PHP project is clear that there is no complete workaround; only updating makes you safe. These settings reduce exposure while you schedule the update:

• Set session.upload_progress.enabled=0 in php.ini or your server configuration (not in application code), then restart all PHP workers.
• Set memory_limit=-1 in a way applications cannot override, and set a low post_max_size.
• On PHP 8.5, set fatal_error_backtraces=0 and restart.
• If a system is not needed right now, take it offline or restrict who can reach it until it is patched.

Step 4: check for signs of compromise

Because attacks started before many people patched, do a short check after updating:

• Look for new admin users in WordPress or your hosting panel, and for files or plugins you don't recognize.
• Review recent web server logs for unusual errors or a spike in large requests.
• Change passwords and API keys stored on or used by the server: database, email, payment and CRM integrations. Turn on multi-factor sign-in wherever it is available.

If you find something you can't explain, involve your hosting provider or an incident response firm, and remember that if you handle CUI under DFARS 252.204-7012, cyber incidents have a 72-hour reporting rule.

Step 5: write down what you did

Note the date, the systems you checked, what you updated or who confirmed it for you, and any credentials you changed. It takes five minutes, and it is the evidence that you met the flaw remediation requirement if anyone ever asks, including whoever signs your next SPRS affirmation.

Keeping this from being a fire drill

Events like PHP2Shell are why the Level 1 requirements exist: know what systems you have, fix flaws promptly, control who can sign in. If you want a simple way to keep that in order, Fix&Affirm walks through all 15 FAR 52.204-21 requirements, shows how to close gaps and keeps the evidence behind your SPRS affirmation in one place. The assessment is free.

Start your free Level 1 assessment

Source: PHP project security release, October 21, 2026. This article is general information, not legal or incident response advice. If you believe a system was compromised, contact your hosting provider or a qualified incident response firm.