CVE-2026-58441

The CVSS 6.3 score for this SSRF is a floor, not a ceiling — and the EPSS score of 0.00117 is actively dangerous as a guide for prioritization. The vulnerability itself is straightforward: restore-repo uses the CloneURL from pull_request.yml Head directly in a clone operation without sanitization. But the attack surface here isn't random internet scanning — it's CI/CD infrastructure where the attacker already has a foothold via pull request submission. Here's the critical distinction: an attacker doesn't need to guess internal IPs or find a way in. They control a pull request to any public repo using this action, and that pull request triggers a CI pipeline that clones their payload. The PR submission model is the blast radius amplifier — a throwaway GitHub account and a crafted CloneURL is all it takes. No collaborator status required, no social engineering needed. The CVSS metric treats pull_request.yml Head as a low-privilege input, which reveals the scoring model's blind spot. CI runners are designed as high-trust pivot points with access to cloud metadata endpoints (169.254.169.254), internal package registries, secret stores, and VPNs. If your restore-repo action runs in a CI pipeline with elevated network privileges, the exploitation chain is direct: malicious CloneURL fetches internal endpoint, returns credentials or metadata, runner token pivots to artifact registries, signed artifacts are tampered with, downstream consumers trust compromised code. This is exploitation without zero-days. Three concrete actions: First, audit whether restore-repo processes pull requests from untrusted forks — that's the scenario where the attacker has zero friction. Second, determine what network egress your CI runner actually has in fork PR execution contexts. Many organizations assume fork PRs are sandboxed, but the historical record shows sandboxing gaps are discovered reactively, after exploitation. Third, verify whether CloneURL is the only unvalidated input in pull_request.yml or if Head.Ref, Base.Repo, or other fields have the same gap. The exposure window isn't 24 hours — it's measured in workflow versioning cycles. CI pipelines don't update on CVE publication. A medium-severity rating pushes remediation to the next sprint, and in that window every fork PR processed by an unpatched restore-repo is a live exploitation attempt. The EPSS model can't capture this because there's nothing for exploit markets to observe — the exploitation is invisible, ephemeral, and leaves no persistent artifact. Network egress filtering at the runner level is your only realistic detection surface.

Reviewed through automated stages and approved by a human before publication.