Common Weakness Enumeration

CWE-93

Allowed

Improper Neutralization of CRLF Sequences ('CRLF Injection')

Abstraction: Base · Status: Draft

API response cwe.mitre.org

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.

456 vulnerabilities reference this CWE, most recent first.

GHSA-P69P-39VF-6X53

Vulnerability from github – Published: 2025-10-23 15:30 – Updated: 2025-10-23 18:31
VLAI
Details

CRLF-injection in KeeneticOS before 4.3 at "/auth" API endpoint allows attackers to take over the device via adding additional users with full permissions by managing the victim to open page with exploit.

Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-56007"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-93"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-10-23T15:15:39Z",
    "severity": "MODERATE"
  },
  "details": "CRLF-injection in KeeneticOS before 4.3 at \"/auth\" API endpoint allows attackers to take over the device via adding additional users with full permissions by managing the victim to open page with exploit.",
  "id": "GHSA-p69p-39vf-6x53",
  "modified": "2025-10-23T18:31:14Z",
  "published": "2025-10-23T15:30:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-56007"
    },
    {
      "type": "WEB",
      "url": "https://keenetic.com"
    },
    {
      "type": "WEB",
      "url": "https://keenetic.com/global/security#october-2025-web-api-vulnerabilities"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-P759-VW7C-CVG8

Vulnerability from github – Published: 2022-05-14 03:00 – Updated: 2025-04-12 12:57
VLAI
Details

Multiple CRLF injection vulnerabilities in session.c in sshd in OpenSSH before 7.2p2 allow remote authenticated users to bypass intended shell-command restrictions via crafted X11 forwarding data, related to the (1) do_authenticated1 and (2) session_x11_req functions.

Severity
6.4 (Medium)
CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2016-3115"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-93"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2016-03-22T10:59:00Z",
    "severity": "MODERATE"
  },
  "details": "Multiple CRLF injection vulnerabilities in session.c in sshd in OpenSSH before 7.2p2 allow remote authenticated users to bypass intended shell-command restrictions via crafted X11 forwarding data, related to the (1) do_authenticated1 and (2) session_x11_req functions.",
  "id": "GHSA-p759-vw7c-cvg8",
  "modified": "2025-04-12T12:57:53Z",
  "published": "2022-05-14T03:00:08Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2016-3115"
    },
    {
      "type": "WEB",
      "url": "https://bto.bluecoat.com/security-advisory/sa121"
    },
    {
      "type": "WEB",
      "url": "https://github.com/tintinweb/pub/tree/master/pocs/cve-2016-3115"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2018/09/msg00010.html"
    },
    {
      "type": "WEB",
      "url": "https://security.gentoo.org/glsa/201612-18"
    },
    {
      "type": "WEB",
      "url": "https://www.exploit-db.com/exploits/39569"
    },
    {
      "type": "WEB",
      "url": "https://www.freebsd.org/security/advisories/FreeBSD-SA-16:14.openssh.asc"
    },
    {
      "type": "WEB",
      "url": "http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/session.c"
    },
    {
      "type": "WEB",
      "url": "http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/session.c.diff?r1=1.281\u0026r2=1.282\u0026f=h"
    },
    {
      "type": "WEB",
      "url": "http://lists.fedoraproject.org/pipermail/package-announce/2016-April/183101.html"
    },
    {
      "type": "WEB",
      "url": "http://lists.fedoraproject.org/pipermail/package-announce/2016-April/183122.html"
    },
    {
      "type": "WEB",
      "url": "http://lists.fedoraproject.org/pipermail/package-announce/2016-March/178838.html"
    },
    {
      "type": "WEB",
      "url": "http://lists.fedoraproject.org/pipermail/package-announce/2016-March/179924.html"
    },
    {
      "type": "WEB",
      "url": "http://lists.fedoraproject.org/pipermail/package-announce/2016-March/180491.html"
    },
    {
      "type": "WEB",
      "url": "http://lists.fedoraproject.org/pipermail/package-announce/2016-May/184264.html"
    },
    {
      "type": "WEB",
      "url": "http://packetstormsecurity.com/files/136234/OpenSSH-7.2p1-xauth-Command-Injection-Bypass.html"
    },
    {
      "type": "WEB",
      "url": "http://rhn.redhat.com/errata/RHSA-2016-0465.html"
    },
    {
      "type": "WEB",
      "url": "http://rhn.redhat.com/errata/RHSA-2016-0466.html"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2016/Mar/46"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2016/Mar/47"
    },
    {
      "type": "WEB",
      "url": "http://www.openssh.com/txt/x11fwd.adv"
    },
    {
      "type": "WEB",
      "url": "http://www.oracle.com/technetwork/topics/security/bulletinapr2016-2952098.html"
    },
    {
      "type": "WEB",
      "url": "http://www.oracle.com/technetwork/topics/security/linuxbulletinapr2016-2952096.html"
    },
    {
      "type": "WEB",
      "url": "http://www.oracle.com/technetwork/topics/security/ovmbulletinjul2016-3090546.html"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/84314"
    },
    {
      "type": "WEB",
      "url": "http://www.securitytracker.com/id/1035249"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-P77J-G7H5-R2VW

Vulnerability from github – Published: 2026-08-19 19:22 – Updated: 2026-08-19 19:23
VLAI
Summary
GeoLens's authorization and cache-scope flaws disclose private dataset data and metadata to unauthorized users (fixed in 1.2.4)
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.

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>/environ and allowing CRLF header injection.
  • Unauthenticated STAC search DoS. POST /search did not cap the size of GeoJSON intersects geometries (the GET sibling did).
  • API key written to access logs. The bundled reverse proxy logged the api_key query-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_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.
  • 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.
  • 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
Show details on source website
To clipboard 

{
  "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:37
VLAI
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.

Severity
6.1 (Medium)
CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N
Show details on source website
To clipboard 

{
  "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:21
VLAI
Summary
undici vulnerable to HTTP header injection via Set-Cookie percent-decoding
Details

Impact

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.

Severity
5.9 (Medium)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
Show details on source website
To clipboard 

{
  "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:30
VLAI
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.

Severity
4.7 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:N/I:L/A:N
Show details on source website
To clipboard 

{
  "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:32
VLAI
Details

An 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

Severity
4.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N
Show details on source website
To clipboard 

{
  "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-PRPW-WWV7-XJJR

Vulnerability from github – Published: 2026-10-06 20:37 – Updated: 2026-10-06 20:37
VLAI
Summary
Coraza: Native audit-log format allows CRLF injection and log forgery via request body and header fields
Details

Root Cause

File: internal/auditlog/formats.go — multiple sites write attacker-influenced bytes into the Native audit-log stream without escaping \r or \n:

// Part B — request headers (lines 72–80)
for k, vv := range al.Transaction().Request().Headers() {
    for _, v := range vv {
        res.WriteByte('\n')
        res.WriteString(k)
        res.WriteString(": ")
        res.WriteString(v)   // ← raw
    }
}

// Part C — request body (lines 85–86)
if body := al.Transaction().Request().Body(); body != "" {
    res.WriteString(body)    // ← raw
    res.WriteByte('\n')
}

// Part E — response body (lines 93–94)      raw
// Part F — response headers (lines 111–118) raw
// Part H — error messages (line 125)        raw
// Part K — matched-rule raw data (line 151)  raw

The Native format's section structure is line-based: sections are delimited by lines of the form --<10-char-random-prefix>-<Part>--, and line-based log parsers / SIEM rules rely on that structure. Any attacker-controlled bytes containing \n break the structural invariant and allow the attacker to inject lines that look like genuine audit content.

The other two Native-format implementations in Coraza are not affected: the JSON formatter (formats_json.go) and the OCSF formatter both round-trip values through json.Marshal, which escapes \r and \n.

Impact

An attacker who can land bytes into any of the listed audit-log fields can inject arbitrary lines — including lines that visually resemble new log entries — into the audit log file of a defender running the default SecAuditLogFormat Native configuration. Realistic consequences:

  • Forging entries to shift attribution. An injected line such as [client "9.9.9.9"] Coraza: Warning. ... sits alongside genuine matches in Part H, and a human operator (or simple SIEM rule) reading the log cannot tell them apart.
  • Confusing SIEM correlation. Any ingestion pipeline that splits on --...-[A-Z]-- boundaries or on [client "..."] patterns without validating the session prefix will treat the forged lines as separate records.
  • Breaking log-parsing tooling. Grep/awk pipelines, log tailers, and log-rotation tools with line-based assumptions can be poisoned with crafted binary sequences.
  • Hiding genuine incidents. An attacker who can also trigger a rule match on the same transaction (trivial — send any request that matches any audit-logged rule) can bury the real match under noise they control.

The forged lines cannot trivially impersonate an entire separate session: the 10-char random prefix in the real boundaries (boundaryPrefix := "--" + utils.RandomString(10) + "-", line 42) is not predictable from outside, and each transaction uses a fresh prefix. But the integrity of a single record is fully compromised, which is enough for the SIEM-confusion and attribution-shifting attacks.

Proof of Concept

Server with coraza.conf-recommended-style defaults:

SecRuleEngine On
SecAuditEngine On
SecAuditLogParts ABCFHZ
SecAuditLogType Serial
SecAuditLog /tmp/audit.log
SecAuditLogFormat Native
SecRequestBodyAccess On
SecRule REQUEST_METHOD "@rx ." \
    "id:1001,phase:1,pass,log,auditlog,msg:'trigger'"

Body vector — reachable via stock coraza/v3/http + net/http

Send an ordinary urlencoded POST whose body contains raw CRLF sequences and forged boundaries:

POST / HTTP/1.1
Content-Type: application/x-www-form-urlencoded

evil=benign\r\n--coraza-forged-X--\r\nForgedLine: yes\r\n--coraza-forged-H--\r\n[client "9.9.9.9"] FAKE ATTACK ENTRY

Resulting audit.log:

--heLNtylvjY-C--
evil=benign
--coraza-forged-X--
ForgedLine: yes
--coraza-forged-H--
[client "9.9.9.9"] FAKE ATTACK ENTRY

--heLNtylvjY-F--

The forged --coraza-forged-X-- / --coraza-forged-H-- boundaries and the spoofed [client "9.9.9.9"] line are structurally indistinguishable from the surrounding genuine log content. No rule fires, no error is raised, the attack is invisible to the WAF.

Header vector — reachable via non-net/http integrations only

The same effect applies to Part B (request headers) and Part F (response headers) when a header value contains raw \r\n. Go's net/http rejects such headers at parse time (400 Bad Request), so the stock HTTP wrapper is safe from this path; the vector is reachable when Coraza is called with header values that were not validated by net/http:

  • coraza-spoa (HAProxy SPOP agent) forwards headers from HAProxy, which has more permissive validation.
  • coraza-proxy-wasm / Envoy WASM hosts forward header values from the upstream proxy.
  • Custom FFI/WASM hosts and any embedder calling tx.AddRequestHeader(k, v) with unvalidated bytes.

Other raw-write sites (Part E response body, Part H error messages, Part K matched-rule data) share the same class of issue and should be fixed together.

Mitigation

Escape \r and \n at every raw-write site in internal/auditlog/formats.go. A single package-level helper is sufficient:

var logEscaper = strings.NewReplacer("\r", "\\r", "\n", "\\n")

// Part B — header values:
res.WriteString(logEscaper.Replace(v))

// Part F — header values: same
// Part H — error messages:
res.WriteString(logEscaper.Replace(alWithErrMsg.ErrorMessage()))
// Part K — matched-rule raw data:
res.WriteString(logEscaper.Replace(alEntry.Data().Raw()))

For Part C / Part E (bodies), the choice is policy-dependent:

  • Escape inline (logEscaper.Replace(body)): keeps the log human-readable for text bodies but loses fidelity for binary.
  • Base64 / hex-encode the whole part: binary-safe, matches the spirit of ModSecurity v2's binary-log handling, but less human-readable.

Escaping is the minimum; base64 for bodies is the more conservative default and is a reasonable audit-log-default change.

Additional defensive measure

Consider lengthening the boundaryPrefix random suffix from 10 chars to ≥16 chars (line 42). This strictly raises the bar for attackers attempting to fully forge a separate-looking session (not just inject lines into the current one). Low-cost change; narrows future variants of this bug class.

Affected versions

The Native formatter has been present since v3.0.0 (file existed at the first-release commit). All releases >= 3.0.0, <= 3.7.0 are affected when SecAuditLogFormat Native is used with SecAuditLogType Serial or SecAuditLogType Concurrent.

Unaffected:

  • Deployments using SecAuditLogFormat JSON (formats_json.go uses json.Marshal which escapes \r\n).
  • Deployments using OCSF output.
  • Deployments with SecAuditEngine Off.

References

  • internal/auditlog/formats.go lines 42, 72–80 (Part B), 85–88 (Part C), 93–96 (Part E), 111–118 (Part F), 125 (Part H), 151 (Part K)
  • coraza.conf-recommended — default SecAuditLogFormat Native, SecAuditLogParts ABIJDEFHZ / ABCFHZ variants
  • CWE-117 — Improper Output Neutralization for Logs
  • CWE-93 — CRLF Injection
Severity
5.8 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.7.0"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/corazawaf/coraza/v3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0"
            },
            {
              "fixed": "3.8.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-41504"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-117",
      "CWE-93"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-06T20:37:27Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Root Cause\n\nFile: `internal/auditlog/formats.go` \u2014 multiple sites write attacker-influenced bytes into the Native audit-log stream without escaping `\\r` or `\\n`:\n\n```go\n// Part B \u2014 request headers (lines 72\u201380)\nfor k, vv := range al.Transaction().Request().Headers() {\n    for _, v := range vv {\n        res.WriteByte(\u0027\\n\u0027)\n        res.WriteString(k)\n        res.WriteString(\": \")\n        res.WriteString(v)   // \u2190 raw\n    }\n}\n\n// Part C \u2014 request body (lines 85\u201386)\nif body := al.Transaction().Request().Body(); body != \"\" {\n    res.WriteString(body)    // \u2190 raw\n    res.WriteByte(\u0027\\n\u0027)\n}\n\n// Part E \u2014 response body (lines 93\u201394)      raw\n// Part F \u2014 response headers (lines 111\u2013118) raw\n// Part H \u2014 error messages (line 125)        raw\n// Part K \u2014 matched-rule raw data (line 151)  raw\n```\n\nThe Native format\u0027s section structure is line-based: sections are delimited by lines of the form `--\u003c10-char-random-prefix\u003e-\u003cPart\u003e--`, and line-based log parsers / SIEM rules rely on that structure. Any attacker-controlled bytes containing `\\n` break the structural invariant and allow the attacker to inject lines that look like genuine audit content.\n\nThe other two Native-format implementations in Coraza are not affected: the JSON formatter (`formats_json.go`) and the OCSF formatter both round-trip values through `json.Marshal`, which escapes `\\r` and `\\n`.\n\n## Impact\n\nAn attacker who can land bytes into any of the listed audit-log fields can inject arbitrary lines \u2014 including lines that visually resemble new log entries \u2014 into the audit log file of a defender running the default `SecAuditLogFormat Native` configuration. Realistic consequences:\n\n- **Forging entries to shift attribution.** An injected line such as `[client \"9.9.9.9\"] Coraza: Warning. ...` sits alongside genuine matches in Part H, and a human operator (or simple SIEM rule) reading the log cannot tell them apart.\n- **Confusing SIEM correlation.** Any ingestion pipeline that splits on `--...-[A-Z]--` boundaries or on `[client \"...\"]` patterns without validating the session prefix will treat the forged lines as separate records.\n- **Breaking log-parsing tooling.** Grep/awk pipelines, log tailers, and log-rotation tools with line-based assumptions can be poisoned with crafted binary sequences.\n- **Hiding genuine incidents.** An attacker who can also trigger a rule match on the same transaction (trivial \u2014 send any request that matches *any* audit-logged rule) can bury the real match under noise they control.\n\nThe forged lines cannot trivially impersonate an entire *separate* session: the 10-char random prefix in the real boundaries (`boundaryPrefix := \"--\" + utils.RandomString(10) + \"-\"`, line 42) is not predictable from outside, and each transaction uses a fresh prefix. But the integrity of a *single* record is fully compromised, which is enough for the SIEM-confusion and attribution-shifting attacks.\n\n## Proof of Concept\n\nServer with `coraza.conf-recommended`-style defaults:\n\n```conf\nSecRuleEngine On\nSecAuditEngine On\nSecAuditLogParts ABCFHZ\nSecAuditLogType Serial\nSecAuditLog /tmp/audit.log\nSecAuditLogFormat Native\nSecRequestBodyAccess On\nSecRule REQUEST_METHOD \"@rx .\" \\\n    \"id:1001,phase:1,pass,log,auditlog,msg:\u0027trigger\u0027\"\n```\n\n### Body vector \u2014 reachable via stock `coraza/v3/http` + `net/http`\n\nSend an ordinary urlencoded POST whose body contains raw CRLF sequences and forged boundaries:\n\n```\nPOST / HTTP/1.1\nContent-Type: application/x-www-form-urlencoded\n\nevil=benign\\r\\n--coraza-forged-X--\\r\\nForgedLine: yes\\r\\n--coraza-forged-H--\\r\\n[client \"9.9.9.9\"] FAKE ATTACK ENTRY\n```\n\nResulting audit.log:\n\n```\n--heLNtylvjY-C--\nevil=benign\n--coraza-forged-X--\nForgedLine: yes\n--coraza-forged-H--\n[client \"9.9.9.9\"] FAKE ATTACK ENTRY\n\n--heLNtylvjY-F--\n```\n\nThe forged `--coraza-forged-X--` / `--coraza-forged-H--` boundaries and the spoofed `[client \"9.9.9.9\"]` line are structurally indistinguishable from the surrounding genuine log content. No rule fires, no error is raised, the attack is invisible to the WAF.\n\n### Header vector \u2014 reachable via non-net/http integrations only\n\nThe same effect applies to Part B (request headers) and Part F (response headers) when a header value contains raw `\\r\\n`. Go\u0027s `net/http` rejects such headers at parse time (`400 Bad Request`), so the stock HTTP wrapper is safe from this path; the vector is reachable when Coraza is called with header values that were not validated by `net/http`:\n\n- `coraza-spoa` (HAProxy SPOP agent) forwards headers from HAProxy, which has more permissive validation.\n- `coraza-proxy-wasm` / Envoy WASM hosts forward header values from the upstream proxy.\n- Custom FFI/WASM hosts and any embedder calling `tx.AddRequestHeader(k, v)` with unvalidated bytes.\n\nOther raw-write sites (Part E response body, Part H error messages, Part K matched-rule data) share the same class of issue and should be fixed together.\n\n## Mitigation\n\nEscape `\\r` and `\\n` at every raw-write site in `internal/auditlog/formats.go`. A single package-level helper is sufficient:\n\n```go\nvar logEscaper = strings.NewReplacer(\"\\r\", \"\\\\r\", \"\\n\", \"\\\\n\")\n\n// Part B \u2014 header values:\nres.WriteString(logEscaper.Replace(v))\n\n// Part F \u2014 header values: same\n// Part H \u2014 error messages:\nres.WriteString(logEscaper.Replace(alWithErrMsg.ErrorMessage()))\n// Part K \u2014 matched-rule raw data:\nres.WriteString(logEscaper.Replace(alEntry.Data().Raw()))\n```\n\nFor Part C / Part E (bodies), the choice is policy-dependent:\n\n- **Escape inline** (`logEscaper.Replace(body)`): keeps the log human-readable for text bodies but loses fidelity for binary.\n- **Base64 / hex-encode** the whole part: binary-safe, matches the spirit of ModSecurity v2\u0027s binary-log handling, but less human-readable.\n\nEscaping is the minimum; base64 for bodies is the more conservative default and is a reasonable audit-log-default change.\n\n### Additional defensive measure\n\nConsider lengthening the `boundaryPrefix` random suffix from 10 chars to \u226516 chars (line 42). This strictly raises the bar for attackers attempting to *fully* forge a separate-looking session (not just inject lines into the current one). Low-cost change; narrows future variants of this bug class.\n\n## Affected versions\n\nThe Native formatter has been present since `v3.0.0` (file existed at the first-release commit). All releases `\u003e= 3.0.0, \u003c= 3.7.0` are affected when `SecAuditLogFormat Native` is used with `SecAuditLogType Serial` or `SecAuditLogType Concurrent`.\n\n**Unaffected:**\n\n- Deployments using `SecAuditLogFormat JSON` (`formats_json.go` uses `json.Marshal` which escapes `\\r\\n`).\n- Deployments using OCSF output.\n- Deployments with `SecAuditEngine Off`.\n\n## References\n\n- `internal/auditlog/formats.go` lines 42, 72\u201380 (Part B), 85\u201388 (Part C), 93\u201396 (Part E), 111\u2013118 (Part F), 125 (Part H), 151 (Part K)\n- `coraza.conf-recommended` \u2014 default `SecAuditLogFormat Native`, `SecAuditLogParts ABIJDEFHZ` / `ABCFHZ` variants\n- CWE-117 \u2014 Improper Output Neutralization for Logs\n- CWE-93 \u2014 CRLF Injection",
  "id": "GHSA-prpw-wwv7-xjjr",
  "modified": "2026-10-06T20:37:27Z",
  "published": "2026-10-06T20:37:27Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/corazawaf/coraza/security/advisories/GHSA-prpw-wwv7-xjjr"
    },
    {
      "type": "WEB",
      "url": "https://github.com/corazawaf/coraza/commit/a3079325547c7c1e08522aed4d6468f25d080e25"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/corazawaf/coraza"
    },
    {
      "type": "WEB",
      "url": "https://github.com/corazawaf/coraza/releases/tag/v3.8.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Coraza: Native audit-log format allows CRLF injection and log forgery via request body and header fields"
}

GHSA-PV9C-9MFH-HVXQ

Vulnerability from github – Published: 2026-03-24 19:13 – Updated: 2026-03-27 22:00
VLAI
Summary
iCalendar has ICS injection via unsanitized URI property values
Details

Summary

.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.

Severity
4.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N
Show details on source website
To clipboard 

{
  "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:29
VLAI
Summary
Req vulnerable to multipart form-data header injection via unescaped name/filename/content_type
Details

Summary

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

  1. Construct a malicious filename such as harmless.txt"\r\nX-Smuggled: marker\r\nContent-Disposition: form-data; name="pwned.
  2. Call Req.post!(url, form_multipart: [upload: {"benign body", filename: <malicious>, content_type: "text/plain"}]).
  3. The emitted multipart body contains a real X-Smuggled: header line and an extra Content-Disposition for name="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.

Severity
6.3 (Medium)
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
Show details on source website
To clipboard 

{
  "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"
}
Mitigation
Implementation

Avoid using CRLF as a special sequence.

Mitigation
Implementation

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.

← Back to the CWE list