Advisoriesby Ibisgh-aw: HTTPS egress allowlist bypass via TLS SNI domain fronting
Summary
GitHub Agentic Workflows generated workflows using gh-aw-firewall versions that authorized HTTPS tunnels from the plaintext HTTP CONNECT destination without verifying that the TLS ClientHello SNI matched the workflow's domain allowlist. An attacker could connect to an allowlisted shared CDN hostname and then request a different, non-allowlisted hostname inside the TLS tunnel.
Impact
An untrusted or prompt-injected agent running in a generated workflow could bypass HTTPS egress restrictions and communicate with non-allowlisted destinations. This could enable unauthorized outbound communication or data exfiltration from the workflow environment.
The bypass affects the default HTTPS filtering path. Trusted AWF-owned sidecars and explicitly allowlisted IP destinations retain their separately scoped behavior. Full SSL Bump content-inspection mode is unchanged.
Remediation
The firewall fix inspects the TLS ClientHello without decrypting application traffic. Connections with missing, blocked, or non-allowlisted SNI are terminated; allowlisted connections are spliced unchanged. Blocked-domain rules take precedence over parent-domain allow rules.
Upgrade gh-aw to the first release that includes a fixed gh-aw-firewall version. Recompile and redeploy existing generated workflows after upgrading; upgrading the compiler alone does not replace firewall...
Affected versions
| Package | Affected | Fixed in |
|---|---|---|
| github/gh-aw Product | < 0.89.17 | 0.89.17 |
Details and references
## Summary GitHub Agentic Workflows generated workflows using `gh-aw-firewall` versions that authorized HTTPS tunnels from the plaintext HTTP `CONNECT` destination without verifying that the TLS ClientHello SNI matched the workflow's domain allowlist. An attacker could connect to an allowlisted shared CDN hostname and then request a different, non-allowlisted hostname inside the TLS tunnel. ## Impact An untrusted or prompt-injected agent running in a generated workflow could bypass HTTPS egress restrictions and communicate with non-allowlisted destinations. This could enable unauthorized outbound communication or data exfiltration from the workflow environment. The bypass affects the default HTTPS filtering path. Trusted AWF-owned sidecars and explicitly allowlisted IP destinations retain their separately scoped behavior. Full SSL Bump content-inspection mode is unchanged. ## Remediation The firewall fix inspects the TLS ClientHello without decrypting application traffic. Connections with missing, blocked, or non-allowlisted SNI are terminated; allowlisted connections are spliced unchanged. Blocked-domain rules take precedence over parent-domain allow rules. Upgrade `gh-aw` to the first release that includes a fixed `gh-aw-firewall` version. Recompile and redeploy existing generated workflows after upgrading; upgrading the compiler alone does not replace firewall versions already pinned in generated workflow lock files. At the time this advisory was drafted, no fixed `gh-aw` release had been published. ## Workarounds No workaround is currently documented. ## References - https://github.com/github/gh-aw-firewall/pull/8878 - https://github.com/github/gh-aw-firewall/commit/7c56dd97cc9938086b2ecf0c61a7344af1ec0dea - https://github.com/github/gh-aw-firewall/security/advisories/GHSA-w6qx-pgrq-2c28
- CVSS 4.0
- CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:H/VI:L/VA:N/SC:L/SI:L/SA:N
- Severity from
- GitHub (reviewed advisory)