Summary
NVIDIA NeMo contains an unsafe deserialization vulnerability in the TabularTokenizer class, which loads attacker-controlled pickle files without adequate validation. If an attacker can place or influence the .pkl file processed by the tokenizer, successful exploitation may enable code execution, data tampering, denial of service, or information disclosure.
Affected context
The vulnerability occurs in NVIDIA NeMo deployments that use the TabularTokenizer class to process serialized .pkl files. Risk is present when a pickle file can be supplied, replaced, or otherwise influenced by an untrusted party before it is passed to the deserialization routine, particularly where the processing environment has meaningful permissions or access to sensitive data.
Exploit preconditions
- Attack surface: TabularTokenizer processing of serialized
.pklfiles - Required access: Ability to provide, replace, or influence the pickle file consumed by the application
- Trigger point: Invocation of
pickle.load()while loading the tokenizer data - Why exploitation is possible: Python pickle deserialization can reconstruct objects and invoke behavior encoded in the serialized data, rather than treating the file as passive data
Why this happens
The underlying issue is the use of Python's general-purpose pickle deserialization on attacker-controlled input without sufficient trust enforcement or validation. Pickle can encode object reconstruction behavior that executes during loading, so treating an untrusted .pkl file as a data-only format creates an unsafe deserialization condition mapped to CWE-502: Deserialization of Untrusted Data.
Potential impact
- An attacker may execute code with the privileges of the NeMo process
- Sensitive files, environment data, or model-related information could be disclosed
- Application or serialized data could be tampered with
- Processing may fail or become unavailable, causing denial of service
- A compromised process could be used to affect connected systems or shared resources
General mitigation guidance
Mitigation generally focuses on eliminating unsafe deserialization of untrusted files and reducing the trust placed in serialized artifacts.
Common defensive patterns include:
- Prefer data-only formats with non-executable parsing semantics over general-purpose object serialization
- Use restricted, integrity-checked loading mechanisms when serialized artifacts are unavoidable
- Authenticate and verify the provenance and integrity of tokenizer files before processing them
- Store model and tokenizer artifacts in locations that untrusted users or processes cannot modify
- Run preprocessing and tokenization workloads with least-privilege identities and isolated filesystem and network access
- Apply strict file-type, schema, and content validation before parsing
How teams detect issues like this
Organizations can identify similar weaknesses through:
- Static analysis rules for
pickle.load,pickle.loads, and related deserialization APIs applied to untrusted or externally sourced data - Code review checks that trace serialized files from upload, download, cache, or shared-storage boundaries to deserialization calls
- Dependency and policy rules that prohibit unrestricted pickle loading in production paths
- Runtime monitoring for unexpected file replacements, deserialization failures, or child-process activity during tokenizer operations
- Automated security review tools that flag unsafe serialization patterns and missing integrity checks
