refactor: Bump parse-server from 9.2.0 to 9.6.1#3275
refactor: Bump parse-server from 9.2.0 to 9.6.1#3275mtrezza merged 1 commit intoparse-community:alphafrom
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. |
✅ Snyk checks have passed. No issues have been found so far.
💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse. |
📝 WalkthroughWalkthroughThis PR upgrades Changes
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~3 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 Checkov (3.2.510)package.json2026-03-29 20:22:39,254 [MainThread ] [ERROR] Template file not found: package.json ... [truncated 2547 characters] ... [MainThread ] [WARNI] Secret scanning: could not process file package.json Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@package-lock.json`:
- Line 92: The dependency parse-server pinned as "parse-server": "9.6.1"
contains known high-severity vulnerabilities; update the dependency to a safe
release (either downgrade to the patched stable "8.6.70" or upgrade to the
forthcoming safe "9.7.0" stable when released), then regenerate the lockfile and
reinstall deps (update package.json to the chosen version, run npm install or
yarn install to update package-lock.json/yarn.lock), run npm audit to confirm no
remaining advisories and run the test suite; ensure CI uses the updated lockfile
before merging.
- Line 25540: The transitive dependency path-to-regexp is pinned to 8.3.0 and
contains known vulnerabilities; update it to 8.4.0 by either regenerating the
lockfile with the patched version or adding a resolution/override: locate the
path-to-regexp entry in package-lock.json and change the version to "8.4.0",
then run a lockfile refresh (e.g., npm install --package-lock-only or npm ci) to
ensure integrity, or alternatively add an npm/yarn resolution for
"path-to-regexp" -> "8.4.0" so parse-server@9.6.1 resolves to the patched 8.4.0
until parse-server itself is updated.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 046b073b-d15a-4df7-bda7-7ab84745e615
📒 Files selected for processing (2)
package-lock.jsonpackage.json
| "marked": "15.0.12", | ||
| "mongodb-runner": "^6.6.0", | ||
| "parse-server": "9.2.0", | ||
| "parse-server": "9.6.1", |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Description: Check for security advisories and latest version of parse-server
# Check latest version available on npm
echo "=== Latest parse-server version on npm ==="
npm view parse-server version
# Check for security advisories using GitHub CLI
echo -e "\n=== Security advisories for parse-server ==="
gh api graphql -f query='
{
securityVulnerabilities(first: 10, ecosystem: NPM, package: "parse-server") {
nodes {
advisory {
summary
severity
publishedAt
ghsaId
}
vulnerableVersionRange
firstPatchedVersion {
identifier
}
}
}
}'
# Check specific advisories mentioned
echo -e "\n=== Checking GHSA-w73w-g5xw-rwhf ==="
gh api /advisories/GHSA-w73w-g5xw-rwhf
echo -e "\n=== Checking GHSA-wp76-gg32-8258 ==="
gh api /advisories/GHSA-wp76-gg32-8258Repository: parse-community/parse-dashboard
Length of output: 692
🌐 Web query:
GHSA-w73w-g5xw-rwhf parse-server MFA token bypass
💡 Result:
GHSA-w73w-g5xw-rwhf is a security vulnerability in Parse Server that allows MFA single-use token bypass via concurrent authData login requests. It was fixed in Parse Server version 8.6.64 (released 2026-03-26) and 9.7.0-alpha.8.
Citations:
- 1: https://newreleases.io/project/github/parse-community/parse-server/release/8.6.64
- 2: https://github.com/parse-community/parse-server/releases
🌐 Web query:
GHSA-wp76-gg32-8258 parse-server auth data exposure
💡 Result:
GHSA-wp76-gg32-8258 is a GitHub Security Advisory identifier for a vulnerability in parse-community/parse-server where authentication data (auth data) is exposed via the verify password endpoint. This is an information disclosure issue allowing unauthorized access to sensitive authentication information. The vulnerability was fixed in recent releases: - Parse Server 8.6.63 (commit #10324, a1d4e7b) - Parse Server 9.7.0-alpha.7 (commit #10323, 770be86) These releases include the bug fix described as "Auth data exposed via verify password endpoint (GHSA-wp76-gg32-8258)". Users should upgrade to these or later versions to mitigate the issue. No detailed advisory page was found in searches, but the fix is confirmed in official release notes from GitHub and NewReleases.io. The issue appears recent, published around March 26, 2026.
Citations:
- 1: https://annpjia.blogspot.com/?page=en-git-7azimo01-vulnerability-spoiler-alert-1774569794688
- 2: https://newreleases.io/project/github/parse-community/parse-server/release/9.7.0-alpha.7
- 3: https://newreleases.io/project/github/parse-community/parse-server/release/8.6.63
- 4: https://loquacious-sunflower-f65308.netlify.app/?page=en-git-7azimo01-vulnerability-spoiler-alert-1774569794688
- 5: https://github.com/parse-community/parse-server/releases
- 6: https://github.com/parse-community/parse-server/tags
🏁 Script executed:
#!/bin/bash
# Try to check npm audit information for parse-server
npm view parse-server@9.6.1 --json | head -100Repository: parse-community/parse-dashboard
Length of output: 1599
Critical security vulnerabilities in parse-server 9.6.1 – do not merge without resolution.
Both HIGH severity security advisories in parse-server 9.6.1 are confirmed:
- GHSA-w73w-g5xw-rwhf: MFA single-use token bypass via concurrent authData login requests (fixed in 8.6.64 and 9.7.0-alpha.8+)
- GHSA-wp76-gg32-8258: Authentication data exposure via verify password endpoint (fixed in 8.6.63 and 9.7.0-alpha.7+)
Action required: Either downgrade to parse-server 8.6.70 (stable, patched) or wait for parse-server 9.7.0 stable release. Do not proceed with 9.6.1.
🧰 Tools
🪛 OSV Scanner (2.3.5)
[HIGH] 92-92: parse-server 9.6.1: Parse Server has an MFA single-use token bypass via concurrent authData login requests
[HIGH] 92-92: parse-server 9.6.1: Parse Server exposes auth data via verify password endpoint
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@package-lock.json` at line 92, The dependency parse-server pinned as
"parse-server": "9.6.1" contains known high-severity vulnerabilities; update the
dependency to a safe release (either downgrade to the patched stable "8.6.70" or
upgrade to the forthcoming safe "9.7.0" stable when released), then regenerate
the lockfile and reinstall deps (update package.json to the chosen version, run
npm install or yarn install to update package-lock.json/yarn.lock), run npm
audit to confirm no remaining advisories and run the test suite; ensure CI uses
the updated lockfile before merging.
There was a problem hiding this comment.
parse-server is a devDependency used only for testing. The two GHSAs mentioned (GHSA-w73w-g5xw-rwhf, GHSA-wp76-gg32-8258) are server-side vulnerabilities that don't affect parse-dashboard in production. Version 9.6.1 is the latest stable release — 9.7.0 is not yet available. Upgrading from 9.2.0 to 9.6.1 already fixes dozens of security issues, which is strictly better than staying on 9.2.0.
There was a problem hiding this comment.
@mtrezza, you're right — I apologize for the false alarm. Since parse-server is a devDependency used exclusively for testing, the two flagged server-side vulnerabilities (GHSA-w73w-g5xw-rwhf and GHSA-wp76-gg32-8258) do not affect parse-dashboard in production. Upgrading from 9.2.0 to 9.6.1 is a clear net security improvement. I'll withdraw this concern.
✏️ Learnings added
Learnt from: mtrezza
Repo: parse-community/parse-dashboard PR: 3275
File: package-lock.json:92-92
Timestamp: 2026-03-29T20:30:04.235Z
Learning: In parse-community/parse-dashboard, `parse-server` is a devDependency used only for testing (not shipped to production). Server-side security vulnerabilities in `parse-server` (e.g. GHSAs affecting parse-server itself) do not affect parse-dashboard in production and should not be flagged as blocking issues for parse-dashboard PRs.
Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.
🧠 Learnings used
Learnt from: mtrezza
Repo: parse-community/parse-dashboard PR: 3113
File: src/lib/GraphPreferencesManager.js:414-416
Timestamp: 2026-01-14T00:14:25.349Z
Learning: The parse-dashboard codebase uses `crypto.randomUUID()` throughout and this pattern is acceptable. Browser compatibility concerns for `crypto.randomUUID()` should not be flagged.
Learnt from: Moumouls
Repo: parse-community/parse-dashboard PR: 3000
File: Parse-Dashboard/Authentication.js:60-68
Timestamp: 2025-10-13T13:02:44.343Z
Learning: In the parse-dashboard repository, NODE_ENV is not used as a standard environment variable for determining production vs development environments.
Learnt from: mtrezza
Repo: parse-community/parse-dashboard PR: 0
File: :0-0
Timestamp: 2025-05-11T16:43:27.354Z
Learning: The bcryptjs library is used in Parse Dashboard for password encryption and validation in three files: Parse-Dashboard/Authentication.js (compareSync), Parse-Dashboard/CLI/mfa.js (genSaltSync, hashSync), and src/dashboard/Settings/DashboardSettings/DashboardSettings.react.js (genSaltSync, hashSync).
Learnt from: Moumouls
Repo: parse-community/parse-dashboard PR: 3000
File: Parse-Dashboard/Authentication.js:60-68
Timestamp: 2025-10-13T13:02:44.343Z
Learning: Parse Dashboard can run locally as a development tool, so security configurations that require HTTPS (like the `secure` cookie flag) should be optional/configurable rather than enforced, to avoid breaking local development workflows.
Learnt from: mtrezza
Repo: parse-community/parse-dashboard PR: 3252
File: changelogs/CHANGELOG_alpha.md:0-0
Timestamp: 2026-03-06T18:23:39.621Z
Learning: In the parse-community/parse-dashboard repository, changelog entries (e.g. changes to `changelogs/CHANGELOG_alpha.md` or `CHANGELOG.md`) are NOT allowed in pull requests. Changelogs are managed automatically by semantic-release. Any PR that includes manual changelog modifications must be rejected and the contributor must be asked to remove the changelog changes.
| "otpauth": "9.4.0", | ||
| "parse": "8.0.3", | ||
| "parse": "8.5.0", | ||
| "path-to-regexp": "8.3.0", |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Description: Check path-to-regexp vulnerabilities and available patches
# Check latest version
echo "=== Latest path-to-regexp version ==="
npm view path-to-regexp version
# Check security advisories
echo -e "\n=== Security advisories for path-to-regexp ==="
gh api graphql -f query='
{
securityVulnerabilities(first: 10, ecosystem: NPM, package: "path-to-regexp") {
nodes {
advisory {
summary
severity
publishedAt
ghsaId
}
vulnerableVersionRange
firstPatchedVersion {
identifier
}
}
}
}'
# Check specific advisories
echo -e "\n=== Checking GHSA-27v5-c462-wpq7 ==="
gh api /advisories/GHSA-27v5-c462-wpq7
echo -e "\n=== Checking GHSA-j3q9-mxjg-w52f ==="
gh api /advisories/GHSA-j3q9-mxjg-w52f
# Check what version parse-server 9.6.1 requires
echo -e "\n=== path-to-regexp version required by parse-server 9.6.1 ==="
npm view parse-server@9.6.1 dependencies.path-to-regexpRepository: parse-community/parse-dashboard
Length of output: 757
🌐 Web query:
GHSA-27v5-c462-wpq7 path-to-regexp vulnerability
💡 Result:
GHSA-27v5-c462-wpq7 is a GitHub security advisory for a Regular Expression Denial of Service (ReDoS) vulnerability in the path-to-regexp npm package (CVE-2026-4923). It affects versions >=8.0.0 and <8.4.0. The issue occurs when using multiple wildcards (*) combined with at least one parameter (:), where the second wildcard is not at the end of the path, generating regex vulnerable to backtracking. Examples of unsafe paths: /*foo-*bar-:baz, /*a-:b-*c-:d, /x/*a-:b/*c/y. Safe examples: /*foo-:bar, /*foo-:bar-*baz. Upgrade to version 8.4.0 to fix. Published around March 26-27, 2026.
Citations:
- 1: https://advisories.gitlab.com/pkg/npm/path-to-regexp/CVE-2026-4923/
- 2: https://www.resolvedsecurity.com/vulnerability-catalog/CVE-2026-4923
- 3: https://newreleases.io/project/npm/path-to-regexp/release/8.4.0
- 4: https://guide.sonatype.com/component/npm/path-to-regexp/8.4.0
🌐 Web query:
GHSA-j3q9-mxjg-w52f path-to-regexp vulnerability
💡 Result:
GHSA-j3q9-mxjg-w52f is a Denial of Service (DoS) vulnerability in the path-to-regexp npm package, also tracked as CVE-2026-4926. It affects versions >=8.0.0 and <8.4.0. The vulnerability occurs when multiple sequential optional groups (using curly brace syntax, e.g., {a}{b}{c}:z) are used in route patterns. This generates a regular expression that grows exponentially with the number of groups, leading to excessive resource consumption and potential DoS during regex matching. No known public exploits exist. The issue was fixed in version 8.4.0, released on 2026-03-26. Workarounds: Limit the number of sequential optional groups in route patterns and avoid passing user-controlled input directly as route patterns. CVSS score: 7.5 (High) - AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H. path-to-regexp is used for converting Express-style paths (e.g., /user/:name) into regular expressions, commonly in Node.js routing libraries like Express, Koa Router, etc. Official advisory: GHSA-j3q9-mxjg-w52f (inferred from references). Upgrade to path-to-regexp >=8.4.0 immediately if using affected versions.
Citations:
- 1: https://advisories.gitlab.com/pkg/npm/path-to-regexp/CVE-2026-4926/
- 2: https://github.com/pillarjs/path-to-regexp
- 3: https://security-tracker.debian.org/tracker/CVE-2026-4926
- 4: https://vulert.com/vuln-db/CVE-2026-4926
- 5: https://cvefeed.io/vuln/detail/CVE-2026-4926
🌐 Web query:
path-to-regexp 8.3.0 security vulnerabilities DoS
💡 Result:
Yes, path-to-regexp 8.3.0 has known security vulnerabilities related to Denial of Service (DoS), specifically Regular Expression Denial of Service (ReDoS). Two high/medium severity ReDoS vulnerabilities affect versions >=8.0.0 <8.4.0, including 8.3.0: 1. GHSA-27v5-c462-wpq7 / CVE-2026-4923 (Moderate, CVSS 5.9, published 2026-03-27): Vulnerable to ReDoS via multiple wildcards combined with at least one parameter, if the second wildcard is not at the end of the path. Examples: /*foo-*bar-:baz, /*a-:b-*c-:d. Patched in 8.4.0. 2. Another ReDoS issue with multiple sequential optional groups in route patterns, also fixed in 8.4.0 (Snyk high severity). Snyk explicitly lists these for 8.3.0, recommending upgrade to >=8.4.0 (latest non-vulnerable version). 8.4.0 was released around 2026-03-26/27 to address CVE-2026-4923 and CVE-2026-4926. Upgrade to path-to-regexp 8.4.0 or higher to mitigate.
Citations:
- 1: https://security.snyk.io/package/npm/path-to-regexp/8.3.0
- 2: GHSA-9wv6-86v2-598j
- 3: GHSA-27v5-c462-wpq7
- 4: https://snyk.io/vuln/SNYK-JS-PATHTOREGEXP-15789761
- 5: https://vulert.com/vuln-db/npm-path-to-regexp-150242
- 6: https://vulert.com/vuln-db/CVE-2026-4923
- 7: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1132020
- 8: https://www.npmjs.com/package/path-to-regexp
- 9: https://newreleases.io/project/npm/path-to-regexp/release/8.4.0
🏁 Script executed:
#!/bin/bash
# Check parse-server versions and their path-to-regexp dependency
echo "=== parse-server versions and path-to-regexp dependency ==="
npm view parse-server versions --json | jq -r '.[]' | tail -20 | while read version; do
dep=$(npm view parse-server@$version dependencies.path-to-regexp 2>/dev/null)
if [ -n "$dep" ]; then
echo "parse-server $version => path-to-regexp $dep"
fi
done
echo -e "\n=== Latest parse-server version ==="
npm view parse-server versionRepository: parse-community/parse-dashboard
Length of output: 1189
Vulnerabilities in path-to-regexp 8.3.0 require upgrade to 8.4.0.
The transitive dependency path-to-regexp@8.3.0 has two confirmed security vulnerabilities:
- GHSA-27v5-c462-wpq7 (CVE-2026-4923): Regular Expression Denial of Service via multiple wildcards (CVSS 5.9 - Moderate)
- GHSA-j3q9-mxjg-w52f (CVE-2026-4926): Denial of Service via sequential optional groups (CVSS 7.5 - High)
Both are fixed in path-to-regexp 8.4.0 (released 2026-03-26). Since parse-server@9.6.1 currently depends on the vulnerable 8.3.0, either:
- Wait for parse-server 9.7.0+ (upcoming releases use the patched 8.4.0), or
- Update path-to-regexp directly in package-lock.json to 8.4.0
🧰 Tools
🪛 OSV Scanner (2.3.5)
[HIGH] 25540-25540: path-to-regexp 8.3.0: path-to-regexp vulnerable to Regular Expression Denial of Service via multiple wildcards
[HIGH] 25540-25540: path-to-regexp 8.3.0: path-to-regexp vulnerable to Denial of Service via sequential optional groups
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@package-lock.json` at line 25540, The transitive dependency path-to-regexp is
pinned to 8.3.0 and contains known vulnerabilities; update it to 8.4.0 by either
regenerating the lockfile with the patched version or adding a
resolution/override: locate the path-to-regexp entry in package-lock.json and
change the version to "8.4.0", then run a lockfile refresh (e.g., npm install
--package-lock-only or npm ci) to ensure integrity, or alternatively add an
npm/yarn resolution for "path-to-regexp" -> "8.4.0" so parse-server@9.6.1
resolves to the patched 8.4.0 until parse-server itself is updated.
There was a problem hiding this comment.
path-to-regexp is a transitive dependency of parse-server and can only be updated upstream. Since parse-server is a devDependency used only for testing, these ReDoS vulnerabilities in a transitive dependency do not pose a risk to parse-dashboard. This will be resolved when parse-server releases a version that includes path-to-regexp 8.4.0.
There was a problem hiding this comment.
@mtrezza, understood — since parse-server is a devDependency used exclusively for testing, its transitive dependency path-to-regexp@8.3.0 is never shipped to parse-dashboard end users and the ReDoS vulnerabilities pose no risk to the production environment. I'll dismiss this finding and note it for future reviews.
✏️ Learnings added
Learnt from: mtrezza
Repo: parse-community/parse-dashboard PR: 3275
File: package-lock.json:25540-25540
Timestamp: 2026-03-29T20:30:04.328Z
Learning: In parse-community/parse-dashboard, `parse-server` is listed under `devDependencies` and is used only for local testing. Vulnerabilities in transitive dependencies of `parse-server` (e.g., `path-to-regexp`) do not pose a security risk to parse-dashboard's production environment and should not be flagged as actionable issues on parse-dashboard PRs. Such vulnerabilities must be resolved upstream in parse-server itself.
Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.
🧠 Learnings used
Learnt from: mtrezza
Repo: parse-community/parse-dashboard PR: 3113
File: src/lib/GraphPreferencesManager.js:414-416
Timestamp: 2026-01-14T00:14:25.349Z
Learning: The parse-dashboard codebase uses `crypto.randomUUID()` throughout and this pattern is acceptable. Browser compatibility concerns for `crypto.randomUUID()` should not be flagged.
Learnt from: mtrezza
Repo: parse-community/parse-dashboard PR: 3185
File: package.json:51-51
Timestamp: 2026-02-07T02:18:58.579Z
Learning: In parse-dashboard, async route handlers use intentional try/catch blocks that send proper HTTP error responses (e.g., 500 with error message). This is deliberate error handling, not promise swallowing. Routes without try/catch rely on Express 5's automatic rejection forwarding.
Learnt from: Moumouls
Repo: parse-community/parse-dashboard PR: 3000
File: Parse-Dashboard/Authentication.js:60-68
Timestamp: 2025-10-13T13:02:44.343Z
Learning: Parse Dashboard can run locally as a development tool, so security configurations that require HTTPS (like the `secure` cookie flag) should be optional/configurable rather than enforced, to avoid breaking local development workflows.
Learnt from: mtrezza
Repo: parse-community/parse-dashboard PR: 0
File: :0-0
Timestamp: 2025-05-11T16:43:27.354Z
Learning: The bcryptjs library is used in Parse Dashboard for password encryption and validation in three files: Parse-Dashboard/Authentication.js (compareSync), Parse-Dashboard/CLI/mfa.js (genSaltSync, hashSync), and src/dashboard/Settings/DashboardSettings/DashboardSettings.react.js (genSaltSync, hashSync).
Learnt from: mtrezza
Repo: parse-community/parse-dashboard PR: 3252
File: changelogs/CHANGELOG_alpha.md:0-0
Timestamp: 2026-03-06T18:23:39.621Z
Learning: In the parse-community/parse-dashboard repository, changelog entries (e.g. changes to `changelogs/CHANGELOG_alpha.md` or `CHANGELOG.md`) are NOT allowed in pull requests. Changelogs are managed automatically by semantic-release. Any PR that includes manual changelog modifications must be rejected and the contributor must be asked to remove the changelog changes.
Learnt from: Moumouls
Repo: parse-community/parse-dashboard PR: 3000
File: Parse-Dashboard/Authentication.js:60-68
Timestamp: 2025-10-13T13:02:44.343Z
Learning: In the parse-dashboard repository, NODE_ENV is not used as a standard environment variable for determining production vs development environments.
Learnt from: mtrezza
Repo: parse-community/parse-dashboard PR: 2979
File: src/dashboard/Data/Views/Views.react.js:905-912
Timestamp: 2025-09-11T00:15:33.497Z
Learning: In the parse-dashboard codebase, class names are used directly in path segments without URL encoding (e.g., `browser/${className}`) for consistency across methods like handlePointerClick, handlePointerCmdClick, and handleOpenAllPointers.
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
mtrezza
dismissed
coderabbitai[bot]’s stale review
Concerns addressed: parse-server is a devDependency used only for testing. The flagged vulnerabilities are server-side issues that don't affect parse-dashboard in production. path-to-regexp is a transitive dependency that can only be updated upstream. CodeRabbit acknowledged both justifications.
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
2 participants
Bumps parse-server from 9.2.0 to 9.6.1.
Closes #3274
Changes
pages.enableRouterBreaking Changes
None
Code Changes Required
None — the upgrade is a drop-in replacement.
Summary by CodeRabbit
parse-serverand related dependencies to latest compatible versions for improved stability and security.