CVE-2026-34715: Ewe Ewe Has Improper Neutralization Of Vulnerability

MODERATE
Advisory Identifier: GHSA-x2w3-23jr-hrpf
CVSS 5.3
CWE-113
Published
Advisory Summary

CVE-2026-34715 is a MODERATE (CVSS 5.3) ewe has improper neutralization of vulnerability (CWE-113: Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Request/Response Splitting')) affecting Ewe libraries in the Hex ecosystem. The issue involves ewe has improper neutralization of crlf sequences in http headers (http request/response splitting). Remediation is available by upgrading affected packages to version 3.0.6.

CVE-2026-34715 at a Glance

CVE Identifier CVE-2026-34715
GHSA Identifier GHSA-x2w3-23jr-hrpf
Severity MODERATE
CVSS v3.1 Base Score 5.3
CWE Classification CWE-113: Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Request/Response Splitting')
Affected Product Ewe
Package Ecosystem Hex
Published Date
Last Updated

Security Impact

CVSS: 5.3

The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N).

Attack Vector Network (AV:N)
Attack Complexity Low (AC:L)
Privileges Required None (PR:N)
User Interaction None (UI:N)
Scope Unchanged (S:U)
Confidentiality None (C:N)
Integrity Low (I:L)
Availability None (A:N)

How to Fix CVE-2026-34715

To remediate this vulnerability, upgrade all affected Ewe dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

ewe fixed: 3.0.6
Upgrade ewe to 3.0.6
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

inspect dependencies for ewe

How to Check if You Are Affected

To determine whether your application is affected by CVE-2026-34715, inspect your project dependencies for Ewe:

inspect dependencies for ewe

Analyze the terminal output to locate any version of Ewe in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 3.0.6), your application is affected.

Note: Verify declared build manifests and deployed runtime container environments.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-113: Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Request/Response Splitting'), where the product receives data from an http agent/component (e.g., web server, proxy, browser, etc.), but it does not neutralize or incorrectly neutralizes cr and lf characters before the data is included in outgoing http headers. In Ewe, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

### Summary 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. ### Details **File:** `src/ewe/internal/encoder.gleam` **Vulnerable code:** ```gleam fn encode_headers(headers: List(#(String, String))) -> BitArray { let headers = list.fold(headers, <<>>, fn(acc, headers) { let #(key, value) = headers <<acc:bits, key:utf8, ": ", value:utf8, "\r\n">> }) <<headers:bits, "\r\n">> } ``` Both `key` and `value` are embedded directly into the `BitArray` output. If either contains `\r\n`, the resulting bytes become a structurally valid but attacker-controlled HTTP response, terminating the current header early and injecting new headers or a second HTTP response. **Contrast with request parsing** (`src/ewe/internal/http1.gleam`): incoming header values are protected: ```gleam use value <- try( validate_field_value(value) |> replace_error(InvalidHeaders) ) ``` No analogous validation exists for outgoing header values in the encoder. The solution is to strip or reject `\r` (0x0D) and `\n` (0x0A) from all header key and value strings in `encode_headers` before encoding, mirroring the validation already applied to incoming request headers via `validate_field_value()` ### PoC An ewe application echoes a user-supplied redirect URL into a `Location` header: ```gleam fn handle_request(req: Request) -> Response { let redirect_url = request.get_query(req) |> result.try(list.key_find(_, "next")) |> result.unwrap("/home") response.new(302) |> response.set_header("location", redirect_url) |> response.set_body(ewe.Empty) } ``` Attacker request: ```bash printf 'GET /?next=https://example.com%%0d%%0aX-Injected:%%20true HTTP/1.1\r\nHost: localhost\r\n\r\n' | nc -w 2 localhost 8080 ``` Resulting response: ``` HTTP/1.1 302 Found location: https://example.com X-Injected: true content-length: 0 date: Tue, 24 Mar 2026 07:53:00 GMT connection: keep-alive ``` The `X-Injected: true` header appears as a separate response header, confirming that CRLF sequences in user input are not sanitized by the encoder.

CVE-2026-34715 Affected Ewe Versions

1 component(s)
Fixed Versions:
3.0.6
Product / Package Ecosystem Affected Versions Fixed Version
ewe
Hex
< 3.0.6
3.0.6

References

Frequently Asked Questions

What is CVE-2026-34715?
CVE-2026-34715 is a security vulnerability in Ewe involving ewe Has Improper Neutralization of CRLF Sequences in HTTP Headers (HTTP Request/Response Splitting) under CWE-113: Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Request/Response Splitting').
Which Ewe versions are affected?
Affected versions include releases prior to 3.0.6 across affected packages: ewe.
What version fixes CVE-2026-34715?
Upgrading to 3.0.6 (or the latest patched release for your respective branch) resolves the vulnerability.
Is ewe affected?
Yes, ewe is affected in releases prior to 3.0.6. Upgrade your dependency to 3.0.6 or later.
What is the CVSS score of CVE-2026-34715?
CVE-2026-34715 has a CVSS v3.1 base score of 5.3 (MODERATE) with vector string CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N.
What CWE is associated with CVE-2026-34715?
CVE-2026-34715 is classified under CWE-113: Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Request/Response Splitting') (The product receives data from an HTTP agent/component (e.g., web server, proxy, browser, etc.), but it does not neutralize or incorrectly neutralizes CR and LF characters before the data is included in outgoing HTTP headers.).
How can I check Hex dependencies for CVE-2026-34715?
Run the dependency tree command: 'inspect dependencies for ewe'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-x2w3-23jr-hrpf",
  "modified" : "2026-04-06T17:25:10Z",
  "published" : "2026-04-01T22:18:27Z",
  "aliases" : [ "CVE-2026-34715" ],
  "summary" : "ewe Has Improper Neutralization of CRLF Sequences in HTTP Headers (HTTP Request/Response Splitting)",
  "details" : "### Summary\n\nThe `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.\n\nNotably, 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.\n\n### Details\n\n**File:** `src/ewe/internal/encoder.gleam`\n\n**Vulnerable code:**\n```gleam\nfn encode_headers(headers: List(#(String, String))) -> BitArray {\n  let headers =\n    list.fold(headers, <<>>, fn(acc, headers) {\n      let #(key, value) = headers\n      <<acc:bits, key:utf8, \": \", value:utf8, \"\\r\\n\">>\n    })\n\n  <<headers:bits, \"\\r\\n\">>\n}\n```\n\nBoth `key` and `value` are embedded directly into the `BitArray` output. If either contains `\\r\\n`, the resulting bytes become a structurally valid but attacker-controlled HTTP response, terminating the current header early and injecting new headers or a second HTTP response.\n\n**Contrast with request parsing** (`src/ewe/internal/http1.gleam`): incoming header values are protected:\n```gleam\nuse value <- try(\n  validate_field_value(value) |> replace_error(InvalidHeaders)\n)\n```\n\nNo analogous validation exists for outgoing header values in the encoder. The solution is to strip or reject `\\r` (0x0D) and `\\n` (0x0A) from all header key and value strings in `encode_headers` before encoding, mirroring the validation already applied to incoming request headers via `validate_field_value()`\n\n### PoC\n\nAn ewe application echoes a user-supplied redirect URL into a `Location` header:\n\n```gleam\nfn handle_request(req: Request) -> Response {\n  let redirect_url =\n    request.get_query(req)\n    |> result.try(list.key_find(_, \"next\"))\n    |> result.unwrap(\"/home\")\n\n  response.new(302)\n  |> response.set_header(\"location\", redirect_url)\n  |> response.set_body(ewe.Empty)\n}\n```\n\nAttacker request:\n```bash\nprintf 'GET /?next=https://example.com%%0d%%0aX-Injected:%%20true HTTP/1.1\\r\\nHost: localhost\\r\\n\\r\\n' | nc -w 2 localhost 8080\n```\n\nResulting response:\n```\nHTTP/1.1 302 Found\nlocation: https://example.com\nX-Injected: true\ncontent-length: 0\ndate: Tue, 24 Mar 2026 07:53:00 GMT\nconnection: keep-alive\n\n\n```\n\nThe `X-Injected: true` header appears as a separate response header, confirming that CRLF sequences in user input are not sanitized by the encoder.",
  "severity" : [ {
    "type" : "CVSS_V3",
    "score" : "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "Hex",
      "name" : "ewe"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "fixed" : "3.0.6"
      } ]
    } ]
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/vshakitskiy/ewe/security/advisories/GHSA-x2w3-23jr-hrpf"
  }, {
    "type" : "ADVISORY",
    "url" : "https://nvd.nist.gov/vuln/detail/CVE-2026-34715"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/vshakitskiy/ewe/commit/ce4ff214d32626a10fda9398dc94a2d720e17446"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/vshakitskiy/ewe"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/vshakitskiy/ewe/releases/tag/v3.0.6"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-113" ],
    "severity" : "MODERATE",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-04-01T22:18:27Z",
    "nvd_published_at" : "2026-04-02T18:16:32Z"
  }
}