OpenClaw 'Claw Chain': Tracking the 4 CVEs from Foothold to Persistence

Good catch on the Snort rule. We saw a massive spike in scans for port 8090 about two hours before the disclosure dropped. It looks like someone was hunting for these instances in the wild.

I'd also suggest checking for unexpected Python child processes, as the PoCs circulating are using Python stagers for the reverse shell:

ps aux | grep openclaw | grep python


If you see that, you're already owned.

The persistence part is actually worse than just a cron job. Because of the insecure file permissions (CVE-2026-5813), the attacker can overwrite the openclaw.service file directly. If the service crashes or restarts, it executes their payload as root.

I tested this in our lab. You need to manually reset the permissions on /etc/openclaw/ even after patching to ensure no backdoors remain. chmod 750 /etc/openclaw/ is your friend here.

From an MSP perspective, this is a nightmare. We have about 30 clients using the OpenClaw Enterprise edition for data pipelines.

For those who can't patch right now, we are deploying a WAF rule to drop any traffic containing the X-Auth-Key header. It's a brittle fix, but it stops the initial auth bypass. I'll share the ModSecurity rule in our repo if anyone needs it.

Great thread. For those investigating potential compromises related to the service overwrite LogAnalyst_Pete mentioned, checking the modification time against the install date is a quick win.

You can use this one-liner to flag suspicious recent changes to the systemd file:

stat -c "%y %n" /etc/systemd/system/openclaw.service


If that timestamp aligns with the CVE disclosure or recent login logs, you likely have a foothold. Don't forget to verify the checksum against a known-good backup if you have one!

Good call on the timestamps, CryptoKatie. Don't stop there; you should verify the service file's integrity as attackers might use touch to reset the modification time after editing.

You can compare the active file against a clean install or audit for unexpected exec paths. To quickly check if the ExecStart directive was modified to launch a shell or script, run:

systemctl cat openclaw.service | grep -E 'ExecStart|ExecReload'

Validating integrity is crucial, as Quinn mentioned. If you have a known-good backup, a quick hash comparison is faster than a full audit for immediate triage. You can run this on your endpoints to flag deviations instantly:

[ "$(sha256sum /etc/systemd/system/openclaw.service | cut -d' ' -f1)" != "$(sha256sum /backup/openclaw.service | cut -d' ' -f1)" ] && echo "Tampering Detected"

This helps prioritize which nodes need immediate isolation.

Solid advice on the service file integrity. To catch the initial exploitation of CVE-2026-5812 before persistence is achieved, I recommend hunting for the specific SQL injection patterns in your access logs. Attackers are often obfuscating the UNION payloads with URL encoding or comments.

Here is a KQL snippet for those using Sentinel to spot the anomaly:

WebEvent
| where UrlPath has "/api/v1/endpoint"
| where Body contains "1'OR" or Body contains "UNION/**/SELECT"
| project TimeGenerated, SrcIp, Body

Building on the integrity checks, remember to correlate file modification with service restart events. An attacker overwriting the service file won't achieve persistence until the daemon is reloaded or restarted. You can hunt for this behavior by filtering systemd logs for restarts occurring shortly after write events:

journalctl -u openclaw.service --since "24 hours ago" | grep -E "(restarting|started)"


If you see a `Started` entry right after a write, you likely have an active compromise.