--- title: Why embargoes matter for open source security description: 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 agreemen […] url: https://canonical.com/blog/why-embargoes-matter-for-open-source-security --- 1. [Blog](https://canonical.com/blog) 2. Article --- [Rajan Patel](https://canonical.com/blog/author/rajanpatel927 "More about Rajan Patel") 30 October 2026 # Why embargoes matter for open source security [Security](https://canonical.com/blog/tag/security) --- Share the article 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](https://certcc.github.io/CERT-Guide-to-CVD/howto/coordination/) (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. [Get in touch Interested in running Ubuntu in your organization?](https://ubuntu.com/about/contact-us/form) ## Sign up for our newsletter Get the latest Canonical news and updates in your inbox. Work email: \*I agree to receive information about Canonical's products and services. In submitting this form, I confirm that I have read and agree to [Canonical's Privacy Notice](https://canonical.com/legal/data-privacy/contact) and [Privacy Policy](https://canonical.com/legal/data-privacy). Sign up ## Share on --- ## Related posts [### Securing open source software dependencies in the public cloud](https://canonical.com/blog/securing-open-source-software-dependencies-in-the-public-cloud) Building stable and secure software requires understanding build systems and having a plan for vulnerabilities in your software dependencies. [Aaron Whitehouse](https://canonical.com/blog/author/aaron-whitehouse) 5 October 2026 [### Accelerating delivery of CVE fixes with a new Kernel release strategy](https://canonical.com/blog/accelerating-delivery-of-cve-fixes-with-a-new-kernel-release-strategy) When it comes to fixing security vulnerabilities, speed is crucial. Canonical is officially outlining a transition from its current 4-week regular and 2-week security kernel... [Canonical](https://canonical.com/blog/author/canonical) 23 September 2026 [### Canonical joins the Open Secure AI Alliance](https://canonical.com/blog/open-secure-ai-alliance) Canonical is now part of the Open Secure AI Alliance, announced by NVIDIA with partners across cloud computing, cybersecurity, enterprise software, open source foundations, and... [Canonical](https://canonical.com/blog/author/canonical) 28 August 2026 [### Januscape vulnerability CVE-2026-53359 mitigations available](https://canonical.com/blog/januscape-linux-vulnerability-mitigations-available) Introduction A local privilege escalation (LPE) vulnerability affecting the Linux kernel was publicly disclosed on July 6, 2026. The vulnerability was assigned CVE ID... [seth-arnold](https://canonical.com/blog/author/seth-arnold) 11 July 2026