Merge pull request #290 from HackTricks-wiki/update_Mini_Shai-Hulud__FAQ_on_the_TeamPCP_npm_and_PyPI_s_20260521_195353

Mini Shai-Hulud FAQ on the TeamPCP npm and PyPI supply-chain...

src/pentesting-ci-cd/github-security/abusing-github-actions/README.md

@@ -516,6 +516,25 @@ GitHub exposes a cross-workflow cache that is keyed only by the string you suppl
 gh-actions-cache-poisoning.md
 {{#endref}}
 
+### OIDC trusted publishing compromise & provenance limits
+
+Cache poisoning and `pull_request_target` abuse become much more impactful when the **release workflow publishes through OIDC trusted publishing** instead of a static registry token:
+
+1. A low-trust workflow (`pull_request_target`, `issue_comment`, bot command, etc.) writes a **malicious binary/script** into a cache key later restored by the privileged release workflow.
+2. The release job restores and executes that binary while holding **`id-token: write`** or an already-minted registry session.
+3. The attacker steals the short-lived identity material, usually by either:
+   - directly requesting a GitHub OIDC token from `ACTIONS_ID_TOKEN_REQUEST_URL` with `ACTIONS_ID_TOKEN_REQUEST_TOKEN`, or
+   - dumping the runner worker process memory / tool-specific token cache after the publish helper requested the token.
+4. The stolen OIDC token is exchanged with the registry trusted-publishing / federation endpoint for **real publish credentials**, so the malicious package is published by the victim's own CI/CD pipeline.
+
+This is important because **npm provenance and Sigstore attestations only prove that the package was produced by the expected build workflow**. They do **not** prove that the workflow was free from attacker-controlled code. If the attacker compromises the trusted builder itself, the backdoored package can still receive valid provenance.
+
+Practical implications during an assessment:
+
+- Look for release jobs with **`permissions: id-token: write`** plus `npm publish`, `pnpm publish`, `changesets`, or custom publish wrappers.
+- Treat `ACTIONS_ID_TOKEN_REQUEST_URL`, `ACTIONS_ID_TOKEN_REQUEST_TOKEN`, runner memory, and CLI token caches as **equivalent credential sources** once code execution is obtained in the release context.
+- Do not assume `npm audit signatures` / provenance verification will detect a package built by a **compromised but legitimate** workflow.
+
 ### Artifact Poisoning
 
 Workflows could use **artifacts from other workflows and even repos**, if an attacker manages to **compromise** the Github Action that **uploads an artifact** that is later used by another workflow he could **compromise the other workflows**:
@@ -910,5 +929,9 @@ An organization in GitHub is very proactive in reporting accounts to GitHub. All
 - [OpenGrep playground releases](https://github.com/opengrep/opengrep-playground/releases)
 - [A Survey of 2024–2025 Open-Source Supply-Chain Compromises and Their Root Causes](https://words.filippo.io/compromise-survey/)
 - [Weaponizing the Protectors: TeamPCP’s Multi-Stage Supply Chain Attack on Security Infrastructure](https://unit42.paloaltonetworks.com/teampcp-supply-chain-attacks/)
+- [Mini Shai-Hulud: Frequently asked questions about the TeamPCP npm and PyPI supply chain campaign](https://www.tenable.com/blog/mini-shai-hulud-frequently-asked-questions)
+- [Events that trigger workflows - GitHub Docs](https://docs.github.com/en/actions/reference/workflows-and-actions/events-that-trigger-workflows)
+- [Trusted publishing for npm packages | npm Docs](https://docs.npmjs.com/trusted-publishers/)
+- [Generating provenance statements | npm Docs](https://docs.npmjs.com/generating-provenance-statements/)
 
 {{#include ../../../banners/hacktricks-training.md}}