Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
3 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
nono-py policy handling could fail open in two ways. First, resolving a policy-derived ProxyConfig did not automatically enforce CapabilitySet.proxyonly, allowing sandboxed children to bypass a resolved domain allowlist by using direct network access. Second, policy JSON accepted unknown security-sensitive fields, so misspelled or unsupported restrictions could be silently ignored. Impact A sandboxed child may receive broader network access than the policy author intended. This can allow outbound requests outside the configured proxy allowlist and may expose sensitive data depending on the execution environment and workload. Older-kernel note On Linux kernels without Landlock ABI v4 network rules, patched versions continue to support proxy-only enforcement through the seccomp supervisor fallback introduced in 807fb4b. Users on older kernels should ensure policy-resolved proxy configurations are coupled to CapabilitySet.proxyonly(proxy); merely injecting proxy environment…
Recommended action: Upgrade to 0.10.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.proxyonly, and reasonably expect network access to be limited to those routes. Instead, because empty allowedhosts 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…
Recommended action: Upgrade to 0.11.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
On Linux kernels that do not support Landlock network rules, nonopy.sandboxedexec() could run CapabilitySet.proxyonly(proxy) without supervising the seccomp-notify proxy-only fallback returned by the Rust core. In that configuration, a sandboxed child process could remove HTTPPROXY / HTTPSPROXY environment variables or use raw sockets and then open direct TCP connections that should have been denied by proxy-only policy. The issue affects proxy-only enforcement. It does not mean that all nono-py network blocking is ineffective. ECS validation showed caps.blocknetwork() denied regular TCP and ECS metadata TCP on the tested Linux 6.1 host. Impact The intended proxyonly() security property is: - child processes may connect only to the local nono proxy port - the proxy enforces host allowlists and metadata/link-local denial - direct TCP to any other target is denied Before the fix, on kernels without Landlock AccessNet, the Python binding applied the sandbox and then executed the…
Recommended action: Upgrade to 0.10.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.