Sync Collecting Fix Commits: Wed Sep 9 17:18:26 UTC 2026

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

Author: aboutcode-automation

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

@@ -1,6 +1,9 @@
 {
   "vcs_url": "https://github.com/langchain-ai/langgraph",
   "vulnerabilities": {
+    "GHSA-2883-XCG3-V3HH": {
+      "e539ac122f4126f6dd850581c1494948cf620e31": "chore(deps): fix vulnerable dev dependencies (#8449)\n\n## Summary\nPatch both `js-yaml` release lines in `libs/cli/js-examples` for\nGHSA-2883-xcg3-v3hh: Jest's transitive copy to 3.15.2 and ESLint's to\n4.3.2. Updates the existing fix rather than opening a duplicate; no\nruntime dependencies added and no major-version overrides.\n\nAddresses Dependabot alerts\n[#398](https://github.com/langchain-ai/langgraph/security/dependabot/398)\nand\n[#397](https://github.com/langchain-ai/langgraph/security/dependabot/397).\nThese are real vulnerable versions in example development tooling; patch\nrather than dismiss. Alerts remain open until this reaches `main` and\nGitHub rescans.\n\n## Verification\n- [x] Yarn 1.22.22 regenerated the lockfile with lifecycle scripts\ndisabled; diff limited to the two js-yaml entries and scoped\nresolutions.\n- [x] `yarn install --frozen-lockfile --ignore-scripts --force\n--non-interactive` in `libs/cli/js-examples`.\n- [x] `yarn why js-yaml`: ESLint 4.3.2 and Jest/Istanbul 3.15.2.\n- [x] Resolved versions checked against freshly retrieved GitHub\nadvisory patched versions for both alerts.\n- [x] `yarn format:check` and `git diff --check`.\n- [ ] Build fails in unchanged `tests/graph.int.test.ts:7`: `input` is\nnot a valid update property (also recorded in the earlier PR\nverification).\n- [ ] Unit-test script fails because it uses Jest's removed\n`--testPathPattern` option; Jest requires `--testPathPatterns`.\n- [ ] Lint fails because ESLint 10 requires `eslint.config.*`, which\nthis example lacks.\n\nThe build/test/lint configuration issues are outside this scoped\ndependency patch and remain unresolved. No full test-pass claim.\n\n---------\n\nCo-authored-by: langsmith-fleet[bot] <langsmith-fleet[bot]@users.noreply.github.com>"
+    },
     "GHSA-6M44-FPC8-C3RQ": {
       "11738d83db4320bb191804342b5c76ae7eca54a0": "chore(langgraph): bump mistune to 3.3.4 (#8804)\n\nUpdates the `libs/langgraph/uv.lock` development dependency from Mistune\n3.3.0 to 3.3.4, resolving GHSA-6m44-fpc8-c3rq (Dependabot #389). The\nchange is scoped to the affected lockfile.\n\nValidation: `uv lock --project libs/langgraph --locked`.\n\nCo-authored-by: langsmith-fleet[bot] <langsmith-fleet[bot]@users.noreply.github.com>"
     },

data/fix-commits/bun-1f8d61fe.json

@@ -1,6 +1,9 @@
 {
   "vcs_url": "https://github.com/netty/netty",
   "vulnerabilities": {
+    "CVE-2025-59419": {
+      "028d715ba16f872f1e43841b6181a99736d1814e": "Validate SMTP command name for CRLF to prevent command injection\n\nMotivation:\n\nCVE-2025-59419 added CR/LF validation for SMTP request parameters but\nleft the command name unvalidated: neither SmtpCommand.valueOf nor the\nSmtpCommand constructor nor SmtpRequestEncoder checks it. A command name\nwith embedded CR/LF (e.g. \"NOOP\\r\\nMAIL FROM:<...>\") therefore encodes\nto several smuggled commands on the wire \u2014 the same injection class\n(CWE-93) the parent CVE set out to close, on a field it did not cover.\n\nModification:\n\n- Validate CR/LF in the private SmtpCommand(AsciiString) constructor,\nthe single construction path for all commands (cached constants and\nvalueOf alike).\n- Widen SmtpUtils.validateSMTPParameter to package-private for reuse.\n- Add a regression test asserting valueOf rejects CR/LF in the command\nname.\n\nResult:\n\nA command name with CR/LF can no longer be constructed, so the encoder\ncannot emit smuggled commands. This completes the CVE-2025-59419 fix\nacross both parameters and the command-name field."
+    },
     "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>",