GitHub Security Lab published a technical account of CVE-2026-92261 in ipdxco/unified-github-workflows. An external contributor could turn a version string into command execution inside a privileged release-check job.

The October 22 report describes an already-fixed issue. The maintainer advisory, published September 27, lists versions before v1.0.44 as affected and v1.0.44 as patched. This is newly published analysis, not a newly discovered unpatched emergency.

Data crossed two trust boundaries

The reusable workflow read a version from the pull request’s version.json. It then wrote that value into GitHub Actions’ step-output file, which passes named values between steps.

An unchecked newline could create an additional output record and replace a previously trusted prefix. Later code treated that prefix as part of a text-processing program. Shell quoting protected against word splitting but left the text-processing interpreter able to treat the value as instructions.

Restoring the original version file did not help. The untrusted string had already been copied into a variable and survived the restoration.

Who was exposed

The project’s caller template used pull_request_target, which runs in the base repository’s security context. It granted repository-content and pull-request write permissions.

Under that configuration, a contributor able to open a pull request changing the version file could reach the vulnerable job. The consuming repository’s approval policy could add a maintainer-approval prerequisite.

Successful execution could use the job’s token within branch-protection limits, read secrets actually exposed to the job, and tamper with release artifacts. Installing a project that merely uses GitHub Actions does not establish exposure to this specific workflow.

Exploitation status: controlled demonstration reported by GitHub Security Lab. The maintainer advisory describes an end-to-end test against a private repository. Neither reviewed report identifies real-world intrusions exploiting this flaw.

Update the workflow reference and review its authority

  • Move affected references to v1.0.44 or a verified fixed commit. The release notes describe rejecting multiline version values and removing unsafe prefix matching.
  • Check the commit behind a tag. Researchers tested v1.0 at e08e90c46d931f457e5d8e292ffa988c0c0b5b70. A mutable tag can move; its spelling does not prove which code ran.
  • Reduce write permissions and exposed secrets while arranging a fix. This limits consequences but does not repair the parsing flaw.
  • Keep external input out of interpreter programs. Validate each derived value and treat version strings as literal data throughout the workflow.

The fix commit linked by both the report and release is 9f5f9a1d74ef7b0b2b843545aa8a2c675fe52eb1. Pinning an older vulnerable commit provides reproducibility without providing this security fix.

A later step’s secret can still be at risk

A separate October 22 kpt report illustrates the same broader boundary problem. An external branch name reached an inline shell script in a privileged follow-on workflow.

Its job token was read-only, but a later step received SONAR_TOKEN. Earlier injected code could alter runner state before that secret arrived. GitHub Security Lab says kpt fixed that workflow on September 30.

The reports come from GitHub’s own security research team and credit Jaroslav Lobačevski. They provide concrete source traces and controlled findings, not an independent survey of all repositories using these patterns.

Caveat: approval rules and available credentials change the attack’s prerequisites and impact; a fixed workflow cannot establish whether earlier privileged runs were abused.