[Blog](/blog) Show links Resources [Blog](/blog) [Breaches](/breaches) [eBooks, reports, & more](/resources) [Events](/events) [News](/news) [Third-Party Risk Management](/category/third-party-risk-management) Show links Categories [Attack Surface Management](/category/attack-surface-management) [Company News](/category/company-news) [Compliance and Regulations](/category/compliance-and-regulations) [Cybersecurity](/category/cybersecurity) [Data Breaches](/category/data-breaches) [DevOps](/category/devops) [Human Cyber Risk](/category/human-cyber-risk) [Risks and Vulnerabilities](/category/risks-and-vulnerabilities) [Third-Party Risk Management](/category/third-party-risk-management) [Vendor Risk Management](/category/vendor-risk-management) [PHP2Shell Is a Vendor Problem Too: How to Find and Close Third-Party Exposure](/blog/php2shell-third-party-exposure) Publish date November 2, 2026 {x} minute read # PHP2Shell Is a Vendor Problem Too: How to Find and Close Third-Party Exposure [Get a demo](/contact-sales) [Free trial](/demo) [Download the PDF guide](#) [Free trial](/demo) Written by [Cassy van Eeden](/team/cassy-van-eeden) Content Writer Cassy is a Content Writer at UpGuard with a background in B2B SaaS and tech writing. Reviewed by [Kaushik Sen](/team/kaushik-sen) Chief Marketing Officer Kaushik has a background in software engineering, enterprise solution architecture, and data analytics. He brings a unique, data-driven perspective to cybersecurity education. Table of contents Free resource ### [Download now](#) PHP2Shell [affects every PHP version back to 5.4](https://www.cisa.gov/news-events/alerts/2026/10/21/critical-vulnerabilities-php-require-immediate-patching), released in 2012. That range covers 14 years of releases, and some of them are still running on vendor servers you don’t control and can’t patch. If you need background on the vulnerabilities themselves, start with our [PHP2Shell explainer and response framework](https://www.upguard.com/blog/php2shell-a-clear-explanation-and-response-framework). This guide walks through four steps, from finding exposed vendors to closing out your response. ## Why PHP2Shell is a third-party risk problem Patching your own servers is the part of PHP2Shell you control. The rest sits with your vendors, on servers you can’t scan from the inside and on patch schedules you don’t set. Some of them haven’t touched their PHP version in years. So when leadership asks whether any of your vendors are exposed, your own patch records can’t answer the question. That gap is what turns a PHP vulnerability into third-party risk. Here’s where vulnerable PHP may be hiding in your vendor portfolio: * Managed WordPress and other content management system (CMS) hosting, where the host picks the PHP version, and your vendor may never see it. * Marketing and web agencies running campaign sites and landing pages under your brand. * SaaS products with PHP behind the login screen. * Appliances and licensed software with PHP built in, which stay vulnerable until the manufacturer ships an update. Then there’s the layer you can’t see at all: many vendors don’t run their own web servers. A hosting company or CMS provider runs PHP for them, which makes that provider a fourth party. Ask your vendor whether they’ve patched, and the honest answer may be “we’ll have to check with our host.” Some vendors can’t patch quickly even when they want to. PHP 8.1 and older are end-of-life, so there’s no official release to install. For a vendor on one of those versions, the lasting fix is a migration project, and their timeline becomes your exposure window. ## How to find exposed vendors and confirm they’ve patched If you’re triaging PHP2Shell vendor risk right now, you need two answers quickly: which vendors are exposed, and which of those matter most. Four steps get you both and leave a record you can defend later: ### Step 1: Find which vendors are exposed You don’t have to check vendors one at a time. [UpGuard Vendor Risk](https://www.upguard.com/product/vendor-risk) scans more than 15 million organizations daily across over 400 risk signals and treats CVE-2026-109618 and CVE-2026-109619 as verified vulnerabilities. It flags any vendor domain or IP address running an affected PHP version. Both findings show up in one view across your monitored vendors, with a count of how many vendors carry each one. So when someone asks “How many of our vendors are affected?” you’ve got the number in front of you. From there, select either finding to see which vendors make up that count, then drill into each one to pull the specific domains and IPs running a vulnerable PHP version. That’s the list you’ll send each vendor, so nobody has to guess which assets need fixing. > *Only need to check one vendor? Run their domain through our free *[*PHP2Shell Check*](https://www.upguard.com/tools/php2shell-check)*. It looks at one domain at a time, and you don’t need to log in to anything. You’ll also get a response pack with a vendor evidence questionnaire and a remediation guide.* ### Step 2: Prioritize by what the vendor touches A vendor hosting a campaign microsite and one processing your customer data can carry the same finding, but they don’t deserve the same urgency. Start with vendors that hold your data or credentials, or the vendors your organization most depends on, then work through your top tiers. Vendor Risk already knows each vendor’s tier and labels, so it shows them right alongside the finding. Add the count of each vendor’s affected domains and IPs, and your priority list is ready. Next, you can [send a remediation request](https://www.upguard.com/product/vendor-risk/risk-remediation) straight from the finding. The vendor sees the risk details in their own portal, so you don’t have to rebuild the context in an email thread. ‍[Daily scanning](https://www.upguard.com/product/vendor-risk/continuous-monitoring) picks up the vendor’s fix once it goes live, and you can run an on-demand rescan if you need confirmation sooner without waiting on the vendor.  ### Step 3: Ask vendors what only they can tell you To go with our scanning, we’ve built the PHP2Shell Incident Response Questionnaire, now in the [Vendor Risk Questionnaire Library](https://www.upguard.com/product/vendor-risk/questionnaire-management). Send it to affected vendors to find out what only they can tell you, such as whether they’ve patched and whether your data was affected. The scan tells you who’s exposed; the questionnaire tells you how much it matters. The questionnaire is short. The first part asks about PHP exposure, including any PHP that hosting or CMS providers run for your vendor, and whether those systems hold your data or credentials. The second part covers remediation, including how long the vendor’s systems sat exposed before they patched. The last part gets to exploitation and impact. Did the vendor review its logs and rotate credentials? And the one you care about most: was your data affected? As the questionnaire sits in the same platform as your PHP2Shell findings, the vendors you prioritized in Step 2 can have it the same day. It’s just as useful for critical vendors whose scans come back clean. For top-tier vendors and anyone holding your data or credentials, a clean scan is a good start, but a completed questionnaire puts their confirmation in writing. > ‍*To see vendor close-out live, *[*register for our PHP2Shell webinar*](https://www.upguard.com/webinars/php2shell)*. We’ll share what our scanning data shows, then walk through finding and closing out PHP2Shell across your vendors. Everyone who registers gets a vendor questionnaire template to send the same day. Can’t attend live? Register anyway, and we’ll send you the recording.* ### Step 4: Show the response is closed Leadership and auditors will eventually ask the same question: were we exposed through a vendor, and what did we do about it? Vendor Risk has that answer ready, because it keeps a record of what you asked for, what each vendor told you, what they fixed, and what you accepted as an exception. And exceptions will come up. When a vendor shows you a backported fix but their version string still reads as vulnerable, you can log an approved risk waiver with their evidence attached and an expiry date for review. The decision stays tied to the original finding, so nobody has to piece it together from scattered spreadsheets later. When the board wants a summary, our library of [over 14 built-in reports](https://www.upguard.com/product/vendor-risk/risk-reporting) draws on the same record. You can show which vendors were affected and where remediation stands without manually stitching together slide decks. ## Close the PHP2Shell gap in your vendor portfolio Patching your own PHP was the first job. The rest of the work sits with your vendors and the providers they rely on, and it’s done when you can show which vendors were at risk and what they did about it. UpGuard Vendor Risk brings scanning, questionnaires, remediation tracking, and reporting into one place, so you can get there without juggling spreadsheets and email threads. [Start a free trial](https://www.upguard.com/demo) to find out which of your vendors are running vulnerable PHP. ## Frequently asked questions ### What is PHP2Shell? PHP2Shell is the name of two critical vulnerabilities, tracked as CVE-2026-109618 and CVE-2026-109619, both rated 9.2 on the Common Vulnerability Scoring System v4.0. They allow an unauthenticated attacker to run code on a vulnerable PHP server. The PHP project released fixes on October 21, 2026. ### Which PHP versions are affected by PHP2Shell? PHP2Shell affects every PHP version from 5.4 up to the fixed releases, including end-of-life branches. The fixed versions are 8.2.35, 8.3.36, 8.4.27, and 8.5.12. Servers running Apache with mod\_php face the highest risk because the exploit runs before any application code. ### Is there a fix for end-of-life PHP versions? Partly. There’s no new official release for end-of-life PHP versions. The PHP security team has published minimal source patches for 7.4 through 8.1, and some Linux distributions have backported fixes. Nothing older than 7.4 has a fix from the PHP project, so the lasting fix is an upgrade to a supported version. ### How do I check whether my vendors are affected by PHP2Shell? Use external scanning that flags vendor domains and IPs running an affected PHP version. UpGuard Vendor Risk does this across your monitored vendors, and the [PHP2Shell Check](https://www.upguard.com/tools/php2shell-check) tests a single domain.  ### What should I ask vendors about PHP2Shell? Ask whether they run PHP, including on systems a hosting or CMS provider manages for them, and which versions. Then ask when they patched, how long they were exposed, whether they checked logs and rotated credentials, and whether your data was affected. Free resource ### [Download now](#) ## Related posts Learn more about the latest issues in cybersecurity. Third-Party Risk Management #### [The Evidence Is In: UpGuard Named a Leader in the IDC MarketScape for Worldwide Third-Party Risk Management](/blog/upguard-named-leader-in-idc-marketscape) UpGuard has been named a Leader in the IDC MarketScape: Worldwide Third-Party Risk Management Services 2026 Vendor Assessment. Find out why. [](/team/cassy-van-eeden) [Cassy van Eeden](#) October 26, 2026 Third-Party Risk Management #### [We Researched Four AI Evidence Analysis Tools for TPRM. Here’s What We Found.](/blog/ai-evidence-analysis-tools-for-tprm) We researched four AI evidence-parsing tools against four criteria that security teams often overlook. None nailed all four. [](/team/cassy-van-eeden) [Cassy van Eeden](#) September 29, 2026 Third-Party Risk Management #### [The Vendor Assurance Confidence Gap: Why It’s Widest With Your Most Critical Vendors](/blog/vendor-assurance-confidence-gap) Vendor assurance efforts are rising while confidence in them is falling. This gap is widest with the vendors that matter most. Here’s why. [](/team/cassy-van-eeden) [Cassy van Eeden](#) August 25, 2026 Third-Party Risk Management #### [Higher Education TPRM in 2026: New Research Maps the Vendor Visibility Gap](/blog/higher-education-tprm-2026) Explore UpGuard’s latest research into higher education third-party risk, including supplier concentration and systemic vendor exposure. [](/team/cassy-van-eeden) [Cassy van Eeden](#) August 10, 2026 Vendor Risk Management #### [Vendor Tiering That Scales: A Weighted-Model Implementation Guide](/blog/vendor-tiering-that-scales) UpGuard's guide to vendor tiering at scale: a weighted risk model that tiers vendors objectively and routes high-risk vendors for review automatically. [](/team/cassy-van-eeden) [Cassy van Eeden](#) October 13, 2026 Vendor Risk Management #### [The Vendor Tiering Series: Why Tier Your Vendors](/blog/vendor-tiering-why-tier-vendors) When every vendor is a priority, none actually are. Learn how effective vendor tiering defines criticality and maintains a defensible security posture. [](/team/revashni-moodley) [Revashni Moodley](#) February 25, 2026 [All posts](/blog) Experience superior visibility and a simpler approach to cyber risk management [Get a demo](/contact-sales) [Free trial](/demo)