CVE-2026-66778

The vulnerability in SAP Approuter is a header injection flaw stemming from its default-forwarding architecture — the component passes through request headers to downstream microservices without sufficient sanitization, allowing attackers to inject or manipulate headers that should be blocked at the boundary. The CVSS complexity rating of 'Low' is telling: exploitation requires nothing more sophisticated than sending crafted headers, which signals this is a design-level failure rather than an implementation oversight. The 5.3 score should not minimize concern. While it captures direct impact, Approuter sits at an entry point forwarding to multiple backend services simultaneously — a boundary enforcement failure here cascades to every downstream service that trusts the forwarded request. Those services built their own defenses on the assumption that the entry point sanitized headers. The vulnerability becomes more severe when you consider that Approuter often handles authentication tokens, session cookies, and authorization context in transit. The real exposure isn't just a single request's data leak — it's potentially every resource those tokens authorize. The core architectural problem is the denylist model itself: SAP designed Approuter to forward headers by default, forcing developers and security teams to anticipate every dangerous header (Host, X-Forwarded-*, Content-Length, Transfer-Encoding, and variants) rather than the tool operating on deny-by-default. This is the same pattern that produced SSRF, request smuggling, and header injection vulnerabilities across countless proxies and API gateways. The fix for each individual header CVE reinforces the denylist paradigm rather than challenging it — the list grows but never contracts, because institutional memory of why each entry was added decays while the code persists. What you should do: audit whether Approuter is processing authentication tokens or session context that could be exposed through forwarded requests; treat the current denylist as incomplete rather than comprehensive; and seriously evaluate whether allowlist-based forwarding should replace the denylist model — not just for this component, but across any middleware that sits at a security boundary. The question SAP's architecture must answer is whether Approuter is routing infrastructure or security infrastructure — because those require fundamentally different design philosophies, and the current denylist-based approach suggests the former while customers likely assume the latter.

Reviewed through automated stages and approved by a human before publication.