How severe is GHSA-9j7f-3r4p-pwh6?

GHSA-9j7f-3r4p-pwh6 has a CVSS score of 5.2/10, rated MEDIUM. Review your exposure and patch according to your risk tolerance.

Which packages are affected by GHSA-9j7f-3r4p-pwh6?

GHSA-9j7f-3r4p-pwh6 affects the following packages: nono-py (PyPI). Ecosystems affected: PyPI.

How do I fix GHSA-9j7f-3r4p-pwh6?

Update nono-py to 0.11.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-9j7f-3r4p-pwh6 is resolved across your whole dependency graph.

How do I detect GHSA-9j7f-3r4p-pwh6 in my PyPI dependencies?

Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for nono-py, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

How do I mitigate GHSA-9j7f-3r4p-pwh6 if there is no patch (or I can't update yet)?

If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

Is GHSA-9j7f-3r4p-pwh6 actively exploited in the wild?

No public exploit code has been indexed for GHSA-9j7f-3r4p-pwh6 yet. This does not mean the vulnerability cannot be exploited — absence of public exploits does not imply safety. Apply the recommended fix and use O3 Security to monitor your exposure.

When was GHSA-9j7f-3r4p-pwh6 published, and has it been updated?

GHSA-9j7f-3r4p-pwh6 was published on June 26, 2026 and was last updated on June 26, 2026. Advisory data evolves as severity scores, affected ranges, and exploit intelligence are revised — always check the latest version of the advisory before acting.

GHSA-9j7f-3r4p-pwh6: nono-py

Real-World Exposure

1 pkg affected

🐍nono-py

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.

Description

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.

Affected Packages

1 total 1 fixed

Ecosystem	Package	Vulnerable range	Fix
🐍PyPI	`nono-py`	all versions	0.11.0`pip install --upgrade 'nono-py==0.11.0'`

Detection & mitigation playbook

Open-source dependency

Detect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for nono-py, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update nono-py to 0.11.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-9j7f-3r4p-pwh6 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

Frequently Asked Questions

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 arbitrar

O3 Security · Impact-Aware SCA

Is GHSA-9j7f-3r4p-pwh6 in your dependencies?

Find it across PyPI, including transitive dependencies.

Scan my dependencies How O3 SCA works

nono-py vulnerable to authorization bypass / policy confusionGHSA-9j7f-3r4p-pwh6