https://seclists.org/oss-sec/2026/q4/480: Apache Traffic Server: heap-buffer-overflow via HTTP Host header (unbounded alloca pattern, 5 sites) — 90-day disclosure
Affected Software
Frequently Asked Questions
Which deployments are exposed to the described HTTP request path?
The described path is exposed when both proxy.config.http.request_header_max_size and proxy.config.http.header_field_max_size have been raised above the worker-thread stack size. Configurations using RECC_NULL have no upper bound and are therefore particularly relevant.
What does an attacker need to exploit the primary finding?
An unauthenticated remote attacker needs to send an HTTP request with a Host header large enough to drive hostname_len to an unsafe size, while the configured request and field size limits permit that header.
Is the default configuration affected by this specific path?
The report describes exploitation after administrators raise both relevant header-size limits beyond the worker-thread stack size. The stated defaults are 32 KiB; the report does not establish exploitation of this path under those defaults.
What can be done if an update is not immediately available?
Avoid RECC_NULL for the relevant header-size settings and keep proxy.config.http.request_header_max_size and proxy.config.http.header_field_max_size at or below the worker-thread stack size. This prevents the oversized Host header condition described in the report.
How can administrators determine whether their configuration is at risk?
Review the values of proxy.config.http.request_header_max_size and proxy.config.http.header_field_max_size, including whether either uses RECC_NULL. Also check whether the deployed source includes the HttpTransact.cc ModifyRequest alloca call using hostname_len derived from the Host header; the report says the pattern was present on master as of 2026-11-03.