Why embargoes matter for open source security

Open source is built on a foundation of transparency, collaboration, and speed. We share code, we share ideas, and together, we build better software. But when it comes to discovering and patching security vulnerabilities, that standard model of immediate, public sharing has to temporarily shift. A security embargo is a temporary agreement to keep a software vulnerability private so that vendors and maintainers can create and release a security patch before malicious actors learn how to exploit it.

Two critical remote code execution (RCE) flaws for PHP security vulnerabilities (CVE-2026-109618 and CVE-2026-109619), collectively dubbed “PHP2Shell” and carrying a critical CVSS v4.0 score of 9.2, were discovered. These vulnerabilities affected every version of PHP released over the last 14 years, spanning from PHP 5.4 up to 8.5. Details leaked on October 20, two days before the security embargo date for when the patches should land. On October 21, major platforms like Wikipedia, and numerous government portals in Finland, the UK, and the Netherlands briefly took pages offline to buy time for patching.

Open source maintainers agreed collectively to a revised embargo date and time of October 21, 2026 at 2PM UTC. Following the embargo leak the Ubuntu Security Team published security notices USN-8948-1 and USN-8948-2 once the embargo officially lifted.

The true purpose of an embargo

An embargo in the open-source security world isn’t about secrecy for secrecy’s sake. It is a temporary, mutually agreed-upon period where researchers, upstream maintainers, and downstream distributors (like Canonical) coordinate quietly before a vulnerability is made public.

Why does this matter? Because the moment a vulnerability is publicly detailed, the race begins. Bad actors start writing exploits, while users scramble to protect their deployments, sometimes when patches are not yet available . An embargo ensures that when the starting gun fires, the good guys have already crossed the finish line. It allows major distributions and cloud providers to have patches built, tested, and ready to distribute and deploy the exact second the vulnerability is announced.

At its core, the embargo process relies entirely on group community trust. Coordination provides protection to the entire ecosystem of users at the same time. Maintaining that alignment is what prevents fragmented, chaotic patching cycles that leave the least agile users exposed.

Coordinated Vulnerability Disclosure (CVD) represents the gold standard for multi-party security collaboration, enabling vendors, researchers, and maintainers to align on synchronized release schedules. In the open-source ecosystem, CVD is paramount due to the sheer diversity of downstream distributors, cloud providers, and enterprise OS vendors reliant on shared upstream components.

The Ubuntu Security Team adheres strongly to the principles of CVD. As key stakeholders in the Linux distribution ecosystem, we participate in many trusted security communication channels. For high-impact security flaws, upstream maintainers notify a designated subset of the Ubuntu Security Team in advance under strict embargo agreements. We collaborate directly with upstream developers to prepare and validate backported fixes across supported Ubuntu releases, ensuring every update is ready for synchronous release on a pre-agreed Coordinated Release Date (CRD). Synchronized disclosure prevents fragmented patch releases that could alert attackers before every ecosystem component is secure.

A retrospective on the recent PHP updates

The recent PHP security patches are a great example of this process in action. PHP powers a massive portion of the web, meaning any vulnerability carries widespread implications.

At Canonical, our priority was ensuring that Ubuntu users were protected immediately without experiencing regressions or downtime. Thanks to the coordinated disclosure process, we were able to deliver these updates exceptionally fast.

Here is what that process looked like behind the scenes:

1. Early notification: Through trusted community channels, our security team received early details of the vulnerabilities under embargo on October 16.
2. Rapid patching & backporting: Our engineers had security patches ready for all security maintained Ubuntu releases from Ubuntu 14.04 LTS to Ubuntu 26.10 by October 19. Because we support multiple versions of PHP across different releases, this required careful backporting to ensure older, stable systems remained secure without breaking compatibility.
3. Rigorous testing: While security patches have the potential to break production environments, we take great care to ensure ours do not. During the embargo window, the updated packages were run through our automated testing pipelines to verify stability.
4. Synchronized release: The moment the embargo lifted, the patched packages were published to the security pocket of the Ubuntu archive. For users with Unattended Upgrades enabled, the default configuration installs available fixes every 24 hours.

Navigating unexpected disclosures during security incidents is strenuous for both software maintainers and end users. When leaks occur, security teams must be agile under pressure, and move faster than originally planned without compromising on quality, verification, communication, and coordination with software maintainers.

Moving forward together

The open-source community is a complex web of vendors, independent contributors, and researchers. Occasionally, the friction of moving quickly can stress the coordinated disclosure process. But rather than pointing fingers when timelines get messy, our focus must remain on strengthening the ties that bind us.

Committing to the embargo process prevents attackers from gaining a head start on reverse-engineering patches, and exploiting systems before the rest of the world can patch.

At Canonical, we are incredibly proud of our security team’s rapid response to the PHP updates, but we are equally grateful for the upstream maintainers and community partners who make that speed possible. By respecting embargoes and fostering community trust, we don’t just secure Ubuntu – we secure the open-source ecosystem as a whole.