Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

CVE-2026-28368

Summary

CVE-2026-28368 is an Undertow request smuggling vulnerability involving inconsistent HTTP header name parsing. Red Hat describes the condition as specially crafted requests whose header names are interpreted differently by Undertow and an upstream proxy, allowing request smuggling when the two components disagree.

Red Hat rates the issue as Important with CVSS 3.1 score 8.7, using high attack complexity because exploitation depends on an upstream proxy/backend parser mismatch. NVD also lists a 9.1 Critical score, but the Red Hat CNA score better reflects the deployment prerequisite.

light-4j Applicability

light-4j uses Undertow through io.undertow:undertow-core, so dependency scanners can report this CVE for light-4j applications.

The issue is conditionally applicable only when malformed HTTP/1.1 requests pass through an upstream proxy, load balancer, gateway, or WAF that interprets header names differently from Undertow and forwards the ambiguous request to the light-4j origin. A direct client-to-Undertow path does not create the front-end/back-end desynchronization required for request smuggling.

The finding is not applicable, or is not exploitable, when:

  • The light-4j service is not deployed behind a permissive HTTP/1.1 proxy or load balancer.
  • The upstream proxy rejects malformed or ambiguous header names.
  • The edge-to-origin hop uses strict request validation and does not forward non-compliant header syntax.
  • The deployment uses HTTPS and HTTP/2 end to end, without translating malformed HTTP/1.1 traffic into the Undertow origin hop.

Mitigation

Red Hat’s public mitigation text says a broadly applicable mitigation is not available under its Product Security criteria. For light-4j deployments, the practical technical mitigation is still to remove the parser mismatch condition:

  • Use a fronting proxy, load balancer, gateway, or WAF that rejects malformed HTTP/1.1 header names.
  • Avoid forwarding raw, ambiguous, or normalized-but-non-compliant HTTP/1.1 requests to Undertow.
  • Prefer the default light-4j production posture: HTTPS enabled, clear HTTP disabled, HTTP/2 enabled, and unescaped URL characters disabled.
  • If the deployment requires an HTTP/1.1 hop from edge to light-4j, test the exact edge product and configuration for strict header-name validation.

Customer Response

This CVE is not a standalone application logic issue in light-4j; it is a proxy/backend HTTP parsing ambiguity in Undertow. A scanner can flag the Undertow dependency, but exploitability requires a permissive upstream HTTP/1.1 proxy path that forwards ambiguous header names to Undertow. In deployments where the edge rejects malformed headers or uses strict HTTPS/HTTP2 request handling to the service, the issue is not exploitable in light-4j.

References