One fix, every vendor: how to reach suppliers as partners when a widely used product is hit

On October 21, the PHP project shipped fixes for two critical flaws that, in its words, "can allow unauthenticated remote code execution". Its advisory covers "all PHP installations serving web requests" and is blunt about the way out: updating to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 is "the only safe choice". CISA published its own alert the same day urging organizations to patch immediately. CISA added both flaws to its Known Exploited Vulnerabilities catalog on October 26.

Within hours, a familiar email started going out from third-party risk teams everywhere. Are you affected by the PHP vulnerabilities? Yes / No. Please respond within 24 hours.

Every supplier got it. Most got it from every customer at once.

This post isn't about the vulnerabilities. Rescana's PHP advisory covers versions, mitigations and status. It's about that email, and why a week like this one goes better when you reach your vendors as partners rather than as auditors.

Why the blast email stalls everyone

PHP is a good example of what makes these weeks hard. It rarely shows up on a vendor inventory. It sits underneath customer portals, hosting control panels, content platforms and appliances that bundle their own runtime. Cisco's advisory for this release initially listed some products as affected and a longer set as still "under investigation". Many vendors honestly didn't know the full answer on day one, because they were waiting on their own suppliers.

Now picture the supplier's side. Their security team is planning the patch, chasing their own providers and answering the same question from dozens of customers in dozens of formats. The yes/no form gets the quickest reply they can give: "We are reviewing and will update." That answer is accurate, but it isn't useful.

Your side isn't better. The business asks security whether the customer portal launch is still on. You have a spreadsheet of "reviewing", no way to tell the critical vendors from the long tail, and no record of what anyone actually checked. The process feels thorough, but nobody has an answer they can act on.

Same side of the table

The supplier received this news the same day you did. They want it fixed more than you do, because it's their environment. When the outreach sounds like an audit, you get defensive, minimal answers. When it sounds like help, you get specifics: which products, which version, what's in place now, when the fix lands.

That isn't softness. It's how you get accurate answers, and accurate answers are what let the business keep moving.

What partner-style outreach looks like

1. Tier before you send. You don't need to contact every supplier today. Rate each one on three things: access into your systems or identities, sensitive data you send them, and how badly their outage would disrupt you. Then cross that with likely exposure to this product: web-facing SaaS, portals, hosting and appliances first. Reach out today to suppliers that rank high on both. Contact the next tier this week. Confirm the rest lightly and keep monitoring them.
2. Look before you ask. Check what's visible from outside first: exposed web services, version banners where they exist, appliances you know about. It turns "are you affected?" into "we noticed this service on your side; is it on a fixed build, or is it fronting something that bundles PHP?" A specific question gets a specific answer, and it shows you've done your share of the work.
3. Ask three questions, not thirty.
   • Are you running PHP, including builds bundled inside products or appliances, and is it on a fixed version?
   • If not yet, what interim measures are in place, and roughly when do you expect to update?
   • Is there anything we should do on our side, such as rotating a key, restricting an integration or adding monitoring?
4. Give before you take. Pass along what you know: the fixed versions, links to vendor advisories that matter to them, the note that PHP's interim measures reduce exposure but, as PHP itself says, don't make an installation safe. A two-way exchange gets more honest answers. Some providers already work this way. Railway's preliminary report on its own October incident notes that it "reported potentially impacted secrets to partner vendors". Incident notices can flow both directions.
5. Agree a plan, not a demand. Agree on an interim measure, a target date and how they'll tell you if something changes. Write it down as a shared plan. A deadline you impose produces a date. A plan you agree on produces a date the supplier will actually hit.
6. Keep "patched" and "reviewed" separate. A fixed version is one answer. Whether anything happened before the fix is another, and it needs different evidence. The same distinction runs through our piece on fourth-party risk after a KEV week.
7. Leave the record open. Information keeps moving. Two days after the release, PHP published an informational advisory recommending one more configuration setting until its next regular release. Save each supplier's answer as evidence with a date on it, and reopen it automatically when new guidance lands. That's the difference between a closed ticket and closed exposure, which we covered in Remediation theater.
8. Close the loop with the business. Tell product and business owners which vendors are confirmed, which are in progress with a plan, and what's in place in the meantime. Most launches don't need every supplier answered. They need the right ones answered accurately. That's how a review keeps pace with the business instead of blocking it.

What to ask this week

For your critical and high-tier suppliers, in a short, friendly note:

1. "We know this landed on everyone at once. We're checking in so we can support each other, not to add to your load."
2. Do you run PHP anywhere that touches our data or services, including inside products or appliances? Is it on a fixed version?
3. If not yet, what's in place in the meantime, and what's your rough target date?
4. Are any of your providers still investigating, and is there anything you're waiting on from them?
5. Is there anything you'd like us to do on our side?
6. How would you like to let us know if anything changes?

If you can't say which of your suppliers need that note today, the gap isn't in your questionnaire. It's in your tiering.

Where this fits

This is the layer Rescana works on in supply chain security and risk. It finds third and fourth parties through identity, procurement, IT-asset and OSINT signal, checks vendor answers against live exposure, and keeps follow-up moving until there's evidence. Follow-up stays under your approval. The aim is reviews that don't block the business and answers you can stand behind.

Further reading

• Rescana advisory: Two Critical PHP Vulnerabilities (PHP 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35)
• Risk-based TPRM isn’t a lighter questionnaire
• Your vendor patched. Their MSP didn't
• Remediation theater

Soft next step

If your security, legal and risk teams want a calmer way to work weeks like this with suppliers, focused on the vendors that matter, accurate on what's actually fixed, and done as partners, we're glad to compare notes.

Talk to an expert