There is a tension worth naming in how software vulnerability disclosure works now. 

Detailed advisories are a public good for defenders. Security teams need to understand the scope of a flaw, the affected versions, and the path to remediation. Every maintainer who publishes a clear, thorough CVE advisory is doing the right thing for their users. 

The problem is the aggregate effect. In a world where a capable AI model can compile a functional exploit from an advisory in under a day, defenders and attackers receive the same starting gun, and attackers are finishing the race first. 

This is not a theoretical concern. The data is in. 

What Marimo Taught Us About the New Timeline 

On April 8, 2026, a vulnerability was disclosed for Marimo, a Python notebook framework with roughly 20,000 GitHub stars. The CVE number is CVE-2026-39987. According to Sysdig’s research, first exploitation occurred nine hours and 41-minutes after disclosure. Credential theft completed in under three minutes. There was no public proof-of-concept available. Someone read the advisory, built a working exploit from the text, and went to work. 

That is not a sophisticated nation-state operation. That is an attacker using what is publicly available today. 

The follow-on activity made it worse. In the days after initial exploitation, researchers observed an NKAbuse variant hosted on a typosquatted Hugging Face Space, lateral movement into Postgres and Redis via leaked environment variables, and 662 exploit events from 11 IP addresses across 10 countries. A project with a modest open source footprint was fully weaponized in under two weeks. 

Three weeks earlier, Langflow (CVE-2026-33017, disclosed March 17) was weaponized in roughly 20 hours under similar conditions. Marimo cut that timeline nearly in half. 

The trend line is not ambiguous. 

The Acceleration Has a Ceiling Nobody Has Hit Yet 

Here is the part that should get people’s attention: Everything described above happened with what is publicly accessible today. 

Mythos, Anthropic’s next-generation vulnerability analysis model, is currently behind Project Glasswing. Access is limited to a small set of industry partners and open-source developers. When Mythos-class capability becomes broadly accessible, or when another model crosses a comparable threshold and ships widely, the reasonable hypothesis is that the time-to-exploit curve continues compressing toward zero. 

AISLE’s follow-up research already showed that smaller open-weight models can recover much of a flagship model’s analysis when fed the right code chunks. The floor is dropping faster than the ceiling is rising, and the ceiling has not even been released yet. 

The n-day window, the gap between disclosure and weaponization that defenders historically used to respond, is not just shrinking. In some cases, it has effectively disappeared. 

The Real Bottleneck is Not What You Think 

When most teams think about vulnerability response, they think about patching speed. How fast can engineering deploy a fix? How quickly can we push the update? 

That framing assumes something important: that you already know you are exposed. 

The Marimo case makes the actual bottleneck visible. The gap between “advisory published” and “I know whether I’m running the affected version” is where response time is truly lost. Everything downstream, whether patching, compensating controls, or credential rotation, cannot start until someone has confirmed exposure. 

If that confirmation takes hours or days because component inventory is incomplete, maintained in spreadsheets, or dependent on manual ticket triage, then detection speed and patch speed are irrelevant. You are already behind. 

Software bill of materials (SBOM) data, kept current and queryable, is what makes that confirmation fast. Not after the fact. At the moment, the advisory drops. Manifest has written previously about why open source software (OSS) vulnerability management is structurally broken and what the end of OSS-as-usual means for security teams. The n-day collapse is the next chapter of that same story. 

Common Mistakes That Extend Your Exposure Window 

Security teams under pressure tend to make the same errors. Recognizing them is the first step to correcting them. 

• Treating inventory as a project, not a practice. SBOMs generated once at release go stale immediately. Components change across environments, branches, and deployments. Inventory needs to be continuous. 

• Waiting for a CVSS score to act. Scoring lags exploitation. In the Marimo case, exploitation was underway before most organizations had completed a severity triage. 

• Relying on scanner output alone. Scanners find what they are pointed at. If a component is not in scope or not in the scan schedule, the scanner does not help when the advisory drops. 

• Separating exposure confirmation from response workflow. If the person who can answer “are we running this?” is not part of the incident response loop, every hour of coordination is wasted time. 

• Assuming low-profile projects carry low risk. Marimo is not a household name. Attackers do not screen for brand recognition. They screen for exploitability and deployment density. 

One Thing You Can Do Today 

Pull your current component inventory for your three most externally facing services and check it against the last 30 days of CVE disclosures for the frameworks and libraries those services depend on. 

If that check takes more than 30 minutes, that is your gap. Not theoretically. Operationally. 

The Marimo window was nine hours and 41 minutes. Your inventory process needs to fit inside that window, with time left over to actually respond. 

The Collective Output Has Changed the Rules 

Individual maintainers are not doing anything wrong. Publishing detailed advisories is the right behavior for the software ecosystem. The problem is the collective output in an environment where advisory text compiles into working exploits faster than most organizations can confirm exposure. 

Defenders are operating as if the rules of 2019 still apply. They do not. The intelligence advantage that attackers have always had is being amplified by tooling that turns public disclosures into operational weapons in hours, not weeks. 

The answer is not less transparency from maintainers. The answer is faster confirmation from defenders. That requires knowing exactly what you are running, all the time, not when you think to check. 

Conclusion: Inventory is the Leverage Point 

The zero-day-to-n-day collapse is not a prediction. It is the current operating environment. CVE-2026-39987 is one data point. Langflow is another. The pattern is clear and the tooling accelerating it is only becoming more accessible. 

Response processes built around the assumption that defenders have days to assess exposure before exploitation begins are no longer fit for purpose. The question is not whether your team can patch fast. The question is whether your team can confirm exposure fast. 

That is an inventory and visibility problem, and it is solvable.