The python API made a restrictive-looking configuration unsafe by default. A caller could configure only reverse-
proxy credential routes, put the child in CapabilitySet.proxy_only, and reasonably expect network access to be limited
to those routes. Instead, because empty allowed_hosts meant allow-all inside nono-proxy, the child could use the local
proxy as a transparent CONNECT tunnel to non-route nominated hosts (not including metadata endpoints).
That is an authorization bypass / policy confusion issue:
- Intended policy: route-only proxy access.
- Actual policy: route-only plus arbitrary transparent CONNECT.
- Boundary crossed: sandboxed child gains broader outbound network reach than the Python policy appears to grant.
- Impact depends on environment, but it can allow exfiltration or access to unintended internet/internal services
through the unsandboxed proxy.
This should be classified as medium severity by default, potentially high if users rely on route-only configs for strict egress
control around untrusted code or sensitive credentials. The fix is security-relevant because it changes the default from
implicit allow-all to explicit opt-in.
References
The python API made a restrictive-looking configuration unsafe by default. A caller could configure only reverse-
proxy credential routes, put the child in CapabilitySet.proxy_only, and reasonably expect network access to be limited
to those routes. Instead, because empty allowed_hosts meant allow-all inside nono-proxy, the child could use the local
proxy as a transparent CONNECT tunnel to non-route nominated hosts (not including metadata endpoints).
That is an authorization bypass / policy confusion issue:
through the unsandboxed proxy.
This should be classified as medium severity by default, potentially high if users rely on route-only configs for strict egress
control around untrusted code or sensitive credentials. The fix is security-relevant because it changes the default from
implicit allow-all to explicit opt-in.
References