PHP2Shell and SecurityScorecard: No Platform Exposure, No Customer Impact
The SecurityScorecard platform was not exposed to the PHP2Shell vulnerabilities, and there is no impact to the platform or to customer data within it. CVEdetails.com, a SecurityScorecard-owned property, was running an affected PHP version and was patched immediately upon release of the fix on October 21, 2026. We have reviewed logs for the exposure window and found no evidence of exploitation or unauthorized data access. There was no impact to SecurityScorecard services and no downtime.
No action is required on your part regarding SecurityScorecard services. The rest of this advisory covers what we recommend for your own environment and your third parties.
What PHP2Shell Is
PHP2Shell is two critical memory-safety flaws in the PHP runtime itself, CVE-2026-109618 and CVE-2026-109619, each rated CVSS v4.0 9.2. Any site on an affected PHP version is exposed even if its application code is secure. PHP powers roughly 70% of websites, including WordPress, Drupal, Joomla, Moodle, Nextcloud and MediaWiki.
- What an attacker can do: execute code without authentication as the PHP web worker, or read process memory belonging to other requests, including passwords, session tokens, API keys and certificates. The memory-disclosure path leaves no code-execution artifacts and is harder to detect.
- Affected versions: PHP 5.4 through every release before the October 21, 2026 fixes.
- Fixed versions: 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1 and earlier are end of life. The PHP security team published minimal source backports for 7.4, 8.0 and 8.1; 7.3 and earlier and 5.x have no fix from the PHP project. Linux distributions and extended-support vendors are shipping backported packages under their own version numbers.
- Exploitation: technical details leaked on October 20, ahead of coordinated disclosure, and PHP shipped fixes a day early. Cloudflare, watchTowr and Amazon report exploitation attempts against their networks and honeypots; CISA’s October 21 alert said it had not observed exploitation at publication, and neither CVE was on the Known Exploited Vulnerabilities list as of this writing. Publicly circulating proof-of-concept code does not yet achieve code execution against default installs, but expect that to change within days.
What to Do Now
Patching the PHP runtime and restarting every worker is the only complete fix. Work the steps below in order; most organizations will find more PHP than they expected.
- Inventory every PHP runtime from scanning and cloud telemetry, not from asking around. Our own response found PHP on managed hosting, self-managed VMs across several cloud accounts, containers on end-of-life versions and an orphaned demo box no team owned. Include sites owned by teams outside IT, and tag each as managed (vendor patches) or self-managed (you patch).
- Patch to a fixed release, then restart. Install 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or your distribution’s backported package, then restart Apache, PHP-FPM and any long-running PHP workers. Updating WordPress or another application does nothing for the runtime beneath it. Verify by checking the running version, not the package you installed.
- Track your distribution’s advisory, not the upstream version number. On most managed Linux distributions the fix arrives as a backported revision that keeps the old version string. Hunting for “8.2.35” in a repository that ships backports wastes a day.
- Decide what to do with end-of-life PHP. For 7.4, 8.0 and 8.1, apply your vendor’s backport or PHP’s minimal source patch. For 7.3 and earlier, use an extended-support channel if you have one, or isolate or take the system offline. CISA’s guidance is that systems that cannot be updated immediately, or that run 8.1 or earlier, should be taken offline until patched.
- If you cannot patch within days, apply the interim measures below. None is a substitute for the update; each closes some attack paths and not others.
- Confirm your WAF rule is actually in the request path. Edge providers shipped rules within hours, but a rule protects nothing if the origin answers directly. Several of our highest-risk hosts resolved straight to their cloud origin IPs. Block direct-to-origin traffic or the rule is theater.
- Hunt back to at least October 17. Amazon’s honeypot data shows exploitation attempts began before the patch. Look for memory-limit errors, repeated 500s and unexplained PHP worker restarts or segfaults; multipart POSTs carrying the PHP_SESSION_UPLOAD_PROGRESS field, especially to endpoints that never take uploads; a “php2shell” user-agent; abnormally large PHPSESSID values in responses; and shells or downloaders spawned by php-fpm, php-cgi or Apache.
- Rotate secrets on exposed hosts. One of the two flaws leaks process memory, so patching does not undo what was already read. Most web servers do not log request bodies, so absence of evidence is weak. For internet-facing hosts that sat unpatched while exposed, rotate session keys, database credentials, API tokens and certificates that lived in worker memory.
- After patching, restore your limits and test. The patched build adds a hard out-of-memory limit; workers that hit it exit with code 137. Replace any temporary memory_limit = -1 with a real value, keep post_max_size below the memory budget, leave session.upload_progress disabled if nothing uses it, and watch error rates for 48 hours.
Interim Measures if You Cannot Patch Immediately
| Measure | What it addresses | Caveat |
|---|---|---|
| memory_limit = -1, set administratively (php_admin_value or server config) and paired with a cgroup v2 memory.max cap | Removes PHP’s own out-of-memory abort, which most attack paths rely on | Never substitute RLIMIT_AS or RLIMIT_DATA; PHP warns they trigger the same vulnerable path. Without the cgroup cap one request can exhaust the host |
| session.upload_progress.enabled = 0 in php.ini, the FPM pool or server config, then restart every worker | Blocks the confirmed session paths of CVE-2026-109619 | Must apply before request parsing: ini_set() and .user.ini do not work. Does not cover other variants |
| fatal_error_backtraces = 0 (PHP 8.5 only), then restart | Blocks the fatal-backtrace path of CVE-2026-109619 | Fatal errors lose their backtrace |
| Lower post_max_size (8M without uploads, 32M with) and matching body limits at the web server or proxy | Less attacker-controlled memory pressure during multipart parsing | Caps legitimate uploads; test upload flows |
| WAF rule blocking the PHP_SESSION_UPLOAD_PROGRESS field | Catches the most common probe pattern | Safe for nearly every site. Blocking all multipart POSTs instead breaks uploads, AJAX forms and common form plugins. Attackers are already mutating payloads |
Which Systems to Fix First
Start with internet-facing hosts running Apache mod_php with default session settings; that is the configuration where unauthenticated code execution was validated with no application bug required. The session path also works against PHP-FPM, and session.upload_progress is on by default, so FPM hosts are next, not exempt.
Do not rank by finding count. In our own triage the noisiest host, with hundreds of findings, was not the most dangerous one; the host that mattered was live, internet-facing and had its full port range open, with far fewer findings attached. Score each system on the factors below, starting with the services you must keep running.
| Factor | Question to ask | Move it up when |
|---|---|---|
| Exposure | Is the system reachable from the internet, and can the origin be reached directly? | Yes to either |
| Configuration | mod_php or PHP-FPM? Is session.upload_progress enabled? | mod_php, or upload_progress on |
| Exploitability | Does it accept multipart POSTs? Are probes already in the logs? | Yes to either |
| Mitigation speed | Can you patch or apply interim measures within days? | No |
| Data sensitivity | What would an attacker reach in process memory or on disk? | Credentials, tokens, personal or regulated data |
| Lateral movement | Could an attacker pivot from this host to others? | Shared credentials, flat network, management agents |
| Public impact | Does an outage or a compromise cause more harm? | Decide in advance per service |
Taking a service offline protects data but interrupts the service; leaving it online risks compromise. Decide which outcome you can tolerate for each service before the exploitation picture forces the choice.
Your Third Parties and Shared Dependencies
Your exposure extends to every provider that runs PHP on your behalf, and many of your vendors share the same few providers. Managed WordPress and Drupal platforms, cPanel and Plesk shared hosting, MSPs, and products that embed PHP (Moodle, Nextcloud, MediaWiki, many appliances) are common points of concentration: what looks like dozens of separate exposures often traces back to a handful of shared points of failure.
Map those dependencies now. Identify which providers sit behind your highest-priority services and which of them also serve your peers. Then open a ticket with each and ask:
- Do you run PHP on any system that supports our services or handles our data, including embedded products and appliances, not just websites?
- Which PHP versions and which SAPI (mod_php or PHP-FPM) do you run, and is session.upload_progress enabled?
- Have you patched, and have you restarted the workers? What version is running now?
- For end-of-life branches, which backport channel covers you?
- Which compensating controls protect those systems until then, and can your origin be reached directly, bypassing the WAF?
- Have you reviewed logs back to October 17, and have you rotated secrets on hosts that were exposed?
- Which of our services share infrastructure with other customers?
Two cautions. Many large platforms were part of the coordinated disclosure and patched early, but “they were in the loop” is an assumption to verify, not an answer; our managed-site providers handled their own patching and we still opened tickets and confirmed it. And treat outside-in version evidence, including ours, as a lead rather than proof: distribution backports keep old version strings (false positives), while expose_php = 0 and CDN fronting hide the version entirely (false negatives). Use it to triage; confirm by attestation.
How SecurityScorecard Can Help
SecurityScorecard’s STRIKE Threat Intelligence Team observes approximately six million internet-facing assets running PHP. Our scanning identifies exposed PHP infrastructure in your own footprint and across your vendor portfolio, so you can see which third parties advertise affected versions and which providers your vendors have in common. TITAN Secure customers with the Driftnet add-on can build a PHP2Shell response workflow; see the walkthrough video here for details.
For questions about this advisory or about SecurityScorecard’s own response, contact your account team or security@securityscorecard.com. We will update this advisory as the exploitation picture changes.
