CVE-2026-71293 in Statamic
Summary
by MITRE • 08/05/2026
Statamic CMS's user-augmentation resolver, AugmentedUser::get() in src/Auth/AugmentedUser.php, contains an explicit case for the `two_factor_recovery_codes` handle that returns the user's raw two-factor recovery codes with no access restriction: `if ($handle === 'two_factor_recovery_codes') { return new Value($this->data->get('two_factor_recovery_codes'), ...); }`. Unlike sensitive fields such as password/password_hash, which are excluded from AugmentedUser entirely, two_factor_recovery_codes is neither excluded from augmentation nor present in Statamic's Antlers variable guard lists (guardedVariablePatterns/guardedContentVariablePatterns in src/Providers/ViewServiceProvider.php, and the runtime GlobalRuntimeState guard paths), which by default only guard config.app.key. On any Antlers template field where raw/dynamic template rendering is enabled for a given field (an admin/developer-configured, blueprint-level field option), a template such as `{{ current_user.two_factor_recovery_codes }}{{ value }}|{{ /current_user.two_factor_recovery_codes }}` renders the viewing user's own 2FA recovery codes directly into the HTML response, allowing an attacker who can view or capture that response (e.g. via a shared/observable page, or a crafted link causing a victim to render it) to obtain the codes and bypass 2FA. Exploitation requires that dynamic Antlers rendering already be enabled on a field the target user's data flows through, which is a blueprint-configuration privilege rather than a standard content-editing permission.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 08/05/2026
The vulnerability described represents a critical access control flaw in Statamic CMS's user augmentation system where sensitive two-factor authentication recovery codes are exposed through the Antlers templating engine without proper authorization checks. This issue stems from the explicit handling of the 'two_factor_recovery_codes' handle within the AugmentedUser::get() method, which directly returns raw user data without implementing any access restrictions or validation mechanisms. The flaw exists because this specific field is treated differently from other sensitive user attributes such as passwords and password hashes, which are entirely excluded from the augmentation process to prevent unauthorized access. Unlike these protected fields, recovery codes are explicitly included in the augmentation pipeline but remain unprotected by any security controls within the system's default configuration.
The technical implementation of this vulnerability allows attackers to extract sensitive two-factor authentication recovery codes through direct template rendering when dynamic Antlers template processing is enabled on specific blueprint fields. The exploitation requires that administrators have configured dynamic rendering for a particular field, which represents an additional attack vector since this setting typically requires administrative privileges or developer-level access to modify. However, once this configuration is in place and the attacker can influence template rendering through accessible pages, they can craft malicious Antlers syntax such as `{{ current_user.two_factor_recovery_codes }}{{ value }}|{{ /current_user.two_factor_recovery_codes }}` to directly inject recovery code values into HTML responses. This creates a scenario where an attacker who can observe or capture the rendered page content can extract multiple recovery codes and subsequently bypass two-factor authentication mechanisms entirely.
The operational impact of this vulnerability extends beyond simple information disclosure, as it fundamentally undermines the security guarantees provided by two-factor authentication systems. When attackers obtain access to recovery codes, they can completely circumvent the layered security protections that two-factor authentication is designed to provide, essentially allowing them to impersonate legitimate users without requiring knowledge of their primary credentials or additional authentication factors. This vulnerability aligns with CWE-284 (Improper Access Control) and represents a specific instance where insufficient authorization controls allow sensitive data exposure through templating systems. The flaw also relates to ATT&CK technique T1566 (Phishing) and T1078 (Valid Accounts) as attackers can use recovered codes to maintain persistent access to user accounts. The lack of inclusion in Statamic's default guarded variable patterns, which only protect config.app.key by default, demonstrates a failure in the security-by-design principles that should apply to all sensitive user data within web applications.
Mitigation strategies for this vulnerability require immediate implementation of both runtime and configuration-based protections. Organizations should ensure that two-factor recovery codes are excluded from all augmentation processes regardless of field configuration settings, effectively removing them from the data flow that could potentially expose them through templating engines. The system should implement a comprehensive variable guarding mechanism that automatically protects sensitive fields such as recovery codes, password hashes, and other authentication-related data from appearing in any template contexts where dynamic rendering might occur. Additionally, administrators must review all blueprint configurations to ensure that dynamic template rendering is not enabled on fields containing sensitive user information unless absolutely necessary and properly secured through additional access controls. The fix should include updates to Statamic's default security configuration to automatically exclude recovery codes from the augmentation pipeline and prevent their exposure in any Antlers template contexts, thereby addressing both the immediate vulnerability and preventing similar issues from occurring with other sensitive data fields that may not yet be protected by the system's default safeguards.