CVE-2026-39987: Marimo Notebooks abused for LLM-powered Post-Exploitation
Just saw the report on THN regarding threat actors leveraging LLM agents for post-exploitation following a Marimo compromise. It looks like CVE-2026-39987 is being actively exploited in the wild to hit internet-facing notebooks.
The attack chain is a significant evolution. Instead of dropping a standard webshell or C2 beacon immediately, the actor is deploying an LLM agent directly after achieving RCE. This agent autonomously analyzes the compromised environment to locate and extract cloud credentials. The report indicates they successfully pulled two sets of cloud credentials this way.
This creates a massive detection challenge. The agent's behavior can mimic administrative activity if it leverages valid cloud APIs to "read" data before exfiltration, bypassing traditional signature-based defenses.
For those running Marimo or similar notebook tools, you need to restrict access immediately. Ensure these instances are not exposed to the public internet without strict authentication.
Here is a quick Linux command to hunt for suspicious parent-child relationships involving Marimo processes spawning unauthorized shells:
ps -ef --forest | grep -A 5 '[m]arimo'
You might also want to scan your logs for specific API calls to the Marimo endpoints that resemble enumeration attempts:
grep "GET /api/" /var/log/nginx/marimo_access.log | awk '{print $1}' | sort | uniq -c | sort -nr | head
I'm particularly worried about the "AI Agent" component. If the attacker uses stolen credentials to query commercial LLM APIs, we might catch this via cost anomaly alerts, but if they run a local LLM on the compromised box (e.g., via Ollama), it's completely invisible to external billing.
Is anyone actively hunting for AI-based lateral movement tools in their environment? How are we distinguishing between a developer's legitimate AI helper and a malicious autonomous agent?
We've been tracking a similar spike in anomalous cloud API calls. The tricky part is that LLM agents often make "human-like" sequences of requests (ListBuckets -> GetObject -> HeadObject) which usually bypass heuristic anomaly detectors designed for botnets.
I recommend checking your CloudTrail logs for AssumeRole events originating from the notebook instance IDs immediately following the exploit window. You can use this AWS CLI filter to hunt for it:
aws cloudtrail lookup-events --lookup-attributes AttributeKey=ResourceName,AttributeValue= --start-time $(date -u -d '2 hours ago' +%Y-%m-%dT%H:%M:%S)
If you see IAM role assumption happening alongside the Marimo exploit attempts, you're likely dealing with this agent.
This aligns with what we saw in a recent red team exercise. We didn't use an LLM agent directly, but the ability to script complex post-exploitation logic via Python makes notebooks a gold mine.
The critical failure vector here is usually overly permissive IAM roles attached to the EC2 instance or container running the notebook. Developers love to attach AdministratorAccess to make things 'just work'.
If you are on AWS, block public access to Marimo ports (default is usually 2718) via Security Groups or NACLs immediately. Also, consider implementing IAM deny policies that prevent credentials from being read unless the source IP is internal.
{ "Version": "2012-10-17", "Statement": [{ "Effect": "Deny", "Action": "iam:ListAccessKeys", "Resource": "*", "Condition": { "NotIpAddress": { "aws:SourceIp": "10.0.0.0/8" } } }] }
Detection aside, the remediation here needs to be aggressive. If the agent is smart enough to extract creds, it's likely smart enough to establish persistence.
Check for new cron jobs or systemd timers created by the marimo user or the user running the notebook service.
crontab -u marimo -l
systemctl list-timers --all | grep marimo
We found a similar case where the persistence mechanism was hidden inside a Jupyter kernel spec, so don't assume standard locations are safe.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access