Tenstorrent tt-metal: path traversal via the weight_map argument when loading transformer checkpoints

CVSS 2.1CVE-2026-113743NVIDIA / GPU stackcurated

Impact

In tt-metal up to 0.80.0, load_hf_state_dict_filtered in models/tt_transformers/tt/load_checkpoints.py uses the weight_map entries from a checkpoint without constraining them to the checkpoint directory, so a crafted weight map can make the loader open files elsewhere on the filesystem. On a host driving Tenstorrent accelerators, the process doing model loading usually has access to the device and to whatever credentials the serving or training job holds, so a checkpoint pulled from an untrusted source gets a read path outside its own directory. The record describes path traversal with low confidentiality, integrity and availability impact and requires user interaction, which fits the case where an operator or job loads a supplied checkpoint. Nothing in the record claims code execution.

Who can reach it

Anyone who can get a crafted checkpoint, including its weight_map, in front of a tt-metal model load - a tenant submitting a model, or a job fetching one from a public hub. No authentication to the host is needed beyond whatever is required to supply the checkpoint.

What to do

Upgrade tt-metal to 0.81.0-dev20261016 or later, which contains commit 4851ccf347f6903c3d819eed60705600386e52c3, and restart the jobs or serving processes that use it. Until then, only load checkpoints from sources you control and validate weight_map paths before handing them to the loader.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-113743 https://github.com/tenstorrent/tt-metal/commit/4851ccf347f6903c3d819eed60705600386e52c3 https://github.com/tenstorrent/tt-metal/pull/60634 https://github.com/tenstorrent/tt-metal/issues/59616

Related entries

All NVIDIA / GPU stack entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.