Marimo CVE-2026-39987
Everyone's talking about how AI is speeding up attacks. And it is. But here's the thing. Skilled humans can still move just as fast. Sometimes faster.
Sysdig just published research on an attacker who pivoted from a vulnerable Marimo notebook to an SSH bastion host in eight seconds. No AI agent. No automation framework. Just a custom Python toolkit the operator wrote and debugged by hand.
"Eight seconds is the kind of speed we expect to see in AI-assisted attacks," the Sysdig Threat Research Team said. "This operator got there on skill alone."
And it gets better. Along the way, the attacker walked past a trap that every AI-powered threat actor Sysdig profiled against the same CVE fell into.
Let me break this down.
Quick Summary
|
What |
Details |
|
Vulnerability |
CVE-2026-39987 (Marimo pre-auth RCE) |
|
CVSS |
9.3 |
|
Attacker |
Human operator, no AI |
|
Speed |
8 seconds from WebSocket to SSH |
|
Session |
9 hours, 850+ commands |
|
Tooling |
Hand-rolled Python, no public offensive tools |
The Marimo Bug
CVE-2026-39987 is a pre-authenticated remote code execution flaw in Marimo. It affects all versions. It was exploited within hours of public disclosure.
The attack vector is the /terminal/ws WebSocket endpoint. An attacker connects, gets a shell, and starts moving.
The Eight-Second Pivot
Here's the timeline Sysdig captured.
|
Time |
Event |
|
18:57:22 |
Fresh WebSocket connection |
|
18:57:26 |
AWS Secrets Manager lookup returns harvested key |
|
18:57:30 |
SSH authentication at the bastion host |
That's eight seconds from initial connection to authenticating on a separate system.
The attacker didn't use a scanner. They didn't use a framework. They used a Python script that pulled credentials from the compromised instance, called AWS Secrets Manager, fetched an SSH private key, wrote it to disk, and authenticated to the bastion. All in one shot.
The full session started at 12:52 p.m. when the first WebSocket connection came in from 172.236.12[.]17. It ended at 9:50 p.m. when the attacker set up an asyncssh listener against their own VPS.
Over those nine hours, the operator issued more than 850 interactive commands. No recognizable offensive tooling. Everything was hand-rolled in the session.
Why This Matters
Sysdig's point is important. AI is changing the economics of attacks. It lowers the barrier. It speeds up repetitive tasks. It lets less skilled people do more.
But it hasn't replaced the skilled attacker who can build from scratch and avoid traps.
The operator in this case walked past a trap that every AI-powered threat actor fell into. That's not a knock on AI. It's just a reminder. Human expertise still matters. Especially when it comes to evading detection.
"AI may be changing the economics of attacks - more targets, faster time-to-exploit, and less manual grind on repetitive tasks - but it has not yet replaced the skilled attacker who knows how to build from scratch and avoid traps."
Meanwhile: 3,562 Redis Servers Hit
Hunt.io also published research on a cryptomining campaign. This one compromised 3,562 Redis servers.
The attackers swept the internet for Redis hosts on port 6379. They found exposed instances. They exploited them.
The toolkit had three pipelines:
|
Pipeline |
What It Does |
|
WordPress discovery |
Scans hosts for WordPress version, plugins, XML-RPC, directory listings |
|
AOF-based SSH injection |
Uses Redis append-only file mode to inject SSH authorized_keys |
|
Lua sandbox probing |
Runs EVAL commands and sandbox escape attempts |
What actually worked?
Only the Redis rogue replication. The SSH key injection and MongoDB sandbox escape returned zero across 2,810 attempts. A WordPress credential-to-webshell chain was recovered but not confirmed at scale.
The main technique was using the SLAVEOF command. That lets an attacker make a Redis server replicate from a malicious master. The attacker smuggles content onto the target. In this case, it resulted in an XMRig miner.
The victims:
Confirmed victims span Redis 2.8.17 from 2015 through Redis 7.2.0 from 2023. Linux systems from end-of-life RHEL/CentOS 6 to current Ubuntu kernels.
Hunt.io's conclusion: the weakness is missing authentication, not a version-specific bug. If you expose Redis to the internet without a password, you're a target.
The campaign was discovered after an exposed working environment at 188.245.99[.]156. No attribution yet.
The CameraSwarm Connection
Hunt.io also noted a single operator linked to a campaign called Operation CameraSwarm. That one compromised over 14,000 Dahua IP cameras.
The techniques: brute-force, authentication bypass flaws (CVE-2021-33044 and CVE-2021-33045), and a peer-to-peer relay technique.
What You Should Do
For Marimo:
- Patch immediately. CVE-2026-39987 affects all versions.
- Check for WebSocket connections. Look for connections to /terminal/ws from unexpected IPs.
- Review AWS credentials. If you're on AWS, check Secrets Manager for unauthorized access.
- Audit SSH keys. Look for unauthorized keys on bastion hosts.
- Monitor for unusual outbound traffic. Especially to VPS providers.
For Redis:
- Set a password. This is the big one. Most of these compromises are just exposed instances with no auth.
- Don't expose Redis to the internet. Put it behind a firewall. Use a VPN. Restrict access.
- Check for rogue replication. Look for unexpected SLAVEOF commands.
- Review authorized_keys. Look for SSH keys you didn't add.
- Check for XMRig. Watch out for high CPU usage and unexpected connection to mining pools.
For Dahua Cameras:
- Firmware update. CVE-2021-33044 and CVE-2021-33045 are old but still exploited.
- Change default credentials. Brute-force only works if passwords are weak.
- Disable P2P if you don't need it.
- Segment your cameras. Don't let them talk to the internet directly.
The Bottom Line
A human attacker exploited Marimo CVE-2026-39987 and pivoted to an SSH bastion in eight seconds. No AI. Just skill. Meanwhile, 3,562 Redis servers got hit by a cryptomining campaign that exploited missing authentication. Both stories point to the same lesson. The basics matter. Patch. Authenticate. Segment. Monitor.
Quick Reference:
|
Story |
Key Point |
|
Marimo |
Human attacker, 8-second pivot, no AI |
|
Redis |
3,562 servers, SLAVEOF + XMRig |
|
Dahua |
14,000+ cameras, brute-force + CVEs |
What to Do:
- Patch Marimo
- Set Redis passwords
- Update Dahua firmware
- Monitor for rogue replication
- Watch for XMRig activity
FAQ Section
What is CVE-2026-39987?
A pre-authenticated remote code execution bug in Marimo. It affects all versions and was exploited within hours of disclosure.
How did the attacker pivot so fast?
They used a hand-written Python script. It pulled credentials from the compromised instance, called AWS Secrets Manager, fetched an SSH key, and authenticated to a bastion host in one shot. Eight seconds.
Did the attacker use AI?
No. Sysdig says the operator wrote and debugged the toolkit by hand. No AI agent in the loop.
What is the Redis cryptomining campaign?
A campaign that compromised 3,562 Redis servers using the SLAVEOF command to smuggle content and deploy an XMRig miner. The weakness was missing authentication.
What should I do?
Patch Marimo. Set Redis passwords. Update Dahua firmware. Monitor for rogue replication and XMRig activity.