What Happened
On a Friday in early 2025, CoreWeave disclosed CVE-2026-39987, a critical remote code execution vulnerability in Marimo, their Python notebook platform. This flaw allowed attackers to execute arbitrary code without authentication on any exposed Marimo instance running versions before 0.23.0.
Within 10 hours of public disclosure, attackers exploited the vulnerability. Sysdig's honeypot infrastructure captured the attack chain: the attacker gained initial access, executed reconnaissance commands, and extracted AWS access keys and credentials—all within three minutes of compromise.
This was not theoretical. The vulnerability was exploited in the wild, showing how quickly adversaries move from disclosure to active exploitation when authentication controls are absent.
Timeline
T+0 hours: CVE-2026-39987 disclosed publicly. Marimo version 0.23.0 released with patch.
T+10 hours: First exploitation attempts detected against Sysdig honeypot infrastructure.
T+10 hours, 3 minutes: Attacker successfully extracted AWS credentials and other sensitive data from the compromised system.
Unknown: Number of production systems compromised before organizations could patch.
The speed here matters. Ten hours spans a single work shift. If your security team learned about this vulnerability at 9 AM, attackers were already inside systems by 7 PM—potentially before your change control board even met to approve the emergency patch.
Which Controls Failed or Were Missing
Missing authentication enforcement: The Marimo platform allowed code execution without verifying the user's identity. Any network-accessible instance was vulnerable to anonymous attackers.
Insufficient network segmentation: Vulnerable instances were exposed to the internet rather than isolated behind VPNs or jump hosts. The honeypot data shows attackers scanning for and finding these exposed services.
Inadequate secrets management: The compromised system stored AWS access keys in a location accessible to the application runtime. Once the attacker gained code execution, credential extraction took under three minutes.
Delayed patching process: The 10-hour exploitation window suggests many organizations lacked emergency patch procedures for critical vulnerabilities in development tools.
No runtime monitoring: Organizations running Marimo without runtime security monitoring wouldn't have detected the reconnaissance commands or credential exfiltration happening on their systems.
What the Relevant Standard Requires
PCI DSS v4.0.1 Requirement 6.3.2 mandates that security vulnerabilities are identified and addressed based on a formal risk assessment. Critical vulnerabilities require remediation within timeframes defined by your risk assessment—typically hours, not days, for remotely exploitable RCE flaws.
OWASP ASVS v4.0.3 Section 4.1 requires authentication for all pages and resources except those specifically intended to be public. Allowing code execution without authentication violates this fundamental control.
ISO/IEC 27001:2022 Control 8.8 (Management of technical vulnerabilities) requires you to obtain timely information about technical vulnerabilities, evaluate exposure, and take appropriate measures. A 10-hour response window tests whether your processes can actually execute at the speed threats move.
NIST 800-53 Rev 5 SI-2 (Flaw Remediation) requires you to install security-relevant software updates within organization-defined timeframes. For critical vulnerabilities with public exploits, your timeframe needs to be measured in hours.
SOC 2 Type II CC7.1 requires you to identify, report, and act upon security incidents. An unauthenticated RCE in a development tool qualifies as an incident requiring immediate response.
The authentication failure also violates OWASP Top 10 2021 A07:2021 - Identification and Authentication Failures, which specifically calls out missing or ineffective authentication as a critical risk.
Lessons and Action Items for Your Team
Build a critical vulnerability response playbook. Define what "critical" means (CVSS 9.0+, remote code execution, no authentication required), who has authority to approve emergency patches, and how quickly you can deploy them. Test this quarterly with tabletop exercises.
Implement authentication for all development tools. Your notebook platforms, CI/CD systems, and internal tools need authentication even if they're "only used by engineers." Add SSO integration and enforce MFA for any tool that can execute code or access production credentials.
Segment development infrastructure. Don't expose Jupyter, Marimo, or similar platforms directly to the internet. Put them behind VPNs, require bastion hosts, or use zero-trust network access. If attackers can't reach the service, they can't exploit it.
Remove credentials from application runtimes. Use IAM roles, workload identity, or secret management services instead of storing AWS keys in files or environment variables. When the attacker in this incident gained code execution, they shouldn't have found anything to steal.
Deploy runtime security monitoring. Tools that detect unusual process execution, network connections, or file access would have flagged the reconnaissance commands and credential exfiltration within seconds. Your development environments need the same monitoring as production.
Subscribe to security advisories for your entire stack. This includes development tools, not just production dependencies. You need to know about Marimo vulnerabilities the same day CoreWeave discloses them, not when your vendor sends a quarterly newsletter.
Measure your patch deployment speed. Track how long it takes from vulnerability disclosure to patch deployment in production. If your fastest emergency patch took longer than 10 hours, you're slower than the attackers in this incident.
The Marimo exploitation shows that development tools are production assets. When a notebook platform can access your cloud credentials and execute arbitrary code, it's not a developer convenience—it's part of your attack surface. Treat it accordingly.
CVE Details AWS IAM Roles
