CVE-2026-31900 is a critical code execution flaw in the GitHub Action for the Black Python formatter, scored 9.8. With the use_pyproject option on, a malicious pull request can edit pyproject.toml and point the tool at a malicious package. Black 26.3.0 fixes it, or turn that option off.
What's affected
The GitHub Action published by psf/black, in versions before 26.3.0. The risk applies to workflows that set use_pyproject to true so that the action reads the Black version from the repository's pyproject.toml.
The advisory says users who reference the action as psf/black@stable pick up the update automatically. Workflows that pin an older version or a commit stay on the vulnerable code until you change them.
The Black formatter on a developer's machine is not the problem. The weakness is in how the action reads the version field in CI.
How to check if you're exposed
Search every workflow file in your repositories for the action and the option.
grep -rn "psf/black" .github/workflows
grep -rn "use_pyproject" .github/workflows
A workflow that uses psf/black with use_pyproject set to true is in scope. Then look at what triggers it. A workflow that runs on pull requests from forks, or that runs with write permissions or secrets in the environment, raises the stakes. Check the pin too: a branch name such as stable follows updates, while an older tag or SHA does not.
What to do now
- Update workflows to use the Black action at 26.3.0 or later, or confirm they track the stable reference.
- If you cannot update yet, remove use_pyproject: true from the workflow. The advisory lists that as a workaround.
- Limit the permissions of the job to read only unless it truly needs more, and keep repository secrets out of formatting jobs.
- Review recent pull requests that changed pyproject.toml in repositories where this action ran, looking for version fields that point at a direct URL.
- Rotate secrets that were available to a workflow run if you find such a change.
Why it matters
The record lists CWE-20, improper input validation. The version field in pyproject.toml is data that a contributor controls. The action treated it as a trusted version number, so a direct URL reference could pull in a package from a repository chosen by the author of the pull request. The fix tightens validation of that field.
This shape of bug shows up often in CI. A build step that reads configuration from the code under review hands control to whoever writes that code. A pull request does not need to be merged to cause harm if the workflow runs on the proposed branch.
The advisory notes that attackers could reach secrets or permissions available in the action's context. That is why the blast radius depends on your workflow design, not only on the Black version. Formatting jobs rarely need secrets, and removing them makes this class of bug much less costly.
The record does not flag this CVE as listed in CISA's Known Exploited Vulnerabilities catalog, and no advisory I read says it is exploited in the wild. Treat it as a patch to schedule promptly, not a fire drill, unless your own logs say otherwise.
Safeguard's free in-browser dependency scan at https://gold.safeguard.sh/scan covers your dependencies. CI configuration is worth reviewing on top of that.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Does this affect the black package on my laptop?
The advisory is about the GitHub Action and its use_pyproject option. It does not describe the locally installed formatter as the vulnerable piece.
What is the quickest mitigation?
Update the action to 26.3.0 or later. If that has to wait, the advisory says to avoid use_pyproject: true.
Sources
Last reviewed: 19 October 2026.
