Tensorizer .tensors dtype-validation PoC (huntr responsible disclosure)
This repository contains a proof-of-concept model file for a responsible security disclosure submitted to huntr regarding coreweave/tensorizer.
Access is gated with manual review so the crafted file is not freely
downloadable. It is shared with protectai-bot for huntr triage.
What this is
malicious_tensor.tensors (222 bytes) is a minimal, hand-constructed
Tensorizer file whose tensor header declares dtype="O" (numpy object
dtype). Every other byte is produced by Tensorizer's own serialization
classes, so the file is structurally legitimate.
Loading it causes Tensorizer to construct a numpy object-dtype array over
raw file bytes, meaning attacker-controlled bytes are treated as
PyObject* pointers. numpy.frombuffer refuses this exact operation by
design; Tensorizer reaches around that guard via the low-level
numpy.ndarray.__new__ path.
Scope of the claim
This is reported as a latent memory-safety / defense-in-depth defect, not
a working RCE. All public deserialization paths currently funnel through
to_tensor() → torch.from_numpy(), which rejects object dtype before the
array reaches a caller. That containment is incidental (it lives in PyTorch,
not Tensorizer) rather than a designed validation step.
The constructed array is nonetheless genuinely unsafe: accessing an element
of it segfaults (SIGSEGV), demonstrated in verify_gc_claim.py.
Files
| File | Purpose |
|---|---|
malicious_tensor.tensors |
The 222-byte PoC file |
build_tensorizer_poc.py |
Builds the PoC from scratch; --load runs it in a resource-bounded subprocess |
verify_gc_claim.py |
Three-stage isolated-subprocess probe (metadata / GC / element access) that produced the SIGSEGV evidence |
Safety
The payload is a repeating 0x41 pattern — a non-canonical, unmapped
address, chosen so that a genuine dereference faults rather than
corrupting anything real. The file performs no I/O, spawns nothing, and
contains no executable payload. It is a crash-reproduction artifact.