Poisoned Pipeline / Techniques / T0219
Exfiltrate secrets through the CI platform's own log store
The attacker does not send secrets anywhere. A pipeline run prints them
into its own job log, and the attacker then retrieves that log through
the CI platform's public API from outside the victim's network, deleting
the run afterwards. Nothing on the runner opens an outbound connection,
so egress filtering, network detection, proxy allow-lists and domain
reputation have no traffic to inspect or block: the exfiltration channel
is the platform's own log retention and log-download API.
Two properties make it work. Secret masking is usually literal — the
platform redacts a value only where it appears verbatim — so encoding the
value first (base32, base64, hex) prints it in full. And a job's token
permissions do not scope the secrets context, so a workflow that grants
its GITHUB_TOKEN nothing can still read every repository secret.
Distinct from T0192 (an adversary reading logs that already contain
sensitive data) and from T0145 (data leaving the network disguised inside
a legitimate channel). Here the data never leaves the network; the
attacker collects it later, from the platform side.
Where this idea came from
This catalogue, from the Gheist campaign (Wiz Research, 25 October 2026) where a planted sync-check workflow printed base32-encoded repository secrets into its own job log and the operator downloaded the log through the GitHub API, deleting the run seconds later. No attacker domain and no outbound connection, so egress controls saw nothing. Distinct from the GhostAction family (AS304), which posts secrets out to an attacker IP.
Mitigations
None linked yet.
Detections
None linked yet.
Observed in incidents (2)
- Stolen GitHub tokens planted a secret-dumping workflow in 850+ accounts and pulled the logs back through the API
- Stolen GitHub tokens planted a secret-dumping workflow in 850+ accounts and pulled the logs back through the API