GHSA-pv39-qrfq-g8gc
Duplicate Advisory: NLTK: Missing Post-Download Integrity Verification Allows Malicious Package Injection
- Severity
- 5.3 / 10
- Medium · CVSS 3.0
- Exploit chance (EPSS)
- —
- No score published
- Known exploited
- No
- Not in CISA's catalog
- Weakness
- CWE-494 Download of Code Without Integrity Check
- Fix
- None yet
- No fixed version published
Description
Duplicate Advisory
This advisory has been withdrawn because it is a duplicate of GHSA-5wp5-5229-5g6q. This link is maintained to preserve external references.
Original Description
In nltk version 3.9.4, the nltk.downloader.Downloader._download_package() function writes downloaded package bytes to disk and may extract them before enforcing SHA-256 or MD5 checksum validation. This allows an attacker to tamper with the package response body for info.url through a compromised mirror, malicious proxy, or other source-substitution condition, leading to the installation of attacker-controlled package bytes. The vulnerability can result in malicious corpus or model content being trusted by downstream users or applications.
Affected versions
PyPI
| Package | Vulnerable | Fixed in |
|---|---|---|
| nltk | <= 3.9.2 |
No fix yet |
How to fix
No fixed version has been published yet. Until one is, remove or replace the package, or turn off or isolate the affected feature. This page updates when a fix ships.
Severity breakdown
CVSS 3.0 5.3
CVSS:3.0/AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:H/A:N
- Attack vector
- Network
- Attack complexity
- High
- Privileges required
- None
- User interaction
- Required
- Scope
- Unchanged
- Confidentiality
- None
- Integrity
- High
- Availability
- None
Weakness
CWE-494: Download of Code Without Integrity Check
The product downloads source code or an executable from a remote location and executes the code without sufficiently verifying the origin and integrity of the code.
How to prevent it
- Implementation: Perform proper forward and reverse DNS lookups to detect DNS spoofing.
- Architecture and Design, Operation: Encrypt the code with a reliable encryption scheme before transmitting. This will only be a partial solution, since it will not detect DNS spoofing and it will not prevent your code from being modified on the hosting site.
- Architecture and Design: Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid [REF-1482]. Speficially, it may be helpful to use tools or frameworks to perform integrity checking on the transmitted code. When providing the code that is to be downloaded, such as for automatic updates of the software, then use cryptographic signatures for the code and modify the download clients to verify the signatures. Ensure that the implementation does not contain CWE-295, CWE-320, CWE-347, and related weaknesses. Use code signing technologies such as Authenticode. See references [REF-454] [REF-455] [REF-456].
- Architecture and Design, Operation: Run your code using the lowest privileges that are required to accomplish the necessary tasks [REF-76]. If possible, create isolated accounts with limited privileges that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations.
- Architecture and Design, Operation: Run the code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which files can be accessed in a particular directory or which commands can be executed by the software. OS-level examples include the Unix chroot jail, AppArmor, and SELinux. In general, managed code may provide some protection. For example, java.io.FilePermission in the Java SecurityManager allows the software to specify restrictions on file operations. This may not be a feasible solution, and it only limits the impact to the operating system; the rest of the application may still be subject to compromise. Be careful to avoid CWE-243 and other weaknesses related to jails.
References
Advisories
Other links
Timeline
- Published
- Withdrawn
- Last updated by the source
Related advisories
| Advisory | Severity | Why it's related |
|---|---|---|
| GHSA-j456-xh4h-cpf2 NLTK: WekaClassifier passes an unvalidated caller-controlled model path to the weka JVM, bypassing nltk.pathsec containment | High | Also affects nltk |
| GHSA-ff5c-cp5c-9wjf NLTK: Uncontrolled resource consumption in RecursiveDescentParser via ambiguous or left-recursive grammars | Medium | Also affects nltk |
| GHSA-f794-5jv7-7672 NLTK: Downloader.download follows hardlinks and overwrites outside-root files | High | Also affects nltk |
| GHSA-8mgp-746c-j5xp NLTK: Model-artifact APIs bypass pathsec and touch files outside allowed roots | High | Also affects nltk |
| GHSA-8mpw-7fpc-4gqj NLTK: Pl196xCorpusReader has quadratic ReDoS on malformed TEI blocks | Low | Also affects nltk |
| GHSA-cw6x-m8jw-qmrh NLTK: Uncontrolled recursion in nltk.featstruct.FeatStructReader causes unhandled RecursionError (DoS) via deeply nested feature-structure input | Medium | Also affects nltk |
| GHSA-vp2x-qp44-57v7 NLTK: Quadratic CPU Exhaustion in `XMLCorpusView._read_xml_fragment()` | Low | Also affects nltk |
| GHSA-ww6m-cw3f-q94g NLTK: Quadratic-time DoS in PorterStemmer via long runs of 'y' | High | Also affects nltk |
MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.
Check your repos with MergeHarbor