vLLM Hardcoded trust_remote_code Bypass Enables Remote Code Execution via Malicious Model Repositories (CVE-2026-27893)

1. Executive Summary

CVE-2026-27893 is a high-severity protection mechanism failure in vLLM, the widely-used open-source LLM inference and serving engine, whereby two model implementation files hardcode trust_remote_code=True, silently bypassing an operator's explicit --trust-remote-code=False security setting (GHSA-7972-pg2x-xr59). An attacker who publishes a malicious model repository targeting the Nemotron-VL or Kimi-K25 architecture can achieve arbitrary code execution on the inference server even when the operator has deliberately disabled remote code trust (GHSA-7972-pg2x-xr59). Organisations running vLLM versions 0.10.1 through 0.17.x should upgrade to 0.18.0 immediately (GHSA-7972-pg2x-xr59).

2. Risk Rating

CVSS Detail

The CVSS 8.8 score is CNA-submitted via GitHub and classified as the sole available score. NVD has received the CVE but has not completed its own analysis (NVD status: Received as of 2026-03-27) (NVD). The score may change once NVD completes independent analysis.

CVE-2026-27893: Base Score 8.8 HIGH -- CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H (CNA: GitHub) (NVD)

The UI:R (user interaction required) component reflects the requirement that an operator must initiate loading of the malicious model (GHSA-7972-pg2x-xr59). The attacker does not require any privileges on the target system (PR:N); the prerequisite is control of a model repository (GHSA-7972-pg2x-xr59).

3. Affected Products

Vendor: vLLM Project. Version range and fix version sourced from the GitHub Security Advisory (GHSA-7972-pg2x-xr59). NVD CPE data is not yet populated (NVD status: Received) (NVD). The fix was delivered in PR vllm-project/vllm#36192 (GHSA-7972-pg2x-xr59).

Am I Affected?

• Check if you run vLLM for LLM inference serving
• Check your installed version: pip show vllm | grep Version -- versions 0.10.1 through 0.17.x are affected (GHSA-7972-pg2x-xr59)
• Check if any deployed models use the Nemotron-VL or Kimi-K25 architecture (these route through the vulnerable code paths) (GHSA-7972-pg2x-xr59)
• Check whether you rely on --trust-remote-code=False as a security control -- if so, it is silently bypassed for these two architectures on affected versions (GHSA-7972-pg2x-xr59)

4. Abstract

CVE-2026-27893 (CWE-693, Protection Mechanism Failure) is a hardcoded trust_remote_code=True bypass in two vLLM model implementation files: nemotron_vl.py (line 430, AutoModel.from_config()) and kimi_k25.py (line 177, cached_get_image_processor()) (GHSA-7972-pg2x-xr59). These call sites ignore the operator's --trust-remote-code=False configuration -- which is propagated through self.config.model_config.trust_remote_code -- and substitute a literal True, causing the HuggingFace Transformers library to download and execute remote Python modules from the model repository regardless of the security setting (GHSA-7972-pg2x-xr59).

The vulnerability enables a supply-chain attack vector: an adversary publishes a model repository on HuggingFace Hub containing malicious Python code, targeting either the Nemotron-VL or Kimi-K25 architecture. When an operator loads this model, the hardcoded override causes the malicious code to execute at import time with the privileges of the vLLM process (GHSA-7972-pg2x-xr59). The bypass is silent -- no warning or log entry is emitted when the operator's security setting is overridden (RAXE assessment).

These hardcoded values survived previous patches for CVE-2025-66448 and CVE-2026-22807, which addressed the same vulnerability class in different code paths (GHSA-7972-pg2x-xr59). This is the third trust_remote_code bypass CVE in vLLM, indicating a systemic architectural issue in model implementation review (RAXE assessment).

5. Key Findings

1. Two hardcoded trust_remote_code=True bypass sites -- nemotron_vl.py line 430 (AutoModel.from_config()) and kimi_k25.py line 177 (cached_get_image_processor()) override the operator's explicit --trust-remote-code=False setting with a hardcoded True (GHSA-7972-pg2x-xr59).

2. Silent security control failure -- The override produces no warning, error, or audit log entry. Operators who set --trust-remote-code=False have no indication that their security setting is being ignored at these code paths (RAXE assessment, consistent with advisory description).

3. Supply-chain RCE enabler -- An attacker controlling a model repository targeting the Nemotron-VL or Kimi-K25 architecture achieves code execution on the inference server regardless of the operator's trust configuration (GHSA-7972-pg2x-xr59).

4. Recurring vulnerability class -- CVE-2026-27893 is the third trust_remote_code bypass in vLLM, following CVE-2025-66448 and CVE-2026-22807, each in different code paths. The pattern of individual model implementation files hardcoding security-critical parameters has not been resolved at the architectural level (GHSA-7972-pg2x-xr59, RAXE assessment).

5. Fix replaces literals with config propagation -- The remediation in PR vllm-project/vllm#36192 replaces the hardcoded True with self.config.model_config.trust_remote_code at both affected call sites, correctly propagating the operator's setting (GHSA-7972-pg2x-xr59).

6. Attack Flow

+------------------------------------+
| 1. Attacker publishes a malicious  |
|    HuggingFace model repo for the  |
|    Nemotron-VL or Kimi-K25 path.   |
+-----------------+------------------+
                  |
                  v
+------------------------------------+
| 2. Operator loads the model with   |
|    --trust-remote-code=False,      |
|    expecting remote code to stay   |
|    disabled.                       |
+-----------------+------------------+
                  |
                  v
+------------------------------------+
| 3. vLLM dispatches into            |
|    nemotron_vl.py or kimi_k25.py   |
|    on the vulnerable code path.    |
+-----------------+------------------+
                  |
                  v
+------------------------------------+
| 4. Hardcoded trust_remote_code=    |
|    True overrides the operator's   |
|    False setting.                  |
+-----------------+------------------+
                  |
                  v
+------------------------------------+
| 5. HuggingFace Transformers pulls  |
|    and executes the attacker's     |
|    Python module during load.      |
+-----------------+------------------+
                  |
                  v
+------------------------------------+
| 6. Attacker code now runs inside   |
|    the vLLM server process, with   |
|    no warning shown to the         |
|    operator.                       |
+------------------------------------+

The attack requires user interaction (UI:R) -- the operator must initiate model loading (GHSA-7972-pg2x-xr59). The attacker requires no privileges on the target system (PR:N); only control of a model repository is needed (GHSA-7972-pg2x-xr59).

7. Technical Details

Vulnerable Code Paths

Two model implementation files in vLLM's model_executor/models/ directory contain the hardcoded bypass (GHSA-7972-pg2x-xr59):

Path A -- nemotron_vl.py (line 430):

# Vulnerable: hardcoded True ignores operator's --trust-remote-code=False
AutoModel.from_config(config, trust_remote_code=True)

This call site loads the vision encoder component for Nemotron-VL multimodal models. The trust_remote_code=True parameter causes HuggingFace Transformers to download and execute arbitrary Python modules from the model repository, regardless of the operator's global setting (GHSA-7972-pg2x-xr59).

Path B -- kimi_k25.py (line 177):

# Vulnerable: hardcoded True ignores operator's --trust-remote-code=False
cached_get_image_processor(model_name, trust_remote_code=True)

This call site loads the image processor component for Kimi-K25 multimodal models. The same hardcoded override applies (GHSA-7972-pg2x-xr59).

Root Cause: CWE-693 (Protection Mechanism Failure)

The operator's --trust-remote-code=False CLI setting is correctly propagated through the vLLM configuration hierarchy via self.config.model_config.trust_remote_code. However, the two affected call sites ignore this configuration attribute and substitute a literal True (GHSA-7972-pg2x-xr59). This is classified as CWE-693 (Protection Mechanism Failure): the trust_remote_code security mechanism exists and is correctly configured by the operator, but it is defeated by hardcoded values in specific model implementation files (NVD).

Fix: Config Propagation (PR #36192)

The fix in vllm-project/vllm#36192 replaces the hardcoded True with self.config.model_config.trust_remote_code at both affected call sites, ensuring the operator's security setting is respected (GHSA-7972-pg2x-xr59):

# Fixed: reads from operator's configuration instead of hardcoding
AutoModel.from_config(config, trust_remote_code=self.config.model_config.trust_remote_code)

Relationship to Prior trust_remote_code CVEs

CVE-2026-27893 is the third trust_remote_code bypass vulnerability in vLLM. The prior CVEs addressed different code paths but the same vulnerability class (GHSA-7972-pg2x-xr59):

The recurrence demonstrates that the vulnerability class is not confined to a single code location. vLLM's model implementation architecture requires each model file to correctly propagate security settings, and any file that hardcodes trust_remote_code=True creates a silent bypass. The pattern has recurred across three CVE patches, each targeting different files (GHSA-7972-pg2x-xr59, RAXE assessment).

Relationship to Other vLLM Findings

• RAXE-2026-020 (GHSA-4r2x-xpjr-7cvv): vLLM Video Processing RCE -- different component (video handling), different attack vector, unrelated to trust_remote_code
• RAXE-2026-023 (GHSA-2pc9-4j83-qjmr): vLLM RCE via auto_map dynamic module loading -- related trust bypass theme (CVE-2026-22807), different mechanism (auto_map rather than hardcoded trust parameter)

Three distinct vLLM CVEs involving untrusted code execution from model repositories suggest a structural weakness in the inference engine's trust boundary enforcement (RAXE assessment).

8. Confidence & Validation

Assessment Confidence: High

Limitations

• The attack mechanism has not been dynamically reproduced in a sandboxed environment. Steps are derived from the vendor advisory description (GHSA-7972-pg2x-xr59)
• The exact model architecture names in config.json that trigger routing to nemotron_vl.py and kimi_k25.py have not been independently verified by RAXE
• The assessment that the override is silent (no log entry) is inferred from the advisory description, which does not mention any warning mechanism (RAXE assessment)
• All technical details are sourced from a single vendor advisory (GHSA-7972-pg2x-xr59); no independent third-party analysis has been referenced

9. Detection Signatures

Sigma Rules -- Process Telemetry

Rule RAXE-2026-044-001: vLLM Serving Vulnerable Model Architecture

title: vLLM Serving Nemotron-VL or Kimi-K25 Model -- trust_remote_code Bypass Scenario (CVE-2026-27893)
id: 8c1e4f7a-3d9b-42e6-a5f0-6b2c8d1e3a7f
status: experimental
description: >
  Detects vLLM process invocations that load a model associated with the
  Nemotron-VL or Kimi-K25 architectures. These architectures route through
  code paths that hardcode trust_remote_code=True, bypassing the operator's
  security opt-out on vLLM 0.10.1 through 0.17.x (GHSA-7972-pg2x-xr59).
  Lane 2 (vulnerability-informed).
references:
  - https://github.com/vllm-project/vllm/security/advisories/GHSA-7972-pg2x-xr59
  - https://nvd.nist.gov/vuln/detail/CVE-2026-27893
author: RAXE Labs (M. Hirani)
date: 2026-03-27
tags:
  - attack.execution
  - attack.defense_evasion
  - attack.t1059.006
  - attack.t1195.002
  - cve.2026-27893
logsource:
  category: process_creation
  product: linux
detection:
  selection_vllm_serve:
    CommandLine|contains:
      - 'vllm serve'
      - 'vllm.entrypoints'
      - 'vllm.engine'
  selection_vulnerable_model:
    CommandLine|contains:
      - 'nemotron'
      - 'Nemotron'
      - 'kimi'
      - 'Kimi'
      - 'moonshot-ai/Kimi'
      - 'nvidia/Nemotron'
  condition: selection_vllm_serve and selection_vulnerable_model
falsepositives:
  - Legitimate vLLM deployments serving these models on patched versions (>= 0.18.0)
  - Model names containing "nemotron" or "kimi" that do not route through the vulnerable code paths
level: high

Rule RAXE-2026-044-002: Suspicious Child Process Under vLLM Worker

title: Suspicious Child Process Spawned by vLLM Worker Process (CVE-2026-27893 Post-Exploitation)
id: 2f5a9c3e-8b7d-41e0-c6a2-4d1f7e8b3c5a
status: experimental
description: >
  Detects suspicious child processes spawned by a vLLM inference worker.
  When CVE-2026-27893 is exploited, malicious code runs during model loading
  with vLLM process privileges (GHSA-7972-pg2x-xr59). Lane 3 (hunting/heuristic).
  RAXE assessment: child process indicators are inferred from standard
  post-exploitation behaviour, not from observed exploitation of CVE-2026-27893.
references:
  - https://github.com/vllm-project/vllm/security/advisories/GHSA-7972-pg2x-xr59
  - https://nvd.nist.gov/vuln/detail/CVE-2026-27893
author: RAXE Labs (M. Hirani)
date: 2026-03-27
tags:
  - attack.execution
  - attack.t1059.004
  - attack.t1059.006
  - cve.2026-27893
logsource:
  category: process_creation
  product: linux
detection:
  selection_parent_vllm:
    ParentCommandLine|contains:
      - 'vllm'
      - 'vllm.entrypoints'
      - 'model_executor'
  selection_suspicious_child:
    Image|endswith:
      - '/sh'
      - '/bash'
      - '/curl'
      - '/wget'
      - '/nc'
      - '/ncat'
      - '/socat'
  selection_suspicious_commands:
    CommandLine|contains:
      - '/dev/tcp/'
      - 'socket.connect'
      - 'base64 -d'
      - 'mkfifo'
      - 'import pty'
      - 'pty.spawn'
  filter_legitimate_workers:
    CommandLine|contains:
      - 'ray::IDLE'
      - 'multiprocessing'
      - 'torch.distributed'
      - 'worker_init'
      - 'model_runner'
  condition: selection_parent_vllm and (selection_suspicious_child or selection_suspicious_commands) and not filter_legitimate_workers
falsepositives:
  - vLLM model implementations that legitimately spawn subprocesses for preprocessing
  - Container entrypoint scripts wrapping vLLM invocation
level: high

Sigma Rules -- Network Telemetry

Rule RAXE-2026-044-003: HuggingFace Python Module Download

title: HuggingFace Python Module Download by vLLM Process -- trust_remote_code Bypass Indicator (CVE-2026-27893)
id: 7a3d2e5f-9c1b-48f6-b4e0-3d8a7f2c6e1b
status: experimental
description: >
  Detects HTTPS requests to HuggingFace Hub that download Python files (.py)
  for Nemotron or Kimi model architectures. When trust_remote_code is disabled,
  these downloads should not occur (GHSA-7972-pg2x-xr59). Lane 3 (hunting).
  RAXE assessment: network indicator inferred from standard HuggingFace
  trust_remote_code download behaviour.
references:
  - https://github.com/vllm-project/vllm/security/advisories/GHSA-7972-pg2x-xr59
  - https://nvd.nist.gov/vuln/detail/CVE-2026-27893
author: RAXE Labs (M. Hirani)
date: 2026-03-27
tags:
  - attack.command_and_control
  - attack.t1071.001
  - attack.t1195.002
  - cve.2026-27893
logsource:
  category: proxy
detection:
  selection_huggingface_domain:
    r-dns|endswith:
      - '.huggingface.co'
      - 'huggingface.co'
  selection_python_file:
    cs-uri|endswith:
      - '.py'
    cs-uri|contains:
      - '/resolve/'
      - '/raw/'
  selection_model_architecture:
    cs-uri|contains:
      - 'nemotron'
      - 'Nemotron'
      - 'kimi'
      - 'Kimi'
      - 'moonshot-ai'
  condition: selection_huggingface_domain and selection_python_file and selection_model_architecture
falsepositives:
  - Legitimate vLLM deployments with trust_remote_code intentionally enabled on patched versions
  - Developers downloading model code for inspection
level: high

Rule RAXE-2026-044-004: DNS/Connection to HuggingFace from vLLM Host

title: vLLM Host Network Connection to HuggingFace -- Model Download Activity Hunt (CVE-2026-27893)
id: 4b6e1d8c-2a7f-43c5-d9e0-5f3b8a2c7d4e
status: experimental
description: >
  Detects DNS queries or network connections from vLLM inference hosts to
  HuggingFace domains. In production environments where models are pre-cached,
  outbound connections during inference are unexpected (RAXE assessment).
  Lane 3 (hunting). Requires environmental baselining.
references:
  - https://github.com/vllm-project/vllm/security/advisories/GHSA-7972-pg2x-xr59
  - https://nvd.nist.gov/vuln/detail/CVE-2026-27893
author: RAXE Labs (M. Hirani)
date: 2026-03-27
tags:
  - attack.command_and_control
  - attack.t1071.001
  - cve.2026-27893
logsource:
  category: dns
detection:
  selection_huggingface_dns:
    query|endswith:
      - 'huggingface.co'
      - 'hf.co'
  condition: selection_huggingface_dns
falsepositives:
  - Production vLLM deployments downloading models from HuggingFace during initial setup
  - Developer workstations or CI/CD pipelines interacting with HuggingFace
level: medium

YARA Rules -- File Scanning

Rule RAXE-2026-044-YARA-001: Vulnerable nemotron_vl.py

rule RAXE_2026_044_vLLM_NemotronVL_Hardcoded_TrustRemoteCode
{
    meta:
        description = "Detects vulnerable nemotron_vl.py with hardcoded trust_remote_code=True in AutoModel.from_config() (CVE-2026-27893). Lane 2 (vulnerability-informed)."
        reference   = "https://github.com/vllm-project/vllm/security/advisories/GHSA-7972-pg2x-xr59"
        cve         = "CVE-2026-27893"
        author      = "RAXE Labs (M. Hirani)"
        date        = "2026-03-27"

    strings:
        $vuln_pattern = /AutoModel\.from_config\s*\([^)]*trust_remote_code\s*=\s*True[^)]*\)/
        $trust_hardcoded = "trust_remote_code=True"
        $nemotron_class = "NemotronVL"
        $nemotron_model = "nemotron_vl"
        $fixed_pattern_config = "trust_remote_code=self.config.model_config.trust_remote_code"

    condition:
        filesize < 1MB and
        $trust_hardcoded and
        ($nemotron_class or $nemotron_model) and
        $vuln_pattern and
        not $fixed_pattern_config
}

Rule RAXE-2026-044-YARA-002: Vulnerable kimi_k25.py

rule RAXE_2026_044_vLLM_KimiK25_Hardcoded_TrustRemoteCode
{
    meta:
        description = "Detects vulnerable kimi_k25.py with hardcoded trust_remote_code=True in cached_get_image_processor() (CVE-2026-27893). Lane 2 (vulnerability-informed)."
        reference   = "https://github.com/vllm-project/vllm/security/advisories/GHSA-7972-pg2x-xr59"
        cve         = "CVE-2026-27893"
        author      = "RAXE Labs (M. Hirani)"
        date        = "2026-03-27"

    strings:
        $vuln_pattern = /cached_get_image_processor\s*\([^)]*trust_remote_code\s*=\s*True[^)]*\)/
        $trust_hardcoded = "trust_remote_code=True"
        $kimi_class = "KimiK25"
        $kimi_model = "kimi_k25"
        $fixed_pattern_config = "trust_remote_code=self.config.model_config.trust_remote_code"

    condition:
        filesize < 1MB and
        $trust_hardcoded and
        ($kimi_class or $kimi_model) and
        $vuln_pattern and
        not $fixed_pattern_config
}

Rule RAXE-2026-044-YARA-003: Generic Hardcoded trust_remote_code Hunt

rule RAXE_2026_044_vLLM_Generic_Hardcoded_TrustRemoteCode
{
    meta:
        description = "Broad hunt: detects any vLLM model file with hardcoded trust_remote_code=True. Catches known CVE-2026-27893 files plus future instances (RAXE assessment). Lane 3 (hunting)."
        reference   = "https://github.com/vllm-project/vllm/security/advisories/GHSA-7972-pg2x-xr59"
        cve         = "CVE-2026-27893"
        author      = "RAXE Labs (M. Hirani)"
        date        = "2026-03-27"

    strings:
        $trust_true = "trust_remote_code=True"
        $vllm_import_1 = "from vllm"
        $vllm_import_2 = "import vllm"
        $vllm_import_3 = "vllm.model_executor"
        $hf_automodel = "AutoModel"
        $hf_from_pretrained = "from_pretrained"
        $hf_from_config = "from_config"
        $hf_image_processor = "image_processor"
        $config_propagated = "trust_remote_code=self.config"

    condition:
        filesize < 1MB and
        $trust_true and
        any of ($vllm_import_*) and
        any of ($hf_automodel, $hf_from_pretrained, $hf_from_config, $hf_image_processor) and
        not $config_propagated
}

Detection Coverage Matrix

10. Detection & Mitigation

Detection Guidance

• YARA file scanning (deploy first): Scan all vLLM installation directories (vllm/model_executor/models/) for the hardcoded trust_remote_code=True pattern using YARA rules 001-003. This identifies vulnerable installations before any exploitation occurs (RAXE assessment)
• Process telemetry: Monitor vLLM process invocations for model names associated with Nemotron-VL or Kimi-K25 architectures (Sigma-001). Monitor for anomalous child processes under vLLM workers (Sigma-002) (RAXE assessment)
• Network monitoring: If HTTP proxy logs with URL path visibility are available, detect Python module downloads from HuggingFace for the affected model architectures (Sigma-003). For environments without URL path visibility, use DNS-level detection (Sigma-004) as a lower-fidelity hunting query (RAXE assessment)
• Container image scanning: Integrate YARA rules into CI/CD pipelines to scan container images before deployment. Block images containing vulnerable vLLM model files (RAXE assessment)

Mitigation

1. Upgrade to vLLM 0.18.0 -- This is the primary remediation. The fix in PR vllm-project/vllm#36192 replaces hardcoded True with self.config.model_config.trust_remote_code at both vulnerable call sites (GHSA-7972-pg2x-xr59).

2. Audit model sources -- Restrict model loading to trusted, verified publishers. Do not load arbitrary models from public HuggingFace Hub repositories without review, particularly models targeting Nemotron-VL or Kimi-K25 architectures (RAXE assessment).

3. Container isolation -- Run vLLM inference servers in minimal containers with restricted outbound network access. Limit egress to required model registries and API endpoints only (RAXE assessment).

4. Network segmentation -- Isolate the inference tier from sensitive data stores and internal networks to limit lateral movement from a compromised vLLM process (RAXE assessment).

5. Model provenance verification -- Implement integrity checks (checksums, signatures) for model artefacts before loading. Do not rely solely on trust_remote_code as the security boundary (RAXE assessment).

6. Runtime monitoring -- Monitor vLLM processes for unexpected child process creation, network connections to external hosts during steady-state inference, and filesystem writes outside the model cache directory (RAXE assessment).

7. Proactive source code scanning -- For organisations running custom or forked vLLM builds: scan all model implementation files (vllm/model_executor/models/*.py) for hardcoded trust_remote_code=True patterns using YARA rule 003. The recurrence of this vulnerability class across three CVEs suggests additional instances may exist (RAXE assessment).

11. Indicators of Compromise

All behavioural and network indicators above are hunting-grade -- they are inferred from the advisory description and standard post-exploitation behaviour, not from observed exploitation of CVE-2026-27893 (RAXE assessment).

12. Strategic Context

CVE-2026-27893 is the third trust_remote_code bypass vulnerability in vLLM, following CVE-2025-66448 and CVE-2026-22807 (GHSA-7972-pg2x-xr59). The recurrence of this vulnerability class across three distinct code paths -- each surviving the patches for its predecessors -- reveals a systemic weakness in vLLM's model implementation architecture (RAXE assessment).

The root cause is architectural: vLLM delegates model-specific behaviour to individual Python files in model_executor/models/, and each file must independently propagate the global trust_remote_code setting. There is no centralised enforcement mechanism that prevents a model file from hardcoding True. Every new model implementation added to vLLM is a potential new instance of this vulnerability class (RAXE assessment).

This pattern is significant for enterprise AI deployments because vLLM is a foundational component in many production LLM serving stacks. Organisations that have adopted --trust-remote-code=False as a security control may have a false sense of protection if they serve models through affected code paths. The silent nature of the bypass -- no warning, no log entry -- means the security control failure is invisible without proactive file scanning or network monitoring (RAXE assessment).

The broader lesson extends beyond vLLM: any framework that distributes security-critical configuration propagation across many independent files, without centralised enforcement, is susceptible to this class of failure. As the AI infrastructure ecosystem matures, centralised trust boundary enforcement -- rather than per-file opt-in -- will be necessary to prevent recurring bypass vulnerabilities (RAXE assessment).

MITRE ATLAS Alignment

MITRE ATT&CK Alignment

13. References

1. CVE-2026-27893 -- NVD entry (status: Received; CNA-submitted CVSS 8.8 HIGH)
2. GHSA-7972-pg2x-xr59 -- GitHub Security Advisory: vLLM hardcoded trust_remote_code bypass
3. vllm-project/vllm#36192 -- Fix PR: replace hardcoded True with config propagation
4. CWE-693 -- Protection Mechanism Failure
5. MITRE ATLAS AML.T0010.001 -- ML Supply Chain Compromise: AI Software
6. CVE-2025-66448 -- Prior vLLM trust_remote_code bypass (different code path); referenced in GHSA-7972-pg2x-xr59
7. CVE-2026-22807 / GHSA-2pc9-4j83-qjmr -- Prior vLLM RCE via auto_map dynamic module loading (RAXE-2026-023)
8. GHSA-4r2x-xpjr-7cvv -- vLLM Video Processing RCE (RAXE-2026-020)