CVE-2026-29069: Craft CMS Auth Bypass Vulnerability

CVE-2026-29069 Overview

CVE-2026-29069 is an Authorization Bypass vulnerability in Craft CMS, a popular content management system. The vulnerability exists in the actionSendActivationEmail() endpoint, which is accessible to unauthenticated users and lacks proper permission checks for pending user accounts. This flaw allows an attacker with no prior access to trigger activation emails for any pending user account by knowing or guessing the user ID. If the attacker controls the target user's email address, they can activate the account and gain unauthorized access to the system.

Critical Impact

Unauthenticated attackers can trigger activation emails for pending accounts and potentially gain system access if they control the target email address.

Affected Products

• Craft CMS versions prior to 5.9.0-beta.2
• Craft CMS versions prior to 4.17.0-beta.2
• Craft CMS version 4.0.0 through 4.17.0-beta1
• Craft CMS version 5.0.0 through 5.9.0-beta1

Discovery Timeline

• 2026-03-04 - CVE-2026-29069 published to NVD
• 2026-03-05 - Last updated in NVD database

Technical Details for CVE-2026-29069

Vulnerability Analysis

This vulnerability is classified under CWE-639 (Authorization Bypass Through User-Controlled Key), which occurs when an application uses user-supplied input to determine which resource or function to access without proper authorization checks. In the case of Craft CMS, the actionSendActivationEmail() endpoint fails to verify whether the requesting user has the appropriate permissions to trigger activation emails for pending accounts.

The vulnerability is network-accessible, requiring no authentication or user interaction to exploit. An attacker can enumerate or guess user IDs and trigger activation emails for those pending accounts. The primary security impact is unauthorized information disclosure and potential account takeover when the attacker controls the email address associated with the pending account.

Root Cause

The root cause of this vulnerability lies in the missing authorization check within the actionSendActivationEmail() endpoint. The endpoint was designed to send activation emails for user accounts but failed to implement proper access control to verify that:

1. The requester is authenticated
2. The requester has permission to trigger activation emails
3. The target account belongs to or is managed by the requester

This oversight allows any unauthenticated remote user to invoke this functionality by simply providing a valid or guessed user ID.

Attack Vector

The attack vector for CVE-2026-29069 is network-based, making it remotely exploitable. An attacker can exploit this vulnerability by sending crafted HTTP requests to the vulnerable endpoint. The attack requires no authentication and can be performed without user interaction.

The exploitation scenario involves:

1. The attacker identifies or enumerates pending user accounts by their user IDs
2. The attacker sends requests to the actionSendActivationEmail() endpoint for each target user ID
3. If the attacker controls the email address of a pending user account, they receive the activation email
4. The attacker uses the activation link to complete account setup and gain system access

For detailed technical information about the exploitation mechanism, refer to the GitHub Security Advisory.

Detection Methods for CVE-2026-29069

Indicators of Compromise

• Unusual volume of requests to activation email endpoints from unauthenticated sources
• Multiple activation email trigger attempts for different user IDs from the same source IP
• Successful account activations for users where the registration source differs from the activation source
• Log entries showing activation email requests without corresponding authenticated sessions

Detection Strategies

• Monitor web application logs for requests to the actionSendActivationEmail() endpoint from unauthenticated sessions
• Implement rate limiting detection for activation email requests to identify enumeration attempts
• Set up alerts for activation email requests originating from suspicious IP addresses or geographic locations
• Review Craft CMS access logs for patterns indicating user ID enumeration

Monitoring Recommendations

• Enable detailed logging for all authentication and account management endpoints in Craft CMS
• Implement network-level monitoring for abnormal traffic patterns to the CMS installation
• Configure SIEM rules to correlate activation email requests with subsequent successful account activations
• Monitor email server logs for unusual volumes of activation emails being sent

How to Mitigate CVE-2026-29069

Immediate Actions Required

• Upgrade Craft CMS to version 5.9.0-beta.2 or later for version 5.x installations
• Upgrade Craft CMS to version 4.17.0-beta.2 or later for version 4.x installations
• Review pending user accounts and remove any suspicious or unrecognized entries
• Audit recent account activations for any unauthorized access
• Implement web application firewall rules to restrict access to the activation endpoint

Patch Information

Craft CMS has released security patches to address this vulnerability. The fix is available in versions 5.9.0-beta.2 and 4.17.0-beta.2. The patch commit can be reviewed at the GitHub Commit Detail.

Organizations should prioritize upgrading to the patched versions. The fix implements proper authorization checks to ensure only authenticated users with appropriate permissions can trigger activation emails.

Workarounds

• Implement WAF rules to block unauthenticated requests to the actionSendActivationEmail() endpoint
• Restrict access to the Craft CMS admin panel to trusted IP addresses using network-level controls
• Disable user registration functionality if not actively required until the patch can be applied
• Monitor and manually approve all pending user accounts before allowing activation

# Example: Nginx configuration to restrict access to activation endpoints
location ~* /actions/users/send-activation-email {
    # Allow only authenticated admin requests or block entirely
    deny all;
    # Or restrict to trusted networks
    # allow 10.0.0.0/8;
    # deny all;
}