Detecting Vulnerable Python Dependencies: A Real NLTK Security Scan

A Python project can work as expected while using a dependency with publicly documented security vulnerabilities. A successful application run does not establish that its installed packages are secure.

In October 2026, we tested LegacyFixer against an intentionally vulnerable version of nltk, the Natural Language Toolkit. The test asked whether the scanner could identify known advisories, preserve the reported fixed versions, and leave the repository unchanged.

We then checked the advisories against the upstream Python vulnerability database and independently audited the newer NLTK 3.10.4 release.

The 2026 NLTK security context

During 2026, multiple security advisories affected NLTK components, including file and resource handling, deserialization, and potentially expensive parsing operations. The scope of an individual advisory matters: an issue in one component does not imply that every NLTK application exercises the vulnerable path.

For example, CVE-2026-79674 / PYSEC-2026-3736 concerns a bypass of file-access restrictions in corpus-reader handling. Its upstream advisory identifies NLTK 3.10.3 as the fixed version. This is one of the identifiers found in the controlled scan.

The purpose of this guide is not to reproduce or exploit those vulnerabilities. It is to document how known advisory evidence travels from a pinned dependency to a human-readable security report.

The controlled LegacyFixer repository

The test used the GitHub repository Dom-33/legacyfixer-guides-test. Its dependency manifest pinned the vulnerable package explicitly:

nltk==3.10.2

The repository was connected to LegacyFixer with optional fix pull requests disabled. That distinction is essential: this test evaluated detection and reporting, not an automated upgrade or pull request.

What the actual scan reported

On October 22, 2026, scan #205 completed successfully in 56 seconds. Its classification was success / NO_ACTION / passive_findings.

The report recorded 30 vulnerability entries across 1 affected package. After deduplicating repeated log entries, it displayed 17 distinct PYSEC identifiers for nltk==3.10.2. For each of those 17 identifiers, the auditor's recorded fix version was 3.10.3.

The 17 distinct advisory identifiers from scan #205 are reproduced below as an accessible HTML table rather than an image of the report.

The 30 entries are not evidence of 30 distinct vulnerabilities. The report explicitly deduplicated the logged package/version/advisory combinations.

Checking the advisory evidence upstream

A scan result is stronger when its identifiers can be reconciled with an independent advisory source. We checked each of the 17 PYSEC IDs displayed for NLTK against the PyPA Advisory Database.

All 17 records identified 3.10.3 as the fixed version for their respective advisories. For example, the source records for PYSEC-2026-3736 and PYSEC-2026-3867 include the same fixed version reported by LegacyFixer.

A fixed version is advisory-specific. It does not establish that the release is free of other vulnerabilities, including issues disclosed later.

Why we also checked NLTK 3.10.4

The official NLTK 3.10.4 release was published on October 21, 2026, after the versions referenced by the tested advisories. Its release notes describe further security hardening, including safeguards around paths, deserialization, and potentially expensive input processing.

It would therefore be misleading to recommend 3.10.3 as the universally best upgrade solely because that version appears in the scan report. We performed a separate audit of the newer release.

Independent audit of NLTK 3.10.4

On October 22, 2026, we used pip-audit 2.10.1 to check the pinned NLTK 3.10.4 package without installing it and without including its transitive dependencies. The input contained:

nltk==3.10.4

The audit used the following options:

python -m pip_audit -r /tmp/legacyfixer-nltk-3104-audit.txt   --no-deps --disable-pip --progress-spinner off

The result was:

No known vulnerabilities found

This means that the vulnerability database consulted by pip-audit did not report a known vulnerability for nltk==3.10.4 in this specific check. It does not guarantee the absence of undisclosed issues or vulnerabilities in other installed packages.

The standalone NLTK 3.10.4 check and the LegacyFixer repository scan are related, but they are not identical end-to-end tests. In particular, --no-deps deliberately excludes transitive dependencies.

What the experiment demonstrates — and what it does not

The controlled scan demonstrates that the production LegacyFixer detect-only path identified documented NLTK advisories, preserved package and advisory evidence, and displayed fixed versions provided by its auditor. It finished without changing repository files or creating a pull request.

The independent NLTK 3.10.4 audit adds evidence about a newer package release, but it was not a validation of compatibility with an existing application. We did not upgrade or run application tests in the repository as part of this guide.

Nor does an absence of known findings prove that a dependency or a complete application is secure. Findings depend on the database, its update state, package coverage, and the dependencies selected for analysis.

Detection first, remediation after verification

This example shows a practical sequence for dependency security: identify the current dependency version, review the advisory evidence, check an appropriate newer release, and verify compatibility before applying an update.

LegacyFixer can keep the first stage separate from repository modification. In this test, the scan provided actionable information without automatically producing a branch or pull request.

First verify the signal. Then decide how the dependency should change.

Sources and verification

• NLTK 3.10.4 — official release
• NLTK on PyPI
• PyPA Advisory Database — NLTK advisories
• CVE-2026-79674 / PYSEC-2026-3736
• pip-audit — project documentation

Verification date: October 22, 2026. Security advisory databases and package releases change over time; repeat the audit before making a production upgrade decision.