GHSA-234Q-VVW3-MRFQ
Vulnerability from github – Published: 2026-03-04 20:52 – Updated: 2026-03-04 20:52The actionSendActivationEmail() endpoint is accessible to unauthenticated users and does not require a permission check for pending users. An attacker with no prior access can 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 access to the system.
The vulnerability is not that anonymous access exists - there’s a legitimate use case for it. The vulnerability is that the endpoint accepts arbitrary userId parameters without verifying ownership.
Craft CMS allows public user registration. When a user registers but doesn’t receive their activation email (spam filter, typo correction, etc.), they need a way to request a resend. This is why send-activation-email is in the allowAnonymous array - it’s intentional self-service functionality.
The Security Gap
The endpoint accepts userId as the identifier:
$userId = $this->request->getRequiredBodyParam('userId');
This allows any visitor to trigger activation emails for any pending user, not just their own registration.
Background
When administrators create new user accounts in Craft CMS, users are created in a “pending” state until they activate their account via an emailed link. The actionSendActivationEmail() function sends (or resends) this activation email.
Expected Behavior: Anonymous users should only be able to resend activation emails for their own registration.
Actual Behavior:
1. The endpoint is listed in allowAnonymous - no login required (intentional for self-service)
2. For pending users, there is NO ownership verification
3. Any unauthenticated visitor can trigger activation emails for ANY pending user by ID
Attack Scenarios
Scenario 1: Targeted Account Takeover
Prerequisites: Attacker controls target user’s email (compromised email, shared mailbox, typosquatting, etc.)
1. Admin creates a user account for victim@company.com
2. User account is in PENDING state (hasn’t activated yet)
3. Attacker has compromised victim@company.com (or it’s a typo of attacker’s domain)
4. Attacker discovers user ID (brute-force, GraphQL enumeration, or insider knowledge)
5. Attacker (unauthenticated) triggers: POST /actions/users/send-activation-email
6. Activation email sent to victim@company.com (attacker-controlled)
7. Attacker clicks activation link, sets password
8. Attacker gains access as that user with pre-assigned permissions
Scenario 2: User ID Brute-Force Enumeration
1. Attacker iterates through user IDs (1, 2, 3, ...)
2. For each ID, the attacker calls send-activation-email
3. Response reveals user state:
- "Activation email sent." = Pending user exists
- "User not found" = No user with this ID
- "Activation emails can only be sent to inactive or pending users" = Active user exists
4. Attacker builds a map of all user IDs and their states
5. For any pending user whose email an attacker controls → account takeover
Scenario 3: GraphQL + Targeted Attack
Prerequisites: GraphQL public schema allows user queries
1. Attacker queries GraphQL: { users { id email status } }
2. Filters for pending users
3. Cross-references with emails attacker controls
4. Triggers activation for the target user
5. Account takeover
Scenario 4: Email Spam / Harassment
1. Attacker brute-forces all pending user IDs
2. Repeatedly triggers activation emails
3. Victims receive unwanted emails from the Craft site
4. Potential for:
- Reputation damage to the site
- Email deliverability issues (spam reports)
- User confusion/phishing vector
References
https://github.com/craftcms/cms/commit/c3d02d4a7246f516933f42106c0a67ce062f68d8
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "craftcms/cms"
},
"ranges": [
{
"events": [
{
"introduced": "5.0.0-RC1"
},
{
"fixed": "5.9.0-beta.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "craftcms/cms"
},
"ranges": [
{
"events": [
{
"introduced": "4.0.0-RC1"
},
{
"fixed": "4.17.0-beta.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-29069"
],
"database_specific": {
"cwe_ids": [
"CWE-287",
"CWE-639"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-04T20:52:31Z",
"nvd_published_at": "2026-03-04T17:16:22Z",
"severity": "HIGH"
},
"details": "The `actionSendActivationEmail()` endpoint is accessible to unauthenticated users and does not require a permission check for pending users. An attacker with no prior access can trigger activation emails for any pending user account by knowing or guessing the user ID. If the attacker controls the target user\u2019s email address, they can activate the account and gain access to the system.\n\nThe vulnerability is not that anonymous access exists - there\u2019s a legitimate use case for it. The vulnerability is that the endpoint accepts arbitrary `userId` parameters without verifying ownership.\n\nCraft CMS allows public user registration. When a user registers but doesn\u2019t receive their activation email (spam filter, typo correction, etc.), they need a way to request a resend. This is why `send-activation-email` is in the `allowAnonymous` array - it\u2019s intentional self-service functionality.\n\n### The Security Gap\n\nThe endpoint accepts `userId` as the identifier:\n```php\n$userId = $this-\u003erequest-\u003egetRequiredBodyParam(\u0027userId\u0027);\n```\n\nThis allows any visitor to trigger activation emails for any pending user, not just their own registration.\n\n---\n\n## Background\n\nWhen administrators create new user accounts in Craft CMS, users are created in a \u201cpending\u201d state until they activate their account via an emailed link. The `actionSendActivationEmail()` function sends (or resends) this activation email.\n\n**Expected Behavior:** Anonymous users should only be able to resend activation emails for their own registration.\n\n**Actual Behavior:**\n1. The endpoint is listed in `allowAnonymous` - no login required (intentional for self-service)\n2. For pending users, there is NO ownership verification\n3. Any unauthenticated visitor can trigger activation emails for ANY pending user by ID\n\n---\n\n## Attack Scenarios\n\n### Scenario 1: Targeted Account Takeover\n\n**Prerequisites:** Attacker controls target user\u2019s email (compromised email, shared mailbox, typosquatting, etc.)\n\n```\n1. Admin creates a user account for victim@company.com\n2. User account is in PENDING state (hasn\u2019t activated yet)\n3. Attacker has compromised victim@company.com (or it\u2019s a typo of attacker\u2019s domain)\n4. Attacker discovers user ID (brute-force, GraphQL enumeration, or insider knowledge)\n5. Attacker (unauthenticated) triggers: POST /actions/users/send-activation-email\n6. Activation email sent to victim@company.com (attacker-controlled)\n7. Attacker clicks activation link, sets password\n8. Attacker gains access as that user with pre-assigned permissions\n```\n\n### Scenario 2: User ID Brute-Force Enumeration\n\n```\n1. Attacker iterates through user IDs (1, 2, 3, ...)\n2. For each ID, the attacker calls send-activation-email\n3. Response reveals user state:\n - \"Activation email sent.\" = Pending user exists\n - \"User not found\" = No user with this ID\n - \"Activation emails can only be sent to inactive or pending users\" = Active user exists\n4. Attacker builds a map of all user IDs and their states\n5. For any pending user whose email an attacker controls \u2192 account takeover\n```\n\n### Scenario 3: GraphQL + Targeted Attack\n\n**Prerequisites:** GraphQL public schema allows user queries\n\n```\n1. Attacker queries GraphQL: { users { id email status } }\n2. Filters for pending users\n3. Cross-references with emails attacker controls\n4. Triggers activation for the target user\n5. Account takeover\n```\n\n### Scenario 4: Email Spam / Harassment\n\n```\n1. Attacker brute-forces all pending user IDs\n2. Repeatedly triggers activation emails\n3. Victims receive unwanted emails from the Craft site\n4. Potential for:\n - Reputation damage to the site\n - Email deliverability issues (spam reports)\n - User confusion/phishing vector\n```\n\n---\n\n## References\n\nhttps://github.com/craftcms/cms/commit/c3d02d4a7246f516933f42106c0a67ce062f68d8",
"id": "GHSA-234q-vvw3-mrfq",
"modified": "2026-03-04T20:52:32Z",
"published": "2026-03-04T20:52:31Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/craftcms/cms/security/advisories/GHSA-234q-vvw3-mrfq"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-29069"
},
{
"type": "WEB",
"url": "https://github.com/craftcms/cms/commit/c3d02d4a7246f516933f42106c0a67ce062f68d8"
},
{
"type": "PACKAGE",
"url": "https://github.com/craftcms/cms"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:H/VA:N/SC:N/SI:N/SA:N/E:P",
"type": "CVSS_V4"
}
],
"summary": "Craft CMS has unauthenticated activation email trigger with potential user enumeration"
}
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.