NLTK model-artifact APIs bypass the pathsec sandbox

NLTK through 3.10.3 contains a path traversal vulnerability in model-artifact APIs that bypass pathsec enforcement by using raw file operations on caller-controlled paths. Attackers can read or write files outside allowed sandbox roots through TransitionParser, AveragedPerceptron, PerceptronTagger, and maxent parameter APIs when pathsec is enabled.

• nltk package: the normalized record identifies versions from 0 through 3.10.3, inclusive, as affected under semver; the supplied default status is unaffected outside that affected range.
• The vendor advisory reproduced the issue in 3.9.4 and source v3.10.0-rc2. These are reproduced examples, not a complete safe boundary.
• The GitHub advisory lists no patched versions. The normalized record marks patch_available as true, but it supplies no exact fixed release; later or parallel branches remain unverified.

NLTK model import and export helpers accept caller-controlled paths but use raw file operations instead of pathsec-aware helpers. This is a CWE-73 flaw because externally controlled names or paths reach filesystem operations without being properly confined to the sandbox. The documented affected flows include TransitionParser.train, TransitionParser.parse, AveragedPerceptron.save, AveragedPerceptron.load, PerceptronTagger.save_to_json, and save_maxent_params. When pathsec enforcement is enabled and an untrusted workflow can choose model import or export paths, an attacker can direct these APIs to locations outside approved roots; published testing showed that reads and writes succeeded where guarded helpers rejected the same paths. The filesystem operation runs with the permissions of the NLTK process. The available evidence does not define every deployment interface that can expose these APIs, nor does it establish additional path normalization or symlink behavior for every deployment.

• Reachability: The record classifies the attack as network-reachable. The vulnerable file operation runs in the NLTK host process, so remote triggering depends on an application exposing model path selection or an equivalent workflow input.
• Preconditions: pathsec must be enabled, and an untrusted workflow must be allowed to choose model import or export paths.
• Authentication and interaction: The supplied metrics indicate that no prior privileges and no separate user interaction are required.
• Complexity: The record characterizes attack complexity as high and identifies a deployment-specific attack requirement.
• Known status: A public proof of concept is documented in the advisory, and the normalized record marks a public exploit as available. This entry does not infer a specific campaign or victim.

The primary technical outcome is a sandbox bypass for file reads and writes. A read can disclose data available to the NLTK process; a write can alter or corrupt files and may disrupt service if critical files are targeted. The supplied metrics indicate that no prior privilege or separate user interaction is required, but exploitation still depends on pathsec being enabled and an attacker-controlled workflow path. The process’s operating-system permissions limit reachable files. The available evidence does not establish impact to other systems.

Successful exploitation can expose files readable by the NLTK process outside the approved sandbox. It can also overwrite or corrupt files that the process can write, potentially affecting model artifacts, data, or service operation depending on the selected path. The practical consequence depends on the process’s filesystem permissions and on how much control the application gives untrusted workflows over model paths. Any broader consequence depends on the files reachable from that process and is not established by the available evidence.

1. Apply the official NLTK fix when a release explicitly addressing this issue is available. The normalized record marks a patch as available, but the inspected advisory lists no patched version; do not assume that an unverified later release is fixed.
2. For maintainers or downstream forks, route all model-path file access through nltk.pathsec.open() or existing pathsec-aware helpers, and add regression tests pairing each affected API with a guarded negative control on the same outside-root path.
3. Until a fixed release is confirmed, prevent untrusted workflows from selecting model import or export paths, or isolate the NLTK process so its filesystem permissions exclude sensitive files. Do not rely on pathsec alone to protect the affected APIs.

• Inventory NLTK installations and compare their versions with the affected boundaries listed in affected_summary.
• Identify deployments that enable pathsec and allow untrusted workflows to provide model import or export paths.
• Review source code or call graphs for TransitionParser.train, TransitionParser.parse, AveragedPerceptron.save, AveragedPerceptron.load, PerceptronTagger.save_to_json, and save_maxent_params, then determine whether their path arguments can be influenced by external input.
• In an isolated environment, use disposable non-sensitive files to confirm that guarded helpers reject paths outside the approved root and to compare the behavior of the corresponding model APIs. Do not test against system files or production data.
• Review filesystem audit logs or telemetry for the NLTK process accessing paths outside approved roots. This is precautionary monitoring, not a confirmed indicator of compromise.
• These checks establish exposure conditions; they do not by themselves prove that exploitation occurred.