CVE-2026-25574
📋 TL;DR
This CVE describes an Insecure Direct Object Reference (IDOR) vulnerability in Payload CMS where authenticated users from one authentication collection can read and delete preferences belonging to users in different authentication collections when numeric IDs collide. This affects multi-auth collection environments using Postgres or SQLite with default serial/auto-increment IDs. The vulnerability allows unauthorized access to user preferences across different authentication contexts.
💻 Affected Systems
- Payload CMS
📦 What is this software?
Payload by Payloadcms
⚠️ Risk & Real-World Impact
Worst Case
Malicious authenticated users could systematically enumerate and delete preferences for all users across different auth collections, potentially disrupting user sessions, configurations, and application functionality.
Likely Case
Authenticated users accidentally or intentionally accessing preferences of users in other auth collections, leading to data leakage of user-specific settings and potential account disruption.
If Mitigated
With proper access controls and ID collision prevention, impact is limited to the intended scope of each user's own preferences within their auth collection.
🎯 Exploit Status
Exploitation requires authenticated access to at least one auth collection. Attackers need to identify ID collisions between users in different auth collections.
🛠️ Fix & Mitigation
✅ Official Fix
Patch Version: 3.74.0
Vendor Advisory: https://github.com/payloadcms/payload/security/advisories/GHSA-jq29-r496-r955
Restart Required: Yes
Instructions:
1. Backup your database and application. 2. Update Payload CMS to version 3.74.0 or later using your package manager. 3. Restart the Payload CMS service. 4. Verify the update was successful.
🔧 Temporary Workarounds
Implement custom ID generation
allReplace default serial/auto-increment IDs with UUIDs or other collision-resistant identifiers for preferences collection
Modify Payload CMS configuration to use custom ID generation for preferences collection
Enforce collection-specific access controls
allImplement middleware or hooks to validate that users can only access preferences within their own auth collection
Add access control logic to preferences endpoints to verify user's auth collection matches preference's collection
🧯 If You Can't Patch
- Implement strict access control middleware to validate user authorization before allowing preference operations
- Monitor and audit all preference read/delete operations for suspicious cross-collection access patterns
🔍 How to Verify
Check if Vulnerable:
Check if using Payload CMS version <3.74.0 with multi-auth collections and Postgres/SQLite using default IDsCheck Version:
npm list payload (for npm installations) or check package.json versionVerify Fix Applied:
Verify Payload CMS version is 3.74.0 or higher and test that users from one auth collection cannot access preferences from another auth collection📡 Detection & Monitoring
Log Indicators:
- Unusual preference access patterns across different auth collections
- Failed authorization attempts for preference operations
Network Indicators:
- HTTP requests to preferences endpoints with user IDs from different auth collections
SIEM Query:
source="payload-logs" AND (operation="read_preference" OR operation="delete_preference") AND user_auth_collection != preference_auth_collection