CloudPirates Helm Charts CVE-2026-54532

Exploitation requires that the repository (prior to commit 271d415) run a pull_request_target workflow that checks out fork code via github.event.pull_request.head.sha or .head.ref, AND that this fork-triggered workflow write to an Actions cache scope later restored by a release or publish workflow. The attacker must be able to open a pull request from a fork. Limiting factors: UI:R reflects that the fork-triggered workflow must actually run - GitHub's default requires maintainer approval before running workflows from first-time/external contributors, which blunts drive-by exploitation; the issue is fixed in commit 271d415 (fixed repositories are not exploitable); and impact is tied to the secrets/tokens exposed to that specific repository's workflows and its release pipeline.

Signals are moderate and partly conflicting. The official CVSS is 6.9 (CVSS:3.1/AV:N/AC:L/PR:H/UI:R/S:C/C:N/I:H/A:L), while the GHSA advisory author independently estimated 8.1 with PR:N and C:H - a meaningful disagreement: opening a pull request from a fork requires no privileges on the target repository, so the official PR:H appears too high, and C:N understates an attack whose core goal is stealing base-repository secrets and OIDC tokens (confidentiality impact). Verify the authentication metric with the vendor. No CISA KEV entry is present, so this is 'no public exploit identified at time of analysis' and there is no evidence of active exploitation; no EPSS score was supplied, so exploitation probability cannot be quantified here; no SSVC decision vector was provided beyond the vuln.today priority label 'this_month'. A detailed public advisory describes the technique (modeled on the May 2026 TanStack supply-chain compromise) but no working exploit code is referenced. Net: this is a genuine supply-chain / CI-security issue rather than a high-CVSS-but-trivial one, but it is already patched (commit 271d415), is confined to one niche repository's workflows, and the 'this_month' label plus absence of KEV/EPSS point to scheduled remediation, not emergency response.

An attacker opens a pull request from a fork; the repository's pull_request_target workflow checks out the fork's head.sha/head.ref and runs that attacker-controlled code with base-repository permissions, allowing exfiltration of secrets, tokens, and deploy keys. The same workflow writes to a shared Actions cache that a later release/publish workflow restores, so a poisoned cache entry can execute during release and ship malicious artifacts. No working exploit code is published, but a detailed public advisory describes the full technique; the CVSS vector indicates network reach with low complexity but requires the fork workflow to actually run.