x.com/elon_lit/status/2112957586886860880

The linked writeup’s threat model is: install an untrusted package, import its regularizer, and call it inside your training loop. In that setup, the attacker already has their code executing inside your process.

PyTorch’s maintainers explicitly say this category is not a PyTorch security vulnerability:

• PyTorch is "a framework that executes user-provided code, including model definitions, custom operators, and training scripts."
• "An attacker who already has the ability to execute arbitrary code locally ... does not gain any additional capability by exploiting PyTorch."
• They also say that the topics under "Using PyTorch Securely" are not considered vulnerabilities of PyTorch, and recommend being careful about where Python code comes from and to "do not run any pip installed package" unless you trust it.

That directly contradicts calling this a "zero-day in PyTorch autograd." The ability of a third-party loss/regularizer package to run code during training is part of PyTorch’s normal execution model, not a newly discovered autograd vulnerability.

PyTorch’s own operator-extension docs reinforce this: third-party libraries can wrap arbitrary Python functions as custom operators and add training support to them. So a loss term performing arbitrary computation is expected framework behavior when you run untrusted extension code.

In short: the post describes a stealthy way an untrusted dependency could hide behavior inside training, but mislabels that as a PyTorch autograd "zero-day."