CVE-2026-34760: vLLM: Processing differential in multi-channel audio downmixing enables hidden-input/moderation bypass for audio models

Librosa's to_mono averages all channels with numpy.mean. The ITU-R BS.775-4 standard instead weights channels, and consumer playback ignores the low-frequency effects (LFE) channel and anything past the sixth channel. So the same file is heard one way by a person and read another way by a model.

An attacker builds a multichannel file where the front left and right channels carry harmless content, and the LFE channel, or channels beyond the sixth, carry interference or hidden content. On speakers or headphones that skip those channels, a listener hears the harmless audio. When vLLM downmixes with the mean, the hidden channel is mixed in and the audio model processes it.

The advisory lists these outcomes: voice authentication that accepts anomalous audio, content moderation that misses prohibited content, and speech recognition that gives wrong transcripts. The attack can go both ways: hidden instructions for an audio model that the human reviewer never hears.

The attacker needs to submit audio to a vLLM server that serves an audio model. The CVSS vector sets high attack complexity and low privileges. The impact is on integrity, rated high, with a low availability effect. This is not a crash or code execution bug. It is a mismatch between what is reviewed and what is processed.

The pip package vllm from 0.5.5 up to, but not including, 0.18.0. Servers serving audio-capable models and accepting audio input are the ones at risk. Text-only deployments are not affected in a way the advisory describes.

pip show vllm

If you run your own preprocessing with librosa before vLLM, the same mismatch applies there, as the librosa security report linked from the advisory covers it.

Upgrade to vLLM 0.18.0:

pip install --upgrade "vllm>=0.18.0"

The fix, pull request 37058, removes the librosa dependency from vLLM and loads audio with PyAV instead. The pull request page does not show which downmix method the new code uses, so test your audio pipeline against known multichannel samples after upgrading.

The advisory gives no workaround. If you cannot upgrade, do the downmix yourself before the audio reaches vLLM, using the ITU-R BS.775-4 weights, and reject files with more than two channels.

There is no log signature, since the request is valid. Look at stored uploads for multichannel files, especially 5.1 or larger layouts with a loud or speech-like LFE or rear channel. A script that splits channels and compares transcripts of the front pair against a plain average will show the difference.

Review moderation misses where the transcript differs from what reviewers heard. If you keep original files, replay them with the LFE channel muted and check whether the model output changes.

Issue Description

Librosa defaults to using numpy.mean for mono downmixing (to_mono), while the international standard ITU-R BS.775-4 specifies a weighted downmixing algorithm. This discrepancy results in:

• Inconsistency between audio heard by humans (e.g., through headphones/regular speakers) and audio processed by AI models (Which infra via Librosa, such as vllm, transformer).

https://github.com/librosa/librosa/blob/af8c839fb15317fa2712ea66e7a22da6a9267b32/librosa/core/audio.py#L478

Attack Scenario and Impact

LFE (Low-Frequency Effects) Channel Exploit

Attackers can craft special multichannel audio files containing:

1. Normal content in front channels (L/R)
2. Either interference signals or hidden content in the LFE channel

Notice: It is worth noting that not only the LFE channel is excluded, but in fact, channels beyond the 6th (such as rear surround channels, overhead channels, height speakers, etc.) are also not supported.

Attack Methodology:

Attackers can create specially engineered multichannel audio with LFE interference, where front channels (L/R) contain normal content while the LFE channel carries interference signals or hidden content. When played on consumer devices that ignore LFE channels, only the normal content is heard. However, when processed by AI systems using Librosa (which mixes all channels), the LFE interference affects speech recognition feature extraction or masks critical detection features. This enables malicious content to bypass AI detection while still reaching end users, potentially compromising voice authentication systems, evading content moderation, or disrupting speech recognition accuracy.

Potential Exploitation Scenarios:

• Voice authentication systems may be tricked into accepting anomalous audio
• Content moderation systems may fail to detect prohibited content hidden in LFE channels
• Speech recognition systems may produce incorrect transcriptions

Note: torch.audio implements this correctly. Failure to do so may lead to inconsistencies between training and test audio, resulting in performance degradation.

Resources

• ITU-R BS.775-4 Standard
• Librosa Source Code
• Librosa securty report

Fixes

• https://github.com/vllm-project/vllm/pull/37058, which removes the librosa dependency from vLLM.