Share this article
PHP2Shell: The Critical PHP Vulnerabilities and The Vendor Blast Radius
No items found.
Accelerating security solutions for small businesses Tagore offers strategic services to small businesses. | A partnership that can scale Tagore prioritized finding a managed compliance partner with an established product, dedicated support team, and rapid release rate. | Standing out from competitors Tagore's partnership with Vanta enhances its strategic focus and deepens client value, creating differentiation in a competitive market. |
TL;DR
- The threat: PHP2Shell is a set of critical PHP vulnerabilities, rated CVSS 9.2, that can allow attackers to run code remotely or expose sensitive information without authentication.
- Who is affected: Websites and services running affected PHP versions, including WordPress, Drupal, Joomla and custom applications.
- Immediate action: Update PHP to a fixed release. If your hosting provider manages PHP, confirm that it has applied the update.
- Supply chain risk: Your organization can face data exposure or service disruption through a vendor, even if your own infrastructure does not use PHP.
The critical PHP vulnerabilities explained
PHP has released security updates for critical vulnerabilities known as PHP2Shell. The potential blast radius is substantial: PHP is estimated to be used by roughly 70% of websites whose server-side programming language is known. Because the flaws sit in PHP itself, exposure can extend across applications, hosting providers and vendor services running affected versions.
For security teams, the priority is to identify where affected PHP is running, get it updated and understand whether a vendor’s exposure could affect your data or operations.
What is PHP2Shell?
PHP2Shell can let an attacker run code on an affected web server without authentication. It can also expose information held in server memory, including credentials used by the application.
The issues are tracked as CVE-2026-109618 and CVE-2026-109619. Both concern how PHP manages memory during the lifecycle of a web request, particularly when processing is interrupted:
CVE-2026-109618 — Unsafe cleanup after memory exhaustion. An out-of-memory error can interrupt PHP while internal data structures are only partially initialized. During request cleanup, PHP may then treat that incomplete data as valid, creating a memory-corruption condition that can lead to remote code execution.
CVE-2026-109619 — Stale memory references between requests. PHP may retain references to a request’s data after the memory containing it has been freed. When the same PHP worker handles a later request, it can access those outdated references before they are reset. This creates a use-after-free condition that can enable memory disclosure or code execution.
Why updated applications can still be at risk
An application can be fully up to date and still run on a vulnerable PHP version. Updating WordPress, Drupal or Joomla does not necessarily update the PHP runtime underneath it.
Researchers demonstrated remote code execution against all three platforms, illustrating how the same underlying PHP flaws can affect different applications. Remediation must therefore include updating PHP itself, whether it is managed by your team or a hosting provider.
Which products and versions are affected?
Affected releases date back to PHP 5.4. Check the PHP runtime behind your websites, APIs and custom applications.
Update to the fixed release or a later security release in the same series. PHP 8.1 and older are outside regular upstream support; upgrade or use a verified provider-patched build.
Providers may backport fixes without changing the PHP version number, so confirm patch status against your provider’s security advisory.
How to mitigate
Update PHP promptly, including where it is bundled into a server or application image. WordPress’s guidance confirms that these issues require a PHP update rather than a WordPress update.
- Apply and verify the update: Install the fixed PHP release or your provider’s patched package, and restart the affected services. Confirm that the application is actually using the updated software.
- Replace unsupported versions: If you use PHP 8.1 or older, move to a supported version or confirm that your support provider has supplied a fix.
- Reduce exposure while patching: Exploitation attempts have been reported, and WAF rules can help block known attack patterns. Keep relevant protections enabled, but do not treat them as a substitute for updating PHP. If an affected application cannot be patched promptly, consider restricting access to trusted networks or temporarily taking it offline until the update is applied.
What this means for your third-party vendors
PHP’s widespread use creates a broad potential blast radius across the vendor ecosystem, even for organizations that do not run PHP themselves.
The impact depends on what an affected vendor’s systems hold, what they connect to, and which services they support:
- Data exposure: A compromised vendor application could expose information the vendor stores or processes on your behalf.
- Access to connected systems: Some vendors have network access or integration credentials for your environment. Compromising those systems could give an attacker a path into connected services.
- Business disruption: If a vendor’s critical systems become unavailable, your operations may be interrupted—even without direct access to your data or network.
A vulnerability at a vendor does not automatically mean your organization has been compromised. But it creates a reason to investigate where the exposure sits and how your business depends on the affected service.
How Vanta helps you cut through the noise
Responding starts with knowing which vendors have relevant security findings and understanding the role of the affected assets. A finding on a public marketing website can have different implications from one on a customer portal or a system supporting the vendor’s core service.
Vanta’s Continuous Monitoring brings vendor security alerts and asset-role context into that review. This helps your team identify which findings need attention first, ask vendors more specific questions, and follow up on remediation.
Use that context alongside your knowledge of each vendor’s access and responsibilities: what information they handle, how they connect to your environment, and what would happen if their service became unavailable.
Ask the Vanta Agent about PHP2Shell
You can also use the Vanta Agent with Continuous Monitoring to explore PHP2Shell findings across your monitored vendors and get suggested follow-up steps. For example, ask:
- “Which of my vendors have PHP2Shell findings?”
- “Summarize the PHP2Shell findings for Acme Corporation.”
- “What follow-up steps should I take based on these findings?”
The Agent draws on the monitoring findings available in your Vanta account, helping your team move from reviewing alerts to understanding what needs attention.
Next steps for Vanta customers
We’re here to help you manage this risk. If you use Vanta for TPRM, open Vendors → Monitoring to review relevant security alerts across your vendors.
For vendors that need further follow-up, start a new Vendor Incident assessment in the affected vendor’s Assessments view and send the associated questionnaire through Vanta Exchange. Vendors can upload an incident statement, giving your team a structured way to document their response and track follow-up in one place.
Follow up with vendors that are not meeting their stated SLAs for critical vulnerabilities. If a critical vendor cannot patch promptly, work with your service owner to reduce exposure. This may include restricting the vendor’s access to your data or internal networks, or temporarily pausing data syncing until remediation is confirmed.
“
“
FEATURED VANTA RESOURCE
The ultimate guide to scaling your compliance program
Learn how to scale, manage, and optimize alongside your business goals.
.png)
.png)
.svg)
.svg)
