🚨 Runner-Guard Security Finding
Rule: RGS-012 — Secret Exfiltration via Outbound HTTP Request
Severity: High
File: .github/workflows/daily-byok-ollama-test.lock.yml
Lines: 384, 391 (2 findings in this file)
Description
A run: block contains an outbound HTTP request command (curl, wget, httpie, python requests, node fetch, etc.) targeting a non-GitHub domain (i.e., not github.com, api.github.com, or ghcr.io) in a job context that has access to secrets or publishing capabilities. This pattern is a strong indicator of credential exfiltration — the primary objective of most GitHub Actions supply-chain attacks.
The specific commands flagged are:
- Line 384 (
Install Ollama step): curl -fsSL (ollama.com/redacted) | sh
- Line 391 (
Start Ollama service step): triggers further outbound traffic from the just-installed binary
Impact
Attackers who achieve code execution in a CI runner (via expression injection, fork checkout, compromised action, etc.) need a way to exfiltrate stolen secrets to infrastructure they control. The most common method is an HTTP POST request to an attacker-owned domain carrying environment variables, secret values, or tokens as the request body. While there are legitimate uses of outbound HTTP requests in CI (API calls, webhook notifications, deployment), the combination of external HTTP requests with secrets access in a workflow triggered by untrusted events is a high-confidence indicator of either active exploitation or a dangerous pattern that could be exploited.
In this workflow specifically, the installer script (ollama.com/install.sh) is fetched and piped directly to a shell, and the subsequent ollama daemon makes further outbound calls. If ollama.com were ever compromised or the script tampered with in transit (e.g. DNS hijack), the workflow's secrets would be at risk.
Remediation
Consider one or more of the following:
- Pin Ollama by version + checksum: download the released binary tarball from a specific GitHub release tag and verify its SHA256 instead of piping
install.sh to shell.
- Run installation in a separate job without secrets: split the workflow so the
Install Ollama step runs in a job that has no access to secrets.* or write permissions, then pass the binary to a second job via an artifact.
- Cache the installed Ollama runtime: use
actions/cache to avoid re-fetching the installer on every run, reducing the window where a tampered upstream installer can take effect.
- Allow-list outbound domains via the firewall: if
ollama.com is the only domain needed, lock down egress for the rest of the job using the gh-aw network firewall configuration.
Detected by runner-guard v2.6.0 — CI/CD source-to-sink vulnerability scanner
Workflow run: https://github.com/github/gh-aw/actions/runs/26620964658
Generated by 📊 Static Analysis Report · opus47 22.9M · ◷
🚨 Runner-Guard Security Finding
Rule: RGS-012 — Secret Exfiltration via Outbound HTTP Request
Severity: High
File:
.github/workflows/daily-byok-ollama-test.lock.ymlLines: 384, 391 (2 findings in this file)
Description
A
run:block contains an outbound HTTP request command (curl, wget, httpie, python requests, node fetch, etc.) targeting a non-GitHub domain (i.e., not github.com, api.github.com, or ghcr.io) in a job context that has access to secrets or publishing capabilities. This pattern is a strong indicator of credential exfiltration — the primary objective of most GitHub Actions supply-chain attacks.The specific commands flagged are:
Install Ollamastep):curl -fsSL (ollama.com/redacted) | shStart Ollama servicestep): triggers further outbound traffic from the just-installed binaryImpact
Attackers who achieve code execution in a CI runner (via expression injection, fork checkout, compromised action, etc.) need a way to exfiltrate stolen secrets to infrastructure they control. The most common method is an HTTP POST request to an attacker-owned domain carrying environment variables, secret values, or tokens as the request body. While there are legitimate uses of outbound HTTP requests in CI (API calls, webhook notifications, deployment), the combination of external HTTP requests with secrets access in a workflow triggered by untrusted events is a high-confidence indicator of either active exploitation or a dangerous pattern that could be exploited.
In this workflow specifically, the installer script (
ollama.com/install.sh) is fetched and piped directly to a shell, and the subsequentollamadaemon makes further outbound calls. Ifollama.comwere ever compromised or the script tampered with in transit (e.g. DNS hijack), the workflow's secrets would be at risk.Remediation
Consider one or more of the following:
install.shto shell.Install Ollamastep runs in a job that has no access tosecrets.*or write permissions, then pass the binary to a second job via an artifact.actions/cacheto avoid re-fetching the installer on every run, reducing the window where a tampered upstream installer can take effect.ollama.comis the only domain needed, lock down egress for the rest of the job using the gh-aw network firewall configuration.Detected by runner-guard v2.6.0 — CI/CD source-to-sink vulnerability scanner
Workflow run: https://github.com/github/gh-aw/actions/runs/26620964658