CVEs and Good Corporate Citizenship

When a serious vulnerability is discovered, the clock starts ticking for everyone, something we’ve experienced firsthand this week with the PHP2Shell leak. 

Usually, an established process kicks in: vendors, providers, and researchers agree on a coordinated disclosure date so that patches can be prepared, customers can be warned, and the wider internet isn’t handed an essential ‘roadmap’ to exploit before organizations can prepare defenses.

This agreement is the only thing standing between responsible disclosure and chaos. When a vendor chooses to ignore this protocol, their early response may look like speed, but in practice, they are making a unilateral decision that puts customers and the rest of the market at risk.

A premature fix is an exploit roadmap

Patches and mitigations are not neutral; they reveal flaws and give bad actors a path to reverse-engineer a vulnerability. Diffing (comparing two versions of text, code, files, or data for changes) a patched binary against the original is a well-established way to work out what was broken, and attackers routinely do it within hours of a release. A network-wide mitigation rule works the same way, only faster and more visibly.

When a mitigation goes live across a large network, anyone can observe it. Researchers and attackers can probe the edge, see which requests are now blocked and which still pass, and infer what the rule is looking for. A rule that is meant to protect customers can quickly become an essential ‘description’ of the vulnerability.

This kind of exposure is far more dangerous prior to disclosure. Before official disclosure, most vendors haven't shipped patches, may not yet be notified, and most defenders don’t yet know the issue exists. Anyone who works out the flaw from a premature mitigation has a head start over everyone still waiting for the embargo to lift.

A mitigation also never reaches everything at once. Rules are bypassed and edge cases get missed—plus not every origin sits behind the same protection. Attackers who learn what the rule targets can look for the paths it doesn’t cover, and the customers early deployment was supposed to help are now the ones exposed.

Deploying a visible mitigation before that date erodes the protection the embargo provides. It trades the safety of the whole ecosystem for credit for being ‘first’.

The responsible path is slower and less flashy. Providers prepare their fixes quietly and test them thoroughly. They give customers the information they need to decide how and when to act, and then they release together when the embargo lifts.

An embargo is a promise

Embargoes work when everyone adheres to them. When one party acts early, it isn’t just an attempt to get ahead; it breaks an agreement other providers and their customers were relying on. A blanket mitigation deployment sent out by another vendor added confusion to an already-tense situation: By forcing mitigation on production traffic before official disclosure, the act was essentially the same as disclosing the vulnerability itself. 

This was not a “we want to do this the right way” move; it was a “we got there first” tactic.

The internet is a shared responsibility

No provider operates in isolation. Our traffic, the origins we protect, and users on the other end all share the same internet.  When one player ignores an embargo, the consequences affect everyone downstream, including the customers who trusted the process and the providers who kept their word.

Responsible providers work together: We respect agreed timelines, give customers real choices, and put the health of the wider internet ahead of all else. Too much is at stake to do it any other way.

Your origin, your timeline

At Fastly, our guiding principle is simple: We care deeply about the health and integrity of our customers’ origins, and we want to empower them to make changes on their own schedule.

In the PHP2Shell incident, and in every other situation, there is no single right way to apply a temporary ‘fix’ or make decisions for our customers. The right answer depends on the customer and their specific context. Approaches could include:

• Applying fixes to a lower environment first and monitoring results before rolling out large decisions

• Pushing fixes to production right after a round of regression testing

• Holding off on making large-scale changes when customers are under high-pressure, high-traffic times (holidays, major events)

None of the above is right or wrong, but we want our customers to control their own story. Customers know their business, their traffic, and their risk tolerance better than we do. Our job is to give them the information and controls to choose from, and to support them in every way we can. We don't determine a fix in a vacuum.

Your partner, not just your provider

At Fastly, we don’t see ourselves as a vendor; we see ourselves as a partner. Your origin, your traffic, and your business are yours, and our job is to help you protect and grow them on your terms.

That means putting you in control: when a critical vulnerability emerges, we don’t make the call for you. We give you the context and all available options so you can decide what’s right for your business. It also means being there when it matters. 

We learn what matters most to you, and we help you get there. That’s what doing right by the customer means to us.

You can keep up to date on the latest PHP2Shell updates as the situation evolves by following along here, or, as always, reach out if you need help.