HOL LogoGuard

Explore HOL

  • HOL home
  • AI agent registry
  • AI plugins
  • Open standards
  • HOL members
  • Sponsor HOL
  • Advertise with HOL

Guard product

  • Guard overviewLocal security and control for AI agents and the tools they use.
  • FeaturesRuntime protection, policy routing, review, and evidence.

Explore Guard

  • Product previewWalk through Guard surfaces in read-only demo mode.
  • ComparisonCompare Guard with native controls and AI security vendors.

AI tools

  • All AI toolsEvery supported AI tool and how Guard applies policy to it.
  • Codex
  • Claude Code
  • Cursor
  • Antigravity CLI
  • OpenCode
  • Hermes
  • OpenClaw
  • GitHub Copilot CLI
  • Antigravity
  • Kimi
  • Grok
  • Pi / Oh My Pi
  • Zcode

Extensions

  • All extensionsBrowse command and MCP coverage with owners and stated limits.
  • Command coverageShell command protection across clouds, databases, backups, and packages.
  • MCP server coverageSee how Guard maps risk state across MCP tools and servers.
  • Core safetyThe safety floor listings that ship with Guard.
  • Data and resilienceBackup and storage command protection.
  • Cloud and infrastructureAWS, Azure, GCP, Kubernetes, and more.

Security

  • AI security hubSecurity research, advisories, and agent safety coverage.
  • AI tool securitySecurity profiles for each supported coding agent.
  • Safe labsHands-on attack simulations with safe boundaries.
  • Redacted warningsReal blocked actions with sensitive details removed.
  • AdvisoriesCoordinated disclosure reports for AI tooling.
  • Active CVEsSearch active CVEs affecting AI tooling.

Learn

  • Security guidesPractical guides for securing AI agent workflows.
  • DocsInstall, configure, and operate Guard with confidence.
  • ResearchPublished security research, benchmarks, and methodology.

Community

  • ReleasesVersion history, shipped changes and upgrade notes.
  • ContributorsThe people and contributions behind HOL Guard.
  • AffiliatesShare Guard with your audience and earn from referrals.
  • SponsorFund agreed research, implementation and shared testing through the HOL Partner Program.
  • AdvertiseCompare README logo placements, previews and monthly prices, or promote a plugin or extension.
PricingEnterpriseOpen AppInstall Guard
  1. Guard
  2. Security
  3. CVEs
  4. CVE 2026 47155 vllms artifact pin decay allows pinned
HOL Guard

Public security guidance for teams protecting AI harnesses, MCP servers, skills, prompts, and local tool execution.

Install Guard

AI Security

  • Prompt injection
  • MCP security
  • OWASP MCP mapping
  • Supply chain

Resources

  • Trust packet
  • Harness setup
  • Redacted warnings
  • Safe labs

Product

  • Install Guard
  • Pricing
  • Open dashboard
Guard
  • Guard Overview
  • Releases
  • Contributors
  • Install Guard
  • Pricing
Docs
  • Documentation Index
  • Developer Hub
  • API Reference
  • Root OpenAPI
  • Registry OpenAPI
  • Run in Postman
  • Standards
  • Submit ERC-8004 Contract
  • Feature Your Agent
Best Plugins
  • Browse Plugins
  • Plugin Launches
  • Best Claude Plugins
  • Best Codex Plugins
  • Best Grok Plugins
  • Best Kimi Plugins
  • Best DeepSeek Plugins
  • Best Antigravity Plugins
  • Best MCP Servers
  • Best Cursor Plugins
  • Best OpenCode Plugins
Best Agents
  • Best ERC-8004 Agents
  • Best Virtuals Agents
  • Best MCP Servers
  • Best A2A Agents
  • Best x402 Payable
  • All Categories
Community
  • Telegram
  • X
More
  • About HOL
  • Sponsor
  • Advertise
  • Affiliate program
  • Contact
  • Blog
  • GitHub
  • Privacy
  • Terms of Service
Settings

Copyright © 2026 HOL DAO LLC. All rights reserved.

Back to active CVEs
Medium · CVSS 6.5CVE-2026-47155GHSA-3WW4-5JV9-J5GM

vLLM's Artifact Pin Decay allows pinned deployments to load unpinned code, weights, and processorsCVE-2026-47155

Answer in brief

CVE-2026-47155 records a Medium severity (CVSS 6.5) vulnerability in vLLM's Artifact Pin Decay allows pinned deployments to load unpinned code, weights, and processors. The current sources do not mark it as known exploited. The current feed maps vllm (pip), vllm (pypi). Check affected ranges and fixed versions before updating.

Analysis pending evidence review

HOL Guard separates source facts from reviewed analysis. See the methodology.

Published Jun 10, 2026Updated Oct 25, 2026Source checked Nov 1, 2026First seen by HOL Jun 11, 2026Material review Oct 25, 2026
Upstream Advisory

Key facts

Risk
Medium · CVSS 6.5
Exploitation
Not marked as known exploited
Affected software
3 mapped packages or products
Fix availability
Available

Why this deserves its current priority

CVSS is 6.5. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.

Analysis status

Analysis pending evidence review

Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.

Affected scope and exposure questions

The current feed maps vllm (pip), vllm (pypi). Check affected ranges and fixed versions before updating.

Affected products and reported versions
ProductAffected versionsFixed versions
cpe:2.3:a:vllm:vllm:*:*:*:*:*:*:*:*Not reportedNot reported
Mapped affected packages and fixed versions
PackageAffected rangeFixed version
vllmpip<0.22.00.22.0
vllmpypi>=0 <0.22.00.22.0

Recommended response

  1. 1Check inventory. Check lockfiles and deployed manifests for vllm, vllm.
  2. 2Review the reported fix. Update vllm to 0.22.0; vllm to 0.22.0 if you use the affected versions. Test the change in a non-production environment first.

Evidence timeline and material changes

  1. Published upstream

    Jun 10, 2026

    Evidence: source:nvd:source_dates:source-dates:record
  2. Source modified

    Oct 25, 2026

    Evidence: source:nvd:source_dates:source-dates:record
  3. First seen by HOL

    Jun 11, 2026

Sources and claim methodology

  • GitHub security advisorygithub.com
  • GitHub security advisorygithub.com
  • GitHub security advisorygithub.com
  • Source referencehuntr.com
  • GitHub security advisorygithub.com
  • GitHub security advisorygithub.com
  • NVD vulnerability recordnvd.nist.gov
  • GitHub security advisorygithub.com
Upstream source description

### Summary vLLM's revision pinning controls do not consistently apply to all artifacts loaded for a model. A deployment that supplies `--revision` or `--code-revision` can still load dynamic code, GGUF files, image processors, retrieval side weights, or same-repository subfolder weights/config from an unpinned/default revision. This is a supply-chain integrity issue for pinned vLLM deployments. Operators can believe they are serving a reviewed model revision while vLLM resolves behavior-affecting nested or sibling artifacts outside that reviewed revision. ### Details The expected invariant is: > When a vLLM operator supplies a model or code revision pin, every code, config, processor, weight file, side weight, and same-repository subfolder artifact loaded as part of that model should resolve under that pin unless vLLM exposes and enforces a separate explicit pin for that artifact. Current `main` was verified affected at commit `3795d7acf431980e62e738493f437ae2a51549da`. Affected source boundaries: - `vllm/model_executor/models/registry.py:1045-1051` and `:1058-1064` - `_try_resolve_transformers()` passes `revision=model_config.revision` and `trust_remote_code=model_config.trust_remote_code`, but omits `code_revision=model_config.code_revision` for external `auto_map` dynamic module imports. - `vllm/model_executor/model_loader/gguf_loader.py:58-60` - The direct-file GGUF form `repo/file.gguf` calls `hf_hub_download(repo_id=repo_id, filename=filename)` without passing `revision`. - `vllm/model_executor/models/roberta.py:203-209` - BGE-M3 secondary sparse and ColBERT side weights are declared with `revision=None`. - `vllm/model_executor/models/kimi_k25.py:111-114` - Kimi-K2.5 calls `cached_get_image_processor()` without passing `model_config.revision`. - `vllm/model_executor/models/kimi_audio.py:92-95` - Kimi-Audio loads Whisper config from the `whisper-large-v3` subfolder without a `revision` argument. - `vllm/model_executor/models/kimi_audio.py:425-430` - Kimi-Audio declares same-repository `whisper-large-v3` secondary weights with `revision=None`. - `vllm/model_executor/model_loader/default_loader.py:287-301` - The default loader preserves `model_config.revision` for the primary source, then consumes model-supplied secondary sources as declared. The strongest example is Kimi-Audio: the primary `moonshotai/Kimi-Audio-7B-Instruct` weights preserve the configured model revision, but the same-repository `whisper-large-v3` audio tower config/weights do not. A pinned Kimi-Audio deployment can therefore load the Whisper subfolder outside the audited revision. This report does not claim a `trust_remote_code=False` bypass, unauthenticated RCE, or real artifact compromise. The issue is improper propagation of explicit artifact pins across supported loader paths. ### Impact Affected users are operators who pin vLLM model deployments to a reviewed Hugging Face revision for safety review, provenance, rollback, or reproducibility. The impact is that the pin does not reliably describe the full set of artifacts vLLM serves. Even when the operator selects an audited revision, vLLM can resolve behavior-affecting secondary artifacts from the repository default branch or another mutable ref. Depending on the model path, the unpinned artifact can be dynamic model code, a GGUF file, an image processor, retrieval side weights, or the same-repository Kimi-Audio Whisper subfolder weights/config. This breaks the operational guarantee of a pinned deployment: "serve the exact artifact set I reviewed." A later change to an unpinned secondary artifact can alter model behavior without changing the operator's configured revision, making review, rollback, incident response, and audit records unreliable. ### Occurrences - `vllm/model_executor/models/kimi_k25.py` L111-L114 — Kimi-K2.5 loads its image processor with `cached_get_image_processor()` but does not pass `self.ctx.model_config.revision`. The processor can therefore resolve from the default repository revision even when the model deployment is pinned. - `vllm/model_executor/models/kimi_audio.py` L425-L430 — Kimi-Audio declares same-repository `whisper-large-v3` secondary weights with `revision=None`. A pinned Kimi-Audio deployment can therefore load the Whisper audio tower weights from an unpinned/default revision. - `vllm/model_executor/models/kimi_audio.py` L92-L95 — Kimi-Audio loads Whisper config from the same repository's `whisper-large-v3` subfolder without passing the top-level model revision. The config for this behavior-affecting subcomponent can be resolved outside the audited model revision. - `vllm/model_executor/models/registry.py` L1058-L1064 — The later dynamic model-class resolution repeats the same pin-decay pattern: it forwards `revision` and `trust_remote_code`, but omits `code_revision`. This means an operator-provided code pin is not enforced at the dynamic module loader boundary. - `vllm/model_executor/model_loader/gguf_loader.py` L58-L60 — The direct GGUF form `repo/file.gguf` calls `hf_hub_download(repo_id=repo_id, filename=filename)` without passing `model_config.revision`. A deployment that pins the model revision can therefore resolve this GGUF file from the repository default revision. - `vllm/model_executor/models/registry.py` L1045-L1051 — `try_get_class_from_dynamic_module()` is called for external `auto_map` config/model classes with `revision=model_config.revision`, but without forwarding `model_config.code_revision`. When `--code-revision` is set, this dynamic module resolution can still fall back to the default code revision instead of the audited code revision. - `vllm/model_executor/models/roberta.py` L203-L209 — `BgeM3EmbeddingModel` creates same-repository secondary sparse/ColBERT weight sources with `revision=None`. The primary model revision is not propagated to these side weights, so they can be downloaded outside the operator-selected model revision. ### Fixes This was fixed in: https://github.com/vllm-project/vllm/pull/42616 ___ Originally filed via huntr: https://huntr.com/bounties/3f1e24c0-87d2-4f6c-a705-820f380879ac. The vLLM maintainer (Russell Bryant) redirected the report to the private GHSA channel. Offline proof bundle (`vllm_artifact_pin_decay_bundle_verify.py` + `bundle-verification-20260430T143506Z.json`) is available upon request.

Quoted source text, attributed separately from HOL analysis.

Record context

Vulnerability class
Missing Auth
EPSS
Not reported
CWE IDs
CWE-345
Source
GitHub Security Advisories
Source checked
Nov 1, 2026
References
8 linked sources
Open source record