Package Instance

Payload has Authenticated SSRF via Upload Functionality
### Impact

An authenticated Server-Side Request Forgery (SSRF) vulnerability existed in the upload functionality.

Authenticated users with `create` or `update` access to an upload-enabled collection could cause the server to make outbound HTTP requests to arbitrary URLs.

Consumers are affected if ALL of these are true:

- Payload version **< v3.79.1**
- At least one collection with `upload` enabled
- An authenticated user has `create` or `update` access to that collection

### Patches

This vulnerability has been patched in **v3.79.1**. Users should upgrade to **v3.79.1** or later.

### Workarounds

Until consumers can upgrade:

- Restrict `create` and `update` access to upload-enabled collections to trusted roles only.
- Limit outbound network access from your Payload server where possible.

Payload's SQLite adapter Session Fixation vulnerability
A Session Fixation vulnerability existed in Payload's SQLite adapter due to identifier reuse during account creation. A malicious attacker could create a new account, save its JSON Web Token (JWT), and then delete the account, which did not invalidate the JWT. As a result, the next newly created user would receive the same identifier, allowing the attacker to reuse the JWT to authenticate and perform actions as that user.

This issue has been fixed in version 3.44.0 of Payload.

Unrestricted Upload of File with Dangerous Type
An arbitrary file upload vulnerability in the file upload module of PayloadCMS v0.15.0 allows attackers to execute arbitrary code via a crafted SVG file.

payload-preferences has Cross-Collection IDOR in Access Control (Multi-Auth Environments)
A cross-collection Insecure Direct Object Reference (IDOR) vulnerability exists in the `payload-preferences` internal collection. In multi-auth collection environments using Postgres or SQLite with default serial/auto-increment IDs, authenticated users from one auth collection can read and delete preferences belonging to users in different auth collections when their numeric IDs collide.

**Users are affected if ALL of these are true:**

- Multiple auth collections configured (e.g., `admins` + `customers`)
- Postgres or SQLite database adapter with serial/auto-increment IDs
- Users in different auth collections with the same numeric ID

**Not affected:**

- `@payloadcms/db-mongodb` adapter
- Single auth collection environments
- Postgres/SQLite with `idType: 'uuid'`

Payload: Server-Side Request Forgery (SSRF) in External File URL Uploads
A Server-Side Request Forgery (SSRF) vulnerability exists in Payload's external file upload functionality. When processing external URLs for file uploads, insufficient validation of HTTP redirects could allow an authenticated attacker to access internal network resources.

**Users are affected if ALL of these are true**:

- Payload version < v3.75.0
- At least one collection with `upload` enabled
- A user has `create` access to that upload-enabled collection

An authenticated user with upload collection write permissions could potentially access internal services. Response content from internal services could be retrieved through the application.

Payload has a CSRF Protection Bypass in Authentication Flow
### Impact

A Cross-Site Request Forgery (CSRF) vulnerability existed in the authentication flow. Under certain conditions, the configured CSRF protection could be bypassed, allowing cross-site requests to be made.

Consumers are affected if ALL of these are true:

- Payload version **< v3.79.1**
- `serverURL` is configured

### Patches

This vulnerability has been patched in **v3.79.1**. Additional validation has been added to the authentication flow.

Consumers should upgrade to **v3.79.1** or later.

### Workarounds

There is no complete workaround without upgrading. 

If consumers cannot upgrade immediately, setting `cookies.sameSite` to `'Strict'` will prevent the session cookie from being sent cross-site. However, this will also require users to re-authenticate when navigating to the application from external links (e.g. email, other sites).

Exposure of Sensitive Information to an Unauthorized Actor
Payload is a free and open source headless content management system. In versions prior to 1.7.0, if a user has access to documents that contain hidden fields or fields they do not have access to, the user could reverse-engineer those values via brute force. Version 1.7.0 contains a patch. As a workaround, write a `beforeOperation` hook to remove `where` queries that attempt to access hidden field data.

Payload does not invalidate JWTs after log out
Payload uses JSON Web Tokens (JWT) for authentication. After log out JWT is not invalidated, which allows an attacker who has stolen or intercepted token to freely reuse it until expiration date (which is by default set to 2 hours, but can be changed).

This issue has been fixed in version 3.44.0 of Payload.

Payload has an SQL Injection via Query Handling
### Impact

Certain request inputs were not properly validated. An attacker could craft requests that influence SQL query execution, potentially exposing or modifying data in collections.

### Patches

This issue has been fixed in **v3.79.1** and later. Query input validation has been hardened.

Upgrade to **v3.79.1 or later**.

### Workarounds

Until developers can upgrade:

- Limit access to endpoints that accept dynamic query inputs to trusted users only.  
- Validate or sanitize input from untrusted clients before sending it to query endpoints.

Payload: Pre-Authentication Account Takeover via Parameter Injection in Password Recovery
### Impact

A vulnerability in the password recovery flow could allow an unauthenticated attacker to perform actions on behalf of a user who initiates a password reset.

Users are affected if:

- They are using Payload version **< v3.79.1** with any auth-enabled collection using the built-in `forgot-password` functionality.

### Patches

Input validation and URL construction in the password recovery flow have been hardened.

Users should upgrade to **v3.79.1** or later.

### Workarounds

There are no complete workarounds. Upgrading to **v3.79.1** is recommended.