CVE-2026-29075: Mesa benchmarks.yml Workflow Runs Untrusted Code

CVE-2026-29075 is a high severity (CVSS 8.3) flaw in Mesa, the Python agent-based modeling library, in version 3.5.0 and earlier. Its benchmarks.yml workflow checked out untrusted pull request code in a privileged runner. A fix commit exists, and the advisory points to a later release.

What's affected

The record says Mesa 3.5.0 and prior is affected and was patched through commit c35b8cd. The GitHub advisory lists affected versions as below 3.5.1 and patched versions as later than 3.5.0, and names the package as the GitHub Actions workflow benchmarks.yml.

This is mainly a repository and CI problem. It affected Mesa's own workflow, not the behavior of the library you import. Check the Mesa release notes for the exact release that includes the change.

How to check if you're exposed

Check which Mesa version your projects use:

pip show mesa

The more important check is for your own repositories: search your workflows for the same pattern. Look for pull_request_target triggers combined with a checkout of the pull request branch and steps that install or run code from it.

grep -rn "pull_request_target" .github/workflows

What to do now

1. Update Mesa to the latest release if you depend on it, and confirm the fix in the release notes.
2. Audit your own workflows that use pull_request_target or have write tokens, and never run code from a pull request branch in them.
3. Follow the advisory's remediation: split the workflow in two. Run benchmarks on the low privilege pull_request trigger with read-only permissions, and post comments from a second workflow triggered by workflow_run.
4. Set default workflow token permissions to read-only for the repository.
5. Review recent workflow runs for unexpected commands or changes.

Why it matters

The record lists CWE-94, code injection. This is a pipeline weakness more than a library bug. The workflow ran on pull requests with permission to write to issues and pull requests, but it installed and ran Python code from the pull request branch. A malicious setup file or benchmark script in a pull request could run in that privileged runner.

The advisory, from GitHub Security Lab, explains that only the comment step needs the write permission. Splitting the work keeps untrusted code in an unprivileged job.

CI workflows are part of your supply chain. If a build runs code that outsiders can submit, it needs the same care as a production service. The record does not mark the CVE as exploited in the wild.

Try it yourself

Click through it at your own pace, or open it full screen.

Quick check

Sources

• GitHub advisory GHSA-3j55-5q6x-2h48

Last reviewed: 19 October 2026.