Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
117 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Impact A foreign user can write to the session object of another user if the session object ID is known. For example, a foreign user can assign the session object to their own user by writing to the user field and then read any custom fields of that session object. Note that assigning a session to a foreign user does not usually change the privileges of neither of the two users, according to how Parse Server uses session objects internally. However, if custom logic is used to relate specific session objects to privileges this vulnerability may have a higher level of severity. The vulnerability does not allow a foreign user to assign a session object to themselves, read the session token, and then reassign the session object to the original user to then authenticate as that user with the known session token. The vulnerability only exists for foreign session objects, a user cannot assign their own session to another user. While it is unlikely that the session object ID of another user…
Recommended action: Upgrade to 5.2.6 or 4.10.15 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Internal fields (keys used internally by Parse Server, prefixed by ) and protected fields (user defined) can be used as query constraints. Internal and protected fields are removed by Parse Server from query results and are only returned to the client using a valid master key. However, using query constraints, these fields can be guessed by enumerating until Parse Server returns a response object. Patches The patch requires the master key to use internal and protected fields as query constraints. Workarounds Implement a Parse Cloud Trigger beforeFind and manually remove the query constraints, such as: References - https://github.com/parse-community/parse-server/security/advisories/GHSA-2m6g-crv8-p3c6
Recommended action: Upgrade to 5.2.5 or 4.10.14 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Parse Server LiveQuery does not remove protected fields in classes, passing them to the client. Patches The LiveQueryController now removes protected fields from the client response. Workarounds Use Parse.Cloud.afterLiveQueryEvent to manually remove protected fields. References - https://github.com/parse-community/parse-server/security/advisories/GHSA-crrq-vr9j-fxxh - https://github.com/parse-community/parse-server For more information If you have any questions or comments about this advisory: - For questions or comments about this vulnerability visit our community forum or community chat - Report other vulnerabilities at report.parseplatform.org
Recommended action: Upgrade to 5.2.4 or 4.10.13 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Certain types of invalid files requests are not handled properly and can crash the server. If you are running multiple Parse Server instances in a cluster, the availability impact may be low; if you are running Parse Server as a single instance without redundancy, the availability impact may be high. Patches To prevent this, invalid requests are now properly handled. Workarounds None References - https://github.com/parse-community/parse-server/security/advisories/GHSA-xw6g-jjvf-wwf9 - https://github.com/parse-community/parse-server For more information - For questions or comments about this vulnerability visit our community forum or community chat - Report other vulnerabilities at report.parseplatform.org
Recommended action: Upgrade to 5.2.3 or 4.10.12 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The certificate in Apple Game Center auth adapter not validated. As a result, authentication could potentially be bypassed by making a fake certificate accessible via certain Apple domains and providing the URL to that certificate in an authData object. Patches To prevent this, a new rootCertificateUrl property is introduced to the Parse Server Apple Game Center auth adapter which takes the URL to the root certificate of Apple's Game Center authentication certificate. If no value is set, the rootCertificateUrl property defaults to the URL of the current root certificate as of May 27, 2022. Keep in mind that the root certificate can change at any time (expected to be announced by Apple) and that it is the developer's responsibility to keep the root certificate URL up-to-date when using the Parse Server Apple Game Center auth adapter. Workarounds None. References - https://github.com/parse-community/parse-server/security/advisories/GHSA-rh9j-f5f8-rvgc -…
Recommended action: Upgrade to 5.2.2 or 4.10.11 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Weak validation of the Apple certificate URL in the Apple Game Center authentication adapter allows to bypass authentication and makes the server vulnerable to DoS attacks. Patches The vulnerability has been fixed by improving the URL validation and adding additional checks of the resource the URL points to before downloading it.
Recommended action: Upgrade to 5.2.1 or 4.10.10 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact This is a Remote Code Execution (RCE) vulnerability in Parse Server. This vulnerability affects Parse Server in the default configuration with MongoDB. The main weakness that leads to RCE is the Prototype Pollution vulnerable code in the file DatabaseController.js, so it is likely to affect Postgres and any other database backend as well. This vulnerability has been confirmed on Linux (Ubuntu) and Windows. Patches Upgrade to Parse Server =4.10.7. If you are using a prerelease version of Parse Server 5.0 (alpha, beta) we will publish a timely fix for these. However, as a general reminder we do not consider prerelease versions to be suitable for production deployment. Note that as part of the fix a new security feature scans for sensitive keywords in request data to prevent JavaScript prototype pollution. If such a keyword is found, the request is rejected with HTTP response code 400 and Parse Error 105 (INVALIDKEYNAME). By default these keywords are: {bsontype: "Code"},…
Recommended action: Upgrade to 4.10.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact For regular (non-LiveQuery) queries, the session token is removed from the response, but for LiveQuery payloads it is currently not. If a user has a LiveQuery subscription on the Parse.User class, all session tokens created during user sign-ups will be broadcast as part of the LiveQuery payload. Patches Remove session token from LiveQuery payload. Workaround Set user.acl(new Parse.ACL()) in a beforeSave trigger to make the user private already on sign-up.
Recommended action: Upgrade to 4.10.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact A security incident caused a number of incorrect version tags to be pushed to the Parse Server repository. These version tags linked to a personal fork of a contributor who had write access to the repository. The code to which these tags linked has not been reviewed or approved by Parse Platform. Even though no releases were published with these incorrect versions, it was possible to define a Parse Server dependency that pointed to these version tags, for example if you defined this dependency: ```js "parse-server": "git@github.com:parse-community/parse-server.git#4.9.3" ``` We have since deleted the incorrect version tags, but they may still show up in your personal fork on GitHub or locally. We do not know when these tags have been pushed to the Parse Server repository, but we first became aware of this issue on July 21, 2021. We are not aware of any malicious code or concerns related to privacy, security or legality (e.g. proprietary code). However, it has been reported…
Recommended action: Upgrade to 4.10.0 or 4.5.2 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Parse Server crashes when if a query request contains an invalid value for the explain option. This is due to a bug in the MongoDB Node.js driver which throws an exception that Parse Server cannot catch. Patches Upgrade to Parse Server 4.10.3
Recommended action: Upgrade to 4.10.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Developers that use the REST API to signup users and also allow users to login anonymously. When an anonymous user is first signed up using REST, the server creates session incorrectly, particularly the authProvider field in Session class under createdWith shows the user logged in creating a password. If a developer later depends on the createdWith field to provide a different level of access between a password user and anonymous user, the server incorrectly classified the session type as being created with a password. The server currently doesn't use createdWith to make decisions on how things work internally, so if a developer isn't using createdWith directly, there's nothing to worry about. The vulnerability only affects users who depend on createdWith by using it directly. Patches Upgrade to version 4.5.1. Workarounds Don't use the createdWith Session field to make decisions if you allow anonymous login. References n/a
Recommended action: Upgrade to 4.5.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Parse Server is an open source backend that can be deployed to any infrastructure that can run Node.js. In Parse Server before version 4.5.0, user passwords involved in LDAP authentication are stored in cleartext. This is fixed in version 4.5.0 by stripping password after authentication to prevent cleartext password storage.
Recommended action: Upgrade to 4.5.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Original Message: Hi, I create objects with one client with an ACL of all users with a specific column value. Thats working so far. Then I deleted the session object from one user to look if he can receive subscription objects and he can receive them. The client with the deleted session cant create new objects, which Parse restricts right. The LiveQueryServer doesnt detect deleted sessions after the websocket connection was established. There should be a mechanism that checks in an specific interval if the session exists. I dont know if its true with expired sessions. Any solutions? Parse version: 4.3.0 Parse js SDK version: 2.17 Solution: Hi guys. I've found and fixed the problem. It happens because there are two caches in place for the session token: - at Parse Server level, which, according with the docs, should be changed via cacheTTL option and defaults to 5 seconds; - at Parse Live Query level, which, according with the docs, should be changed via…
Recommended action: Upgrade to 4.4.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact An authenticated user using the viewer GraphQL query can bypass all read security on his User object and can also bypass all objects linked via relation or Pointer on his User object. Patches This vulnerability has been patched in Parse Server 4.3.0. Workarounds No References See commit 78239ac for details.
Recommended action: Upgrade to 4.3.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
1. you can fetch all the users' objects, by using regex in the NoSQL query. Using the NoSQL, you can use a regex on sessionToken ("SessionToken":{"$regex":"r:027f"}} and find valid accounts this way. Using this method, it's possible to retrieve accounts without interaction from the users. GET /parse/users/me HTTP/1.1 When trying it with an update query the same thing luckily doesn't seem to work: POST /parse/classes/User/PPNk59jPPZ 2. There is another similar vulnerability in verify email and the request password reset. If you sign up with someone else's email address, you can simply use regex in the token param to verify the account: http://localhost:1337/parse/apps/kickbox/verifyemail?token[$regex]=a&username=some@email.com The same thing can be done for reset password: http://localhost:1337/parse/apps/kickbox/requestpasswordreset?token[$regex]=a&username=some@email.com You may need to do it a few times with a different letter/number, but as long as the tokens contain the character…
Recommended action: Upgrade to 4.1.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Versions of parse-server prior to 3.6.0 could allow an account enumeration attack via account linking. ParseError.ACCOUNTALREADYLINKED(208) was thrown BEFORE the AuthController checks the password and throws a ParseError.SESSIONMISSING(206) for Insufficient auth. An attacker can guess ids and get information about linked accounts/email addresses. For more information If you have any questions or comments about this advisory, Open an issue in the parse-server Parse Community Vulnerability Disclosure Program
Recommended action: Upgrade to 3.6.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact If a POST request is made to /parse/classes/Audience (or other volatile class), any subsuquent POST requests result in an internal server error (500). Patches Afflicted installations will also have to remove the offending collection from their database. Yes, patched in 3.4.1 Workarounds Yes, user can apply: https://github.com/parse-community/parse-server/commit/8709daf698ea69b59268cb66f0f7cee75b52daa5 References Nothing other than this advisory at this time For more information If you have any questions or comments about this advisory: Open an issue in parse-server Email us at security@parseplatform.org
Recommended action: Upgrade to 3.4.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.