CVE-2026-42298 is a code injection flaw in a GitHub Actions workflow of Postiz, an AI social media scheduling tool, scored CVSS 10.0 (critical). A pull request from a fork could run code in the build and expose a write-all token. It is fixed in commit da44801. Audit your own workflows for the same pattern.
What's affected
The record says the problem existed before commit da44801 in the workflow file .github/workflows/pr-docker-build.yml, named Build and Publish PR Docker Image. The fix is that commit, not a tagged release. The GitHub advisory lists no version numbers.
This is a flaw in the project's own build pipeline, not in the application you deploy. The advisory describes the impact on the repository, such as commits, releases and issue management. If you only run Postiz and do not build or fork its repository, the direct exposure is small. If you maintain a fork, mirror or copy of its workflows, check them.
How to check if you're exposed
- If you work from a clone or a fork of the Postiz repository, check that the fix is in your history.
git merge-base --is-ancestor da448012dd87e94944cbe83a38e7fd023269ec46 HEAD && echo patched
- Look at your own workflow files for the pattern the advisory calls a Pwn Request. Find workflows that run with the
pull_request_targettrigger and check whether they build or run code from the pull request.
grep -rn "pull_request_target" .github/workflows
- For each hit, check what token permissions the job gets and whether it checks out the pull request's own code.
- Review the repository's audit log and recent releases for anything you did not make.
What to do now
- Pull commit da44801 into any fork or mirror of Postiz you maintain.
- Remove or rewrite workflows that run untrusted pull request code with a token that can write to the repository.
- Set default workflow permissions to read only in repository settings, and grant more per job only where needed.
- Split the work. Run untrusted builds in a workflow with no secrets and no write access, and run privileged steps in a separate workflow that only uses trusted inputs.
- Require approval before workflows run on pull requests from outside contributors.
- If you have reason to think a token was exposed, revoke it, rotate secrets and review commits and releases.
Why it matters
The class is CWE-94, improper control of generation of code. The advisory says the workflow built a Docker image from files in a pull request. A modified Dockerfile in a fork could run code during the build, in a job that held a token with write-all permissions. An outsider needs no account on the project, only the ability to open a pull request.
Per the advisory, that gives full read and write access to the repository. The attacker could commit, create releases, and manage pull requests and issues. For a project that publishes container images, access to releases is the real prize, because downstream users pull what the project publishes.
This is a supply chain problem more than an application bug. The code you ship can be changed through the pipeline that builds it. The same pattern appears in many repositories, since it is easy to combine a trigger that runs with repository secrets with a step that uses the pull request's content.
The project's timeline in the advisory shows a fix on the same day it was reported, which is how this should go. The KEV flag is false, and I found no report of exploitation in the wild.
Good controls here are small. Read only default tokens, no secrets in untrusted jobs and a review gate for first time contributors remove most of the risk. Gating changes before they merge is the same idea applied to your own code.
Try it yourself
A pull request gate shows how checks can run on proposed changes before anything is merged or published.
Click through it at your own pace, or open it full screen.
Quick check
Do I need to patch my Postiz deployment?
The record describes the build workflow, not the running app. Deployments are not the focus, but check any fork or CI you maintain, and confirm in the advisory.
Why is the score 10.0?
The vector has network access, no privileges, no user action and a changed scope, with high impact on confidentiality, integrity and availability.
Sources
Last reviewed: 19 October 2026.
