☠️
EXFILTRATING
DATA...
01010111 10110010 00101001 11000110 01101100 10011011 00010001 11100101 01000010 10101111
[ <-- BACK_TO_SEARCH ]
Statamic logo [ WEBSITE ] [ VENDOR STATS ]
CVSS: 1.8 🐛 CWE-312
👁️
Common Weakness Enumeration - Identifies the specific category of software weakness or flaw.

CVE-2024-36119

CVE-2024-36119 Supply Chain Attack in Statamic
📅 PUBLISHED: 2024-05-30 20:57 UTC 🔄 UPDATED: 2026-09-23 20:37 UTC
[ OFFICIAL PATCH DEPLOYED ↓ ] FIX: LIKELY — 2 independent sources confirm fix
[ DEFENSE PATCH ↓ ]
💣 PoC: None
👁️
Proof of Concept - Indicates if functional exploit code is publicly available, drastically increasing the risk of immediate attacks.
🎯 EPSS: 0.14%
👁️
0.14% probability
3.4× above the median CVE
Tier: ELEVATED
30-day exploitation window · FIRST.org · updated daily
Country: United States License: Commercial
Patch available — upgrade to latest release
CVSS SEVERITY SCALE
9.0–10.0 CRITICAL
7.0–8.9 HIGH
4.0–6.9 MEDIUM
0.1–3.9 LOW
0.0 NONE
1.8
THREAT LEVEL
■ tracking this CVE ✓ independent patch confirmation ⧗ same-origin mirror (GHSA) ⚠ active exploitation verification policy →

Executive Summary

CVE-2024-36119 is a low-severity vulnerability affecting Statamic CMS versions 5.3.0 through 5.6.1. The flaw causes the password_confirmation field submitted via the user:register_form tag to be stored in plaintext within the user’s YAML file. This only impacts file-based user accounts (not database-backed users) and only for registrations occurring during the vulnerable window. The stored plaintext password confirmation is only accessible to users with read access to the YAML files, typically developers. The vulnerability has been patched in version 5.6.2, but existing user files must be manually cleaned.

⚡ AUTOMATE YOUR CVE INTELLIGENCE

This record — and 170,000+ others — are available via the ValtersIT API. One endpoint replaces five: NVD + GitHub CVE + CISA KEV + EPSS + Nuclei + Exploit-DB, unified.

›Patch confidence — UNVERIFIED to CONFIRMED, cross-referenced NVD + RHSA + Debian
›Exploit & PoC — poc_status, poc_url, has_exploit. Not in NVD.
›Shodan dorks — ready-made queries to find exposed vulnerable systems
›Detection rules — YARA · Wazuh · Elastic (all plans) · Sigma (Pro)
›pending_fields — know exactly which of 7 fields NVD hasn't processed yet
›Free backfill — data incomplete when you paid? Re-check within 30 days = 0 credits
PAYG €0.08/lookup Standard €19/mo (was €29) · 5k credits Pro €65/mo (was €99) · 20k credits FOUNDING PRICE · LOCKED FOR LIFE · ENDS 31 DEC 2026
[ FROM €19/MO ]
Free sandbox key available
No signup required

Supply Chain & Package Security

This vulnerability is specific to the Statamic CMS package (a Laravel-based CMS). It does not affect the underlying Laravel framework or PHP runtime. The risk is primarily to the confidentiality of user credentials within the application’s file storage.

CVSS Breakdown & Threat Level

  • CVSS Score: 1.8 (Low)
  • Vector: CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:L/I:N/A:N
  • Attack Vector: Local (requires access to the file system)
  • Attack Complexity: High (requires knowledge of the vulnerable version and file structure)
  • Privileges Required: High (requires read access to user YAML files)
  • User Interaction: None
  • Scope: Unchanged
  • Confidentiality Impact: Low (plaintext password confirmation exposed)
  • Integrity Impact: None
  • Availability Impact: None

Threat Level: Low. The vulnerability requires high privileges and local access, and the exposed data is the password confirmation (not the primary password). However, if user files are committed to a public Git repository, the exposure becomes public.

Deep Dive & Mechanics

The vulnerability originates in the user:register_form tag handler. When a user submits the registration form, the password_confirmation field is not stripped before the user data is serialized and written to the YAML file. The code path is as follows:

  1. The UserRegisterForm tag receives form data including password and password_confirmation.
  2. The tag validates the passwords match.
  3. After validation, the entire form data (including password_confirmation) is passed to the user creation method.
  4. The user creation method writes the data to a YAML file without filtering out the password_confirmation field.

The password field itself is hashed before storage, but password_confirmation is stored as plaintext. This is a classic case of failing to sanitize input before persistence.

Vulnerable vs. Patched Code

Vulnerable Code (Statamic 5.3.0 - 5.6.1):

// In UserRegisterForm.php
public function handle()
{
    $data = $this->request->all();
    // Validation happens here
    $user = User::make()->data($data); // $data includes password_confirmation
    $user->save();
}

Patched Code (Statamic 5.6.2):

// In UserRegisterForm.php
public function handle()
{
    $data = $this->request->except(['password_confirmation']);
    // Validation happens here
    $user = User::make()->data($data); // password_confirmation is removed
    $user->save();
}

The patch uses except(['password_confirmation']) to remove the field before passing data to the user creation method.

Exploitation & Lab Setup

Red Team (Attacker Perspective)

Prerequisites:

  • Access to the server’s file system (e.g., via compromised developer account or SSH).
  • Knowledge that the target uses Statamic 5.3.0 - 5.6.1 with file-based users.

Exploitation Steps:

  1. Locate user YAML files, typically in users/*.yaml.
  2. Read the contents of any user file:
    cat /path/to/statamic/users/username.yaml
    
  3. Look for the password_confirmation field containing the plaintext password confirmation.
  4. Use this value to attempt password guessing or social engineering.

Note: No public exploit code exists for this CVE.

Blue Team (Defender Perspective)

Detection:

  • Monitor for unauthorized access to user YAML files (e.g., users/*.yaml).
  • Check Git history for committed user files containing password_confirmation.

Remediation:

  • Upgrade to Statamic 5.6.2 or later.
  • For existing users, reset their passwords and remove the password_confirmation field from their YAML files.
  • If user files were committed to Git, use git filter-branch or BFG Repo-Cleaner to remove the sensitive data from history.

Indicators of Compromise (IOCs)

  • File-based IOCs:

    • Presence of password_confirmation field in user YAML files (e.g., users/*.yaml).
    • User files containing plaintext strings that match password confirmation patterns.
  • Network-based IOCs:

    • Unusual access patterns to user YAML files (e.g., repeated reads by non-admin users).
  • Behavioral IOCs:

    • Developers or users with file access reading user YAML files outside of normal operations.

Detection Engineering

YARA Rule

rule CVE_2024_36119_Statamic_Plaintext_Password
{
    meta:
        description = "Detects plaintext password_confirmation in Statamic user YAML files"
        author = "Valters IT"
        date = "2024-01-01"
        reference = "CVE-2024-36119"
    strings:
        $s1 = "password_confirmation:" nocase
    condition:
        $s1
}

Sigma Rule

title: Statamic Plaintext Password Confirmation Storage
id: 8a9b7c6d-5e4f-3a2b-1c0d-9e8f7a6b5c4d
status: experimental
description: Detects access to Statamic user YAML files containing password_confirmation
author: Valters IT
logsource:
    category: file_access
    product: linux
detection:
    selection:
        TargetFilename|endswith: '.yaml'
        TargetFilename|contains: 'users/'
        EventID: 4663  # Windows file access
    condition: selection
falsepositives:
    - Legitimate admin access
level: low

Suricata Rule

alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"CVE-2024-36119 - Statamic User YAML File Access"; flow:to_server,established; content:"/users/"; http_uri; content:".yaml"; http_uri; classtype:attempted-recon; sid:1000001; rev:1;)

Remediation & Mitigation

  1. Immediate Patch: Upgrade Statamic to version 5.6.2 or later.
  2. User Password Reset: Force all users who registered during the vulnerable period (5.3.0 - 5.6.1) to reset their passwords.
  3. Clean User Files: Manually remove the password_confirmation field from all user YAML files.
  4. Git History Cleanup: If user files were committed to a public or shared Git repository, use git filter-branch or BFG Repo-Cleaner to purge the sensitive data from history.
  5. Access Control: Restrict read access to user YAML files to only necessary personnel.
  6. Monitoring: Implement file integrity monitoring (FIM) on user YAML files to detect unauthorized access.

Valters IT
DevSecOps & Cyber Threat Intelligence

◈ SOURCE Analysis & enrichment: valtersit.com/cve/CVE-2024-36119/ · CVE data: NVD/MITRE (public domain) · © 2026 ValtersIT Hub
>_ SYSTEM_CORE: INTEL_ACTIVE
90% TEAM-CURATED // 10% AUTOMATED INGESTION.
ALL PATCH REFERENCES AND VERSION DATA SOURCED FROM NVD + OSV OFFICIAL REGISTRIES.