CWE-93
AllowedImproper Neutralization of CRLF Sequences ('CRLF Injection')
Abstraction: Base · Status: Draft
The product uses CRLF (carriage return line feeds) as a special element, e.g. to separate lines or records, but it does not neutralize or incorrectly neutralizes CRLF sequences from inputs.
385 vulnerabilities reference this CWE, most recent first.
GHSA-P77J-G7H5-R2VW
Vulnerability from github – Published: 2026-08-19 19:22 – Updated: 2026-08-19 19:23GeoLens 1.2.4 fixes a set of vulnerabilities, the most serious of which allow authenticated or anonymous users to obtain data and metadata for datasets they are not authorized to access.
Impact
- Private record metadata disclosure. Record contact, keyword, and distribution sub-resource endpoints did not re-authorize the backing dataset, so any authenticated user could read a private record's contact details (PII), keywords, and distributions. (Runtime-proven.)
- Private tile data via shared caches. Private raster and vector tiles were served with shared-cache (
Cache-Control: public) headers, so a shared cache (a CDN or the bundled reverse proxy) could retain private tile bytes and replay them to later unauthenticated requests, including unpublished public-dataset previews. - Private dataset title enumeration. The map visibility-check endpoint did not authorize read access to the map, allowing any editor to enumerate the titles of non-public datasets in any map by ID — including private maps owned by other users.
- SSRF via DNS rebinding. URL validation for user-supplied service URLs (probes, STAC/OGC API sources, manifest downloads) resolved DNS once and then let the HTTP client re-resolve at connect time, allowing a low-TTL domain to pass validation as a public address and connect to an internal/metadata address.
- Token leak + header injection in service preview. The remote-service preview path passed the authorization token to GDAL via the process environment without sanitization, leaking it through
/proc/<pid>/environand allowing CRLF header injection. - Unauthenticated STAC search DoS.
POST /searchdid not cap the size of GeoJSONintersectsgeometries (theGETsibling did). - API key written to access logs. The bundled reverse proxy logged the
api_keyquery-string credential in cleartext. - Security posture coupled to a logging flag. API documentation exposure and the Secure flag on the OAuth session cookie were keyed off the
LOG_JSONlogging flag rather than an explicit environment setting, so a production deployment at the default could expose/docsand emit a non-Secure session cookie. - Missing Content-Security-Policy (defense-in-depth). The web application shipped no
script-src/default-srcCSP, leaving no containment for token exfiltration if an XSS issue were introduced. - Weak default install credentials. The installer kept the published default database password and could silently retain the default admin password on a headless install.
Patches
Upgrade to GeoLens 1.2.4. No configuration changes are required for the authorization and cache fixes. Operators on a public, TLS-terminated deployment should additionally set ENVIRONMENT=production to make the production security posture explicit; deployments that do not set it retain their prior behavior.
Workarounds
None for the authorization/cache disclosure flaws — upgrading is required. The SSRF and STAC-DoS surfaces can be partially mitigated at the network/proxy layer (egress filtering to block link-local metadata addresses; a request-size limit on POST /search), but the code fix is the durable remedy.
References
- Release: https://github.com/geolens-io/geolens/releases/tag/v1.2.4
- Pull request: https://github.com/geolens-io/geolens/pull/243
- Prior related advisory: GHSA-p23g-mvhj-jh3j
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "geolens"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.2.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-1021",
"CWE-1392",
"CWE-200",
"CWE-285",
"CWE-400",
"CWE-524",
"CWE-532",
"CWE-918",
"CWE-93"
],
"github_reviewed": true,
"github_reviewed_at": "2026-08-19T19:22:59Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "GeoLens 1.2.4 fixes a set of vulnerabilities, the most serious of which allow authenticated or anonymous users to obtain data and metadata for datasets they are not authorized to access.\n\n### Impact\n\n- **Private record metadata disclosure.** Record contact, keyword, and distribution sub-resource endpoints did not re-authorize the backing dataset, so any authenticated user could read a private record\u0027s contact details (PII), keywords, and distributions. (Runtime-proven.)\n- **Private tile data via shared caches.** Private raster and vector tiles were served with shared-cache (`Cache-Control: public`) headers, so a shared cache (a CDN or the bundled reverse proxy) could retain private tile bytes and replay them to later unauthenticated requests, including unpublished public-dataset previews.\n- **Private dataset title enumeration.** The map visibility-check endpoint did not authorize read access to the map, allowing any editor to enumerate the titles of non-public datasets in any map by ID \u2014 including private maps owned by other users.\n- **SSRF via DNS rebinding.** URL validation for user-supplied service URLs (probes, STAC/OGC API sources, manifest downloads) resolved DNS once and then let the HTTP client re-resolve at connect time, allowing a low-TTL domain to pass validation as a public address and connect to an internal/metadata address.\n- **Token leak + header injection in service preview.** The remote-service preview path passed the authorization token to GDAL via the process environment without sanitization, leaking it through `/proc/\u003cpid\u003e/environ` and allowing CRLF header injection.\n- **Unauthenticated STAC search DoS.** `POST /search` did not cap the size of GeoJSON `intersects` geometries (the `GET` sibling did).\n- **API key written to access logs.** The bundled reverse proxy logged the `api_key` query-string credential in cleartext.\n- **Security posture coupled to a logging flag.** API documentation exposure and the Secure flag on the OAuth session cookie were keyed off the `LOG_JSON` logging flag rather than an explicit environment setting, so a production deployment at the default could expose `/docs` and emit a non-Secure session cookie.\n- **Missing Content-Security-Policy (defense-in-depth).** The web application shipped no `script-src`/`default-src` CSP, leaving no containment for token exfiltration if an XSS issue were introduced.\n- **Weak default install credentials.** The installer kept the published default database password and could silently retain the default admin password on a headless install.\n\n### Patches\n\nUpgrade to **GeoLens 1.2.4**. No configuration changes are required for the authorization and cache fixes. Operators on a public, TLS-terminated deployment should additionally set `ENVIRONMENT=production` to make the production security posture explicit; deployments that do not set it retain their prior behavior.\n\n### Workarounds\n\nNone for the authorization/cache disclosure flaws \u2014 upgrading is required. The SSRF and STAC-DoS surfaces can be partially mitigated at the network/proxy layer (egress filtering to block link-local metadata addresses; a request-size limit on `POST /search`), but the code fix is the durable remedy.\n\n### References\n\n- Release: https://github.com/geolens-io/geolens/releases/tag/v1.2.4\n- Pull request: https://github.com/geolens-io/geolens/pull/243\n- Prior related advisory: GHSA-p23g-mvhj-jh3j",
"id": "GHSA-p77j-g7h5-r2vw",
"modified": "2026-08-19T19:23:00Z",
"published": "2026-08-19T19:22:59Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/geolens-io/geolens/security/advisories/GHSA-p77j-g7h5-r2vw"
},
{
"type": "WEB",
"url": "https://github.com/geolens-io/geolens/pull/243"
},
{
"type": "ADVISORY",
"url": "https://github.com/advisories/GHSA-p23g-mvhj-jh3j"
},
{
"type": "PACKAGE",
"url": "https://github.com/geolens-io/geolens"
},
{
"type": "WEB",
"url": "https://github.com/geolens-io/geolens/releases/tag/v1.2.4"
}
],
"schema_version": "1.4.0",
"severity": [],
"summary": "GeoLens\u0027s authorization and cache-scope flaws disclose private dataset data and metadata to unauthorized users (fixed in 1.2.4)"
}
GHSA-P83Q-QMCG-VF64
Vulnerability from github – Published: 2022-05-17 02:46 – Updated: 2025-04-20 03:37HTTP header injection vulnerability in TS-WPTCAM firmware version 1.18 and earlier, TS-WPTCAM2 firmware version 1.00, TS-WLCE firmware version 1.18 and earlier, TS-WLC2 firmware version 1.18 and earlier, TS-WRLC firmware version 1.17 and earlier, TS-PTCAM firmware version 1.18 and earlier, TS-PTCAM/POE firmware version 1.18 and earlier may allow a remote attackers to display false information.
{
"affected": [],
"aliases": [
"CVE-2017-2111"
],
"database_specific": {
"cwe_ids": [
"CWE-93"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-04-28T16:59:00Z",
"severity": "MODERATE"
},
"details": "HTTP header injection vulnerability in TS-WPTCAM firmware version 1.18 and earlier, TS-WPTCAM2 firmware version 1.00, TS-WLCE firmware version 1.18 and earlier, TS-WLC2 firmware version 1.18 and earlier, TS-WRLC firmware version 1.17 and earlier, TS-PTCAM firmware version 1.18 and earlier, TS-PTCAM/POE firmware version 1.18 and earlier may allow a remote attackers to display false information.",
"id": "GHSA-p83q-qmcg-vf64",
"modified": "2025-04-20T03:37:01Z",
"published": "2022-05-17T02:46:12Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-2111"
},
{
"type": "WEB",
"url": "http://jvn.jp/en/jp/JVN46830433/index.html"
},
{
"type": "WEB",
"url": "http://www.iodata.jp/support/information/2017/camera201702"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/96620"
}
],
"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-P88M-4JFJ-68FV
Vulnerability from github – Published: 2026-06-19 14:21 – Updated: 2026-06-19 14:21Impact
undici's cookie parser in parseSetCookie percent-decodes cookie values via qsUnescape, turning encoded sequences like %0D%0A, %00, %3B, and %3D into their literal byte equivalents. RFC 6265 §5.4 does not specify any decoding and browsers do not decode either.
Applications that parse a Set-Cookie header and then forward the parsed value into a response header (proxies, middleware, SSR frameworks) become vulnerable to HTTP response header injection: an attacker-controlled upstream can inject arbitrary Set-Cookie, Location, or Cache-Control headers into the application's downstream response, enabling session fixation, open redirect, or cache poisoning.
Affected applications are those that use undici's cookie parsing (parseSetCookie, parseCookie, getSetCookies) and forward the parsed cookie value into a response header.
This was introduced in undici 7.0.0 via #3789.
Patches
Upgrade to undici v6.27.0, v7.28.0 or v8.5.0.
Workarounds
If upgrade is not immediately possible, do not forward values returned by parseSetCookie/parseCookie/getSetCookies directly into response headers; sanitize the value first to strip or reject CR, LF, NUL, ;, and = bytes.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "undici"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.27.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "undici"
},
"ranges": [
{
"events": [
{
"introduced": "7.0.0"
},
{
"fixed": "7.28.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "undici"
},
"ranges": [
{
"events": [
{
"introduced": "8.0.0"
},
{
"fixed": "8.5.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-9679"
],
"database_specific": {
"cwe_ids": [
"CWE-93"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-19T14:21:30Z",
"nvd_published_at": "2026-06-17T18:18:06Z",
"severity": "MODERATE"
},
"details": "## Impact\n\nundici\u0027s cookie parser in `parseSetCookie` percent-decodes cookie values via `qsUnescape`, turning encoded sequences like `%0D%0A`, `%00`, `%3B`, and `%3D` into their literal byte equivalents. RFC 6265 \u00a75.4 does not specify any decoding and browsers do not decode either.\n\nApplications that parse a `Set-Cookie` header and then forward the parsed value into a response header (proxies, middleware, SSR frameworks) become vulnerable to HTTP response header injection: an attacker-controlled upstream can inject arbitrary `Set-Cookie`, `Location`, or `Cache-Control` headers into the application\u0027s downstream response, enabling session fixation, open redirect, or cache poisoning.\n\nAffected applications are those that use undici\u0027s cookie parsing (`parseSetCookie`, `parseCookie`, `getSetCookies`) and forward the parsed cookie value into a response header.\n\nThis was introduced in undici 7.0.0 via [#3789](https://github.com/nodejs/undici/pull/3789).\n\n## Patches\n\nUpgrade to undici v6.27.0, v7.28.0 or v8.5.0.\n\n## Workarounds\n\nIf upgrade is not immediately possible, do not forward values returned by `parseSetCookie`/`parseCookie`/`getSetCookies` directly into response headers; sanitize the value first to strip or reject CR, LF, NUL, `;`, and `=` bytes.",
"id": "GHSA-p88m-4jfj-68fv",
"modified": "2026-06-19T14:21:30Z",
"published": "2026-06-19T14:21:30Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/nodejs/undici/security/advisories/GHSA-p88m-4jfj-68fv"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-9679"
},
{
"type": "WEB",
"url": "https://cna.openjsf.org/security-advisories.html"
},
{
"type": "PACKAGE",
"url": "https://github.com/nodejs/undici"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "undici vulnerable to HTTP header injection via Set-Cookie percent-decoding"
}
GHSA-PM23-QJX3-GG3F
Vulnerability from github – Published: 2022-05-24 17:31 – Updated: 2023-08-16 18:30A vulnerability in the Clientless SSL VPN (WebVPN) of Cisco Adaptive Security Appliance (ASA) Software and Cisco Firepower Threat Defense (FTD) Software could allow an unauthenticated, remote attacker to inject arbitrary HTTP headers in the responses of the affected system. The vulnerability is due to improper input sanitization. An attacker could exploit this vulnerability by persuading a user of the interface to click a crafted link. A successful exploit could allow the attacker to conduct a CRLF injection attack, adding arbitrary HTTP headers in the responses of the system and redirecting the user to arbitrary websites.
{
"affected": [],
"aliases": [
"CVE-2020-3561"
],
"database_specific": {
"cwe_ids": [
"CWE-74",
"CWE-93"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-10-21T19:15:00Z",
"severity": "MODERATE"
},
"details": "A vulnerability in the Clientless SSL VPN (WebVPN) of Cisco Adaptive Security Appliance (ASA) Software and Cisco Firepower Threat Defense (FTD) Software could allow an unauthenticated, remote attacker to inject arbitrary HTTP headers in the responses of the affected system. The vulnerability is due to improper input sanitization. An attacker could exploit this vulnerability by persuading a user of the interface to click a crafted link. A successful exploit could allow the attacker to conduct a CRLF injection attack, adding arbitrary HTTP headers in the responses of the system and redirecting the user to arbitrary websites.",
"id": "GHSA-pm23-qjx3-gg3f",
"modified": "2023-08-16T18:30:19Z",
"published": "2022-05-24T17:31:48Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-3561"
},
{
"type": "WEB",
"url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-asa-ftd-crlf-inj-BX9uRwSn"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-PRJC-XC24-CV4P
Vulnerability from github – Published: 2025-11-18 18:32 – Updated: 2025-11-18 18:32An improper neutralization of crlf sequences ('crlf injection') in Fortinet FortiMail 7.6.0 through 7.6.3, FortiMail 7.4.0 through 7.4.5, FortiMail 7.2 all versions, FortiMail 7.0 all versions may allow an attacker to inject headers in the response via convincing a user to click on a specifically crafted link
{
"affected": [],
"aliases": [
"CVE-2025-54972"
],
"database_specific": {
"cwe_ids": [
"CWE-93"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-11-18T17:16:03Z",
"severity": "MODERATE"
},
"details": "An improper neutralization of crlf sequences (\u0027crlf injection\u0027) in Fortinet FortiMail 7.6.0 through 7.6.3, FortiMail 7.4.0 through 7.4.5, FortiMail 7.2 all versions, FortiMail 7.0 all versions may allow an attacker to inject headers in the response via convincing a user to click on a specifically crafted link",
"id": "GHSA-prjc-xc24-cv4p",
"modified": "2025-11-18T18:32:54Z",
"published": "2025-11-18T18:32:54Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-54972"
},
{
"type": "WEB",
"url": "https://fortiguard.fortinet.com/psirt/FG-IR-25-634"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-PV9C-9MFH-HVXQ
Vulnerability from github – Published: 2026-03-24 19:13 – Updated: 2026-03-27 22:00Summary
.ics serialization does not properly sanitize URI property values, enabling ICS injection through attacker-controlled input, adding arbitrary calendar lines to the output.
Details
Icalendar::Values::Uri falls back to the raw input string when URI.parse fails and later serializes it with value.to_s without removing or escaping \r or \n characters. That value is embedded directly into the final ICS line by the normal serializer, so a payload containing CRLF can terminate the original property and create a new ICS property or component. (It looks like you can inject via url, source, image, organizer, attach, attendee, conference, tzurl because of this)
Relevant code:
- lib/icalendar/values/uri.rb:16
PoC
Run the following with the library loaded:
require "icalendar/value"
require "icalendar/values/uri"
v = Icalendar::Values::Uri.new("https://a.example/ok\r\nATTENDEE:mailto:evil@example.com")
puts v.to_ical(Icalendar::Values::Text)
output:
;VALUE=URI:https://a.example/ok
ATTENDEE:mailto:evil@example.com
Impact
Applications that generate .ics files from partially untrusted metadata are impacted. As a result, downstream calendar clients or importers may process attacker-supplied content as if it were legitimate event data, such as added attendees, modified URLs, alarms, or other calendar fields.
Fix
Reject raw CR and LF characters in URI-typed values before serialization, or escape/encode them so they cannot terminate the current ICS content line.
{
"affected": [
{
"package": {
"ecosystem": "RubyGems",
"name": "icalendar"
},
"ranges": [
{
"events": [
{
"introduced": "2.0.0"
},
{
"fixed": "2.12.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-33635"
],
"database_specific": {
"cwe_ids": [
"CWE-93"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-24T19:13:41Z",
"nvd_published_at": "2026-03-26T21:17:07Z",
"severity": "MODERATE"
},
"details": "### Summary\n.ics serialization does not properly sanitize URI property values, enabling ICS injection through attacker-controlled input, adding arbitrary calendar lines to the output.\n\n### Details\n`Icalendar::Values::Uri` falls back to the raw input string when `URI.parse` fails and later serializes it with `value.to_s` without removing or escaping `\\r` or `\\n` characters. That value is embedded directly into the final ICS line by the normal serializer, so a payload containing CRLF can terminate the original property and create a new ICS property or component. (It looks like you can inject via url, source, image, organizer, attach, attendee, conference, tzurl because of this)\n\nRelevant code:\n- `lib/icalendar/values/uri.rb:16`\n\n### PoC\nRun the following with the library loaded:\n\n```ruby\nrequire \"icalendar/value\"\nrequire \"icalendar/values/uri\"\n\nv = Icalendar::Values::Uri.new(\"https://a.example/ok\\r\\nATTENDEE:mailto:evil@example.com\")\nputs v.to_ical(Icalendar::Values::Text)\n```\n\noutput:\n\n```text\n;VALUE=URI:https://a.example/ok\nATTENDEE:mailto:evil@example.com\n```\n\n### Impact\nApplications that generate `.ics` files from partially untrusted metadata are impacted. As a result, downstream calendar clients or importers may process attacker-supplied content as if it were legitimate event data, such as added attendees, modified URLs, alarms, or other calendar fields.\n\n## Fix\nReject raw CR and LF characters in `URI`-typed values before serialization, or escape/encode them so they cannot terminate the current ICS content line.",
"id": "GHSA-pv9c-9mfh-hvxq",
"modified": "2026-03-27T22:00:24Z",
"published": "2026-03-24T19:13:41Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/icalendar/icalendar/security/advisories/GHSA-pv9c-9mfh-hvxq"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33635"
},
{
"type": "WEB",
"url": "https://github.com/icalendar/icalendar/commit/b8d23b490363ee5fffaec1d269a8618a912ca265"
},
{
"type": "PACKAGE",
"url": "https://github.com/icalendar/icalendar"
},
{
"type": "WEB",
"url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/icalendar/CVE-2026-33635.yml"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "iCalendar has ICS injection via unsanitized URI property values"
}
GHSA-PX9F-WHJ3-246M
Vulnerability from github – Published: 2026-07-29 15:29 – Updated: 2026-07-29 15:29Summary
Req's multipart form encoder interpolates the per-part name, filename, and content_type directly into the part headers without escaping. An attacker who can influence any of those values can inject CRLF-separated header lines, smuggle additional form fields, or prepend a whole extra part into the request the victim service sends downstream.
Details
Req.Utils.encode_form_part/2 in lib/req/utils.ex builds the per-part header iodata by concatenating the three caller-supplied strings verbatim into content-disposition: form-data; name="<name>"; filename="<filename>" and content-type: <content_type>. There is no CRLF stripping, no quote escaping, and no validation. A value containing "\r\n closes the surrounding quoted value and starts a new header line; an additional \r\n--<boundary> terminates the current part and lets the attacker prepend a smuggled part.
The flaw is reachable through every supported way of supplying a part. It is especially easy to hit when value is a %File.Stream{}, because filename then defaults to Path.basename(stream.path) and POSIX filenames may legitimately contain \r and \n. RFC 7578 / WHATWG form-data requires percent-encoding ", CR, and LF in these fields; the fix adopts that behavior.
PoC
- Construct a malicious
filenamesuch asharmless.txt"\r\nX-Smuggled: marker\r\nContent-Disposition: form-data; name="pwned. - Call
Req.post!(url, form_multipart: [upload: {"benign body", filename: <malicious>, content_type: "text/plain"}]). - The emitted multipart body contains a real
X-Smuggled:header line and an extraContent-Dispositionforname="pwned", alongside Req's legitimate headers.
Impact
HTTP request smuggling / multipart parameter smuggling in the HTTP client. Any application using Req to send form_multipart requests where any of name, filename, or content_type can be influenced by an untrusted source is affected, most commonly upload proxies and re-uploaders that derive filename from Path.basename/1 on a user-controlled path.
{
"affected": [
{
"package": {
"ecosystem": "Hex",
"name": "req"
},
"ranges": [
{
"events": [
{
"introduced": "0.5.3"
},
{
"fixed": "0.6.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-49756"
],
"database_specific": {
"cwe_ids": [
"CWE-93"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-29T15:29:14Z",
"nvd_published_at": "2026-06-08T16:16:44Z",
"severity": "MODERATE"
},
"details": "### Summary\n\nReq\u0027s multipart form encoder interpolates the per-part `name`, `filename`, and `content_type` directly into the part headers without escaping. An attacker who can influence any of those values can inject CRLF-separated header lines, smuggle additional form fields, or prepend a whole extra part into the request the victim service sends downstream.\n\n### Details\n\n`Req.Utils.encode_form_part/2` in `lib/req/utils.ex` builds the per-part header iodata by concatenating the three caller-supplied strings verbatim into `content-disposition: form-data; name=\"\u003cname\u003e\"; filename=\"\u003cfilename\u003e\"` and `content-type: \u003ccontent_type\u003e`. There is no CRLF stripping, no quote escaping, and no validation. A value containing `\"\\r\\n` closes the surrounding quoted value and starts a new header line; an additional `\\r\\n--\u003cboundary\u003e` terminates the current part and lets the attacker prepend a smuggled part.\n\nThe flaw is reachable through every supported way of supplying a part. It is especially easy to hit when `value` is a `%File.Stream{}`, because `filename` then defaults to `Path.basename(stream.path)` and POSIX filenames may legitimately contain `\\r` and `\\n`. RFC 7578 / WHATWG form-data requires percent-encoding `\"`, CR, and LF in these fields; the fix adopts that behavior.\n\n### PoC\n\n1. Construct a malicious `filename` such as `harmless.txt\"\\r\\nX-Smuggled: marker\\r\\nContent-Disposition: form-data; name=\"pwned`.\n2. Call `Req.post!(url, form_multipart: [upload: {\"benign body\", filename: \u003cmalicious\u003e, content_type: \"text/plain\"}])`.\n3. The emitted multipart body contains a real `X-Smuggled:` header line and an extra `Content-Disposition` for `name=\"pwned\"`, alongside Req\u0027s legitimate headers.\n\n### Impact\n\nHTTP request smuggling / multipart parameter smuggling in the HTTP client. Any application using Req to send `form_multipart` requests where any of `name`, `filename`, or `content_type` can be influenced by an untrusted source is affected, most commonly upload proxies and re-uploaders that derive `filename` from `Path.basename/1` on a user-controlled path.",
"id": "GHSA-px9f-whj3-246m",
"modified": "2026-07-29T15:29:15Z",
"published": "2026-07-29T15:29:14Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/wojtekmach/req/security/advisories/GHSA-px9f-whj3-246m"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-49756"
},
{
"type": "WEB",
"url": "https://github.com/wojtekmach/req/commit/74506ff2c5addf74df85d79dc726e9b2e264a8ba"
},
{
"type": "WEB",
"url": "https://cna.erlef.org/cves/CVE-2026-49756.html"
},
{
"type": "PACKAGE",
"url": "https://github.com/wojtekmach/req"
},
{
"type": "WEB",
"url": "https://github.com/wojtekmach/req/releases/tag/v0.6.0"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/EEF-CVE-2026-49756"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:L/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Req vulnerable to multipart form-data header injection via unescaped name/filename/content_type"
}
GHSA-Q768-X9M6-M9QP
Vulnerability from github – Published: 2022-07-21 20:31 – Updated: 2022-07-21 20:31Impact
Authorization headers are already cleared on cross-origin redirect in https://github.com/nodejs/undici/blob/main/lib/handler/redirect.js#L189, based on https://github.com/nodejs/undici/issues/872.
However, cookie headers which are sensitive headers and are official headers found in the spec, remain uncleared. There also has been active discussion of implementing a cookie store https://github.com/nodejs/undici/pull/1441, which suggests that there are active users using cookie headers in undici. As such this may lead to accidental leakage of cookie to a 3rd-party site or a malicious attacker who can control the redirection target (ie. an open redirector) to leak the cookie to the 3rd party site.
Patches
This was patched in v5.8.0.
Workarounds
By default, this vulnerability is not exploitable.
Do not enable redirections, i.e. maxRedirections: 0 (the default).
References
https://hackerone.com/reports/1635514 https://curl.se/docs/CVE-2018-1000007.html https://curl.se/docs/CVE-2022-27776.html
For more information
If you have any questions or comments about this advisory: * Open an issue in undici repository * To make a report, follow the SECURITY document
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "undici"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.8.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-31151"
],
"database_specific": {
"cwe_ids": [
"CWE-346",
"CWE-601",
"CWE-93"
],
"github_reviewed": true,
"github_reviewed_at": "2022-07-21T20:31:05Z",
"nvd_published_at": "2022-07-21T04:15:00Z",
"severity": "LOW"
},
"details": "### Impact\n\nAuthorization headers are already cleared on cross-origin redirect in\nhttps://github.com/nodejs/undici/blob/main/lib/handler/redirect.js#L189, based on https://github.com/nodejs/undici/issues/872.\n\nHowever, cookie headers which are sensitive headers and are official headers found in the spec, remain uncleared. There also has been active discussion of implementing a cookie store https://github.com/nodejs/undici/pull/1441, which suggests that there are active users using cookie headers in undici.\nAs such this may lead to accidental leakage of cookie to a 3rd-party site or a malicious attacker who can control the redirection target (ie. an open redirector) to leak the cookie to the 3rd party site.\n\n### Patches\n\nThis was patched in v5.8.0.\n\n### Workarounds\n\nBy default, this vulnerability is not exploitable.\nDo not enable redirections, i.e. `maxRedirections: 0` (the default). \n\n### References\n\nhttps://hackerone.com/reports/1635514\nhttps://curl.se/docs/CVE-2018-1000007.html\nhttps://curl.se/docs/CVE-2022-27776.html\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Open an issue in [undici repository](https://github.com/nodejs/undici/issues)\n* To make a report, follow the [SECURITY](https://github.com/nodejs/node/blob/HEAD/SECURITY.md) document\n",
"id": "GHSA-q768-x9m6-m9qp",
"modified": "2022-07-21T20:31:05Z",
"published": "2022-07-21T20:31:05Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/nodejs/undici/security/advisories/GHSA-q768-x9m6-m9qp"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-31151"
},
{
"type": "WEB",
"url": "https://github.com/nodejs/undici/issues/872"
},
{
"type": "WEB",
"url": "https://github.com/nodejs/undici/pull/1441"
},
{
"type": "WEB",
"url": "https://github.com/nodejs/undici/commit/0a5bee9465e627be36bac88edf7d9bbc9626126d"
},
{
"type": "WEB",
"url": "https://hackerone.com/reports/1635514"
},
{
"type": "PACKAGE",
"url": "https://github.com/nodejs/undici"
},
{
"type": "WEB",
"url": "https://github.com/nodejs/undici/blob/main/lib/handler/redirect.js#L189"
},
{
"type": "WEB",
"url": "https://github.com/nodejs/undici/releases/tag/v5.8.0"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20220909-0006"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "undici before v5.8.0 vulnerable to uncleared cookies on cross-host / cross-origin redirect"
}
GHSA-Q7JX-V53G-848W
Vulnerability from github – Published: 2026-07-10 00:03 – Updated: 2026-07-10 00:03Summary
Tesla.Multipart.add_content_type_param/2 appends caller-supplied strings to the multipart Content-Type header with no validation. A param value containing \r\n splits the header line, allowing an attacker who controls any content-type parameter (charset, boundary parameter, etc.) to inject arbitrary headers into the outbound HTTP request.
Details
add_content_type_param/2 in lib/tesla/multipart.ex stores the supplied string directly in multipart.content_type_params without any CR/LF check. headers/1 then joins all params with "; " and appends the result verbatim to the Content-Type header value. Because HTTP headers are delimited by \r\n, a param containing that sequence breaks out of the header field and introduces new header lines before the adapter writes the request to the socket.
The precondition is that untrusted input reaches add_content_type_param/2, which is the normal pattern for applications that accept user-supplied charset values, file type parameters, or any other content-type extension fields.
PoC
- Call
Tesla.Multipart.add_content_type_param/2with a value containing\r\nX-Injected: pwned. - Pass the resulting
Multipartstruct as the request body via any Tesla adapter. - The raw request on the wire contains
X-Injected: pwnedas a standalone header line.
Impact
Low severity (CVSS v4.0: 2.1). Any application using tesla 0.8.0 through 1.18.2 that passes untrusted input into Tesla.Multipart.add_content_type_param/2 is affected. Consequences range from forging arbitrary outbound request headers to potential request smuggling against the upstream server. Fixed in tesla 1.18.3.
Workarounds
Validate content-type parameter strings before passing them to Tesla.Multipart.add_content_type_param/2, rejecting any value that contains \r or \n.
Reesources
- Introduction commit: https://github.com/elixir-tesla/tesla/commit/6ebfdb9abe9c6f119408045b933d82462decd351
- Patch commit: https://github.com/elixir-tesla/tesla/commit/23601edac5d22ba9407b427967b5bdbda201aec2
{
"affected": [
{
"package": {
"ecosystem": "Hex",
"name": "tesla"
},
"ranges": [
{
"events": [
{
"introduced": "0.8.0"
},
{
"fixed": "1.18.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-48596"
],
"database_specific": {
"cwe_ids": [
"CWE-113",
"CWE-93"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-10T00:03:12Z",
"nvd_published_at": "2026-06-02T20:16:38Z",
"severity": "LOW"
},
"details": "### Summary\n\n`Tesla.Multipart.add_content_type_param/2` appends caller-supplied strings to the multipart `Content-Type` header with no validation. A param value containing `\\r\\n` splits the header line, allowing an attacker who controls any content-type parameter (charset, boundary parameter, etc.) to inject arbitrary headers into the outbound HTTP request.\n\n### Details\n\n`add_content_type_param/2` in `lib/tesla/multipart.ex` stores the supplied string directly in `multipart.content_type_params` without any CR/LF check. `headers/1` then joins all params with `\"; \"` and appends the result verbatim to the `Content-Type` header value. Because HTTP headers are delimited by `\\r\\n`, a param containing that sequence breaks out of the header field and introduces new header lines before the adapter writes the request to the socket.\n\nThe precondition is that untrusted input reaches `add_content_type_param/2`, which is the normal pattern for applications that accept user-supplied charset values, file type parameters, or any other content-type extension fields.\n\n### PoC\n\n1. Call `Tesla.Multipart.add_content_type_param/2` with a value containing `\\r\\nX-Injected: pwned`.\n2. Pass the resulting `Multipart` struct as the request body via any Tesla adapter.\n3. The raw request on the wire contains `X-Injected: pwned` as a standalone header line.\n\n### Impact\n\nLow severity (CVSS v4.0: 2.1). Any application using `tesla` 0.8.0 through 1.18.2 that passes untrusted input into `Tesla.Multipart.add_content_type_param/2` is affected. Consequences range from forging arbitrary outbound request headers to potential request smuggling against the upstream server. Fixed in tesla 1.18.3.\n\n### Workarounds\n\nValidate content-type parameter strings before passing them to `Tesla.Multipart.add_content_type_param/2`, rejecting any value that contains `\\r` or `\\n`.\n\n### Reesources\n\n* Introduction commit: https://github.com/elixir-tesla/tesla/commit/6ebfdb9abe9c6f119408045b933d82462decd351\n* Patch commit: https://github.com/elixir-tesla/tesla/commit/23601edac5d22ba9407b427967b5bdbda201aec2",
"id": "GHSA-q7jx-v53g-848w",
"modified": "2026-07-10T00:03:12Z",
"published": "2026-07-10T00:03:12Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/elixir-tesla/tesla/security/advisories/GHSA-q7jx-v53g-848w"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-48596"
},
{
"type": "WEB",
"url": "https://github.com/elixir-tesla/tesla/commit/23601edac5d22ba9407b427967b5bdbda201aec2"
},
{
"type": "WEB",
"url": "https://cna.erlef.org/cves/CVE-2026-48596.html"
},
{
"type": "PACKAGE",
"url": "https://github.com/elixir-tesla/tesla"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/EEF-CVE-2026-48596"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:L/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:N/SC:N/SI:L/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Tesla has CRLF injection in request `Content-Type` header via `add_content_type_param`"
}
GHSA-Q83Q-GHHM-P7G4
Vulnerability from github – Published: 2026-06-10 21:31 – Updated: 2026-06-19 18:32Metrics::Any::Adapter::Statsd versions before 0.04 for Perl does not protect against metric injections.
The statsd protocol (and extensions) allow mutiple metrics,separated by newlines, to be sent per packet.
The send method does not validate the contents of the metric names or values. If the names have newlines and statsd control characters (colon, pipe) then metric injections are possible.
Version 0.04 fixed this by modifying the _make method to block metric names with characters below ASCII 32 (which includes the newline), or colons or pipes.
{
"affected": [],
"aliases": [
"CVE-2026-50637"
],
"database_specific": {
"cwe_ids": [
"CWE-93"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-10T19:16:37Z",
"severity": "HIGH"
},
"details": "Metrics::Any::Adapter::Statsd versions before 0.04 for Perl does not protect against metric injections.\n\nThe statsd protocol (and extensions) allow mutiple metrics,separated by newlines, to be sent per packet.\n\nThe send method does not validate the contents of the metric names or values. If the names have newlines and statsd control characters (colon, pipe) then metric injections are possible.\n\nVersion 0.04 fixed this by modifying the _make method to block metric names with characters below ASCII 32 (which includes the newline), or colons or pipes.",
"id": "GHSA-q83q-ghhm-p7g4",
"modified": "2026-06-19T18:32:30Z",
"published": "2026-06-10T21:31:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-50637"
},
{
"type": "WEB",
"url": "https://metacpan.org/release/PEVANS/Metrics-Any-Adapter-Statsd-0.04/changes"
},
{
"type": "WEB",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46719"
},
{
"type": "WEB",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46720"
},
{
"type": "WEB",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46739"
},
{
"type": "WEB",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-50638"
},
{
"type": "WEB",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-50639"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:N",
"type": "CVSS_V3"
}
]
}
Mitigation
Avoid using CRLF as a special sequence.
Mitigation
Appropriately filter or quote CRLF sequences in user-controlled input.
CAPEC-15: Command Delimiters
An attack of this type exploits a programs' vulnerabilities that allows an attacker's commands to be concatenated onto a legitimate command with the intent of targeting other resources such as the file system or database. The system that uses a filter or denylist input validation, as opposed to allowlist validation is vulnerable to an attacker who predicts delimiters (or combinations of delimiters) not present in the filter or denylist. As with other injection attacks, the attacker uses the command delimiter payload as an entry point to tunnel through the application and activate additional attacks through SQL queries, shell commands, network scanning, and so on.
CAPEC-81: Web Server Logs Tampering
Web Logs Tampering attacks involve an attacker injecting, deleting or otherwise tampering with the contents of web logs typically for the purposes of masking other malicious behavior. Additionally, writing malicious data to log files may target jobs, filters, reports, and other agents that process the logs in an asynchronous attack pattern. This pattern of attack is similar to "Log Injection-Tampering-Forging" except that in this case, the attack is targeting the logs of the web server and not the application.