Repository navigation
fix: Bump body-parser from 2.3.0 to 2.4.0 - #960
Conversation
|
🚀 Thanks for opening this pull request! We appreciate your effort in improving the project. Please let us know once your pull request is ready for review. Tip
Note Please respond to review comments from AI agents just like you would to comments from a human reviewer. Let the reviewer resolve their own comments, unless they have reviewed and accepted your commit, or agreed with your explanation for why the feedback was incorrect. Caution Pull requests must be written using an AI agent with human supervision. Pull requests written entirely by a human will likely be rejected, because of lower code quality, higher review effort and the higher risk of introducing bugs. Please note that AI review comments on this pull request alone do not satisfy this requirement. Our CI and AI review are safeguards, not development tools. If many issues are flagged, rethink your development approach. Invest more effort in planning and design rather than using review cycles to fix low-quality code. |
|
No actionable comments were generated in the recent review.
|
| Layer / File(s) | Summary |
|---|---|
Update body-parser resolutions package-lock.json |
The lockfile records body-parser 2.4.0, updates its content-type, iconv-lite, and qs requirements, and resolves nested content-type to 2.1.0. |
Priority:
Estimated code review effort: 1 (Trivial) | ~4 minutes
Possibly related PRs
- parse-community/parse-server-example#954: Both PRs update the
qslockfile resolution to 6.16.1. This PR updates it throughbody-parser2.4.0.
Merge Risk: 
Minimal · up to 22b15
-
This dependency-only update is ready to merge with normal checks.
Pre-merge checks: 
6
-
Full details: Linked Issues check
-
Explanation
Issue
#949requiresbody-parser2.4.0 and its release fixes. The whole-PR lockfile diff updates both lockfile representations from 2.3.0 to 2.4.0 and records the required nestedcontent-type2.1.0 dependency. The installed package therefore includes the CVE-2026-111181 fix and the 2.4.0 parser behavior, including conditionalzstdsupport. The issue does not require application code changes or a repository test addition.
Full details: Out of Scope Changes check
-
Explanation
The whole-PR diff changes only
package-lock.json. It updatesbody-parserand the nestedcontent-typeentry, plus the dependency ranges required bybody-parser2.4.0. These changes directly support issue#949. No unrelated source, configuration, or dependency changes are present.
Full details: Security Check
-
Explanation
PASS. The pull request changes only package-lock.json. It replaces body-parser 2.3.0 with 2.4.0 and updates its nested content-type dependency to 2.1.0, with matching integrity values in both lockfile representations. No application code or executable lifecycle configuration changed, and the diff introduces no security-vulnerable code pattern.
-
Finishing Touches
-
🧪 Generate unit tests (beta)
-
- Create a new PR
-
- Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
Comment @coderabbitai help to get the list of available commands.
## [3.1.3](3.1.2...3.1.3) (2026-10-27) ### Bug Fixes * Bump body-parser from 2.3.0 to 2.4.0 ([#960](#960)) ([8d76e46](8d76e46))
|
🎉 This change has been released in version 3.1.3 |
Closes #949
Issue
Addresses Dependabot alert 470 (high): GHSA-27r3-jxmh-p828 / CVE-2026-111181, "body-parser vulnerable to Denial of Service via trailing bytes after a compressed request body". Vulnerable
>= 2.0.0, < 2.4.0; patched in2.4.0.body-parseris a transitive production dependency (npm ls body-parser --omit=dev):express@5.2.1→body-parser, andparse-server@9.10.7→@apollo/server@5.5.0→body-parser(deduped). The lock has a single hoisted copy, so this update covers both parents.Reachability in this app
index.tsmountsserver.appat/parseand adds no body parser of its own.parse-server@9.10.7mounts threebody-parserparsers onserver.app. Express 5'sexpress.json,express.urlencodedandexpress.rawarebody-parser's parsers.express.json({ type: req => !req.is('multipart/form-data'), limit: maxUploadSize })inlib/ParseServer.jshandles every request body that is notmultipart/form-data.express.urlencoded({ extended: false })inlib/ParseServer.jsis mounted on/, in front of the pages router.express.raw({ type: () => true, limit })inlib/Routers/FilesRouter.jshandles file uploads (POST /files/:filename).All three read compressed bodies through
body-parser's shared read path, and all three run before Parse Server checks the application ID or any key. A test harness replicated these three mounts. Withbody-parser@2.3.0, a gzip-encoded body followed by extra bytes terminated the Node.js process through each of them. With2.4.0, the process stayed up in every case.Changes
errorevent. As part of the same fix, theverifycharset check now runs before the stream is created.zstdcontent-encoding support (feat: zstandard support expressjs/body-parser#586). It is only active when the runtime provideszlib.createZstdDecompress(Node.js^22.15.0or>=23.8.0); on older runtimeszstdbodies still return415. The size limit applies to the decompressed body.req.lengthisundefinedin both versions, but 2.4.0 no longer defines the property, so only its presence changes (Object.hasOwn(req, 'length')and'length' in reqnow returnfalse).getCharsethelper moved to its only caller (refactor: move getCharset helper to only usage expressjs/body-parser#707), and the code style switched to neostandard (refactor: switch to neostandard expressjs/body-parser#751).content-type@^2.1.0,iconv-lite@^0.7.3andqs@^6.16.1(deps: qs@^6.16.0 expressjs/body-parser#762, chore: update dependencies expressjs/body-parser#778).Lock file
Changed entries:
body-parser2.3.0 → 2.4.0body-parser/node_modules/content-type2.0.0 → 2.1.0, becausebody-parser@2.4.0requirescontent-type@^2.1.0. Version 2.1.0 adds two opt-inparse()options,commaandstart(Parse up to comma jshttp/content-type#72).body-parsercallscontentType.parse(header)without options and only reads thecharsetparameter, so the new options stay off. Running 20,035Content-Typeheaders through that exact call gave identical results with 2.0.0 and 2.1.0. The top-levelcontent-type@1.0.5(used byexpressand@apollo/server) and the copy undertype-isare unchanged.qs@6.16.1andiconv-lite@0.7.3were already in the lock. Theqschanges only affect extended URL-encoded parsing, and Parse Server usesextended: false.This lock was generated with
npm update body-parser --package-lock-onlyon the currentmaster(d7753a5), instead of reusing the lock from #949. Dependabot's lock (+20/−152) also removes the entries forgcp-metadata(with its nestedgaxiosandnode-fetch) andsocks, which are optional peer dependencies ofmongodb, and forsmart-buffer, a dependency ofsocks. That removal is unrelated to this update. This lock changes only the two entries above.Breaking Changes
None
Code Changes Required
None. The upgrade is a lock-file-only drop-in replacement.
Summary by CodeRabbit