Skip to content

Password confirmation stored in plain text via registration form in statamic/cms

Low severity GitHub Reviewed Published May 30, 2024 in statamic/cms • Updated Jun 2, 2024

Package

composer statamic/cms (Composer)

Affected versions

>= 5.3.0, < 5.6.2

Patched versions

5.6.2

Description

Users registering via the user:register_form tag will have their password confirmation stored in plain text in their user file.

Impact

This only affects sites matching all of the following conditions:

  • Running Statamic versions between 5.3.0 and 5.6.1. (This version range represents only one calendar week)
  • Using the user:register_form tag.
  • Using file-based user accounts. (Does not affect users stored in a database.)
  • Has users that have registered during that time period. (Existing users are not affected.)

The password is only visible to users that have access to read user yaml files, typically developers of the application itself.

Patches

The issue has been patched in 5.6.2, however any users registered during that time period and using the affected version range will still have the the password_confirmation value in their yaml files.

We recommend that affected users have their password reset. The following query can be entered into php artisan tinker and will output a list of affected emails:

Statamic\Facades\User::query()->whereNotNull('password_confirmation')->get()->map->email

The following can be entered into tinker and will clear both password_confirmation as well as their existing password. They will be required to reset their password before their next login attempt.

Statamic\Facades\User::query()
  ->whereNotNull('password_confirmation')->get()
  ->each(fn ($user) => $user->remove('password_confirmation')->passwordHash(null)->save());

References

If you are committing user files to a public git repo, you may consider clearing the sensitive data from the git history. You can use the following links for details.

References

@jasonvarga jasonvarga published to statamic/cms May 30, 2024
Published by the National Vulnerability Database May 30, 2024
Published to the GitHub Advisory Database Jun 2, 2024
Reviewed Jun 2, 2024
Last updated Jun 2, 2024

Severity

Low

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v3 base metrics

Attack vector
Local
Attack complexity
High
Privileges required
High
User interaction
Required
Scope
Unchanged
Confidentiality
Low
Integrity
None
Availability
None

CVSS v3 base metrics

Attack vector: More severe the more the remote (logically and physically) an attacker can be in order to exploit the vulnerability.
Attack complexity: More severe for the least complex attacks.
Privileges required: More severe if no privileges are required.
User interaction: More severe when no user interaction is required.
Scope: More severe when a scope change occurs, e.g. one vulnerable component impacts resources in components beyond its security scope.
Confidentiality: More severe when loss of data confidentiality is highest, measuring the level of data access available to an unauthorized user.
Integrity: More severe when loss of data integrity is the highest, measuring the consequence of data modification possible by an unauthorized user.
Availability: More severe when the loss of impacted component availability is highest.
CVSS:3.1/AV:L/AC:H/PR:H/UI:R/S:U/C:L/I:N/A:N

EPSS score

0.045%
(17th percentile)

Weaknesses

CVE ID

CVE-2024-36119

GHSA ID

GHSA-qvpj-w7xj-r6w9

Source code

Loading Checking history
See something to contribute? Suggest improvements for this vulnerability.