In March 2026, a GitHub account called hackerbot-claw, describing itself as an “autonomous security research agent powered by claude-opus-4-5,” began systematically targeting open source repositories—including one from Datadog. Over a week, it opened many pull requests designed to exploit misconfigurations in GitHub Actions workflows.

The attacks demonstrated something the security community had long anticipated: AI agents autonomously hunting for and exploiting CI/CD vulnerabilities at scale. CI/CD misconfigurations have long been exploited in the wild, from Trivy to Ultralytics. But the hackerbot-claw campaign showed that AI agents are now capable of finding and exploiting these same flaws.

The good news: GitHub Actions misconfigurations can be caught in the diff, before a PR ever merges. Datadog IaC Security scans workflows, surfaces findings as inline comments, and can block merge until issues are resolved.

In this post, we’ll cover:

• How GitHub Actions workflows become an attack surface

• The benefits of scanning workflows before they’re merged

• What security looks like with Datadog IaC Security

• How IaC Security coverage expanded after hackerbot-claw

• Best practices for securing your GitHub Actions workflows

How GitHub Actions workflows become an attack surface

GitHub Actions workflows can reference dynamic inputs like PR titles, commit messages, and branch names using the ${{ }} expression syntax. When those expressions are interpolated directly into shell commands in a run block, they become vectors for expression injection. Hackerbot-claw exploited this against datadog-iac-scanner, encoding malicious payloads in base64 within PR titles, commit messages, and file names to bypass naive string matching.

The campaign also exploited:

• Unsafe pull_request_target configurations. This trigger runs in the base repository’s context, giving it access to secrets. Combined with checkout from an untrusted fork, it creates a direct path to secret exfiltration.

• Unspecified workflow permissions. Workflows without explicit permissions inherit broad defaults, giving attackers the ability to write to repos, create releases, and interact with the package registry.

• Unpinned actions. Tags like @v3 can be silently updated by a compromised maintainer.

• Overprivileged tokens. In the broader campaign, a stolen personal access token (PAT) from Trivy had enough permissions to rename and privatize the repo, wipe releases, and push malicious artifacts.

None of these vulnerabilities were exotic zero-days. The campaign just took advantage of simple misconfigurations present in thousands of public repos today.

The benefits of scanning workflows before they’re merged

The traditional CI/CD security model is reactive: Monitor for anomalous behavior, alert, and investigate after the fact. That model has real value, but it has a fatal flaw. By the time you detect the attack, the vulnerable workflow has already been deployed.

Static analysis shifts detection earlier. An unescaped ${{ github.event.pull_request.title }} in a run block is identifiable before the PR ever merges. Misconfigurations are caught in the diff, surfaced to the developer in context, and merging is blocked until they’re resolved to prevent them from reaching the default branch.

What security looks like with Datadog IaC Security

Datadog IaC Security scans GitHub Actions workflow files on every pull request and surfaces findings as inline PR comments. Findings appear directly in the diff, next to the line that introduced the issue. When PR gating is enabled, a workflow with a critical misconfiguration can be blocked from merging.

Here’s what that looks like in practice. A contributor opens a PR that adds a new workflow step that uses ${{ github.event.pull_request.title }} in a run block. IaC Security flags it inline with the finding, severity, and a plain-language explanation of the risk. The PR check fails. The developer fixes the violation and pushes again. This time, the check passes. The misconfiguration never reaches the default branch, preventing common attack vectors like:

• Expression injection in run blocks. IaC Security flags workflow steps where ${{ }} expressions referencing user-controlled inputs (PR titles, commit messages, branch names) are interpolated directly into shell commands. This is the core technique used against datadog-iac-scanner.

• Unspecified workflow permissions. IaC Security flags workflows that don’t explicitly declare a permissions block, which can cause them to inherit overly broad defaults.

• Unpinned actions. IaC Security flags uses: references that point to mutable tags rather than full commit SHAs. Mutable tags (e.g., v4) can be silently redirected if an upstream action is compromised; pinning to a full SHA ensures that the code that runs is exactly what was reviewed.

• Unsecured commands. IaC Security flags the use of deprecated set-env and add-path workflow commands. These commands allow steps to inject environment variables and PATH entries that persist across subsequent steps—a lateral movement primitive within a running workflow.

Expanding security coverage in CI/CD

The hackerbot-claw campaign prompted a thorough audit of coverage gaps. While IaC Security already covered core attack vectors, the audit revealed two additional risk categories: how dangerous triggers and conditions interact, and how supply chain and runtime integrity can be compromised.

IaC Security’s GitHub Actions ruleset has expanded with new coverage across these two key areas:

• Trigger and condition safety. New rules flag dangerous trigger configurations. These include pull_request_target paired with an untrusted checkout, insufficient bot or actor conditions before privileged steps, and conditional logic vulnerable to string manipulation. These patterns can allow attackers to bypass intended access controls even when individual steps appear safe in isolation.

• Supply chain and runtime integrity. New rules detect unpinned container images, hardcoded container credentials, and cache poisoning patterns where untrusted code can write to shared caches. Additional coverage includes Dependabot execution contexts running with elevated privileges.

Together, these rules make IaC Security a comprehensive security baseline for any organization running GitHub Actions, from small open source projects to enterprise-scale CI/CD pipelines.

Best practices for securing your GitHub Actions workflows

Regardless of whether you’re using automated scanning today, there are several baseline practices that reduce your GitHub Actions attack surface.

Pin actions to a full commit SHA

Mutable tags can be moved, but a SHA cannot. So, instead of using a mutable tag like this:

uses: actions/checkout@v4

Use a SHA like this:

uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2

Explicitly declare minimum permissions

Set permissions at the org level and narrow them further at the job level where possible. For example:

permissions:
  contents: read
  issues: write

For more information, consult the GitHub documentation on modifying permissions for the GITHUB_TOKEN.

Never interpolate user-controlled input into run blocks

Assign environment variables to sanitize the input before it reaches the shell:

# Dangerous:
run: echo "${{ github.event.pull_request.title }}"
# Safer: pass through an environment variable
env:
  PR_TITLE: ${{ github.event.pull_request.title }}
run: echo "$PR_TITLE"

Avoid pull_request_target with untrusted code checkout

If you need pull_request_target for access to secrets, don’t combine it with checking out code from the head of a fork. Separate the workflow into a privileged portion that runs on the base ref and an unprivileged portion that runs on the fork.

Scope secrets to the jobs that need them

Don’t pass a secret into a job unless that job explicitly requires it. The blast radius of a compromised step is limited to the secrets it can access.

Add IaC Security scanning to your PR checks

Static analysis catches configuration mistakes that code review misses. Treating workflow files like any other code, subject to automated analysis before merge, is the most reliable way to prevent misconfigurations from reaching production.

Getting started with Datadog IaC Security

IaC Security integrates into your developer workflows to provide a unified view of findings in your CI/CD, your source code, and your cloud environment.

Setup is a few clicks: Just connect your repositories on the Code Security Setup page, and toggle on IaC scanning. Findings appear as inline PR comments and optionally block merge on detected issues. To learn more, visit the Datadog IaC Security documentation and the guide on adding it to your CI pipeline.

If you’re not yet a Datadog customer, sign up for our free 14-day trial.