Jtdowney

**Name of the Vulnerable Software and Affected Versions** ewe versions 0.8.0 through 3.0.4 **Description** ewe, a Gleam web server, is affected by an issue in the `handle trailers` function. When encountering rejected trailer headers (those that are forbidden or undeclared), the function enters an infinite loop. This occurs because the function recurses using the original buffer instead of advancing past the rejected header. The loop has no timeout or escape mechanism, causing the BEAM process to become permanently wedged at 100% CPU utilization. Any application utilizing `ewe.read body` on chunked requests is susceptible to this issue, and it can be exploited by any unauthenticated remote client. The issue is triggered before control returns to application code, preventing application-level workarounds. A proof of concept involves sending a chunked request with a forbidden trailer, such as 'host', which causes the server to hang. Concurrent requests can exhaust server resources, leading to stuck processes with continuously increasing reduction counts. The vulnerable code resides within the `handle trailers` function, specifically in the `False`/`Error` branches where the original buffer is incorrectly used for recursion. **Recommendations** Versions prior to 3.0.5 are vulnerable. Update to version 3.0.5 or later to resolve the issue.

**Name of the Vulnerable Software and Affected Versions** ewe versions 0.6.0 through 3.0.4 **Description** ewe, a Gleam web server, is susceptible to authentication bypass and spoofed proxy-trust headers. The server's handling of chunked transfer encoding trailers merges declared trailer fields into request headers after body parsing. However, the denylist only blocks nine header names. A malicious client can exploit this by declaring headers in the Trailer field and appending them after the final chunk, causing `request.set header` to overwrite legitimate values. This allows attackers to forge authentication credentials, hijack sessions, bypass IP-based rate limiting, or spoof proxy-trust headers in downstream middleware that reads headers after `ewe.read body` is called. The issue stems from the `handle trailers` function (`ewe/internal/http1.gleam:493`) which uses `request.set header` (line 517) and a limited denylist (line 534). Security-sensitive headers like `authorization`, `cookie`, `proxy-authorization`, `x-forwarded-for`, `x-forwarded-host`, `x-forwarded-proto`, and `x-real-ip` are not blocked and can be injected or overwritten. A proof of concept demonstrates injecting or overwriting headers such as `authorization` and `x-forwarded-for` using crafted HTTP requests with the `Trailer` header. **Recommendations** Versions 0.6.0 through 3.0.4 are affected and should be updated to version 3.0.5 or later. Expand the denylist in the `is forbidden trailer` function to include `authorization`, `cookie`, `set-cookie`, `proxy-authorization`, `x-forwarded-for`, `x-forwarded-host`, `x-forwarded-proto`, and `x-real-ip`. Alternatively, switch to an allowlist model that only permits explicitly safe trailer field names.