Rapid exploitation of CVE-2026-39987 in Marimo and mass campaign of Reis to mine XMRig

Two recent investigations - one from Sysdig and one from Hunt.io - stress that the separation between discovering a vulnerability and exploiting it has been drastically reduced: not only artificial intelligence-based tools speed up attacks, but highly duchy human operators can move at the same rate and with great stealth. Sysdig documents an intrusion where, after exploiting a vulnerability in Marimo (reported as CVE-2026-39987), an attacker achieved from a WebSocket connection a chain of pivots that allowed him to recover a private AWS Secrets Manager key and authenticate himself by SSH to a bastion within seconds. In parallel, Hunt.io describes a massive cryptominery campaign that has compromised thousands of Redis instances through malicious replication and other persistence techniques.

Facts confirmed: Sysdig reported active exploitation of CVE-2026-39987 in Marimo, with an actor who got an interactive shell and, using credentials obtained from the engaged machine, called AWS Secrets Manager to recover a private key and connect SSH to a bastion. According to the record Sysdig published, the operator took only eight seconds to pivote from the initial breach to the SSH authentication in the bastion. Hunt.io confirmed the verification of 3,562 Reis servers exposed on the Internet, using mainly replication (SLAVEOF / REPLICAOF command) to inject payloads that deploy XMRig.

Estimated or still uncertain information: There is no public and reliable attribution on which group is behind the intrusions; nor is it completely clear the final scope of the possible exfiltrations made after access to the bastion or whether there was post-access to additional AWS accounts. Sysdig stated that the operator did not use IA agents and that the tools were written "by hand" during the session; that statement is based on telemetry and analysis of tactics, techniques and procedures, but the possibility that the attacker has used automated tools outside the observed session cannot be ruled out.

Technically, the attack chain described by Sysdig follows this pattern: preauthenticated exploitation of the WebSocket terminal functionality exposed by Marimo for remote execution; search and extraction of local credentials (configuration files or environment variables) that allowed you to call AWS Secrets Manager and recover a private key; writing that key on disk and authentication by SSH to the bastion. The key vector here is that an application with an interactive endpoint WebSocket exposed an area that, once violated, gave access to credentials in the host itself. In the case of Reis, the technique that worked on a scale was to use SLAVEOF to induce the target server to replicate data controlled by the attacker; that content can end up in the AOF file and, with sufficient conditions, inject SSH keys or other persistent artifacts. For details on the Reis replication command, see the official documentation at redis.io.

Those affected: organizations that run Marimo without patches or with configurations that expose the endpoint of WebSocket terminal on the Internet; AWS accounts and systems that store secrets accessible from damaged instances; Reds servers exposed at port 6379 without authentication or with weak ACLs; outdated WordPress sites that can be identified by automated sweep. The variety of victims - from old servers to recent kernel, according to Hunt.io - shows that the vector does not depend so much on specific versions as on unsafe configurations or unnecessarily exposed services.

The practical consequences are tangible: attested access to SSH bastions (critical infrastructure control block), private key theft from Secrets Manager (risk of lateral movement and climbing), deployment of XMRig miners who consume resources and raise operational costs, and potential deployment of persistent back doors. At the organizational level, these intrusions can result in service interruptions, costs of cloud abuse and risk of using compromised access for more harmful actions (exfiltration, data destruction, ransomware).

What the reader should do (concrete and prioritized measures):

1) Park and reduce the surface. Update Marimo and any other software with interactive endpoints; apply patches as soon as they are available and block external access to endpoints of administration. If you cannot park immediately, restrict access through access control lists and firewalls.

2) Segment and tighten access to bastions. Limit the PIs that can access the bastion, force multifactor authentication, and consider using managed session mechanisms (e.g. AWS Systems Manager Session Manager) rather than opening SSH directly to the public. Review and rotate potentially compromised private keys.

3) Minimize privileges in Secrets Manager and rotate secrets. Apply IAM policies with the principle of less privilege: an instance should not be able to read secrets it does not need. Enable CloudTrail and alerts about unusual GetSecretValue calls in AWS; audit secret access and root if there are signs of exposure. The AWS Guide to Secrets Manager is available at docs.aws.amazon.com.

4) Protect Reis and exposed database services. Do not expose Reis to the public Internet; enable authentication, use ACLs and bind to the localhost or a private network. Block port 6379 in public perimeters and monitor incoming replication connections. For AOF-based attacks, have integrity policies and do not allow external processes to overwrite critical files.

5) Detection and response: instrumentally detection for specific observed patterns: unexpected WebSocket connections to terminal endpoints, calls to Secrets Manager from instances that should not need them, creation of private key files on ephemeral disks, interactive command peaks and processes that install miners such as XMRig (information on XMRig in xmrig.com). Establish quick response alerts and playbooks that include machine isolation, tilt capture and credentials rotation.

6) Review and harden WordPress deployments. Disable XML-RPC if not used, keep plugins and kernel up to date, and limit exposed information that can provide automated scanning.

In conclusion, the cases described above show two lessons: first, the speed of operation can come from both automation and human expertise; second, the most exploited vulnerability is not always a timely technical failure but the combination of vulnerable software and configurations that expose credentials and key services. Preventing means reducing exposure, applying the principle of less privilege and establishing specific early detection for pivot chains involving access to secrets and bastions. For reading and following up on the original reports, you can review the resources on the research pages of Sysdig and Hunt.io: sysdig.com / blog and hunt.io / blog.