How severe is GHSA-6ww7-3frv-cqxh?

No CVSS score has been assigned to GHSA-6ww7-3frv-cqxh yet. Review the advisory details and affected package list to assess your exposure.

Which packages are affected by GHSA-6ww7-3frv-cqxh?

GHSA-6ww7-3frv-cqxh affects the following packages: nltk (PyPI). Ecosystems affected: PyPI.

How do I fix GHSA-6ww7-3frv-cqxh?

Update nltk to 3.10.3 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-6ww7-3frv-cqxh is resolved across your whole dependency graph.

How do I detect GHSA-6ww7-3frv-cqxh in my PyPI dependencies?

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

How do I mitigate GHSA-6ww7-3frv-cqxh if there is no patch (or I can't update yet)?

Restrict outbound requests from the affected component to an allowlist of hosts, block access to link-local and internal address ranges at the network layer, and require authentication on internal services so a forged request cannot reach them unauthenticated.

Is GHSA-6ww7-3frv-cqxh actively exploited in the wild?

No public exploit code has been indexed for GHSA-6ww7-3frv-cqxh 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.

What is the EPSS score for GHSA-6ww7-3frv-cqxh?

GHSA-6ww7-3frv-cqxh has an EPSS (Exploit Prediction Scoring System) score of 0.4%, placing it in the 36th percentile of all CVEs. EPSS is maintained by FIRST.org and estimates the probability that a vulnerability will be exploited in the wild within the next 30 days. This score indicates relatively lower exploitation probability, though the CVSS severity should still guide your patching priority.

What type of vulnerability is GHSA-6ww7-3frv-cqxh?

GHSA-6ww7-3frv-cqxh is classified as Server-Side Request Forgery (SSRF) (CWE-918). This weakness type describe the underlying flaw category, which helps determine the potential impact and the right class of mitigation. This is a high-impact weakness class that often enables remote code execution or data exposure.

When was GHSA-6ww7-3frv-cqxh published, and has it been updated?

GHSA-6ww7-3frv-cqxh was published on September 8, 2026 and was last updated on September 8, 2026. Advisory data evolves as severity scores, affected ranges, and exploit intelligence are revised — always check the latest version of the advisory before acting.

🐍 PyPI

Not in CISA KEV

NLTK: pathsec SSRF protection can be bypassed when a proxy is configuredGHSA-6ww7-3frv-cqxh

Fix: nltk/nltk@767333a

GHSA-6ww7-3frv-cqxh is a Server-Side Request Forgery (SSRF) vulnerability in nltk. A fix is available for nltk — see the affected versions and patch details below.

Also known asCVE-2026-78682PYSEC-2026-3733

Published

Sep 8, 2026

Updated

Sep 8, 2026

Affected

1 pkg

Patched

1 / 1

Exploits

None indexed

Exploitation data as of Oct 9, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

Proof-of-concept exploit code exists

CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.

Exploitation and automatability from CISA’s SSVC triage for GHSA-6ww7-3frv-cqxh.

EPSS Exploitation Probability

via FIRST.org ↗

0.4%probability of exploitation in next 30 days

Lower Risk0.00%

Lower risk than most CVEs36th percentile — riskier than 36% of all scored CVEsHighest risk

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

Real-World Exposure

1 pkg affected

🐍nltk

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

Summary

Current NLTK source reopens SSRF in proxied environments. pathsec.urlopen() validates the requested hostname locally, but once proxy inheritance is enabled the real fetch is performed by the proxy rather than by the validated direct-connect socket path.

Details

Vulnerability type: Server-side request forgery
Affected component: nltk.pathsec.urlopen, nltk.data.load, nltk.downloader.Downloader.index, nltk.downloader.Downloader.download
Affected versions: Current source v3.10.0-rc2; published 3.9.4 was a negative control and did not reproduce.
Patched versions: Not yet patched
Root cause: Proxy-handler inheritance disables _SafeHTTPHandler and _SafeHTTPSHandler, so the validated hostname no longer matches the actual egress destination.

The hardened direct path pins the validated numeric destination IP before opening the socket. The proxied branch instead copies ProxyHandler instances from the global opener, marks the request as proxied, and skips the pinned handlers. I confirmed that a validated public URL can be fetched from a loopback-only internal service through the proxy path via pathsec.urlopen(), nltk.data.load(), Downloader.index(), and Downloader.download().

PoC

Preconditions

The runtime has an HTTP proxy configured and the caller relies on pathsec to keep network fetches SSRF-safe.

Steps

Start a loopback-only HTTP server that serves secret text, a valid downloader index, and a ZIP payload.
Configure a proxy that forwards a validated public URL to that internal loopback service.
Call pathsec.urlopen() or nltk.data.load() on the public URL and observe the internal response is returned.
Instantiate Downloader(server_index_url=...), call index() and download(), and observe internal-only content is parsed and installed.

Minimal reproducible excerpt

{'urlopen': 'PROXY_TEXT_SECRET', 'data_load': 'PROXY_TEXT_SECRET', 'downloaded_file': 'INTERNAL_ZIP_SECRET'}

Impact

Consumers that trust pathsec as an SSRF barrier in proxied environments can be made to read internal-only HTTP resources, load forged downloader indexes, and install attacker-chosen package content fetched from the proxy's network view.

Remediation

Preserve destination validation for the actual proxy egress target or fail closed when the request would otherwise downgrade into an unpinned proxied path. Add regression tests across pathsec.urlopen, nltk.data.load, and downloader fetches with a configured proxy.

References

Fix + attack demonstration (verified)

NLTK cannot pin the egress through a proxy, so it stops pretending to: under ENFORCE a proxied fetch is refused rather than performed unvalidated. Operators who trust their proxy opt back in with NLTK_ALLOW_PROXIED_URLOPEN=1 or nltk.pathsec.ALLOW_PROXIED_FETCH=True; under ENFORCE=False the refusal degrades to a warning. This closes the whole class (environment proxies and explicit ProxyHandler alike), because NLTK declines any fetch whose egress it cannot validate.

Attack demonstration (reproduced; captured output)

A loopback HTTP server stands in for the internal target; http_proxy points at it; NLTK is asked for a public IP URL.

Before the fix — the internal secret is exfiltrated through the proxy:

validate_network_url(public): PASSED
*** BYPASS: pathsec.urlopen returned INTERNAL content via proxy: 'INTERNAL_ONLY_SECRET'

After the fix — five scenarios, isolated subprocesses:

Scenario	Result
proxied (env) + ENFORCE	`PermissionError` — blocked
proxied + opt-in	returns secret — escape hatch works
explicit `ProxyHandler` (not env) + ENFORCE	`PermissionError` — blocked (whole class)
no proxy (direct)	internal IP still refused — pinning intact
proxied + `ENFORCE=False`	returns secret + warns

Tests

nltk/test/unit/test_pathsec.py: 64 passed. Added an end-to-end regression (test_proxied_fetch_does_not_reach_internal_target) plus test_env_proxy_fails_closed_under_enforce; the prior test_env_proxy_skips_pinning_handlers (which encoded the vulnerable path) is re-expressed as the opt-in case. Existing direct-path DNS-rebinding and IP-policy tests unchanged and passing. pre-commit (isort/black/ruff) clean.

Note

The upfront validate_network_url() and the direct-path IP pinning (from the earlier DNS-rebinding fixes, CVE-2026-54296 / GHSA-qvv7) are unchanged — this only closes the proxied downgrade they didn't cover.

Affected Packages

1 total 1 fixed

Ecosystem	Package	Vulnerable range	Fix
🐍PyPI	`nltk`	all versions	3.10.3`pip install --upgrade 'nltk==3.10.3'`

Affected Products

1 product · 1 configurations

Application

nltknltk

< 3.10.3

range

Detection & mitigation playbook

Open-source dependency

Detect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for nltk, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update nltk to 3.10.3 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-6ww7-3frv-cqxh is resolved across your whole dependency graph.
Workarounds
Restrict outbound requests from the affected component to an allowlist of hosts, block access to link-local and internal address ranges at the network layer, and require authentication on internal services so a forged request cannot reach them unauthenticated.

Fixing This On Your OS

If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.

Red HatImportant

This is a server-side request forgery (SSRF) vulnerability in NLTK when an HTTP proxy is configured. The flaw allows an attacker to bypass local hostname validation, enabling the proxy to forward requests to internal loopback services. This can lead to the disclosure of internal HTTP resources or the installation of…

Workaround published by Red Hat

To mitigate this issue, avoid configuring an HTTP proxy for NLTK if it is not strictly necessary. If an HTTP proxy must be used, implement strict network egress filtering to prevent NLTK from initiating connections to internal or loopback network addresses. This measure restricts the potential for an attacker to exploit the SSRF to access internal resources.

Source: Red Hat security advisory for GHSA-6ww7-3frv-cqxh (CC BY 4.0)

Product	Fixed in	Advisory
Red Hat OpenShift AI 3.3	`rhoai/odh-llama-stack-core-rhel9:1789121286`	RHSA-2026:73987

Frequently Asked Questions

### Summary Current NLTK source reopens SSRF in proxied environments. `pathsec.urlopen()` validates the requested hostname locally, but once proxy inheritance is enabled the real fetch is performed by the proxy rather than by the validated direct-connect socket path. ### Details - **Vulnerability type:** Server-side request forgery - **Affected component:** `nltk.pathsec.urlopen`, `nltk.data.load`, `nltk.downloader.Downloader.index`, `nltk.downloader.Downloader.download` - **Affected versions:** Current source `v3.10.0-rc2`; published `3.9.4` was a negative control and did not reproduce. -

O3 Security · Impact-Aware SCA

Is GHSA-6ww7-3frv-cqxh in your dependencies?

Find it across PyPI, including transitive dependencies.

Scan my dependencies How O3 SCA works