Sync Collecting Fix Commits: Fri Aug 7 09:54:45 UTC 2026

Signed-off-by: AboutCode Automation <automation@aboutcode.org>

Author: aboutcode-automation

data/fix-commits/advisory-database-b78f1d41.json

@@ -1,10 +1,15 @@
 {
   "vcs_url": "https://github.com/github/advisory-database",
   "vulnerabilities": {
+    "GHSA-HF6X-8P5F-CGMF": {
+      "eebfe29382bab0555b71aeccfc726ee84366cc67": "Improve GHSA-hf6x-8p5f-cgmf"
+    },
+    "GHSA-RPF9-HRJR-88FV": {
+      "6b5c5d130b77accffb77ce5856e9e73203fad25a": "Improve GHSA-rpf9-hrjr-88fv"
+    },
     "GHSA-QWWW-VCR4-C8H2": {
       "9e8b271a0d4ad205159c8d69b6a8a45062257a6f": "Improve GHSA-qwww-vcr4-c8h2",
       "f0d1bd1cd6cc2e8fea4f1352372728b50c3fe7ca": "Improve GHSA-qwww-vcr4-c8h2",
-      "e464bb099932cbbee4fb835c2d721c0448e18242": "Improve GHSA-qwww-vcr4-c8h2",
       "5f2e84d26f073330d4c324f0b1a9b9454cb866aa": "Improve GHSA-qwww-vcr4-c8h2",
       "e5949167053c6366f8ec76e715366fe3807afb45": "Improve GHSA-qwww-vcr4-c8h2",
       "f124383bedf26a55baaa839b1e08df6ec51681c7": "Improve GHSA-qwww-vcr4-c8h2",

data/fix-commits/netty-fc636c35.json

@@ -2,8 +2,8 @@
   "vcs_url": "https://github.com/netty/netty",
   "vulnerabilities": {
     "CVE-2026-42581": {
+      "09f55884dec3525b0a7031c056d63996b552eade": "Auto-port 4.1: Validate chunked-must-be-last regardless of HTTP version (#17228)\n\nAuto-port of #17055 to 4.1\nCherry-picked commit: fcf427d91c8321b3aa3f83af4a7029b98ce1753d\n\n---\n### Motivation\nRFC 9112 \u00a76.1 requires that when a message uses Transfer-Encoding,\n\"chunked\" must be the last encoding listed \u2014 a value like `chunked,\nidentity` is malformed. This rule was added to `HttpObjectDecoder`\nalongside the fix for CVE-2026-42581, nested inside a pre-existing\n`protocolVersion() == HttpVersion.HTTP_1_1` condition \u2014 the same\ncondition that gates a different, older check (the\nContent-Length/Transfer-Encoding conflict handling).\n\nUnder the default configuration this is harmless: an earlier guard\nalready rejects any Transfer-Encoding header on a non-1.1 message\noutright, so the ordering check's version scoping is not expected to be\nexercised under normal use. However,\n`HttpDecoderConfig#setUseRfc9112TransferEncoding(false)` is a documented\nopt-out for restoring RFC 7230 behavior, and under that configuration a\nnon-1.1 message can legitimately carry Transfer-Encoding without being\nrejected for it. In that case, the inherited version gate meant the\nchunked-must-be-last check was silently skipped for HTTP/1.0 (and other\nnon-1.1 versions) \u2014 a message with `Transfer-Encoding: chunked,\nidentity` would decode successfully instead of being rejected.\n\n### Modification\n\n- Extracted the chunked-must-be-last check from inside the\n`protocolVersion() == HTTP_1_1` block in `HttpObjectDecoder#readHeaders`\nand gave it its own, version-independent condition, since the RFC 9112\nordering rule has no dependency on protocol version.\n\n- Added two regression tests to `HttpRequestDecoderTest`: one\nreproducing the original scenario (HTTP/1.0,\n`useRfc9112TransferEncoding(false)`, `Transfer-Encoding: chunked,\nidentity)`, and a companion using a non-no-op trailing encoding\n(`chunked, gzip`) confirming the fix isn't tied to the specific encoding\nthat follows `chunked`.\n\n- Corrected a pre-existing inaccuracy in\n`handleTransferEncodingChunkedWithContentLength`'s javadoc, which stated\nthat earlier HTTP versions \"will reject requests that include\n[Transfer-Encoding]\" without qualification \u2014 true only under the default\nconfiguration, and already inaccurate before this change since\n`useRfc9112TransferEncoding(false)` predates it.\n\n### Result\n\n- The chunked-must-be-last validation now applies to any message\ncarrying a Transfer-Encoding header, independent of protocol version or\nthe `useRfc9112TransferEncoding` setting.\n\nSigned-off-by: husseinvr97 <husseinmustafabas05@gmail.com>\nCo-authored-by: Hussein Mustafa <husseinmustafabas05@gmail.com>\nCo-authored-by: Chris Vest <christianvest_hansen@apple.com>",
       "e93e3f2c59198dc78b9f8d396e8af5632b9c09ee": "Auto-port 5.0: Validate chunked-must-be-last regardless of HTTP version (#17227)\n\nAuto-port of #17055 to 5.0\nCherry-picked commit: fcf427d91c8321b3aa3f83af4a7029b98ce1753d\n\n---\n### Motivation\nRFC 9112 \u00a76.1 requires that when a message uses Transfer-Encoding,\n\"chunked\" must be the last encoding listed \u2014 a value like `chunked,\nidentity` is malformed. This rule was added to `HttpObjectDecoder`\nalongside the fix for CVE-2026-42581, nested inside a pre-existing\n`protocolVersion() == HttpVersion.HTTP_1_1` condition \u2014 the same\ncondition that gates a different, older check (the\nContent-Length/Transfer-Encoding conflict handling).\n\nUnder the default configuration this is harmless: an earlier guard\nalready rejects any Transfer-Encoding header on a non-1.1 message\noutright, so the ordering check's version scoping is not expected to be\nexercised under normal use. However,\n`HttpDecoderConfig#setUseRfc9112TransferEncoding(false)` is a documented\nopt-out for restoring RFC 7230 behavior, and under that configuration a\nnon-1.1 message can legitimately carry Transfer-Encoding without being\nrejected for it. In that case, the inherited version gate meant the\nchunked-must-be-last check was silently skipped for HTTP/1.0 (and other\nnon-1.1 versions) \u2014 a message with `Transfer-Encoding: chunked,\nidentity` would decode successfully instead of being rejected.\n\n### Modification\n\n- Extracted the chunked-must-be-last check from inside the\n`protocolVersion() == HTTP_1_1` block in `HttpObjectDecoder#readHeaders`\nand gave it its own, version-independent condition, since the RFC 9112\nordering rule has no dependency on protocol version.\n\n- Added two regression tests to `HttpRequestDecoderTest`: one\nreproducing the original scenario (HTTP/1.0,\n`useRfc9112TransferEncoding(false)`, `Transfer-Encoding: chunked,\nidentity)`, and a companion using a non-no-op trailing encoding\n(`chunked, gzip`) confirming the fix isn't tied to the specific encoding\nthat follows `chunked`.\n\n- Corrected a pre-existing inaccuracy in\n`handleTransferEncodingChunkedWithContentLength`'s javadoc, which stated\nthat earlier HTTP versions \"will reject requests that include\n[Transfer-Encoding]\" without qualification \u2014 true only under the default\nconfiguration, and already inaccurate before this change since\n`useRfc9112TransferEncoding(false)` predates it.\n\n### Result\n\n- The chunked-must-be-last validation now applies to any message\ncarrying a Transfer-Encoding header, independent of protocol version or\nthe `useRfc9112TransferEncoding` setting.\n\n---------\n\nSigned-off-by: husseinvr97 <husseinmustafabas05@gmail.com>\nCo-authored-by: Hussein Mustafa <husseinmustafabas05@gmail.com>\nCo-authored-by: Chris Vest <christianvest_hansen@apple.com>",
-      "cd3a48911ecc2b120d824ae11ab627aa6ea296fa": "Validate chunked-must-be-last regardless of HTTP version (#17055)\n\n### Motivation\nRFC 9112 \u00a76.1 requires that when a message uses Transfer-Encoding,\n\"chunked\" must be the last encoding listed \u2014 a value like `chunked,\nidentity` is malformed. This rule was added to `HttpObjectDecoder`\nalongside the fix for CVE-2026-42581, nested inside a pre-existing\n`protocolVersion() == HttpVersion.HTTP_1_1` condition \u2014 the same\ncondition that gates a different, older check (the\nContent-Length/Transfer-Encoding conflict handling).\n\nUnder the default configuration this is harmless: an earlier guard\nalready rejects any Transfer-Encoding header on a non-1.1 message\noutright, so the ordering check's version scoping is not expected to be\nexercised under normal use. However,\n`HttpDecoderConfig#setUseRfc9112TransferEncoding(false)` is a documented\nopt-out for restoring RFC 7230 behavior, and under that configuration a\nnon-1.1 message can legitimately carry Transfer-Encoding without being\nrejected for it. In that case, the inherited version gate meant the\nchunked-must-be-last check was silently skipped for HTTP/1.0 (and other\nnon-1.1 versions) \u2014 a message with `Transfer-Encoding: chunked,\nidentity` would decode successfully instead of being rejected.\n\n### Modification\n\n- Extracted the chunked-must-be-last check from inside the\n`protocolVersion() == HTTP_1_1` block in `HttpObjectDecoder#readHeaders`\nand gave it its own, version-independent condition, since the RFC 9112\nordering rule has no dependency on protocol version.\n\n- Added two regression tests to `HttpRequestDecoderTest`: one\nreproducing the original scenario (HTTP/1.0,\n`useRfc9112TransferEncoding(false)`, `Transfer-Encoding: chunked,\nidentity)`, and a companion using a non-no-op trailing encoding\n(`chunked, gzip`) confirming the fix isn't tied to the specific encoding\nthat follows `chunked`.\n\n- Corrected a pre-existing inaccuracy in\n`handleTransferEncodingChunkedWithContentLength`'s javadoc, which stated\nthat earlier HTTP versions \"will reject requests that include\n[Transfer-Encoding]\" without qualification \u2014 true only under the default\nconfiguration, and already inaccurate before this change since\n`useRfc9112TransferEncoding(false)` predates it.\n\n### Result\n\n- The chunked-must-be-last validation now applies to any message\ncarrying a Transfer-Encoding header, independent of protocol version or\nthe `useRfc9112TransferEncoding` setting.\n\nSigned-off-by: husseinvr97 <husseinmustafabas05@gmail.com>\nCo-authored-by: Chris Vest <christianvest_hansen@apple.com>\n(cherry picked from commit fcf427d91c8321b3aa3f83af4a7029b98ce1753d)",
       "fcf427d91c8321b3aa3f83af4a7029b98ce1753d": "Validate chunked-must-be-last regardless of HTTP version (#17055)\n\n### Motivation\nRFC 9112 \u00a76.1 requires that when a message uses Transfer-Encoding,\n\"chunked\" must be the last encoding listed \u2014 a value like `chunked,\nidentity` is malformed. This rule was added to `HttpObjectDecoder`\nalongside the fix for CVE-2026-42581, nested inside a pre-existing\n`protocolVersion() == HttpVersion.HTTP_1_1` condition \u2014 the same\ncondition that gates a different, older check (the\nContent-Length/Transfer-Encoding conflict handling).\n\nUnder the default configuration this is harmless: an earlier guard\nalready rejects any Transfer-Encoding header on a non-1.1 message\noutright, so the ordering check's version scoping is not expected to be\nexercised under normal use. However,\n`HttpDecoderConfig#setUseRfc9112TransferEncoding(false)` is a documented\nopt-out for restoring RFC 7230 behavior, and under that configuration a\nnon-1.1 message can legitimately carry Transfer-Encoding without being\nrejected for it. In that case, the inherited version gate meant the\nchunked-must-be-last check was silently skipped for HTTP/1.0 (and other\nnon-1.1 versions) \u2014 a message with `Transfer-Encoding: chunked,\nidentity` would decode successfully instead of being rejected.\n\n### Modification\n\n- Extracted the chunked-must-be-last check from inside the\n`protocolVersion() == HTTP_1_1` block in `HttpObjectDecoder#readHeaders`\nand gave it its own, version-independent condition, since the RFC 9112\nordering rule has no dependency on protocol version.\n\n- Added two regression tests to `HttpRequestDecoderTest`: one\nreproducing the original scenario (HTTP/1.0,\n`useRfc9112TransferEncoding(false)`, `Transfer-Encoding: chunked,\nidentity)`, and a companion using a non-no-op trailing encoding\n(`chunked, gzip`) confirming the fix isn't tied to the specific encoding\nthat follows `chunked`.\n\n- Corrected a pre-existing inaccuracy in\n`handleTransferEncodingChunkedWithContentLength`'s javadoc, which stated\nthat earlier HTTP versions \"will reject requests that include\n[Transfer-Encoding]\" without qualification \u2014 true only under the default\nconfiguration, and already inaccurate before this change since\n`useRfc9112TransferEncoding(false)` predates it.\n\n### Result\n\n- The chunked-must-be-last validation now applies to any message\ncarrying a Transfer-Encoding header, independent of protocol version or\nthe `useRfc9112TransferEncoding` setting.\n\nSigned-off-by: husseinvr97 <husseinmustafabas05@gmail.com>\nCo-authored-by: Chris Vest <christianvest_hansen@apple.com>"
     },
     "GHSA-6CX8-RJF8-PR8G": {