PHP2Shell: Your Entire Vendor Portfolio Could Be at Risk. Where Do You Start?

On October 21, 2026, two critical PHP vulnerabilities were disclosed: CVE-2026-109618 and CVE-2026-109619, collectively known as PHP2Shell.

Both carry a CVSS 4.0 score of 9.2 and can allow an unauthenticated attacker to execute code on an affected web server.

The vulnerabilities were leaked on October 20, before the coordinated disclosure and before patches were available. Security researchers have demonstrated a working exploit, and exploitation attempts have already been reported. The UK's National Cyber Security Centre (NCSC) has advised organizations to consider taking affected systems offline if they cannot be fixed immediately.

Why PHP2Shell is different

The scale makes this particularly concerning.

PHP powers 69.3% of websites whose server-side programming language is known, according to W3Techs. Roughly half of those PHP websites run version 8.1 or older.

That means approximately one-third of websites run PHP versions that no longer receive standard security releases from the PHP project. Fixes are available in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, but those updates still need to be installed. Older versions may require a backported fix from a distribution or support provider, or an upgrade to a supported PHP release.

For some organizations, that upgrade is a full software project involving changes to application code, dependencies and testing. It could take weeks or months.

And some of those organizations are your vendors.

Which of your vendors are affected?

How many of your vendors are running vulnerable PHP versions? How many have already patched? And how many are running unsupported versions that could take months to upgrade?

You probably can't answer those questions.

External scanning can't reliably confirm which vendors are affected or whether they've applied the fix. A strong security rating doesn't answer that question either.

The problem extends beyond a vendor's main application. PHP can also run inside hosting control panels, bundled software, appliances and other services the vendor relies on. A vendor might not even manage the affected PHP installation directly.

That leaves TPRM teams with a difficult task: determining which vendors are affected, which have remediated the issue, and which could remain exposed for an extended period.

But not every affected vendor creates the same risk for your organization.

Same vulnerability. Very different consequences.

Consider two vendors affected by PHP2Shell.

One hosts a public marketing website. The other processes your customer data, has access to your CRM, and supports a critical business operation.

Same vulnerability. Very different consequences for your organization.

And if both vendors tell you they won't be able to fix the issue for months, which one deserves your attention first?

Where do you start? Prioritize by inherent risk.

When a major vulnerability is disclosed, TPRM teams face a familiar problem.

Everyone needs answers at the same time.

Hundreds of customers contact the same vendors, asking whether they're affected, whether they've patched, and when they'll be done. Vendors receive a flood of nearly identical requests, while security teams spend their time chasing responses.

With PHP2Shell, the potential scale makes that problem considerably worse.

Sending the same questionnaire to every vendor creates more work on both sides, without necessarily getting the most important answers first.

A better approach starts with inherent risk.

Prioritize vendors based on what they mean to your organization:

• Sensitive data: Does the vendor hold employee records, financial information, customer data, or intellectual property?
• Access: What systems and environments can the vendor access, and with what permissions?
• Business criticality: What happens to your operations if the vendor becomes unavailable?

The goal isn't to determine which vendors have the worst security posture. It's to identify where a vulnerability or outage could have the greatest impact on your business.

Contact those vendors first.

Why external security ratings won't give you the answer

External security scanners and ratings platforms can provide information about a vendor's visible security posture. But they can't reliably tell you whether a vendor is affected by PHP2Shell or has applied the fix.

A vendor can have an A security rating while running vulnerable software. A rating updated today doesn't necessarily reflect a vulnerability disclosed today.

And even if a scanner identifies an outdated PHP version, that alone doesn't establish whether the system is vulnerable or whether a security fix has already been applied.

For the vendors that matter most, you need direct answers about their exposure, patch status, and remediation timeline.

What to ask your vendors about PHP2Shell

For the vendors you prioritize, a generic request for their latest security assessment won't be enough.

You need specific answers:

• Are any systems processing our data or supporting our services affected by CVE-2026-109618 or CVE-2026-109619? Include PHP running inside bundled software, appliances, hosting control panels, or services provided by your own third parties.
• Have the affected systems received a fix? Are they running PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or a distribution package or backported build containing the security fix?
• If not, what is the remediation plan? Are interim mitigations in place, and when will the affected systems be fixed?
• Could remediation require downtime or affect the services we use?

The answers determine what happens next.

Not every vendor response means the same thing

‍

The important distinction is between a vendor that can install an available fix today and one facing a substantial upgrade project.

Those are different problems. They require different follow-up timelines, and potentially different decisions about your exposure.

How Lema helps teams respond to PHP2Shell

The challenge isn't just understanding the vulnerability. It's managing the response across an entire vendor portfolio.

Lema helps TPRM teams focus on the vendors that matter most, contact them at scale, and manage their responses without running hundreds of separate assessments.

1. Prioritize vendors by inherent risk

Lema uses the context of each vendor relationship, including the data a vendor holds and the access it has to your environment, to prioritize vendors by inherent risk.

For PHP2Shell, teams can identify which vendors warrant immediate outreach based on their potential impact, rather than treating every vendor equally.

2. Launch targeted outreach campaigns

With Lema's Outreach Campaigns, teams can select the vendors they want to contact and use a dedicated PHP2Shell questionnaire.

Lema generates the outreach emails, and teams can add missing vendor contacts as needed.

Instead of sending a generic questionnaire to everyone, the campaign focuses on the specific information required to determine whether a vendor is affected and what remediation is underway.

3. Track responses and follow up in one place

Lema tracks vendor responses centrally and sends reminders to vendors that haven't replied.

Teams can see which vendors have responded and which still need follow-up.

Outreach Campaigns operates separately from regular vendor assessments, so the same workflow can be used for the next critical vulnerability, vendor incident, or emerging third-party threat.

You can't patch your vendors. But you can control your exposure.

PHP2Shell illustrates how quickly a newly disclosed vulnerability can create a problem across an entire vendor portfolio.

You may have hundreds of vendors to investigate, limited visibility into their systems, and remediation timelines that stretch for months.

Trying to assess everyone at once isn't the answer.

Start with the vendors whose compromise or downtime would have the greatest impact on your organization. Get specific answers about their exposure and remediation plans. Track the ones that haven't responded or can't fix the problem immediately.

You can't control when a vendor patches its systems. But you can control where you focus, what information you demand, and how you manage your exposure while you wait.

For Lema customers: Outreach Campaigns is available under Outreach in the left navigation, with a PHP2Shell questionnaire template ready to use.

Not using Lema? Share your vendor inventory with us, and we'll show you how to prioritize outreach based on inherent risk.