CVE-2026-25574: Payload CMS Auth Bypass Vulnerability

CVE-2026-25574 Overview

A cross-collection Insecure Direct Object Reference (IDOR) vulnerability has been discovered in Payload CMS, a free and open source headless content management system. Prior to version 3.74.0, the payload-preferences internal collection is vulnerable to unauthorized access across different authentication collections. 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.

Critical Impact

Authenticated attackers can access and delete user preferences belonging to other users in different authentication collections due to predictable ID collision, potentially leading to unauthorized data disclosure and data integrity issues.

Affected Products

• Payload CMS versions prior to 3.74.0
• Environments using Postgres database with default serial IDs
• Environments using SQLite database with auto-increment IDs

Discovery Timeline

• February 6, 2026 - CVE-2026-25574 published to NVD
• February 9, 2026 - Last updated in NVD database

Technical Details for CVE-2026-25574

Vulnerability Analysis

This vulnerability is classified under CWE-639 (Authorization Bypass Through User-Controlled Key), a common weakness where the application fails to properly verify that a user has the authorization to access or modify a specific resource. The flaw specifically affects Payload CMS deployments configured with multiple authentication collections.

The vulnerability arises in multi-tenant or multi-auth scenarios where Payload CMS manages separate user populations through distinct authentication collections. When these environments utilize Postgres or SQLite databases with their default sequential ID generation mechanisms, a dangerous condition emerges: users from different auth collections can have matching numeric identifiers.

The payload-preferences internal collection, which stores user-specific settings and configurations, does not adequately scope authorization checks to the originating authentication collection. This means that when User A from Auth Collection X has the same numeric ID as User B from Auth Collection Y, User A can potentially read or delete User B's preferences.

Root Cause

The root cause stems from insufficient authorization validation in the payload-preferences collection access control logic. The system relies solely on numeric user IDs without verifying the authentication collection context from which the request originates. This creates an authorization bypass when ID values collide across different authentication namespaces.

The default auto-increment ID strategy in both Postgres and SQLite guarantees that IDs will eventually collide across collections starting at ID 1, making this vulnerability reliably exploitable in affected configurations.

Attack Vector

An authenticated attacker can exploit this vulnerability through the following attack methodology:

1. Reconnaissance: The attacker identifies that the target Payload CMS instance uses multiple authentication collections with default serial/auto-increment IDs
2. ID Enumeration: The attacker determines or guesses numeric user IDs from other authentication collections
3. Cross-Collection Access: By manipulating requests to the payload-preferences endpoints, the attacker can read preferences belonging to users in other auth collections whose IDs match known or guessed values
4. Data Exfiltration/Manipulation: The attacker can view sensitive preference data or delete preferences, potentially disrupting other users' configured settings

The attack requires only low-privilege authenticated access to the system, making it particularly concerning in environments where user registration is open or minimally restricted.

Detection Methods for CVE-2026-25574

Indicators of Compromise

• Unusual access patterns to the payload-preferences collection from users accessing preferences not belonging to their authentication collection
• API requests targeting preference endpoints with user IDs that don't correspond to the authenticated user's collection
• Unexpected preference deletions or modifications reported by users
• Audit logs showing cross-collection preference access attempts

Detection Strategies

• Implement logging on all payload-preferences API endpoints to capture the requesting user's authentication collection alongside the target preference ID
• Monitor for anomalous patterns where users query or modify preferences with IDs outside their expected range
• Deploy application-layer monitoring to detect IDOR-style sequential ID probing behavior
• Review existing access logs for historical evidence of cross-collection preference access

Monitoring Recommendations

• Enable detailed audit logging for all preference collection operations including read, update, and delete actions
• Configure alerts for preference access requests where the target user ID doesn't match the authenticated session
• Implement rate limiting on preference endpoints to slow down potential enumeration attacks
• Establish baseline metrics for preference API usage to detect anomalous access patterns

How to Mitigate CVE-2026-25574

Immediate Actions Required

• Upgrade Payload CMS to version 3.74.0 or later immediately
• Audit existing preference data for signs of unauthorized access or deletion
• Review authentication collection configurations and assess exposure risk
• Consider implementing UUIDs instead of sequential IDs for new deployments pending upgrade

Patch Information

Payload CMS has addressed this vulnerability in version 3.74.0. The security patch implements proper authorization checks that scope preference access to the originating authentication collection, preventing cross-collection access even when numeric IDs collide.

For detailed technical information about this security fix, refer to the GitHub Security Advisory GHSA-jq29-r496-r955.

Workarounds

• If immediate upgrade is not possible, consider implementing custom access control hooks on the payload-preferences collection to validate authentication collection context
• Migrate to UUID-based identification for user records to eliminate ID collision scenarios
• Restrict multi-auth collection deployments to use separate database instances where feasible
• Implement additional application-layer authorization middleware to validate cross-collection access attempts