The vulnerability in NLTKY's AllowlistUnpickler exposes a fundamental weakness in module-name allowlisting: checking only that a module string matches an approved list does not prevent attribute traversal chains from reaching dangerous callables. An attacker can specify something like 'os.path.join' or chain through subclasses — the module string passes inspection while the final resolved object executes arbitrary code. The allowlist treats 'which module' as equivalent to 'what is safe,' but dotted names resolve dynamically through attribute traversal, not by string matching against a list.
The attack surface is model loading via TransitionParser.parse and allowlisted_pickle_load. Exploitation requires a target to load a crafted transition-parser model file, which narrows the path compared to direct network RCE but is far from theoretical in practice. ML pipelines increasingly download models from repositories, share checkpoints across teams, and process user-submitted model artifacts. Compromising a model checkpoint in a shared model zoo or HuggingFace dataset gives an attacker leverage over every downstream consumer who loads it — the CVSS 8.8 scores a single system, not a dependency-graph failure.
This specific bypass was documented in Python security research as early as 2011-2012. The fact that it appeared in NLTK in 2025 reflects a knowledge propagation failure in the open-source ecosystem — past bypasses aren't reaching the developers who need them when they're adding new allowlists. More fundamentally, module-name allowlisting creates false confidence rather than real security. Until the ecosystem provides safe serialization alternatives, these bypasses will keep appearing. For defenders: validate the final resolved object, not just the module string; treat model-loading from external sources as a legitimate attack vector; and assume allowlist-based pickle protections will be bypassed unless the full name resolution path is controlled.