vLLM CVE-2026-114053: include processor loading in your inference review

Sources checked: 2 November 2026. FailSafe Research.

An inference server's security boundary includes the code it loads to process requests. vLLM advisory GHSA-h3rc-6mm3-gc2m describes a conditional path where a multimodal request can influence the revision of processor code. Pinning model data is therefore only part of the deployment review.

Establish whether the conditions apply

The maintainer lists affected versions from 0.7.3 up to, but excluding, 0.31.0. The described configuration involves dynamic processor code, enabled remote-code trust and other conditions specified in the advisory. The default remote-code-trust setting is not affected by this particular path.

Record the running serving package, processor type, trust configuration and artifact sources before making an exposure decision. A business owner needs an applicability statement supported by deployment evidence, not a blanket assertion that every vLLM service is compromised.

Map the supporting service surface

Inventory auxiliary request paths, proxies, authentication enforcement and worker permissions alongside the familiar inference API. A protected application gateway may not represent every route to the serving process. Confirm the deployed architecture rather than assuming an API-key setting covers every reachable interface.

Keep this review within an authorized environment. An assessment can examine configuration and use benign test artifacts without importing unknown code or writing a public exploitation recipe.

Treat code provenance as a runtime control

Ask which exact processor artifact is permitted to execute, who approved it and what happens when a request conflicts with that decision. Review cached artifacts as well as fresh downloads. Removing internet access does not establish that every previously cached artifact is appropriate.

The acceptance evidence should connect an approved artifact to the code actually used by the worker. A repository's display name and the model's marketing name are insufficient identifiers for that purpose.

Validate the corrected deployment

Follow the maintainer's remediation and confirm the replacement reaches every relevant instance. Then verify allowed inference behavior and the intended loading restrictions using synthetic requests. Preserve the release identifiers, configuration decision and observed result.

For FailSafe, owning inference includes reviewing the serving boundary, not merely selecting a hosting country. A customer-operated deployment still needs access control, approved updates and artifact review. Discuss inference-stack testing as an explicit part of an AI security assessment; a standard application test does not automatically cover every serving component.

A deployment owner’s evidence pack

• Running package and processor identifiers.
• The remote-code trust decision and artifact approval.
• The reachable serving interfaces and enforcing controls.
• The completed change and benign acceptance-test results.

Source review, 2 November 2026: vLLM maintainer advisory GHSA-h3rc-6mm3-gc2m. This is conditional exposure analysis, not a claim of observed exploitation.