Parse Server is an open source http web server backend. In versions prior to 4.10.7 there 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. Users are advised to upgrade as soon as possible. The only known workaround is to manually patch your installation with code referenced at the source GHSA-p6h4-93qp-jhcm.

Impact

An attacker can use this prototype pollution sink to trigger a remote code execution through the MongoDB BSON parser.

Patches

Prevent prototype pollution in MongoDB database adapter.

Workarounds

Disable remote code execution through the MongoDB BSON parser.

Collaborators

Mikhail Shcherbakov (KTH), Cristian-Alexandru Staicu (CISPA) and Musard Balliu (KTH) working with Trend Micro Zero Day Initiative

References

- https://github.com/parse-community/parse-server/security/advisories/GHSA-prm5-8g2m-24gg

Impact

An unauthenticated attacker can cause Denial of Service by sending authentication requests with arbitrary, unconfigured provider names. The server executes a database query for each unconfigured provider before rejecting the request, and since no database index exists for unconfigured providers, each request triggers a full collection scan on the user database. This can be parallelized to saturate database resources.

Patches

The fix validates that an authentication provider is configured before executing any database query. Requests with unconfigured providers are now rejected immediately without querying the database.

Workarounds

There is no known workaround other than upgrading.

Parse Server is an open source backend that can be deployed to any infrastructure that can run Node.js. Parse Server uses the request header x-forwarded-for to determine the client IP address. If Parse Server doesn't run behind a proxy server, then a client can set this header and Parse Server will trust the value of the header. The incorrect client IP address will be used by various features in Parse Server. This allows to circumvent the security mechanism of the Parse Server option masterKeyIps by setting an allowed IP address as the x-forwarded-for header value. This issue has been patched in version 5.4.1. The mechanism to determine the client IP address has been rewritten. The correct IP address determination now requires to set the Parse Server option trustProxy.

Parse Server is an open source backend that can be deployed to any infrastructure that can run Node.js. Prior to versions 4.10.11 and 5.2.2, the certificate in the Parse Server 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. Versions 4.0.11 and 5.2.2 prevent this by introducing a new rootCertificateUrl property 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 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. There are no known workarounds for this issue.

Parse Server is an open source backend that can be deployed to any infrastructure that can run Node.js. 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 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, prior to versions 4.10.14 or 5.2.5, returns a response object. The patch available in versions 4.10.14 and 5.2.5 requires the maser key to use internal and protected fields as query constraints. As a workaround, implement a Parse Cloud Trigger beforeFind and manually remove the query constraints.

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

Parse Server is an open source backend that can be deployed to any infrastructure that can run Node.js. It is an npm package "parse-server". 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.

Impact

A Parse Pointer can be used to access internal Parse Server classes. It can also be used to circumvent the beforeFind query trigger which can be an additional vulnerability for deployments where the beforeFind trigger is used as a security layer to modify an incoming query.

Patches

The vulnerability was fixed by implementing a patch in the internal query pipeline to prevent a Parse Pointer to be used to access internal Parse Server classes or circumvent the beforeFind trigger.

Workarounds

There is no known workaround to prevent a Parse Pointer to be used to access internal Parse Server classes. A workaround if a beforeFind trigger is used as a security layer is to instead use the Parse Server provided security layers to manage access levels with Class-Level Permissions and Object-Level Access Control.

References

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-fcv6-fg5r-jm9q - Patched in Parse Server 6.x: https://github.com/parse-community/parse-server/releases/tag/6.2.2 - Patched in Parse Server 5.x (LTS): https://github.com/parse-community/parse-server/releases/tag/5.5.5

Impact

Parse Server crashes when a file download request is received with an invalid byte range.

Patches

Improved parsing of the range parameter to properly handle invalid range requests.

Workarounds

None

References

- GHSA-h423-w6qv-2wj3

Improper validation of the Apple certificate URL in the Apple Game Center authentication adapter allows attackers to bypass authentication, making the server vulnerable to DoS attacks. The vulnerability has been fixed by improving the URL validation and adding additional checks of the resource the URL points to before downloading it.

Parse Server is an open source backend that can be deployed to any infrastructure that can run Node.js. In affected versions 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 single instance without redundancy, the availability impact may be high. This issue has been addressed in versions 4.10.12 and 5.2.3. Users are advised to upgrade. There are no known workarounds for this issue.

Impact

Parse Server crashes when uploading a file without extension.

Patches

A permanent fix has been implemented to prevent the server from crashing.

Workarounds

There are no known workarounds.

References

- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-792q-q67h-w579 - Patched in Parse Server 6: https://github.com/parse-community/parse-server/releases/tag/6.3.1 - Patched in Parse Server 5 (LTS): https://github.com/parse-community/parse-server/releases/tag/5.5.6

Impact

Phishing attack vulnerability by uploading malicious files. A malicious user could upload a HTML file to Parse Server via its public API. That HTML file would then be accessible at the internet domain at which Parse Server is hosted. The URL of the the uploaded HTML could be shared for phishing attacks. The HTML page may seem legitimate because it is served under the internet domain where Parse Server is hosted, which may be the same as a company's official website domain.

An additional security issue arises when the Parse JavaScript SDK is used. The SDK stores sessions in the internet browser's local storage, which usually restricts data access depending on the internet domain. A malicious HTML file could contain a script that retrieves the user's session token from local storage and then share it with the attacker.

Patches

The fix adds a new Parse Server option fileUpload.fileExtensions to restrict file upload on Parse Server by file extension. It is recommended to restrict file upload for HTML file extensions, which this fix disables by default. If an app requires upload of files with HTML file extensions, the option can be set to ['.'] or another custom value to override the default.

References

- https://github.com/parse-community/parse-server/security/advisories/GHSA-9prm-jqwx-45x9 - https://github.com/parse-community/parse-server/pull/8538 (Parse Server 6) - https://github.com/parse-community/parse-server/pull/8537 (Parse Server 5)

Impact

An authenticated user can bypass the immutability guard on session fields (expiresAt, createdWith) by sending a null value in a PUT request to the session update endpoint. This allows nullifying the session expiry, making the session valid indefinitely and bypassing configured session length policies.

Patches

The truthiness-based guard checks were replaced with key-presence checks that reject any value for protected session fields, including null.

Workarounds

There is no known workaround. A beforeSave trigger on Session could be used to reject null values for expiresAt and createdWith.

Parse Server (npm package parse-server) broadcasts events to all clients without checking if the session token is valid. This allows clients with expired sessions to still receive subscription objects. It is not possible to create subscription objects with invalid session tokens. The issue is not patched.

Parse Server is an open source backend that can be deployed to any infrastructure that can run Node.js. In versions prior to 4.10.15, or 5.0.0 and above prior to 5.2.6, a user can write to the session object of another user if the session object ID is known. For example, an attacker 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 another user does not usually change the privileges of either of the two users, and a user cannot assign their own session to another user. This issue is patched in version 4.10.15 and above, and 5.2.6 and above. To mitigate this issue in unpatched versions add a beforeSave trigger to the Session class and prevent writing if the requesting user is different from the user in the session object.

Parse Server is an open source backend that can be deployed to any infrastructure that can run Node.js. In versions prior to 4.10.16, or from 5.0.0 to 5.2.6, validation of the authentication adapter app ID for Facebook and Spotify may be circumvented. Configurations which allow users to authenticate using the Parse Server authentication adapter where appIds is set as a string instead of an array of strings authenticate requests from an app with a different app ID than the one specified in the appIds configuration. For this vulnerability to be exploited, an attacker needs to be assigned an app ID by the authentication provider which is a sub-set of the server-side configured app ID. This issue is patched in versions 4.10.16 and 5.2.7. There are no known workarounds.

Impact

The default file upload extension blocklist can be bypassed by appending a trailing dot to a filename whose extension would otherwise be blocked (e.g. poc.svg.). The trailing dot causes the extension parser to extract an empty string, which short-circuits the blocklist check, and the attacker-controlled Content-Type is forwarded to the storage adapter unchanged. Storage adapters that persist and serve the provided Content-Type (such as S3 or GCS) then serve the file with an active type such as image/svg+xml, enabling stored XSS when a victim opens the file URL. The default GridFS adapter is not affected because it sets X-Content-Type-Options: nosniff on responses.

Patches

A filename ending in a dot is now treated as extensionless. When the parser produces an empty extension, the request handler falls back to validating the Content-Type subtype against the configured extension blocklist, matching the path that already catches truly extensionless uploads with a dangerous Content-Type. This is a follow-up to the previous fix GHSA-vr5f-2r24-w5hc.

Workarounds

Configure the storage adapter or CDN to derive Content-Type from the filename extension instead of using the stored Content-Type, or replace the default blocklist with an explicit allowlist of needed file extensions.