RHSA-2026:70965HighCVSS 9.1

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

Published
September 23, 2026
Last Modified
October 4, 2026

🔗 CVE IDs covered (34)

CVE-2026-68508 →CVE-2026-44827 →CVE-2026-48710 →CVE-2026-54283 →CVE-2026-58659 →CVE-2026-69244 →CVE-2026-59197 →CVE-2026-69247 →CVE-2026-41523 →CVE-2026-48746 →CVE-2026-54234 →CVE-2026-34993 →CVE-2026-54058 →CVE-2026-55380 →CVE-2026-59199 →CVE-2026-59205 →CVE-2026-69243 →CVE-2026-44513 →CVE-2026-54060 →CVE-2026-55574 →CVE-2026-57585 →CVE-2026-59204 →CVE-2026-59881 →CVE-2026-69249 →CVE-2026-73556 →CVE-2026-5497 →CVE-2026-44223 →CVE-2026-45804 →CVE-2026-59200 →CVE-2026-64847 →CVE-2026-69248 →CVE-2026-5241 →CVE-2026-48526 →CVE-2026-55379 →

📋 Description

CVE-2026-5241 — python-transformers: python-transformers: Arbitrary code execution due to overridden trust_remote_code setting CVE-2026-5497 — vllm: vLLM: Denial of Service via unbounded video frame processing CVE-2026-34993 — aiohttp: AIOHTTP: Arbitrary code execution via untrusted input to CookieJar.load() CVE-2026-41523 — vllm: vLLM: Arbitrary code execution via malicious HuggingFace model CVE-2026-44223 — vllm: vLLM: Denial of Service via malformed tensor shape in speculative decoding CVE-2026-44513 — Diffusers: Diffusers: Arbitrary remote code execution via trust_remote_code bypass CVE-2026-44827 — diffusers: Diffusers: Arbitrary Code Execution via malicious model loading CVE-2026-45804 — diffusers: Diffusers: Arbitrary code execution due to trust_remote_code guard bypass CVE-2026-48526 — python-pyjwt: PyJWT: Authentication bypass due to forged JSON Web Tokens CVE-2026-48710 — starlette: Starlette: Security restriction bypass via malformed HTTP Host header CVE-2026-48746 — vllm: starlette: vLLM: Critical authentication bypass allows unauthorized API access CVE-2026-54058 — Pillow: Pillow: Memory disclosure or denial of service via crafted McIdas AREA image CVE-2026-54060 — python-pillow: Pillow: Denial of Service via excessive memory allocation when processing font files CVE-2026-54234 — vllm: vLLM: Denial of Service via malformed speculative decoding workload CVE-2026-54283 — starlette: Starlette: request.form() limits silently ignored for application/x-www-form-urlencoded enable DoS CVE-2026-55379 — python-pillow: Pillow: Denial of Service via crafted BDF font file CVE-2026-55380 — python-pillow: Pillow: Denial of Service via crafted GD 2.x image file CVE-2026-55574 — vllm: vLLM: Denial of Service via adversarial regular expression in structured outputs API CVE-2026-57585 — msgpack: MessagePack for Python: Denial of Service via Unpacker reuse after error CVE-2026-58659 — pytorch-lightning: PyTorch Lightning: Remote code execution via malicious checkpoint files CVE-2026-59197 — Pillow: Pillow: Native heap out-of-bounds write CVE-2026-59199 — Pillow: Pillow: Denial of Service via out-of-bounds write in image processing CVE-2026-59200 — Pillow: Pillow: Denial of service via crafted PDF stream CVE-2026-59204 — Pillow: Pillow: Denial of Service via crafted JPEG2000 image CVE-2026-59205 — Pillow: Pillow: Controlled native heap corruption in ImageCms.ImageCmsTransform.apply API CVE-2026-59881 — aiohttp: AIOHTTP: Denial of Service via unnegotiated WebSocket compression CVE-2026-64847 — anyio: AnyIO: Denial of Service due to undrained stderr in process-pool workers CVE-2026-68508 — hydra: Hydra: Arbitrary code execution via untrusted configuration CVE-2026-69243 — aiohttp: AIOHTTP: HTTP Request Smuggling via WebSocket Upgrade CVE-2026-69244 — aiohttp: AIOHTTP: Denial of Service via malformed HTTP responses CVE-2026-69247 — python-cryptography: python-cryptography: PKCS#7 EnvelopedData decryption exposes a Bleichenbacher oracle through distinguishable errors and timing CVE-2026-69248 — python-cryptography: python-cryptography: python-cryptography verifier accepts wildcard DNS names allowing escape from permittedSubtrees CVE-2026-69249 — python-cryptography: python-cryptography: Duplicate self-signed intermediates can cause exponential path-building CVE-2026-73556 — vllm: vLLM: Denial of Service via Regular Expression processing

🎯 Affected products2

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

✅ Remediation

For more information visit https://access.redhat.com/errata/RHSA-2026:70965 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: 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: Applications using AIOHTTP that are configured to load untrusted files via the `CookieJar.load()` function should implement input sanitization prior to loading. This prevents the injection of malicious code. Workaround: Avoid running vLLM with python -O or PYTHONOPTIMIZE=1 until updated packages are available. Only load models from trusted sources. Restrict who can deploy or update models on inference endpoints. Apply network access controls and authentication in front of vLLM APIs. Workaround: Use DiffusionPipeline.from_pretrained() only with model paths, custom pipelines, and local snapshots from fully trusted and audited sources. Avoid setting custom_pipeline= to a Hub repository that differs from the primary model path unless its pipeline.py has been manually reviewed. When loading a local snapshot, check for unexpected *.py files at the snapshot root and under component subdirectories (unet/, scheduler/, etc.) before calling from_pretrained. The only complete fix is upgrading to diffusers 0.38.0. Workaround: Deploying an RFC-compliant reverse proxy (such as nginx, Apache, HAProxy, or Caddy) in front of the ASGI server will reject malformed Host headers before they reach the application. This is the most straightforward mitigation that does not require code changes. If custom middleware is present, it should be updated to use `request.scope["path"]` instead of `request.url.path` for any security decisions. The ASGI scope path is derived from the HTTP request line and is not influenced by the Host header, so it reflects the actual request target. Workaround: Restrict network access to the vLLM API endpoint to only trusted clients and internal networks. Implement firewall rules or network policies to limit inbound connections to the vLLM service, thereby reducing the attack surface. This operational control helps prevent unauthorized external access to the vulnerable API. Workaround: To mitigate this issue, restrict network access to the vLLM inference engine's gRPC Generate and Abort endpoints. Configure firewall rules to limit incoming connections to trusted clients or internal networks only. This will prevent remote, unauthenticated attackers from sending malformed workloads and triggering a denial of service. If the service is exposed via a proxy or load balancer, ensure that access controls are in place at that layer. Workaround: Do not load BDF font files from untrusted sources. Applications that only process standard image formats (PNG, JPEG, etc.) and do not use BdfFontFile or ImageFont.load() with BDF files are not affected. Workaround: Avoid processing untrusted GD 2.x image files with PIL.GdImageFile.open(). Use Image.open() instead, which includes decompression bomb protections for supported formats. If GdImageFile must be used, validate the image dimensions before calling load(). Restricting accepted image formats at the application boundary to only those explicitly needed can reduce exposure. Workaround: To mitigate this issue, applications utilizing MessagePack for Python should be reviewed to ensure that `Unpacker` instances are not reused after an error has occurred during unpacking. Instead, a new `Unpacker` instance should be created for subsequent operations. Workaround: If the application does not need JPEG2000 support, block .jp2, .j2k, .jpf, and .jpx uploads at the input layer. For services that do process JPEG2000, set memory limits on the process or container (LimitAS= in systemd, or memory limits in Kubernetes/Podman) so a crafted image can only crash the worker, not the whole host. Add automatic restarts (Restart=always in systemd, or container restart policies) so the service recovers from OOM kills without someone having to intervene. Workaround: Most applications using Pillow's color management via profileToProfile() or applyTransform() are not exposed. Only code that calls ImageCmsTransform.apply() directly with a user-controlled output image whose mode does not match the transform can trigger the heap corruption. Audit your code for direct apply() calls to confirm. RHEL builds ship with ASLR, full RELRO/PIE, and FORTIFY_SOURCE by default, making escalation from crash to code execution much harder. For DoS containment, configure automatic service restart (Restart=always in systemd, or container restart policies) so the process recovers without manual intervention. Workaround: For deployments where upgrading is not immediately possible, ensure that aiohttp WebSocket clients only connect to trusted servers. The vulnerability requires the client to have opted out of permessage-deflate compression and the server to send RSV1-flagged frames, so connections using default compression settings are less likely to trigger this issue. Workaround: To mitigate this issue, applications using the Hydra framework should be configured to only process configuration, CLI overrides, or model metadata from trusted sources. Avoid passing untrusted or unvalidated input to `hydra.utils.instantiate()` to prevent arbitrary code execution. Workaround: The vulnerable APIs were introduced in cryptography 44.0.0 and fixed in 50.0.0. Workaround: The Rust PolicyBuilder verifier was introduced in cryptography 42.0.0 and this issue was fixed in 49.0.0. Workaround: The Rust PolicyBuilder verifier was introduced in cryptography 42.0.0 and this issue was fixed in 49.0.0 (signature-check budget of 128).

🔗 References (38)