Skip to content

GHSA-jppw-r5j3-xf7x CVE-2026-71293

Statamic CMS exposes two-factor recovery codes through dynamic Antlers rendering

Medium Packagist
Severity
6.2 / 10
Medium · CVSS 3.1
Exploit chance (EPSS)
0.37%
Chance of exploitation in the next 30 days. Higher than 31.14% of scored vulnerabilities.
Known exploited
No
Not in CISA's catalog
Weakness
CWE-200 Exposure of Sensitive Information to an Unauthorized Actor
CWE-522 Insufficiently Protected Credentials
Fix
None yet
No fixed version published

Description

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.

Affected versions

Packagist

PackageVulnerableFixed in
statamic/cms
>= 6.0.0-alpha.1, <= 6.30.0
No fix yet

How to fix

No fixed version has been published yet. Until one is, remove or replace the package, or turn off or isolate the affected feature. This page updates when a fix ships.

Severity breakdown

CVSS 3.1 6.2

CVSS:3.1/AV:N/AC:L/PR:H/UI:R/S:C/C:H/I:N/A:N

Attack vector
Network
Attack complexity
Low
Privileges required
High
User interaction
Required
Scope
Changed
Confidentiality
High
Integrity
None
Availability
None

Weakness

CWE-200: Exposure of Sensitive Information to an Unauthorized Actor

The product exposes sensitive information to an actor that is not explicitly authorized to have access to that information.

How to prevent it
  • Architecture and Design: Compartmentalize the system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area. Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.

CWE-522: Insufficiently Protected Credentials

The product transmits or stores authentication credentials, but it uses an insecure method that is susceptible to unauthorized interception and/or retrieval.

How to prevent it
  • Architecture and Design: Use an appropriate security mechanism to protect the credentials.
  • Architecture and Design: Make appropriate use of cryptography to protect the credentials.
  • Implementation: Use industry standards to protect the credentials (e.g. LDAP, keystore, etc.).

References

Timeline

  1. Published
  2. Last updated by the source
  3. Latest EPSS score
AdvisorySeverityWhy it's related
GHSA-vx89-p3j7-8xqc
Statamic: Stored Cross-Site Scripting in Automagic Form Notification Email Template
Medium Also affects statamic/cms
GHSA-qhr7-v3xp-vw9m
Statamic: Missing file upload validation on frontend forms allows uploading disallowed file types
Medium Also affects statamic/cms
GHSA-qh8c-7588-qfrv
Statamic: Missing authorization on navigation endpoint allows disclosure of restricted entries
Medium Also affects statamic/cms
GHSA-j2vp-f2pv-5rj4
Statamic: Unsafe method invocation via Antlers template resolution allows data destruction
Medium Also affects statamic/cms
GHSA-93qh-5269-9wcf
Statamic: Account takeover via OAuth email matching without email-verification check
High Also affects statamic/cms
GHSA-225x-3jhx-wh4q
Statamic: Missing authorization on Control Panel endpoint allows disclosure of user existence
Medium Also affects statamic/cms
GHSA-7mqq-4v55-88gh
Statamic CMS's incorrect authorization lets view-only users submit Live Preview content reserved for editors
Low Also affects statamic/cms
GHSA-h77m-qrj7-jxcw
Statamic Vulnerable to CSV formula injection in form submission exports
Medium Also affects statamic/cms
Is this in your code?

MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.

Check your repos with MergeHarbor