{"id":"GHSA-9j7f-3r4p-pwh6","aliases":[],"status":"published","title":"nono-py vulnerable to authorization bypass / policy confusion","description":"The python API made a restrictive-looking configuration unsafe by default. A caller could configure only reverse-\nproxy credential routes, put the child in CapabilitySet.proxy_only, and reasonably expect network access to be limited\nto those routes. Instead, because empty allowed_hosts meant allow-all inside nono-proxy, the child could use the local\nproxy as a transparent CONNECT tunnel to non-route nominated hosts (not including metadata endpoints).\n\nThat is an authorization bypass / policy confusion issue:\n\n- Intended policy: route-only proxy access.\n- Actual policy: route-only plus arbitrary transparent CONNECT.\n- Boundary crossed: sandboxed child gains broader outbound network reach than the Python policy appears to grant.\n- Impact depends on environment, but it can allow exfiltration or access to unintended internet/internal services\n  through the unsandboxed proxy.\n\nThis should be classified as medium severity by default, potentially high if users rely on route-only configs for strict egress\ncontrol around untrusted code or sensitive credentials. The fix is security-relevant because it changes the default from\nimplicit allow-all to explicit opt-in.","severity":{"version":"3.1","score":5.2,"vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N","level":"medium","from":"ghsa"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-1188"],"published":"2026-06-26T20:39:43Z","modified":"2026-06-26T20:45:12Z","fixes":[{"ecosystem":"PyPI","package":"nono-py","fixed_in":["0.11.0"],"sources":["ghsa","osv"]}],"affected":[{"source":"ghsa","ecosystem":"PyPI","package":"nono-py","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"last_affected":"0.10.1"},{"fixed":"0.11.0"}]}]},{"source":"osv","ecosystem":"PyPI","package":"nono-py","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.11.0"}]}],"versions":["0.1.0","0.10.0","0.10.1","0.2.0","0.3.1","0.4.0","0.4.2","0.5.0","0.6.0","0.7.0","0.7.2","0.8.0","0.9.0","0.9.2"]}],"references":[{"url":"https://github.com/always-further/nono-py/security/advisories/GHSA-9j7f-3r4p-pwh6","tags":["web"]},{"url":"https://github.com/nolabs-ai/nono-py/commit/163fca083a189967b882d1005bfba099fc9a9d63","tags":["web"]},{"url":"https://github.com/advisories/GHSA-9j7f-3r4p-pwh6"},{"url":"https://github.com/always-further/nono-py","tags":["package"]}],"sources":{"ghsa":[{"id":"GHSA-9j7f-3r4p-pwh6","title":"nono-py vulnerable to authorization bypass / policy confusion","description":"The python API made a restrictive-looking configuration unsafe by default. A caller could configure only reverse-\nproxy credential routes, put the child in CapabilitySet.proxy_only, and reasonably expect network access to be limited\nto those routes. Instead, because empty allowed_hosts meant allow-all inside nono-proxy, the child could use the local\nproxy as a transparent CONNECT tunnel to non-route nominated hosts (not including metadata endpoints).\n\nThat is an authorization bypass / policy confusion issue:\n\n- Intended policy: route-only proxy access.\n- Actual policy: route-only plus arbitrary transparent CONNECT.\n- Boundary crossed: sandboxed child gains broader outbound network reach than the Python policy appears to grant.\n- Impact depends on environment, but it can allow exfiltration or access to unintended internet/internal services\n  through the unsandboxed proxy.\n\nThis should be classified as medium severity by default, potentially high if users rely on route-only configs for strict egress\ncontrol around untrusted code or sensitive credentials. The fix is security-relevant because it changes the default from\nimplicit allow-all to explicit opt-in.","status":"published","published":"2026-06-26T20:39:43Z","modified":"2026-06-26T20:39:45Z","cvss":[{"version":"3.1","score":5.2,"vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N","level":"medium"}],"cwes":["CWE-1188"],"updated_at":"2026-11-02T14:40:33.778544Z"}],"osv":[{"id":"GHSA-9j7f-3r4p-pwh6","title":"nono-py vulnerable to authorization bypass / policy confusion","description":"The python API made a restrictive-looking configuration unsafe by default. A caller could configure only reverse-\nproxy credential routes, put the child in CapabilitySet.proxy_only, and reasonably expect network access to be limited\nto those routes. Instead, because empty allowed_hosts meant allow-all inside nono-proxy, the child could use the local\nproxy as a transparent CONNECT tunnel to non-route nominated hosts (not including metadata endpoints).\n\nThat is an authorization bypass / policy confusion issue:\n\n- Intended policy: route-only proxy access.\n- Actual policy: route-only plus arbitrary transparent CONNECT.\n- Boundary crossed: sandboxed child gains broader outbound network reach than the Python policy appears to grant.\n- Impact depends on environment, but it can allow exfiltration or access to unintended internet/internal services\n  through the unsandboxed proxy.\n\nThis should be classified as medium severity by default, potentially high if users rely on route-only configs for strict egress\ncontrol around untrusted code or sensitive credentials. The fix is security-relevant because it changes the default from\nimplicit allow-all to explicit opt-in.","status":"published","published":"2026-06-26T20:39:43Z","modified":"2026-06-26T20:45:12.257730014Z","cvss":[{"version":"3.1","score":5.2,"vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N","level":"medium"}],"cwes":["CWE-1188"],"updated_at":"2026-11-02T15:46:43.875515Z"}]}}