The timeline for security response has inverted. When a maintainer publishes a fix for a vulnerability in open-source software, artificial intelligence can reverse-engineer a functional exploit from the code diff within hours. By the time your security scanner detects the CVE the following morning and a ticket enters the queue for next week's change window, attackers have already been circulating the exploit for days.
This scenario reflects the reality described in Michael Cembalest's "Patchmageddon" report from July 2026, which draws on input from J.P. Morgan Asset Management's cybersecurity leadership. Models including Anthropic's Mythos and OpenAI's GPT–5.5 now discover previously unknown vulnerabilities at volumes that human research teams cannot match. Anthropic and its Project Glasswing partners identified more than 10,000 new high- and critical-severity zero-days in their first month of work.
The window for exploitation has compressed dramatically. In 2021, the median time between disclosure and first exploitation was roughly one year. By 2026, that figure dropped to a single day, with projections suggesting it will shrink to one minute by 2027. Nearly 80% of exploitations now occur on or before public disclosure. The velocity of both vulnerability discovery and weaponization has fundamentally altered the calculus of security operations.
Open source bears the initial burden
The pressure from AI-accelerated vulnerability discovery and exploitation falls first on open-source projects. Open-source code represents the foundation of modern software development, and its accessibility makes it an obvious target for attackers seeking to maximize impact. The people responsible for maintaining these projects are predominantly volunteers operating without institutional support.
The scale of the problem has already become apparent. Of 530 high- and critical-severity vulnerabilities that Anthropic reported to open-source maintainers by May 2026, only 75 had received patches. The stress has driven visible consequences: throughout the summer of 2026, open-source maintainers began shutting down bug bounty programs and stepping back from active development to manage burnout.
Rethinking enterprise security strategy
Organizations face a convergence of pressures that demands immediate strategic revision:
- Advanced AI capabilities are proliferating. Cembalest projects that capabilities currently restricted to nation-state actors will become reproducible in freely available open-weight models within 12 to 24 months. Hamish Low at the Institute for AI Policy and Strategy estimates a 40% probability that a Chinese Mythos-class model will emerge by February 2027, with near-certainty by year-end.
- Your infrastructure already runs vulnerable code. Most software deployed in production was pulled from public registries months or years ago. Datadog's February 2026 data showed the median dependency running 278 days behind its latest major version—old code waiting for a one-day exploit window to be weaponized.
- The measurement standard has shifted. Organizations will now be evaluated on patching speed, not merely patching accuracy. Security programs built around 90-day disclosure windows must now operate against a clock measured in hours.
For platform owners, application security leaders, and technology risk officers in regulated industries, this challenge is unavoidable. Responding with urgency but without a coherent plan creates organizational chaos. The solution requires structured thinking and deliberate action.
Stop treating open source as free infrastructure
The volunteer maintainer model cannot scale to meet the patching demands of the AI-accelerated vulnerability era. Cembalest's analysis of maintainer concentration reveals the fragility of open-source infrastructure: in a Linux Foundation and Harvard study of the top 50 open-source projects, 23% had a single developer responsible for more than 80% of new code, and 94% had fewer than ten developers writing more than 90% of the codebase. At the package registry level, Anchore identified more than 18 million npm packages with a single listed maintainer.
Open-source communities are doing their best under difficult circumstances, and many contributors have burned out in the process. The original promise of open source was never that it would deliver day-zero patches or perfect security. The promise was simply free software. Yet enterprises have built critical infrastructure on this foundation while treating maintainers as if they bore responsibility for security guarantees they never made.
Enterprises have enjoyed decades of free beer – open source software – while being told it was sort of irresponsible of them.
This dynamic must change. Professional open source—software backed by vendors with financial incentive or foundations with dedicated security teams, funded maintainers, and formal release processes—offers a path forward. The teams creating and maintaining the code operate under service-level agreements and own responsibility for delivering fixes.
If you can't name who maintains a package, you can't count on anyone to fix it.
J.P. Morgan's technology leadership, as documented in Cembalest's report, has adopted an explicit standard: deploy current versions and eliminate dependencies where the maintainer cannot be identified, appears to be a single person, or the package shows signs of abandonment. Accountability requires knowing who stands behind the code.
Patching as business continuity
The traditional justification for deferring patches—that applying fixes might disrupt business operations—has lost its validity. Erik Scales, who leads platform engineering for Tanzu Platform at Charles Schwab, articulated this shift during a VMware Explore presentation: "If you've ever tried to patch a server, no one wants to patch anything. No one wants to do anything. Now, everybody's worried about being on the news and being fired."
When exploits took months to weaponize, the trade-off between patch risk and operational continuity was defensible. When exploits arrive within a day of disclosure, the calculation reverses: the unpatched system becomes the greater threat to business continuity.
Now that they show up within a day of disclosure, the unpatched system is the bigger threat to keeping the business running.
Research cited in the J.P. Morgan note found that over 80% of security professionals have deferred patches to avoid business disruption. Yet any fix that introduces additional disruption will face deferral, and deferral is precisely what a one-day exploitation window punishes. Attackers are betting on delay.
Making the secure path the default path
Enterprise developers no longer have the freedom to download arbitrary software from the internet. Most large organizations now route all dependency downloads through internal artifact proxies such as JFrog Artifactory or Sonatype Nexus. Developers configure their builds to fetch from the proxy, which in turn retrieves packages from Maven Central, npm, PyPI, or other registries. Changing this established workflow would require retraining developers—a difficult and undesirable task.
The solution does not require changing developer behavior. Instead, change where the proxy fetches its packages. Point it at a supported source like TrueSource, and the build files, URLs, and pipelines remain unchanged. Developers experience no difference in their workflow. What changes is that the Spring libraries and other dependencies now flowing through the proxy include fixes that often ship before the CVE becomes public.
The proxy itself can perform some patching automatically. Configure it to block known-vulnerable versions and serve the nearest patched alternative instead. Builds continue working without manual intervention or ticket filing. The patched package becomes the default—the version developers receive without requesting it.
This approach is essential for addressing the Patchmageddon scenario. Changing entrenched developer habits is difficult and slow. By routing dependencies through a proxy, organizations can shift to secure sources without requiring developers to alter their workflows. This is why the only acceptable change is no change.
Organizations already running dependencies through proxies have a particular advantage. For them, the conversation is not about implementing a new supply chain platform across the enterprise. It is simply about redirecting the proxy to a new source—a straightforward configuration change.
The remaining elements
Beyond controlling dependency sources, three additional measures deserve attention:
- Measure the speed at which fixes reach production. Track the time from vulnerability disclosure to deployed patch for your top 50 dependencies. This metric, according to the J.P. Morgan analysis, will become the standard by which organizations are evaluated.
- Identify who maintains your critical dependencies. For each one, document the organization or individual behind it. Packages with single maintainers or signs of abandonment warrant separate consideration.
- Leverage AI to identify and propose fixes while keeping humans in the merge process. Ideally, the code's original maintainers perform the final review and integration.
Security has entered a fundamentally different era. Organizations must recognize this shift and adapt their security strategies accordingly. This imperative applies especially to large enterprises and financial institutions that develop and operate substantial portions of their own software. The framework outlined here represents one approach to the challenge. Regardless of which specific plan an organization adopts, inaction is not an option. The time to act is now.