RHSA-2026:83112HighCVSS 8.8

Red Hat Security Advisory: Red Hat AI Inference 3.4.6 (cpu)

Published
October 14, 2026
Last Modified
October 30, 2026

🔗 CVE IDs covered (12)

CVE-2026-37237 →CVE-2026-55514 →CVE-2026-97687 →CVE-2026-100650 →CVE-2026-102273 →CVE-2026-102598 →CVE-2026-104851 →CVE-2026-104874 →CVE-2026-15679 →CVE-2026-93592 →CVE-2026-97688 →CVE-2026-97689 →

📋 Description

CVE-2026-15679 — timm: Hugging Face PyTorch Image Models: Remote Code Execution via Deserialization of Untrusted Data CVE-2026-37237 — vllm: vLLM: Denial of Service via memory exhaustion from oversized media files CVE-2026-55514 — vllm: vLLM: Denial of Service via crafted prompt in /v1/completions request CVE-2026-93592 — vllm: vLLM: Denial of Service via negative token ID input CVE-2026-97687 — urllib3: urllib3: Traffic interception via HTTPS proxy TLS configuration override CVE-2026-97688 — urllib3: urllib3: Denial of Service via infinite loop during chunked Deflate decoding CVE-2026-97689 — urllib3: urllib3: Denial of Service via unbounded memory allocation in chunk parser CVE-2026-100650 — vllm: vLLM: Denial of Service via unbounded media ingestion CVE-2026-102273 — pyjwt: pyjwt: Token forgery via acceptance of public JWK containers as HMAC secrets CVE-2026-102598 — werkzeug: werkzeug: Denial of Service via safe_join() Windows special device paths CVE-2026-104851 — fsspec: fsspec: arbitrary code execution via unrestricted template rendering in ReferenceFileSystem CVE-2026-104874 — multidict: multidict: Denial of Service via memory leak in items-view operations

🎯 Affected products2

  • Red Hat AI Inference Server 3.4
  • registry.redhat.io/rhaii/vllm-cpu-rhel9@sha256:f8a692451f509d11bf166288d614660cf8c15bab7494a822276bf458cfeb757a_amd64 as a component of Red Hat AI Inference Server 3.4

✅ Remediation

For more information visit https://access.redhat.com/errata/RHSA-2026:83112 Workaround: Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base, or stability. Workaround: Restricting the domains that vLLM is allowed to fetch media from reduces exposure to this issue. Set the `--allowed-media-domains` option to an explicit allowlist of the domains you expect media to come from (for example `--allowed-media-domains upload.wikimedia.org github.com`), so that clients cannot direct the server to download arbitrarily large files from arbitrary hosts. Also consider setting `VLLM_MEDIA_URL_ALLOW_REDIRECTS=0` so that HTTP redirects cannot be followed to bypass the domain restrictions, as recommended in the upstream vLLM security documentation. Note that this restricts which hosts may be fetched but does not by itself impose a limit on the size of responses served by allowlisted domains. Workaround: Restrict access to the inference service or filter requests at an upstream reverse proxy or API gateway: 1. Limit network access: Deploy firewall rules or OpenShift NetworkPolicies so that the inference server ports and endpoints are accessible only by authenticated, trusted internal clients. 2. Ingress request validation: Configure an API gateway or reverse proxy placed in front of the model server to inspect request payloads for the `/v1/embeddings` and `/pooling` endpoints, rejecting requests where the `input` array contains negative numbers, or restricting untrusted clients to submitting text prompt strings rather than raw token lists. Caveats: Inspecting request bodies at an intermediary gateway layer may introduce slight processing latency. Modifying reverse proxy rules or applying network policies may require a service configuration reload or restart, which can temporarily disrupt in-flight connections. Workaround: Limit network exposure to the vLLM inference service and block outbound network connections from the serving host or container to prevent fetching untrusted external media: 1. Restrict inbound access using firewall rules so only trusted client networks or API gateways can reach the inference port (e.g., port 8000): # firewall-cmd --zone=public --remove-port=8000/tcp --permanent # firewall-cmd --zone=trusted --add-source=<TRUSTED_IP_OR_CIDR> --permanent # firewall-cmd --reload 2. In OpenShift AI environments, apply a Kubernetes NetworkPolicy to the pod namespace to restrict ingress traffic strictly to authorized proxy pods, and apply an egress rule that blocks outbound internet access, preventing the service from downloading arbitrary remote media URLs. 3. Enforce maximum request body size limits on upstream reverse proxies or ingress controllers to drop oversized inline base64 payloads before forwarding requests to the inference backend. Caveats: Restricting egress traffic will prevent valid remote media references from being processed if external multi-modal inputs are expected. Modifying firewall rules or reloading network services may briefly interrupt active connections.

🔗 References (16)