Updated October 8, 2026: lightning 2.6.6, released September 10, 2026, fixes CVE-2026-58659, and a fresh install of these models now resolves to it. This post first said no fix had shipped; it now describes the exposure window, July 15 to September 10. Download and model counts now carry dates, and the timeline shows when we connected the advisory to these models. The companion case study also drops two verdict-card signals that were our own false positives.
From July 15 to September 10, 2026, a fresh pip install pyannote-audio resolved lightning to 2.6.5, affected by CVE-2026-58659 (GHSA-qqmf-gpg7-g8gw, CVSS 3.1 7.8). A crafted checkpoint executes code on load. Lightning 2.6.6 fixes it, and a fresh install now resolves to it. If you pinned lightning, or built an environment in that window, upgrade to 2.6.6 or later, and keep treating third-party checkpoints as untrusted input.
Summary
- What: from July 15 to September 10, 2026, eight pyannote models we watched on Hugging Face (about 26.6 million downloads in the 30 days to October 8, 2026) inherited a HIGH remote code execution through
pyannote-audio, which pinslightning>=2.4with no ceiling. Lightning 2.6.6 fixed it on September 10. - Why it matters: the models never name lightning, and neither does any tool that stops at the manifest. The declared surface is clean; the installed surface is not.
- What to do: upgrade lightning to 2.6.6 or later wherever it is pinned; load checkpoints only from sources you control, in isolation; if you publish a package, put a ceiling on floor-only pins.
What happened
Speaker diarization is the layer under call transcription, meeting notes and compliance recording: who spoke, and when. pyannote's models are a default choice. Each names one Python package, pyannote-audio, as its library, and its current release, 4.0.7 (June 30, 2026), is clean by every advisory we hold. One of them, speaker-diarization-3.1, also ships a requirements.txt pinning pyannote-audio==3.1.1, whose own floor, lightning>=2.0.1, is just as open.
On July 15, 2026 GitHub published GHSA-qqmf-gpg7-g8gw, CVE-2026-58659, against PyTorch Lightning, and on September 3 reviewed it and mapped it to the lightning package on PyPI. The _load_state routine imports and executes whatever module name a checkpoint's _instantiator hyperparameter points at. Every release before 2.6.6 is affected, up to and including 2.6.5, the current release until September 10. pyannote-audio requires lightning>=2.4, a floor with no ceiling, so until then a fresh install landed on the vulnerable version. On September 10, 2026 Lightning shipped the fix (commit d710d68) in 2.6.6, and a fresh install resolves to it now.
The package you named is clean. The one it pulled was not. A manifest cannot tell you the difference.
The models never name lightning, and pyannote-audio has no advisory against it. A scanner that reads requirements files and stops there reports eight clean models. That is the boundary of what a manifest can tell you, not a bug in those tools.
The attack chain
pyannote-audio 4.0.7 releases with lightning>=2.4. Checked alone, it fires no signal.
GHSA-qqmf-gpg7-g8gw: a checkpoint's hyperparameters can name a module that lightning imports and runs on load.
No upper bound, so until September 10 every fresh install resolved lightning to 2.6.5, which the advisory covers.
A colleague passes along a fine-tuned checkpoint that works better on our accents. Checkpoints are files; people trade them.
The pipeline loads the checkpoint through lightning. _load_state imports the module the file names. Code executes with the pipeline's privileges.
Around September 6, three days after GitHub mapped the advisory to the lightning package, CyberXYZ connected it to these models by resolving each to the whole install. The path from a pyannote model through pyannote-audio to lightning 2.6.5 is depth one, required, version-confirmed. Eight models moved from CLEAN to HIGH, with the reason recorded.
Lightning releases 2.6.6 on September 10. A fresh install resolves to it, and our data rates the eight models CLEAN again. Environments that pinned or cached an older lightning stay exposed until upgraded.
Indicators
| Type | Indicator | Context |
|---|---|---|
| Package | lightning < 2.6.6 | Every release up to and including 2.6.5; fixed in 2.6.6, released September 10, 2026 |
| Advisory | GHSA-qqmf-gpg7-g8gw | CVE-2026-58659, CVSS 3.1 7.8, CWE-470 unsafe reflection |
| Sink | lightning._load_state | Imports the module named in a checkpoint's _instantiator hyperparameter |
| Carrier | *.ckpt / *.pt | Any checkpoint whose hyperparameters carry a module path outside Lightning's own namespaces |
| Pin | lightning>=2.4 | Declared by pyannote-audio 4.0.7 (3.1.1, pinned by speaker-diarization-3.1, declares lightning>=2.0.1); both admit the vulnerable releases |
| Models | pyannote/* | speaker-diarization-3.1, wespeaker-voxceleb-resnet34-LM, segmentation-3.0, speaker-diarization-community-1, segmentation, voice-activity-detection, embedding, speaker-diarization (the eight we watched on September 7, 2026; three more added September 9 rated the same) |
No hashes or hosts are listed because none were observed in an attack. These indicators describe the exposure, not an intrusion.
MITRE mapping
On MITRE ATLAS, the matrix for attacks on AI systems, this is a supply-chain compromise of the model artifact that ends in a user executing an unsafe artifact. On ATT&CK it is a software-dependency compromise triggered by a malicious file.
How CyberXYZ sees it
We do not stop at the manifest. Every watched model is resolved to its transitive closure at the versions that install today, and each reachable package is checked against advisories only when the resolved version is in range and the path is required. Asked about pyannote-audio@4.0.7 alone, the engine fires nothing. Asked about lightning@2.6.5, it answers alert, advisory XYZ score 4.2, with the advisory named and 2.6.6 suggested instead. From around September 6 the fleet view rated the eight pyannote models HIGH under one attack vector, vulnerable by inheritance, and eleven by September 9. Since 2.6.6 shipped, every pyannote model we watch resolves lightning to the fixed release, and the eight read CLEAN again. CyberXYZ did not discover this vulnerability: GitHub published the advisory. What we added is the connection between that advisory and these models, through the install they actually resolve. The full step-by-step, with the platform's own verdict card, is in the case study.
Recommended actions
Upgrade lightning to 2.6.6 or later wherever it is pinned or cached below that, or add lightning>=2.6.6 as a constraint until pyannote-audio raises its floor. Inventory environments built between July 15 and September 10, 2026 that load checkpoints from outside your control. Load third-party checkpoints only in isolation. Inspect _instantiator values in checkpoint hyperparameters; anything outside lightning.* or pytorch_lightning.* is suspect.
Short term: the fixed release has shipped, so constrain lightning to 2.6.6 or later in lockfiles and images. Long term: resolve your models to the whole install, not the manifest, and ask package maintainers to put ceilings on floor-only pins.
References
- GitHub Security Advisory, GHSA-qqmf-gpg7-g8gw
- NIST NVD, CVE-2026-58659
- OSV, GHSA-qqmf-gpg7-g8gw (fixed in 2.6.6)
- Lightning, release 2.6.6 (September 10, 2026), the fixed release
- MITRE ATLAS, AML.T0010.003 and AML.T0011.000
- MITRE ATT&CK, T1195.001
- CyberXYZ, Case study: pyannote and the package it never named