Approved changes feed: RSS · Atom
cpe:2.3:a:vshakitskiy:ewe:*:*:*:*:*:*:*:*part: a version: * update: *
| Vendor | Vshakitskiy (85c9a158-4651-5e53-b3af-48811b7bb7a5) |
|---|---|
| Product | Ewe (31ab05dd-b0c0-5fa6-9680-b532a2619951) |
| Edition | * |
| Language | * |
| Software edition | * |
| Target software | * |
| Target hardware | * |
| Other | * |
Notes
Imported from gcve-enriched-dumps CVE data
PURL mappings
| PURL | Source | Last updated |
|---|---|---|
pkg:github/vshakitskiy/ewe |
purl2cpe | 2026-07-28 16:40:54.946527 |
Vulnerability references
| Identifier | cpeApplicability | Submitted | db.gcve.eu details | Rationale |
|---|---|---|---|---|
CVE:CVE-2026-34715 |
vulnerable | 2026-06-08 07:59:13.037474 |
ewe Has Improper Neutralization of CRLF Sequences in HTTP Headers (HTTP Request/Response Splitting)
MEDIUM (5.3)
ewe is a Gleam web server. Prior to version 3.0.6, the encode_headers function in src/ewe/internal/encoder.gleam directly interpolates response header keys and values into raw HTTP bytes without validating or stripping CRLF (\r\n) sequences. An application that passes user-controlled data into response headers (e.g., setting a Location redirect header from a request parameter) allows an attacker to inject arbitrary HTTP response content, leading to response splitting, cache poisoning, and possible cross-site scripting. Notably, ewe does validate CRLF in incoming request headers via validate_field_value() in the HTTP/1.1 parser — but provides no equivalent protection for outgoing response headers in the encoder. This issue has been patched in version 3.0.6.
Published: 2026-04-02T17:57:00.501Z
Updated: 2026-04-03T16:00:41.121Z |
Imported from gcve-enriched-dumps CVE data |
CVE:CVE-2026-32881 |
vulnerable | 2026-06-08 07:57:18.288285 |
ewe has an Overly Permissive List of Allowed Inputs
MEDIUM (5.3)
ewe is a Gleam web server. ewe is a Gleam web server. Versions 0.6.0 through 3.0.4 are vulnerable to authentication bypass or spoofed proxy-trust headers. Chunked transfer encoding trailer handling merges declared trailer fields into req.headers after body parsing, but the denylist only blocks 9 header names. A malicious client can exploit this by declaring these headers in the Trailer field and appending them after the final chunk, causing request.set_header to overwrite legitimate values (e.g., those set by a reverse proxy). This enables attackers to forge authentication credentials, hijack sessions, bypass IP-based rate limiting, or spoof proxy-trust headers in any downstream middleware that reads headers after ewe.read_body is called. This issue has been fixed in version 3.0.5.
Published: 2026-03-20T01:18:55.382Z
Updated: 2026-03-20T20:03:41.064Z Reference links |
Imported from gcve-enriched-dumps CVE data |
CVE:CVE-2026-32873 |
vulnerable | 2026-06-08 07:57:18.274058 |
ewe: Loop with Unreachable Exit Condition ('Infinite Loop')
HIGH (7.5)
ewe is a Gleam web server. Versions 0.8.0 through 3.0.4 contain a bug in the handle_trailers function where rejected trailer headers (forbidden or undeclared) cause an infinite loop. When handle_trailers encounters such a trailer, three code paths (lines 520, 523, 526) recurse with the original buffer (rest) instead of advancing past the rejected header (Buffer(header_rest, 0)), causing decoder.decode_packet to re-parse the same header on every iteration. The resulting loop has no timeout or escape — the BEAM process permanently wedges at 100% CPU. Any application that calls ewe.read_body on chunked requests is affected, and this is exploitable by any unauthenticated remote client before control returns to application code, making an application-level workaround impossible. This issue is fixed in version 3.0.5.
Published: 2026-03-20T01:13:39.665Z
Updated: 2026-03-20T18:08:59.660Z |
Imported from gcve-enriched-dumps CVE data |
Contribute
You can submit an edit proposal for this CPE entry or suggest a related product/vendor addition using the action button above.
Inspect record JSON
Open this panel to browse, search, copy or download the JSON record.