Veille CVE

Mai 2026

8 CVE

Critique 0 Élevée 6 Moyenne 2 Faible 0 Non évaluée 0 Exploitées (KEV) Tri : plus récentes « Red Hat Exploit Intelligence » ✕
  1. CVE-2026-45292 5.3 Moyenne

    open-telemetry opentelemetry-java · io.opentelemetry opentelemetry-api · io.opentelemetry opentelemetry-extension-trace-propagators · Red Hat Data Grid 8.6.2

    opentelemetry-java is the Java implementation of the OpenTelemetry API for recording telemetry, and SDK for managing telemetry recorded by the API. Prior to 1.62.0, a vulnerability affects the baggage propagation implementation in opentelemetry-api and opentelemetry-extension-trace-propagators. Parsing oversized baggage causes unbounded memory allocation and CPU consumption. Because baggage is automatically re-injected into every outgoing request, the effect can fan out to downstream services that never received the original malicious request. This vulnerability is fixed in 1.62.0.

  2. CVE-2026-48710 6.5 Moyenne Exploitée

    Kludex starlette · Red Hat AI Inference Server 3.3 · Red Hat Ansible Automation Platform 2.6 · Red Hat Ansible Automation Platform 2.7

    Starlette is a lightweight ASGI framework/toolkit. Prior to version 1.0.1, the HTTP `Host` request header was not validated before being used to reconstruct `request.url`. Because the routing algorithm relies on the raw HTTP path while `request.url` is rebuilt from the `Host` header, a malformed header could make `request.url.path` differ from the path that was actually requested. Middleware and endpoints that apply security restrictions based on `request.url` (rather than the raw `scope` path) could therefore be bypassed. Users should upgrade to a version greater than or equal to version 1.0.1, which validates the `Host` header against the grammar of RFC 9112 §3.2 / RFC 3986 §3.2.2 when constructing `request.url` and falls back to `scope["server"]` for malformed values.

  3. CVE-2026-44209 7.5 Élevée

    masci banks · Red Hat Exploit Intelligence · Red Hat OpenShift Lightspeed · Red Hat Ansible Automation Platform 2

    Banks generates meaningful LLM prompts using a template language that makes sense. Prior to 2.4.2, banks uses jinja2.Environment() (unsandboxed) to render prompt templates. Applications that pass user-supplied strings as the template argument to Prompt() are vulnerable to Server-Side Template Injection (SSTI), which can lead to Remote Code Execution (RCE) on the host system. This vulnerability is fixed in 2.4.2.

  4. CVE-2026-47102 8.8 Élevée

    BerriAI litellm · Red Hat Exploit Intelligence · Red Hat Ansible Automation Platform 2 · Red Hat OpenShift AI (RHOAI)

    LiteLLM prior to 1.83.10 allows a user to modify their own user_role via the /user/update endpoint. While the endpoint correctly restricts users to updating only their own account, it does not restrict which fields may be changed. A user who can reach this endpoint can set their role to proxy_admin, gaining full administrative access to LiteLLM including all users, teams, keys, models, and prompt history. Users with the org_admin role have legitimate access to this endpoint and can exploit this vulnerability without chaining any additional flaw.

  5. CVE-2026-47101 8.8 Élevée

    BerriAI litellm · Red Hat Exploit Intelligence · Red Hat Ansible Automation Platform 2 · Red Hat OpenShift AI (RHOAI)

    LiteLLM prior to 1.83.14 allows an authenticated internal_user to create API keys with access to routes that their role does not permit. When generating a key, the allowed_routes field is stored without verifying that the specified routes fall within the user's own permissions. A key created with access to admin-only routes can then be used to reach those routes successfully, bypassing the role-based access controls that would otherwise block the request, enabling full privilege escalation from internal_user to proxy_admin.

  6. CVE-2026-42561 7.5 Élevée

    Kludex python-multipart · Red Hat Ansible Automation Platform 2.6 · Red Hat Ansible Automation Platform 2.7 · Red Hat Migration Toolkit for Applications 8.2

    Python-Multipart is a streaming multipart parser for Python. Prior to 0.0.27, python-multipart has a denial of service vulnerability in multipart part header parsing. When parsing multipart/form-data, MultipartParser previously had no limit on the number of part headers or the size of an individual part header. An attacker could send a request with either many repeated headers without terminating the header block or a single very large header value, causing excessive CPU work before request rejection or completion. This vulnerability is fixed in 0.0.27.

  7. CVE-2026-42271 8.8 Élevée Exploitée

    BerriAI litellm · Red Hat OpenShift AI 2.25 · Red Hat OpenShift AI 3.3 · Red Hat OpenShift AI 3.4

    LiteLLM is a proxy server (AI Gateway) to call LLM APIs in OpenAI (or native) format. From version 1.74.2 to before version 1.83.7, two endpoints used to preview an MCP server before saving it — POST /mcp-rest/test/connection and POST /mcp-rest/test/tools/list — accepted a full server configuration in the request body, including the command, args, and env fields used by the stdio transport. When called with a stdio configuration, the endpoints attempted to connect, which spawned the supplied command as a subprocess on the proxy host with the privileges of the proxy process. The endpoints were gated only by a valid proxy API key, with no role check. Any authenticated user — including holders of low-privilege internal-user keys — could therefore run arbitrary commands on the host. This issue has been patched in version 1.83.7.

  8. CVE-2026-42203 8.8 Élevée

    BerriAI litellm · Red Hat Exploit Intelligence · Red Hat Ansible Automation Platform 2 · Red Hat OpenShift AI (RHOAI)

    LiteLLM is a proxy server (AI Gateway) to call LLM APIs in OpenAI (or native) format. From version 1.80.5 to before version 1.83.7, the POST /prompts/test endpoint accepted user-supplied prompt templates and rendered them without sandboxing. A crafted template could run arbitrary code inside the LiteLLM Proxy process. The endpoint only checks that the caller presents a valid proxy API key, so any authenticated user could reach it. Depending on how the proxy is deployed, this could expose secrets in the process environment (such as provider API keys or database credentials) and allow commands to be run on the host. This issue has been patched in version 1.83.7.