Common Weakness Enumeration

CWE-113

Allowed

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

Abstraction: Variant · Status: Incomplete

The product receives data from an HTTP agent/component (e.g., web server, proxy, browser, etc.), but it does not neutralize or incorrectly neutralizes CR and LF characters before the data is included in outgoing HTTP headers.

177 vulnerabilities reference this CWE, most recent first.

GHSA-9C7V-CW9Q-4FPC

Vulnerability from github – Published: 2026-02-10 06:30 – Updated: 2026-02-10 06:30
VLAI
Details

Due to a CRLF Injection vulnerability in SAP NetWeaver Application Server Java, an authenticated attacker with administrative access could submit specially crafted content to the application. If processed by the application, this content enables injection of untrusted entries into generated configuration, allowing manipulation of application-controlled settings. Successful exploitation leads to a low impact on integrity, while confidentiality and availability remain unaffected.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-23686"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-113",
      "CWE-436"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-02-10T04:16:03Z",
    "severity": "LOW"
  },
  "details": "Due to a CRLF Injection vulnerability in SAP NetWeaver Application Server Java, an authenticated attacker with administrative access could submit specially crafted content to the application. If processed by the application, this content enables injection of untrusted entries into generated configuration, allowing manipulation of application-controlled settings. Successful exploitation leads to a low impact on integrity, while confidentiality and availability remain unaffected.",
  "id": "GHSA-9c7v-cw9q-4fpc",
  "modified": "2026-02-10T06:30:38Z",
  "published": "2026-02-10T06:30:38Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23686"
    },
    {
      "type": "WEB",
      "url": "https://me.sap.com/notes/3673213"
    },
    {
      "type": "WEB",
      "url": "https://url.sap/sapsecuritypatchday"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:R/S:C/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-9F9P-CP3C-72JF

Vulnerability from github – Published: 2024-01-24 20:20 – Updated: 2024-01-24 21:32
VLAI
Summary
Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Request/Response Splitting') in trillium-http and trillium-client
Details

Summary

Insufficient validation of outbound header values may lead to request splitting or response splitting attacks in scenarios where attackers have sufficient control over outbound headers.

Details

Outbound trillium_http::HeaderValue and trillium_http::HeaderName can be constructed infallibly and were not checked for illegal bytes when sending requests from the client or responses from the server. Thus, if an attacker has sufficient control over header values (or names) in a request or response that they could inject \r\n sequences, they could get the client and server out of sync, and then pivot to gain control over other parts of requests or responses. (i.e. exfiltrating data from other requests, SSRF, etc.)

Patches

trillium-http >= 0.3.12:

  • If a header name is invalid in server response headers, the specific header and any associated values are omitted from network transmission.
  • If a header value is invalid in server response headers, the individual header value is omitted from network transmission. Other headers values with the same header name will still be sent.

trillium-client >= 0.5.4:

  • If any header name or header value is invalid in the client request headers, awaiting the client Conn returns an Error::MalformedHeader prior to any network access.

Workarounds

trillium services and client applications should sanitize or validate untrusted input that is included in header values and header names. Carriage return, newline, and null characters are not allowed.

Impact

This only affects use cases where attackers have control of outbound headers, and can insert "\r\n" sequences. Specifically, if untrusted and unvalidated input is inserted into header names or values.

A note on timing from @jbr on behalf of trillium-rs

@divergentdave filed this vulnerability many months ago but I did not see it until the evening of Jan 23, 2024. Patches were issued less than 24h after reading the vulnerability. The security policy has been updated to avoid delays like this in the future.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "trillium-http"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.3.12"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "trillium-client"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.5.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-23644"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-113",
      "CWE-436"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-01-24T20:20:38Z",
    "nvd_published_at": "2024-01-24T20:15:53Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\nInsufficient validation of outbound header values may lead to request splitting or response splitting attacks in scenarios where attackers have sufficient control over outbound headers.\n\n### Details\nOutbound `trillium_http::HeaderValue` and `trillium_http::HeaderName` can be constructed infallibly and were not checked for illegal bytes when sending requests from the client or responses from the server. Thus, if an attacker has sufficient control over header values (or names) in a request or response that they could inject `\\r\\n` sequences, they could get the client and server out of sync, and then pivot to gain control over other parts of requests or responses. (i.e. exfiltrating data from other requests, SSRF, etc.)\n\n### Patches\n\n#### trillium-http \u003e= 0.3.12:\n* If a header name is invalid in server response headers, the specific header and any associated values are omitted from network transmission.\n* If a header value is invalid in server response headers, the individual header value is omitted from network transmission. Other headers values with the same header name will still be sent.\n\n#### trillium-client \u003e= 0.5.4:\n* If any header name or header value is invalid in the client request headers, awaiting the client Conn returns an `Error::MalformedHeader` prior to any network access.\n\n### Workarounds\n\ntrillium services and client applications should sanitize or validate untrusted input that is included in header values and header names. Carriage return, newline, and null characters are not allowed.\n\n### Impact\n\nThis only affects use cases where attackers have control of outbound headers, and can insert \"\\r\\n\" sequences. Specifically, if untrusted and unvalidated input is inserted into header names or values.\n\n### A note on timing from @jbr on behalf of `trillium-rs`\n\n@divergentdave filed this vulnerability many months ago but I did not see it until the evening of Jan 23, 2024. Patches were issued less than 24h after reading the vulnerability. The [security policy](https://github.com/trillium-rs/trillium/blob/main/SECURITY.md) has been [updated](https://github.com/trillium-rs/trillium/commit/b27950ceae52aa7a0f482494fe67b6069234d417) to avoid delays like this in the future.",
  "id": "GHSA-9f9p-cp3c-72jf",
  "modified": "2024-01-24T21:32:24Z",
  "published": "2024-01-24T20:20:38Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/trillium-rs/trillium/security/advisories/GHSA-9f9p-cp3c-72jf"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-23644"
    },
    {
      "type": "WEB",
      "url": "https://github.com/trillium-rs/trillium/commit/16a42b3f8378a3fa4e61ece3e3e37e6a530df51d"
    },
    {
      "type": "WEB",
      "url": "https://github.com/trillium-rs/trillium/commit/8d468f85e27b8d0943d6f43ce9f8c7397141a999"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/trillium-rs/trillium"
    },
    {
      "type": "WEB",
      "url": "https://rustsec.org/advisories/RUSTSEC-2024-0008.html"
    },
    {
      "type": "WEB",
      "url": "https://rustsec.org/advisories/RUSTSEC-2024-0009.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Improper Neutralization of CRLF Sequences in HTTP Headers (\u0027HTTP Request/Response Splitting\u0027) in trillium-http and trillium-client"
}

GHSA-9P6X-P535-C54C

Vulnerability from github – Published: 2022-11-04 19:01 – Updated: 2022-11-08 19:00
VLAI
Details

A vulnerability in Cisco Email Security Appliance (ESA) and Cisco Secure Email and Web Manager could allow an unauthenticated, remote attacker to conduct an HTTP response splitting attack. This vulnerability is due to the failure of the application or its environment to properly sanitize input values. An attacker could exploit this vulnerability by injecting malicious HTTP headers, controlling the response body, or splitting the response into multiple responses.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-20772"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-113",
      "CWE-74"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-11-04T18:15:00Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability in Cisco Email Security Appliance (ESA) and Cisco Secure Email and Web Manager could allow an unauthenticated, remote attacker to conduct an HTTP response splitting attack. This vulnerability is due to the failure of the application or its environment to properly sanitize input values. An attacker could exploit this vulnerability by injecting malicious HTTP headers, controlling the response body, or splitting the response into multiple responses.",
  "id": "GHSA-9p6x-p535-c54c",
  "modified": "2022-11-08T19:00:24Z",
  "published": "2022-11-04T19:01:09Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-20772"
    },
    {
      "type": "WEB",
      "url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-ESA-HTTP-Inject-nvsycUmR"
    },
    {
      "type": "WEB",
      "url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-ESA-HTTP-Inject-nvsycUmR"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-C3H8-G69V-PJRG

Vulnerability from github – Published: 2026-04-22 20:25 – Updated: 2026-05-13 13:29
VLAI
Summary
i18next-http-middleware: HTTP response splitting and DoS via unsanitised Content-Language header
Details

Summary

Versions of i18next-http-middleware prior to 3.9.3 wrote user-controlled language values into the Content-Language response header after passing them through utils.escape(), which is an HTML-entity encoder that does not strip carriage return, line feed, or other control characters. When the application used an older i18next (< 19.5.0) that still exercised the backward-compatibility fallback at LanguageDetector.js:100 or otherwise produced a raw detected value, CRLF sequences in the attacker-controlled lng parameter reached res.setHeader('Content-Language', ...) verbatim.

Impact

Two concrete outcomes depending on the Node.js version:

  • Node.js < 14.6.0 — HTTP response splitting. An attacker crafting a request like GET /?lng=en%0d%0aX-Injected%3A+malicious could inject arbitrary additional HTTP response headers, enabling:
  • Session fixation via an injected Set-Cookie
  • Cache poisoning (injecting Location, Content-Type, etc.)
  • Reflected XSS in controlled response bodies
  • Node.js ≥ 14.6.0 — denial of service. res.setHeader() throws ERR_INVALID_CHAR when the value contains CRLF. Because the middleware did not catch this error, it propagated as an unhandled exception, returning a 500 response to all concurrent users sharing that process (in worker-pool deployments this can knock out a full server instance).

The same header-setting code path fires inside the languageChanged event listener and again in the main middleware flow, so the flaw was triggered at least twice per affected request.

Related (same release)

Version 3.9.3 also tightens the hasXSS() regex that was designed as a secondary filter on detected language values. The previous pattern /<\s*\w+\s*on\w+\s*=.*?>/i only matched event handlers in the first attribute position, so payloads like <input autofocus onfocus=alert(1)> bypassed the filter. Applications that rendered res.locals.language into HTML with a context-unsafe templating mode (EJS <%- %>, Pug !{…}, Handlebars {{{…}}}) could be XSSed despite the filter being in place. This bypass is noted here because it is fixed in the same release, but the primary vulnerability reported in this advisory is the CRLF/header-injection path above.

Affected versions

< 3.9.3.

Patch

Fixed in 3.9.3. The patch introduces utils.sanitizeHeaderValue(str) which strips \r, \n, and other C0/C1 control characters, and replaces both utils.escape(lng) call sites in lib/index.js with it. The hasXSS() regex has also been tightened to match event-handler attributes at any position.

Workarounds

No workaround short of upgrading. Front-proxying the middleware with a WAF rule that rejects \r/\n in query parameters, cookies, and path segments is a partial mitigation.

Credits

Discovered via an internal security audit of the i18next ecosystem.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "i18next-http-middleware"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.9.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-41683"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-113",
      "CWE-79"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-22T20:25:49Z",
    "nvd_published_at": "2026-05-08T16:16:11Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\nVersions of `i18next-http-middleware` prior to 3.9.3 wrote user-controlled language values into the `Content-Language` response header after passing them through `utils.escape()`, which is an HTML-entity encoder that does not strip carriage return, line feed, or other control characters. When the application used an older `i18next` (\u003c 19.5.0) that still exercised the backward-compatibility fallback at `LanguageDetector.js:100` or otherwise produced a raw detected value, CRLF sequences in the attacker-controlled `lng` parameter reached `res.setHeader(\u0027Content-Language\u0027, ...)` verbatim.\n\n### Impact\n\nTwo concrete outcomes depending on the Node.js version:\n\n- **Node.js \u003c 14.6.0 \u2014 HTTP response splitting.** An attacker crafting a request like `GET /?lng=en%0d%0aX-Injected%3A+malicious` could inject arbitrary additional HTTP response headers, enabling:\n  - Session fixation via an injected `Set-Cookie`\n  - Cache poisoning (injecting `Location`, `Content-Type`, etc.)\n  - Reflected XSS in controlled response bodies\n- **Node.js \u2265 14.6.0 \u2014 denial of service.** `res.setHeader()` throws `ERR_INVALID_CHAR` when the value contains CRLF. Because the middleware did not catch this error, it propagated as an unhandled exception, returning a 500 response to **all concurrent users sharing that process** (in worker-pool deployments this can knock out a full server instance).\n\nThe same header-setting code path fires inside the `languageChanged` event listener and again in the main middleware flow, so the flaw was triggered at least twice per affected request.\n\n### Related (same release)\n\nVersion 3.9.3 also tightens the `hasXSS()` regex that was designed as a secondary filter on detected language values. The previous pattern `/\u003c\\s*\\w+\\s*on\\w+\\s*=.*?\u003e/i` only matched event handlers in the **first** attribute position, so payloads like `\u003cinput autofocus onfocus=alert(1)\u003e` bypassed the filter. Applications that rendered `res.locals.language` into HTML with a context-unsafe templating mode (EJS `\u003c%- %\u003e`, Pug `!{\u2026}`, Handlebars `{{{\u2026}}}`) could be XSSed despite the filter being in place. This bypass is noted here because it is fixed in the same release, but the primary vulnerability reported in this advisory is the CRLF/header-injection path above.\n\n### Affected versions\n\n`\u003c 3.9.3`.\n\n### Patch\n\nFixed in **3.9.3**. The patch introduces `utils.sanitizeHeaderValue(str)` which strips `\\r`, `\\n`, and other C0/C1 control characters, and replaces both `utils.escape(lng)` call sites in `lib/index.js` with it. The `hasXSS()` regex has also been tightened to match event-handler attributes at any position.\n\n### Workarounds\n\nNo workaround short of upgrading. Front-proxying the middleware with a WAF rule that rejects `\\r`/`\\n` in query parameters, cookies, and path segments is a partial mitigation.\n\n### Credits\n\nDiscovered via an internal security audit of the i18next ecosystem.",
  "id": "GHSA-c3h8-g69v-pjrg",
  "modified": "2026-05-13T13:29:47Z",
  "published": "2026-04-22T20:25:49Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/i18next/i18next-http-middleware/security/advisories/GHSA-c3h8-g69v-pjrg"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41683"
    },
    {
      "type": "WEB",
      "url": "https://github.com/i18next/i18next-http-middleware/commit/65301c194593d46a84623b64e5fde2f51d3550f6"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/i18next/i18next-http-middleware"
    }
  ],
  "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:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "i18next-http-middleware: HTTP response splitting and DoS via unsanitised Content-Language header"
}

GHSA-C4CH-CV96-R58V

Vulnerability from github – Published: 2024-04-04 21:30 – Updated: 2024-11-12 21:30
VLAI
Details

HTTP Response splitting in multiple modules in Apache HTTP Server allows an attacker that can inject malicious response headers into backend applications to cause an HTTP desynchronization attack.

Users are recommended to upgrade to version 2.4.59, which fixes this issue.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-24795"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-113",
      "CWE-444"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-04-04T20:15:08Z",
    "severity": "MODERATE"
  },
  "details": "HTTP Response splitting in multiple modules in Apache HTTP Server allows an attacker that can inject malicious response headers into backend applications to cause an HTTP desynchronization attack.\n\nUsers are recommended to upgrade to version 2.4.59, which fixes this issue.",
  "id": "GHSA-c4ch-cv96-r58v",
  "modified": "2024-11-12T21:30:49Z",
  "published": "2024-04-04T21:30:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-24795"
    },
    {
      "type": "WEB",
      "url": "https://httpd.apache.org/security/vulnerabilities_24.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2024/05/msg00013.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2024/05/msg00014.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/I2N2NZEX3MR64IWSGL3QGN7KSRUGAEMF"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/LX5U34KYGDYPRH3AJ6MDDCBJDWDPXNVJ"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/WNV4SZAPVS43DZWNFU7XBYYOZEZMI4ZC"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20240415-0013"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/kb/HT214119"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2024/Jul/18"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2024/04/04/5"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-CC39-78P8-96P9

Vulnerability from github – Published: 2023-07-05 21:30 – Updated: 2024-04-04 05:24
VLAI
Details

AMI SPx contains a vulnerability in the BMC where an Attacker may cause an improper neutralization of CRLF sequences in HTTP Headers. A successful exploit of this vulnerability may lead to a loss of integrity.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-34472"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-113"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-07-05T19:15:10Z",
    "severity": "MODERATE"
  },
  "details": "AMI SPx contains a vulnerability in the BMC where an Attacker may cause an improper neutralization of CRLF sequences in HTTP Headers. A successful exploit of this vulnerability may lead to a loss of integrity.\n\n\n\n",
  "id": "GHSA-cc39-78p8-96p9",
  "modified": "2024-04-04T05:24:01Z",
  "published": "2023-07-05T21:30:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-34472"
    },
    {
      "type": "WEB",
      "url": "https://9443417.fs1.hubspotusercontent-na1.net/hubfs/9443417/Security%20Advisories/AMI-SA-2023006.pdf"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-CG44-83GM-9C7J

Vulnerability from github – Published: 2022-05-14 04:00 – Updated: 2022-05-14 04:00
VLAI
Details

IBM Security Guardium 10.0 is vulnerable to HTTP response splitting attacks. A remote attacker could exploit this vulnerability using specially-crafted URL to cause the server to return a split response, once the URL is clicked. This would allow the attacker to perform further attacks, such as Web cache poisoning, cross-site scripting, and possibly obtain sensitive information. IBM X-Force ID: 124737.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2017-1262"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-113"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-12-20T18:29:00Z",
    "severity": "MODERATE"
  },
  "details": "IBM Security Guardium 10.0 is vulnerable to HTTP response splitting attacks. A remote attacker could exploit this vulnerability using specially-crafted URL to cause the server to return a split response, once the URL is clicked. This would allow the attacker to perform further attacks, such as Web cache poisoning, cross-site scripting, and possibly obtain sensitive information. IBM X-Force ID: 124737.",
  "id": "GHSA-cg44-83gm-9c7j",
  "modified": "2022-05-14T04:00:42Z",
  "published": "2022-05-14T04:00:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-1262"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/124737"
    },
    {
      "type": "WEB",
      "url": "http://www.ibm.com/support/docview.wss?uid=swg22010438"
    }
  ],
  "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-CGGP-94XR-PRM6

Vulnerability from github – Published: 2022-05-24 17:21 – Updated: 2023-10-23 21:30
VLAI
Details

A flaw was found in the Red Hat Ceph Storage RadosGW (Ceph Object Gateway). The vulnerability is related to the injection of HTTP headers via a CORS ExposeHeader tag. The newline character in the ExposeHeader tag in the CORS configuration file generates a header injection in the response when the CORS request is made. Ceph versions 3.x and 4.x are vulnerable to this issue.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2020-10753"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-113",
      "CWE-74"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-06-26T15:15:00Z",
    "severity": "MODERATE"
  },
  "details": "A flaw was found in the Red Hat Ceph Storage RadosGW (Ceph Object Gateway). The vulnerability is related to the injection of HTTP headers via a CORS ExposeHeader tag. The newline character in the ExposeHeader tag in the CORS configuration file generates a header injection in the response when the CORS request is made. Ceph versions 3.x and 4.x are vulnerable to this issue.",
  "id": "GHSA-cggp-94xr-prm6",
  "modified": "2023-10-23T21:30:57Z",
  "published": "2022-05-24T17:21:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-10753"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2020-10753"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2021/08/msg00013.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2023/10/msg00034.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/FFU7LXEL2UZE565FJBTY7UGH2O7ZUBVS"
    },
    {
      "type": "WEB",
      "url": "https://security.gentoo.org/glsa/202105-39"
    },
    {
      "type": "WEB",
      "url": "https://usn.ubuntu.com/4528-1"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2020-06/msg00062.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-CM5J-986P-JQRJ

Vulnerability from github – Published: 2026-07-14 18:31 – Updated: 2026-07-14 18:31
VLAI
Details

An Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Response Splitting') vulnerability [CWE-113] vulnerability in Fortinet FortiOS 7.6.0 through 7.6.4, FortiOS 7.4 all versions, FortiOS 7.2 all versions, FortiProxy 7.6.0 through 7.6.4, FortiProxy 7.4 all versions, FortiProxy 7.2 all versions may allow an attacker in possession of a valid web filter override token to inject arbitrary headers via tricking a user into clicking on a crafted link.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-62675"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-113"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-14T16:16:42Z",
    "severity": "LOW"
  },
  "details": "An Improper Neutralization of CRLF Sequences in HTTP Headers (\u0027HTTP Response Splitting\u0027) vulnerability [CWE-113] vulnerability in Fortinet FortiOS 7.6.0 through 7.6.4, FortiOS 7.4 all versions, FortiOS 7.2 all versions, FortiProxy 7.6.0 through 7.6.4, FortiProxy 7.4 all versions, FortiProxy 7.2 all versions may allow an attacker in possession of a valid web filter override token to inject arbitrary headers via tricking a user into clicking on a crafted link.",
  "id": "GHSA-cm5j-986p-jqrj",
  "modified": "2026-07-14T18:31:54Z",
  "published": "2026-07-14T18:31:54Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-62675"
    },
    {
      "type": "WEB",
      "url": "https://fortiguard.fortinet.com/psirt/FG-IR-26-152"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-CW3J-28QQ-X3XH

Vulnerability from github – Published: 2026-07-01 00:34 – Updated: 2026-07-01 00:34
VLAI
Details

Hono before 4.10.2 (fixed in 4.10.3) contains a flaw in its CORS middleware: when the origin is not set to "*", the middleware copies the Vary header from the incoming request into the response. Because Vary is a response header that should be managed by the server, an attacker can supply arbitrary Vary values that are reflected into the response, potentially causing cache key pollution and inconsistent CORS enforcement in environments that rely on shared caches or proxies.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-71381"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-113"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-30T23:16:52Z",
    "severity": "MODERATE"
  },
  "details": "Hono before 4.10.2 (fixed in 4.10.3) contains a flaw in its CORS middleware: when the origin is not set to \"*\", the middleware copies the Vary header from the incoming request into the response. Because Vary is a response header that should be managed by the server, an attacker can supply arbitrary Vary values that are reflected into the response, potentially causing cache key pollution and inconsistent CORS enforcement in environments that rely on shared caches or proxies.",
  "id": "GHSA-cw3j-28qq-x3xh",
  "modified": "2026-07-01T00:34:02Z",
  "published": "2026-07-01T00:34:02Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/honojs/hono/security/advisories/GHSA-q7jf-gf43-6x6p"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71381"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/hono-vary-header-injection-in-cors-middleware"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

Mitigation
Implementation

Strategy: Input Validation

Construct HTTP headers very carefully, avoiding the use of non-validated input data.

Mitigation MIT-5
Implementation

Strategy: Input Validation

  • Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. If an input does not strictly conform to specifications, reject it or transform it into something that conforms.
  • When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."
  • Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
Mitigation MIT-30
Implementation

Strategy: Output Encoding

Use and specify an output encoding that can be handled by the downstream component that is reading the output. Common encodings include ISO-8859-1, UTF-7, and UTF-8. When an encoding is not specified, a downstream component may choose a different encoding, either by assuming a default encoding or automatically inferring which encoding is being used, which can be erroneous. When the encodings are inconsistent, the downstream component might treat some character or byte sequences as special, even if they are not special in the original encoding. Attackers might then be able to exploit this discrepancy and conduct injection attacks; they even might be able to bypass protection mechanisms that assume the original encoding is also being used by the downstream component.

Mitigation MIT-20
Implementation

Strategy: Input Validation

Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked.

CAPEC-105: HTTP Request Splitting

An adversary abuses the flexibility and discrepancies in the parsing and interpretation of HTTP Request messages by different intermediary HTTP agents (e.g., load balancer, reverse proxy, web caching proxies, application firewalls, etc.) to split a single HTTP request into multiple unauthorized and malicious HTTP requests to a back-end HTTP agent (e.g., web server).

See CanPrecede relationships for possible consequences.

CAPEC-31: Accessing/Intercepting/Modifying HTTP Cookies

This attack relies on the use of HTTP Cookies to store credentials, state information and other critical data on client systems. There are several different forms of this attack. The first form of this attack involves accessing HTTP Cookies to mine for potentially sensitive data contained therein. The second form involves intercepting this data as it is transmitted from client to server. This intercepted information is then used by the adversary to impersonate the remote user/session. The third form is when the cookie's content is modified by the adversary before it is sent back to the server. Here the adversary seeks to convince the target server to operate on this falsified information.

CAPEC-34: HTTP Response Splitting

An adversary manipulates and injects malicious content, in the form of secret unauthorized HTTP responses, into a single HTTP response from a vulnerable or compromised back-end HTTP agent (e.g., web server) or into an already spoofed HTTP response from an adversary controlled domain/site.

See CanPrecede relationships for possible consequences.

CAPEC-85: AJAX Footprinting

This attack utilizes the frequent client-server roundtrips in Ajax conversation to scan a system. While Ajax does not open up new vulnerabilities per se, it does optimize them from an attacker point of view. A common first step for an attacker is to footprint the target environment to understand what attacks will work. Since footprinting relies on enumeration, the conversational pattern of rapid, multiple requests and responses that are typical in Ajax applications enable an attacker to look for many vulnerabilities, well-known ports, network locations and so on. The knowledge gained through Ajax fingerprinting can be used to support other attacks, such as XSS.