Mtrezza

An information disclosure issue exists where create or update responses mark fields as deleted based on stored values that the caller is not authorized to read. This allows attackers who possess write access but lack read access to an object to inspect these markers and infer the existence of protected fields.

An issue exists where user email address formats are validated using a regular expression that lacks a length limit and exhibits quadratic runtime growth relative to the input length. An unauthenticated attacker with knowledge of the application ID can submit a sign-up request, or an authenticated user can update their email, using a specially crafted long email address. This action blocks the Node.js event loop, resulting in a denial of service for all clients.

An issue exists where the server returns field values in object create responses to users who do not have read access to the created object via class-level permissions or the object's Access Control List (ACL). A user with create permissions can exploit this to obtain values established by schema defaults, the class default ACL, or Cloud Code triggers.

Prototype pollution occurs when building objects for Cloud Code triggers and LiveQuery. This happens when a dot notation key with an intermediate segment that resolves through an inherited member writes to a process-wide built-in. An attacker with write access to an object in a class associated with a trigger or LiveQuery can corrupt a built-in function. This corruption causes unrelated requests to fail and results in a denial of service for all clients and hosted applications until the process is restarted.

When used with MongoDB, the software skips field type validation for null-valued dot notation keys. This allows sub-documents to be written beneath fields defined as Pointer, Number, String, Date, or Boolean. Clients with write access, including unauthenticated users when public writes are enabled, can corrupt field values, render objects unreadable through internal date fields, or disrupt atomic operations on number fields.

A serialization error occurs during an object update when a dot notation key targets a pointer field's object identifier on a class that utilizes an `afterSave()` trigger. This flaw allows attackers, including unauthenticated clients in scenarios where objects are writable without a session, to trigger a crash of the Node process.

An authorization bypass exists in the session upgrade endpoint. The system creates a new session for any valid session token without enforcing the ` Session` class create class-level permission. An attacker possessing a user's session token can send a revocable token to the '/upgradeToRevocableSession' endpoint to obtain additional sessions with fresh expiration dates. These sessions remain active even after the original session has been logged out.

Stored field values are returned in object update responses without verifying read access. This allows clients with class-level permissions or object Access Control Lists (ACLs) that permit updates but restrict reading to view object data. This can be exploited to read results from atomic operations such as `Increment`, `Add`, `AddUnique`, and `Remove`, as well as values set by Cloud Code triggers. Under certain conditions, using dot notation keys may allow the retrieval of the entire stored parent field.

Prototype pollution occurs because user-controlled keys are expanded into objects without own-property checks. Clients with class write access can send dot notation field keys or ACL entry names that match built-in object members to corrupt built-in functions. This can lead to a denial of service where all requests fail until the server is restarted.

An authorization flaw exists where ` Installation` updates addressed by object ID are applied to the installation specified in the `X-Parse-Installation-Id` header. If the `protectedFieldsTriggerExempt` setting is enabled, an attacker who knows the object ID of another installation can force a `beforeSave()` trigger to process the protected fields of that installation during a write operation elsewhere.

An information disclosure issue exists where clients can receive protected field values written by `beforeSave` triggers using dot notation keys. This occurs when `protectedFieldsSaveResponseExempt` is set to false, allowing clients with create or update permissions to read values written by a trigger beneath a protected field within the same request.

An issue exists where the server returns the stored value of a field that was reverted by a `beforeSave` trigger during object update responses. This occurs even if the client lacks read access to the object or the specific field. An authenticated client can exploit this by updating an object where the `beforeSave` trigger reverts a field using `revert()` or a constant: true validator. This allows the client to read protected values, such as the raw MFA `authData` of their own account when `protectedFieldsTriggerExempt` is enabled.

An issue exists where the software mishandles dot notation keys containing null or undefined values during the construction of the saved object. This causes a write operation to be stored in the database while simultaneously returning an error, which subsequently bypasses afterSave triggers and LiveQuery events. A client with write access can leverage this behavior to evade audit logging, notifications, and updates to derived data.

Insufficient validation of the owning object reference in `$relatedTo` relation queries allows a user to bypass the owning-object Access Control List (ACL) check by providing a query operator instead of an object ID. This enables a client with read access to at least one object of the owning class to discover which readable objects are linked to owning objects they are not authorized to read.

An authentication bypass exists because the `validateSetUp()`, `validateLogin()`, and `validateUpdate()` methods of custom adapters subclassing `AuthAdapter` are not executed. Instead, an inherited default is used that accepts any `authData`. This allows attackers to provide arbitrary `authData` to sign up, link identities, log in as existing users, or bypass custom additional authentication factors.

An information disclosure issue exists in LiveQuery. The subscription hash fails to include constraints adjacent to a `$or` operator, such as the ` Session` owner filter and `beforeSubscribe` constraints, causing distinct subscriptions to be grouped together. Consequently, authenticated clients using `$or` queries can receive events belonging to other users, which may include session tokens that can be used for impersonation.

Parse Server fails to reject reserved internal field names during client object writes, which allows clients to store or clear internal fields. This can be exploited to write a reserved field that causes MongoDB object reads to fail, disrupting queries for all users on that class. Additionally, attackers can clear their own password history and account lockout state to bypass password policies and lockout mechanisms.

On MongoDB deployments, a missing authorization issue allows clients without the master key to delete the stored schema of any class. Unauthenticated attackers can send REST API delete requests targeting the internal ` SCHEMA` collection to remove field definitions, class-level permissions, and protected fields, which exposes data to unauthorized reads and modifications.

When issuing an SMS multi-factor authentication (MFA) verification code, the system saves the entire login request using master privileges. This allows a user enrolled in SMS MFA to include additional fields in the request to modify restricted fields on their own account, including the email-verification flag or values protected by `beforeSave()`.

Insufficient enforcement of class-level permissions for the ` Session` class occurs during session creation. An authenticated user or an entity possessing a valid session token can bypass `create` and `addField` permissions by sending POST requests to the '/sessions' or '/classes/ Session' endpoints. This allows the creation of additional sessions for the user and the addition of fields to the ` Session` class. These unauthorized sessions remain active even after the original session is logged out.