RHSA-2026:61627HighCVSS 9.1

Red Hat Security Advisory: Red Hat AI Inference Server 3.2.2 (CUDA)

Published
August 31, 2026
Last Modified
September 5, 2026

🔗 CVE IDs covered (32)

CVE-2026-0994 →CVE-2026-44222 →CVE-2026-54399 →CVE-2026-56210 →CVE-2026-56211 →CVE-2026-64830 →CVE-2026-11822 →CVE-2026-54512 →CVE-2026-56209 →CVE-2025-52881 →CVE-2025-62593 →CVE-2026-54234 →CVE-2026-54235 →CVE-2026-55574 →CVE-2026-55969 →CVE-2026-58049 →CVE-2026-54060 →CVE-2026-59205 →CVE-2026-57516 →CVE-2026-11824 →CVE-2026-40192 →CVE-2026-54283 →CVE-2026-55379 →CVE-2026-48586 →CVE-2026-64835 →CVE-2025-66418 →CVE-2026-41523 →CVE-2026-48746 →CVE-2026-50193 →CVE-2026-55380 →CVE-2026-56208 →CVE-2026-59204 →

📋 Description

CVE-2025-52881 — runc: opencontainers/selinux: container escape and denial of service due to arbitrary write gadgets and procfs write redirects CVE-2025-62593 — ray: Ray is vulnerable to RCE via Safari & Firefox Browsers through DNS Rebinding Attack CVE-2025-66418 — urllib3: urllib3: Unbounded decompression chain leads to resource exhaustion CVE-2026-0994 — python: protobuf: Protobuf: Denial of Service due to recursion depth bypass CVE-2026-11822 — sqlite: SQLite: Arbitrary code execution via crafted FTS5 full-text search data CVE-2026-11824 — sqlite: SQLite: Arbitrary code execution and crash via heap-based buffer overflow in FTS5 CVE-2026-40192 — Pillow: Pillow: Denial of Service via decompression bomb in FITS image processing CVE-2026-41523 — vllm: vLLM: Arbitrary code execution via malicious HuggingFace model CVE-2026-44222 — vllm: vLLM: Denial of Service via malformed multimodal input or token injection CVE-2026-48586 — thrift: org.apache.thrift/libthrift: github.com/apache/thrift: Apache Thrift: Denial of Service via improper handling of highly compressed data CVE-2026-48746 — vllm: starlette: vLLM: Critical authentication bypass allows unauthorized API access CVE-2026-50193 — jackson-databind: Jackson-databind: Denial of Service via deeply nested JSON processing 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-54235 — vllm: vLLM: Denial of Service due to improper floating-point validation CVE-2026-54283 — starlette: Starlette: request.form() limits silently ignored for application/x-www-form-urlencoded enable DoS CVE-2026-54399 — org.apache.httpcomponents.core5/httpcore5: Apache HttpComponents Core: Denial of Service via excessive HTTP headers CVE-2026-54512 — jackson-databind: jackson-databind: Arbitrary code execution via PolymorphicTypeValidator bypass 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-55969 — thrift: github.com/apache/thrift: Apache Thrift: Denial of Service via integer overflow or wraparound CVE-2026-56208 — libaom: libaom: heap buffer overflow in AV1 encoder first-pass stats buffer via LAP mode CVE-2026-56209 — libaom: libaom: arbitrary address write via SVC layer context OOB and cyclic refresh map pointer hijack CVE-2026-56210 — libaom: libaom: heap-buffer-overflow read via missing bounds check in ctrl_set_layer_id CVE-2026-56211 — libaom: libaom: remote code execution via SVC layer context handling with attacker-controlled frames CVE-2026-57516 — ray: Ray: Remote code execution via unsafe deserialization in WebDataset reader CVE-2026-58049 — FFmpeg: FFmpeg: Memory corruption via crafted RASC video 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-64830 — ffmpeg: FFmpeg: Arbitrary code execution via heap buffer overflow in VobSub subtitle demuxer. CVE-2026-64835 — FFmpeg: FFmpeg: Arbitrary code execution, information disclosure, or denial of service via crafted ADX/AAX audio files

🎯 Affected products3

  • Red Hat AI Inference Server 3.2
  • registry.redhat.io/rhaiis/vllm-cuda-rhel9@sha256:44224455142130c9594b4361fd21494c88244acb59b242f31ecb66019a5238dd_arm64 as a component of Red Hat AI Inference Server 3.2
  • registry.redhat.io/rhaiis/vllm-cuda-rhel9@sha256:e2a077acf23766ef900942296ce963a624d2c4b45ff22ca77cadeb94c051fd95_amd64 as a component of Red Hat AI Inference Server 3.2

✅ Remediation

For more information visit https://access.redhat.com/errata/RHSA-2026:61627 Workaround: Potential mitigations for this issue include: * Using rootless containers, as doing so will block most of the inadvertent writes (runc would run with reduced privileges, making attempts to write to procfs files ineffective). * Based on our analysis, neither AppArmor or SELinux can protect against the full version of the redirected write attack. The container runtime is generally privileged enough to write to arbitrary procfs files, which is more than sufficient to cause a container breakout. Workaround: Mitigation for this issue is either not available or the currently available options don't 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: 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: 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: 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: To mitigate this issue, configure an upstream proxy or web application firewall (WAF) to enforce limits on the number and length of HTTP headers. This prevents malformed requests from reaching and exhausting the vulnerable Apache HttpComponents Core component. Consult your proxy or WAF documentation for specific configuration. A service restart may be required for changes to take effect. 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: There is no complete mitigation for this vulnerability. The following measures can reduce risk: 1. If using libaom as a standalone encoder library, avoid setting g_lag_in_frames to values >= 1 when processing untrusted input, or validate all encoder configuration parameters before passing them to the libaom API. 2. For Firefox and Thunderbird, ensure browsers are updated to versions that include the patched libaom (v3.14.0 or later). 3. For standalone libaom deployments (RHEL-AI, Hummingbird), restrict access to the encoding service to trusted clients only. 4. Apply network-level access controls to limit who can submit video for encoding. Workaround: There is no complete mitigation for this vulnerability. The following measures can reduce risk: 1. If using libaom as a standalone encoder library with SVC enabled, validate that spatial_layer_id and temporal_layer_id values are within the configured range [0, configured_layers) before calling aom_codec_control with AV1E_SET_SVC_LAYER_ID. 2. Restrict access to encoding services to trusted clients only. Do not expose libaom SVC encoder configuration to untrusted input. 3. For Firefox and Thunderbird, ensure browsers are updated to versions that include the patched libaom (v3.14.0 or later). 4. Deploy encoding services with ASLR, stack canaries, and other exploit mitigation technologies enabled. Workaround: There is no complete mitigation for this vulnerability. The following measures can reduce risk: 1. If using libaom as a standalone encoder library with SVC enabled, validate that spatial_layer_id does not exceed the number of configured spatial layers before calling aom_codec_control with AV1E_SET_SVC_LAYER_ID. 2. Restrict access to encoding services to trusted clients only. 3. For Firefox and Thunderbird, ensure browsers are updated to versions that include the patched libaom (v3.14.0 or later). 4. Monitor encoding service processes for unexpected crashes (segfaults) that may indicate exploitation attempts. Workaround: There is no complete mitigation for this vulnerability. The following measures can reduce risk: 1. If using libaom as a standalone encoder in a fork-based service, validate all SVC layer parameters (spatial_layer_id, temporal_layer_id) against configured bounds before passing them to the encoder API. 2. Avoid fork-based architectures for encoding services that accept untrusted input. Use thread-based or container-isolated workers instead, which prevent crash oracle attacks. 3. Restrict access to encoding services to trusted clients only. Do not expose SVC encoder configuration or frame submission to untrusted network input. 4. For Firefox and Thunderbird, ensure browsers are updated to versions that include the patched libaom (v3.14.0 or later). 5. Enable all available exploit mitigations (ASLR, PIE, stack canaries, CFI) on encoding service binaries. Workaround: To mitigate this issue, restrict the processing of untrusted tar archives by the Ray WebDataset reader. Ensure that only verified and trusted data sources are supplied to the `read_webdataset()` function. Implement strict access controls and input validation for data ingestion pipelines that interact with Ray's WebDataset reader to prevent the introduction of malicious archives. 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: To mitigate this issue, avoid processing VobSub subtitle files from untrusted or unknown sources. For applications that utilize FFmpeg's VobSub demuxer, consider …

🔗 References (36)