Loading story…
Lightning AI patched an arbitrary code execution flaw in PyTorch Lightning's LightningModule.load_from_checkpoint path after researchers showed that a malicious checkpoint could abuse the _instantiator value stored in hyper_parameters. In affected versions through 2.6.5, the framework could import and invoke attacker-controlled Python targets during _load_state, allowing code execution when an untrusted checkpoint was loaded. The issue was tracked as CVE-2026-58659 and mapped to CWE-470, with reports noting that even torch.load(weights_only=True) did not prevent the vulnerable behavior.
The fix, merged in commit d710d689510d50e800f53b3cd773cbca20b1f86f, replaces unrestricted import resolution with an allowlist of trusted Lightning instantiator paths and raises an error for untrusted values. Project tests were added to confirm that malicious targets such as os.system are blocked while approved framework instantiators continue to function, closing a checkpoint-loading path that could otherwise let attackers weaponize shared or downloaded model artifacts.
Track how attackers are adapting to this technology.
2 events from the most recent confirmed update back to the earliest known activity.
Lightning AI merged pull request #21832 to fix the checkpoint-loading arbitrary code execution issue by limiting `_instantiator` to an allowlist of trusted import paths and rejecting untrusted values. The associated commit `d710d689510d50e800f53b3cd773cbca20b1f86f` implemented the code changes and tests blocking malicious targets such as `os.system`.
Lightning AI issue #21822 disclosed an arbitrary code execution vulnerability in Lightning/PyTorch Lightning v2.6 where an attacker-controlled `_instantiator` value in checkpoint hyperparameters could be imported and called during `LightningModule.load_from_checkpoint`. The report included a proof of concept and noted the behavior still occurred even with `torch.load(weights_only=True)` enabled.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
Follow how adversaries are adapting to this technology, and where it touches your stack today.
5 references tracked. Mallory keeps watching after this page renders.
vulncheck.com
Open sourcecvefeed.io
Open sourcegithub.com
Open sourcegithub.com
Open sourcegithub.com
Open sourceMap indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
Two widely used Python packages, **LiteLLM** and **PyTorch Lightning**, were distributed on PyPI with malicious code that executed during installation or import and attempted to steal credentials and establish persistence. In the LiteLLM incident, versions `1.82.7` and `1.82.8` were flagged as compromised, with maintainers and downstream projects warning that a `litellm_init.pth` file contained data-exfiltration malware that sent information to `models.litellm.cloud`. Public advisories and community tooling were released to help users determine whether their machines had been affected, while third-party analysis described the package as combining credential theft with a persistent backdoor. In the PyTorch Lightning incident, version `2.6.3` on PyPI was found to trigger a hidden execution chain as soon as the package was imported, launching a background process that downloaded the **Bun** runtime from GitHub and ran an obfuscated JavaScript payload named `router_runtime.js`. Microsoft Threat Intelligence said Defender detected and blocked the activity, tracked as **ShaiWorm**, and reported that only a small number of devices in a narrow set of environments were affected. The malware targeted browser data, `.env` files, API keys, GitHub tokens, and cloud credentials across **AWS**, **Azure**, and **GCP**, and also supported arbitrary command execution; Lightning AI reverted the package to `2.6.1`, urged anyone who imported `2.6.3` to rotate all secrets immediately, and said it is investigating a possible compromise of its build or release pipeline.
Jun 29, 2026
Multiple vulnerabilities in **LightLLM through version 1.2.0** expose reachable AI inference deployments to unauthenticated remote code execution (RCE) and operational disruption. Critical flaws tracked as `CVE-2026-103040`, `CVE-2026-103041`, and `CVE-2026-103395` involve unsafe pickle-backed deserialization in exposed RPyC services, including profiling and `visual_only` image-inference deployments. An attacker able to reach an affected RPyC port can submit crafted Python objects—such as one abusing `__reduce__`—and execute code with the privileges of the LightLLM service account. The profiling path requires `--enable_profiling`; the visual deployment issue affects the `remote_infer_images` method. Additional weaknesses permit unauthenticated denial-of-service and inference disruption. `CVE-2026-103042` can exhaust memory through the NCCL control channel, while `CVE-2026-103270` exposes reinforcement-learning control endpoints when LightLLM runs with `--enable_rl`, allowing remote callers to pause generation, abort requests, flush caches, initialize weight-update groups, and potentially wedge workers. No public exploitation, known victims, or CISA KEV listing had been reported. Organizations should disable profiling, RPyC, and RL features where unnecessary; restrict all related service and dynamically assigned profiler ports to trusted networks; apply vendor fixes when available; review potentially exposed instances; and rotate credentials accessible to inference processes.
Oct 2, 2026
A critical remote code execution flaw tracked as **CVE-2026-68771** affects **ComfyUI v0.23.0** through unsafe deserialization in the `LoadTrainingDataset` node. An attacker can reportedly upload a crafted pickle file to the unauthenticated `POST /upload/image` endpoint and then trigger deserialization through `POST /prompt`, causing `torch.load` to process an attacker-controlled `shard_*.pkl` file. Because Python pickle deserialization can invoke arbitrary code via mechanisms such as `__reduce__`, successful exploitation can lead to command execution with the privileges of the ComfyUI process. A related ComfyUI code change shows the project hardened dataset shard loading by replacing `torch.load(f)` with `torch.load(f, weights_only=True)` in `comfy_extras/nodes_dataset.py`, limiting deserialization to weights-only data and reducing exposure to malicious serialized objects. Reported mitigations include upgrading to a version that incorporates the safer loading behavior, avoiding untrusted pickle files, and reviewing node security settings on exposed deployments.
Aug 1, 2026