AI fights and more attacks on dev infrastructure: Last Week in AppSec for 4. March 2026

Now the AIs are fighting

Two themes stood out this week: automation attacking automation (AI-driven bots and agent frameworks turning CI/CD into an always-on exploit surface), and trusted developer plumbing being repurposed (package registries, plugins, and “helpful” tooling paths becoming execution paths).

For giggles, I let an AI generate the summary this week (the following bullets are AI-generated with human tweaks) — but don’t worry, the details below this list are all human-written:

• AI bot “hackerbot-claw” actively exploited GitHub Actions misconfigs to get RCE in multiple repos and exfiltrate a write-scoped GITHUB_TOKEN. stepsecurity.io

• OpenClaw “ClawJacked” chain let a malicious website take over a local AI agent by abusing localhost exposure (WebSocket + brute force), collapsing “browser tab” → “agent control.” oasis.security

• ModelScope MS-Agent bug (CVE-2026-2256) enabled OS command execution via the Shell tool due to improper input sanitization—exactly the kind of footgun that turns “agent tooling” into a direct host compromise path. SecurityWeek

• StegaBin: 26 malicious npm packages tied to the “Contagious Interview” ecosystem used multi-stage install-time execution with Pastebin/Vercel tradecraft to deploy credential theft + RAT payloads. The Hacker News

• SiteOrigin Page Builder (WordPress) Local File Inclusion (CVE-2026-2448) gave authenticated (Contributor+) attackers a route to include/execute server-side files—high blast radius given the plugin’s install base. NVD

Get notified of new research and analysis, without the marketing

Subscribe to Checkmarx Zero

Never Miss Checkmarx
Zero Research Updates. Subscribe today!

By submitting my information to Checkmarx, I hereby consent to the terms and conditions found in the Checkmarx Privacy Policy and to the processing of my personal data as described therein. By clicking submit above, you consent to allow Checkmarx to store and process the personal information submitted above to provide you the content requested.

Feature: hackerbot-claw showed why CI/CD needs “default-deny” guardrails

The tail end of February brought us an active attack campaign from an AI bot called hackerbot-claw, and claiming to be a “friendly” security bot powered by the Clade-Opus-4.5 model; I’m sure Anthropic is thrilled for the association (that’s sarcasm, folks).

The “friendly” nature of it is disputed, since it scanned GitHub Actions workflows that are subject to various weaknesses like the well-known challenges with Actions that use pull_request_target. And it didn’t just flag them, it opened PRs designed to exploit them, successfully executing arbitrary code in CI/CD pipelines and exfiltrating privileged GitHub tokens (by reading GITHUB_TOKEN, mainly).

According to Step Security, several high-profile organizations disclosed impact. And there seem to be weak indications of many more attempts — I suspect many more orgs were impacted than just those who responsibly disclosed the attacks and breaches.

Important things to learn from this campaign

• CI is increasingly a continuous attack surface, and AI is accelerating that. Nothing about this attack requires AI: traditional automation would work just fine. But available evidence suggests that architecting it around AI has several significant benefits for the attacker, including rapid adaptability, shorter scaling paths, and greater difficulty establishing IoC’s (Indicators of Compromise) for defenders.

• Token exfil sucks. CI/CD tokens (like GITHUB_TOKEN), even when managed using a secrets vault, are by necessity exposed during key parts of CI/CD runs. When those tokens have higher privileges (such as repo-write or release privileges), a compromise of a sandboxed CI runner is suddenly an elevation of privilege. Even without exfiltration, attacker-controlled code in CI has elevated access. But with exfiltration, attackers can launch further, more-targeted attacks until you notice and revoke the credential.

• CI isn’t the only risk. GitHub tokens are bad enough to exfiltrate, but we should take note that some of the compromised Actions also had access to deployment keys and other third-party service credentials. This is a good reminder of the importance of ensuring that attackers can’t influence your CI: something especially relevant to organizations that maintain open-source projects that accept public contributions.

What do you have to do?

1. Eliminate the whole “pwn request” vulnerability class. Just don’t use pull_request_target for untrusted contributions. Or, if there’s really important value to it, at least fully define and document the trust boundary, so you can keep the scope narrow so that Actions implementing it also don’t have elevated privileges.

2. Review your token scopes. Use least-privilege GITHUB_TOKEN permissions; avoid broadly-scoped PAT (Personal Access Token) use and grant tokens only the minimum permissions. Make sure “write” and “release” tokens are narrowly-scoped and not triggered by untrusted users or workflows (which is, I understand, kind of restating the last point a bit).

3. Lock your runners down tight. Make sure container images you use for CI are locked down. Put endpoint controls on them. Control egress. Sandbox as much as possible in ways that code inside can’t have access to.

4. Put CI configs into your security review process. Build up security champions within DevOps, and build processes to regularly review and test CI configurations with an explicit, security-focused scope. It’s honestly some of your most important “code” (yeah, it’s low-code or no-code, but you know what I mean).

5. Invest in reproducible builds. Not that this is easy, mind you. But investing in reproducibility so you can audit what happened during a build and recreate it if needed helps with reducing response costs and with the testing I recommended above. The best time to start working towards SLSA Level 2 builds was a year ago; the second best time is now.

OpenClaw “ClawJacked” turned a browser visit into agent takeover

I generally avoid saying “don’t use this”, but OpenClaw is tempting me. Among the many serious flaws that have been reported in OpenClaw components, SecurityWeek reports an issue where attacker access to a gateway/agent service can turn into arbitrary RCE.

If you use OpenClaw, update to fixed versions (v2026.2.25+ is explicitly called out), and treat agent/gateway services like privileged admin interfaces: bind ports tightly, require strong authentication and authorization, and add rate-limiting/lockouts. And honestly, please please run it in a very hardened, carefully-scoped container. I trust Docker (or whatever) to sandbox resources a heck of a lot more than I trust OpenClaw.

ModelScope MS-Agent Shell tool command execution

Whoops. Some users of the MS-Agent AI framework found themselves on the short end of a prompt-injection-to-arbitrary-command-exec pipeline last week. And it comes with a ready-made, public proof of concept too.

US-CERT has a great technical write-up. The short of it is the check_safe() routine that’s supposed to, as the name implies, check to see if something is safe to pass to the framework’s embedded shell execution hook is actually safe, didn’t really do a great job.

Update to v1.6.0rc1 or later, but also make sure you are deploying agents in trusted contexts with appropriate sandboxing and related controls. I’m sounding like a broken record, but we really need to make this the default advice.

StegaBin: malicious npm packages with install-time execution + staged payload delivery

Checkmarx Zero warned in February that there was a resurgence of the malicious npm package campaign that was previously dubbed “Contagious Interview.” And it seems like at almost exactly the same time, kmsec.uk was digging deep into the campaign’s techniques.

This hit the news last week, despite being largely already contained, as it entered the realm of Security Journalism via [The Hacker News](The Hacker News and some clever naming campaign work.

Nevertheless, it’s worth it for defenders to continue to be vigilant and take actions to protect yourself from malicious packages, including campaigns like this.

WordPress Page Builder by SiteOrigin Local File Inclusion

This WordPress plugin vulnerability in SiteOrigin versions through (and including) 2.33.5 may seem run-of-the-mill at a time of targeted malicious packages and AI-driven attacker campaigns; but it’s a solid reminder that the importance of basic supply-chain security in your AppSec program hasn’t disappeared.

Fortunately, this vulnerability is only exploitable by an attacker who has at least Contributor access. But since there is a path to code execution, it’s still worth prioritizing the patch.

The core issue is that locate_template(), which is presumed to only load approved template files, had an issue where it can be tricked into loading nearly any file on the server; and if a PHP file, executing it.

Upgrade the plugin if you have it, and review logs on impacted servers to identify any indicators of attack attempts.