Salty Docs CVE-2026-55675

Exploitation requires the target to run the vulnerable workflow pair: trigger-pr-build.yml records an untrusted fork commit SHA into the pr_info artifact, and build-pr.yml's workflow_run job checks out that exact fork commit (ref: pr_sha) before running 'pip install -r requirements.txt' with repository secrets in scope. The concrete prerequisite is a fork pull request whose fork content supplies a malicious setup.py or PEP 517 build hook in the installed dependency set. LIMITING FACTORS: the attacker must control fork content (merely tampering with artifact metadata is insufficient, per the description); the repository-fork guard (github.event.repository.fork == false) does NOT prevent this and is not the cause; and exploitation is confined to repositories deploying this specific workflow pattern prior to commit 649c9aea. Note that submitting a fork PR requires a GitHub account even though CVSS scores PR:N, and first-time-contributor workflow-approval settings may add a maintainer-approval gate in some configurations.

This is a genuine high-priority CI/CD supply-chain flaw, not a CVSS-inflated paper risk. The vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H and the source-code diff agree with each other: a classic GitHub Actions 'pwn request' where the secret-bearing workflow_run job in build-pr.yml checks out an untrusted fork commit recorded in the pr_info artifact and runs 'pip install -r requirements.txt', executing attacker-authored setup.py/PEP 517 build hooks with CF_API_TOKEN, GH_TOKEN, MKDOCS_GIT_COMMITTERS_APIKEY, and a write-capable GITHUB_TOKEN. The scope change (S:C) and full CIA impact are well-justified because the leaked tokens pivot into Cloudflare Pages and the GitHub repository itself. CONFLICTING/ABSENT SIGNALS: No EPSS score, no CISA KEV listing, and no public POC were provided in the input, so there is no evidence of active or automated exploitation despite the 10.0 score. A GitHub Security Advisory (GHSA-wr2h-fpxm-ff4x) and the fix commit confirm the vulnerability is real and vendor-acknowledged, but exploitation here would be targeted (attacker must deliberately craft a malicious fork PR against this specific repo) rather than mass/wormable, which is consistent with the absence of EPSS/KEV signals. SSVC-style read: exploitation = none observed, automatable = no (requires bespoke fork content and PR submission), technical impact = total. Priority is high for anyone operating a fork of this workflow pattern, but real-world blast radius is limited to the single project unless the pattern is widely copied.

An attacker forks saltyorg/docs and opens a pull request whose fork commit adds a malicious setup.py (or PEP 517 build backend) to the dependency tree. When the privileged workflow_run job checks out that untrusted fork commit and runs 'pip install -r requirements.txt', the attacker's installation code executes on the base-repository runner and reads CF_API_TOKEN, GH_TOKEN, MKDOCS_GIT_COMMITTERS_APIKEY, and the write-capable GITHUB_TOKEN from the environment, exfiltrating them to an attacker endpoint. No public exploit was identified at time of analysis, but the GitHub advisory describes the technique in full and low complexity (AC:L) makes reproduction straightforward.