CVE-2026-54532 in Helm Charts
Summary
by MITRE • 10/23/2026
CloudPirates Open Source Helm Charts is a collection of Helm charts. Prior to commit 271d415, pull_request_target workflow is vulnerable to cache poisoning and OIDC token theft. A pull_request_target workflow checks out fork code using github.event.pull_request.head.sha or .head.ref. This gives attacker-controlled code access to base repository secrets and tokens. A pull_request_target workflow writes to a shared Actions cache. A subsequent release or publish workflow restores from the same cache scope, allowing a poisoned cache entry to execute during release. This issue has been patched via commit 271d415.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/23/2026
The vulnerability identified in CloudPirates Open Source Helm Charts stems from an insecure implementation of GitHub Actions workflows, specifically within the pull_request_target event handler prior to commit 271d415. This workflow configuration introduces critical security flaws related to code execution context and cache integrity. The primary issue arises because the pull_request_target workflow checks out source code using variables such as github.event.pull_request.head.sha or .head.ref, which point to the head of a forked repository rather than the base branch. In GitHub Actions, workflows triggered by pull_request_target run with elevated permissions and access to secrets defined in the base repository. By checking out untrusted code from external contributors without proper isolation, the workflow effectively grants attacker-controlled code full access to sensitive credentials, tokens, and environment variables stored within the base repository's secret management system. This represents a classic supply chain attack vector where malicious actors can inject harmful payloads into pull requests that are then executed with high-privilege contexts due to the misconfiguration of the CI/CD pipeline.
Beyond credential theft, the workflow exhibits severe cache poisoning vulnerabilities through improper interaction with GitHub Actions caching mechanisms. The vulnerable configuration writes build artifacts or intermediate files to a shared Actions cache scope without implementing sufficient integrity checks or isolation for untrusted inputs. Since subsequent workflows, such as those responsible for releasing or publishing packages, restore from this same global cache scope, any malicious data written by the compromised pull_request_target workflow persists and can be executed during legitimate release processes. This allows an attacker to poison the build environment, potentially injecting backdoors into released Helm charts that are then distributed to downstream users. The lack of scoped caching ensures that the trust boundary between untrusted contributor code and trusted production workflows is completely breached, enabling persistent compromise even after the initial pull request has been closed or rejected.
From a classification perspective, this vulnerability aligns with CWE-798: Use of Hard-coded Credentials when considering the exposure of secrets via OIDC tokens, and more accurately with CWE-613: Insufficient Session Expiration if viewed through the lens of token theft duration. In terms of offensive security frameworks, it maps directly to MITRE ATT&CK technique T1059 Command and Scripting Interpreter for code execution within CI/CD pipelines, as well as T1496 Resource Hijacking or Supply Chain Compromise via cache poisoning mechanisms. The exploitation path involves leveraging the pull_request_target event's elevated privileges combined with shared state management flaws to achieve arbitrary code execution in a privileged context. This dual-vector approach allows attackers not only to steal immediate credentials but also to establish long-term persistence within the software supply chain by corrupting build artifacts that propagate to end users.
Mitigation strategies must focus on isolating untrusted code from sensitive resources and ensuring cache integrity. The primary remediation, already implemented in commit 271d415, involves removing or restricting access to secrets for workflows triggered by pull_request_target when handling external forks. Best practices dictate that any workflow processing untrusted input should run with the lowest possible permissions, ideally using read-only access to repository contents and no access to secrets unless explicitly required and verified. Additionally, cache keys must be scoped specifically to each workflow or branch rather than sharing a global cache across unrelated processes. Implementing strict validation of checkout sources and avoiding direct use of head.sha for untrusted code in privileged workflows are essential steps. Organizations should also adopt automated security scanning tools that detect insecure CI/CD configurations and enforce policies that prevent the execution of arbitrary code from forks with elevated privileges, thereby closing both the credential theft and cache poisoning attack vectors simultaneously.