CVE-2025-24899: Yogeshojha Rengine Info Disclosure Flaw

CVE-2025-24899 Overview

CVE-2025-24899 is an information disclosure vulnerability in reNgine, an open-source automated reconnaissance framework for web applications. An authenticated insider with any assigned role, including Auditor, Penetration Tester, or Sys Admin, can extract sensitive account data belonging to other reNgine users. After running a scan that returns vulnerability findings, the attacker queries the /api/listVulnerability/ endpoint and receives user records containing username, password, email, role, first name, last name, status, and activity metadata. The flaw is tracked under [CWE-200] and resolved in reNgine 2.2.0.

Critical Impact
Any low-privileged reNgine user can harvest credentials and personally identifiable information of every other user through an authenticated API call, enabling lateral movement and account takeover.

Affected Products

reNgine versions prior to 2.2.0
yogeshojha/rengine (all roles: Auditor, Penetration Tester, Sys Admin)
Deployments exposing the /api/listVulnerability/ endpoint

Discovery Timeline

2025-02-03 - CVE-2025-24899 published to the National Vulnerability Database
2025-05-13 - Last updated in NVD database

Technical Details for CVE-2025-24899

Vulnerability Analysis

The vulnerability resides in the serializer feeding the /api/listVulnerability/ REST endpoint. The serializer returns vulnerability scan results joined with user objects, but does not strip sensitive fields from the user model before serialization. As a result, the API response includes the full user record, including the hashed password and account status, alongside vulnerability findings.

Because reNgine performs only role authentication and no field-level authorization on this endpoint, any authenticated principal can issue a single GET request and parse user records from the JSON response. The exposed data covers credential material, contact details, and activity timestamps useful for follow-on attacks against the reNgine application or its operators.

The issue is categorized as Information Exposure [CWE-200]. EPSS data places the exploit probability at 0.543% with a percentile of 67.886, reflecting accessible exploitation given valid credentials.

Root Cause

The web/api/serializers.py module serializes related User objects without restricting fields. The patch in commit a658b85 imports model_to_dict from django.forms.models to control which user attributes are exposed in API responses, removing credential and PII fields from the serialized output.

Attack Vector

An attacker authenticates with any reNgine role, launches or accesses a scan that produces vulnerability findings, and issues a GET request to /api/listVulnerability/. The response body contains other users' credentials and profile data, which the attacker harvests for offline cracking, credential reuse, or impersonation.

python

 from dashboard.models import *
 from django.contrib.humanize.templatetags.humanize import (naturalday, naturaltime)
 from django.db.models import F, JSONField, Value
+from django.forms.models import model_to_dict
 from recon_note.models import *
 from reNgine.common_func import *
 from rest_framework import serializers

Source: GitHub commit a658b85. The patch introduces model_to_dict to enforce field whitelisting when serializing User instances tied to vulnerability records.

Detection Methods for CVE-2025-24899

Indicators of Compromise

HTTP GET requests to /api/listVulnerability/ from non-administrative reNgine accounts at unusual frequency or volume.
Response payloads from /api/listVulnerability/ exceeding expected sizes, indicating bundled user records.
reNgine audit log entries showing scan creation followed immediately by repeated vulnerability listing API calls.
Subsequent authentication attempts using credentials belonging to reNgine accounts outside their normal source addresses.

Detection Strategies

Inspect reverse proxy or web server logs in front of reNgine for repeated calls to the /api/listVulnerability/ endpoint by the same authenticated session.
Alert on outbound JSON responses from reNgine containing the literal keys password and email together, which should never appear in legitimate vulnerability listings.
Correlate reNgine user logins with downstream credential reuse attempts against SSO, VPN, or administrative consoles.

Monitoring Recommendations

Enable verbose API request logging on the reNgine Django backend and forward logs to a centralized SIEM for retention and correlation.
Baseline normal API usage per role and flag deviations, particularly Auditor accounts calling vulnerability APIs at machine speed.
Monitor reNgine database access patterns for unusual joins against the auth_user table during API request handling.

How to Mitigate CVE-2025-24899

Immediate Actions Required

Upgrade reNgine to version 2.2.0 or later, which applies the serializer fix in commit a658b85.
Rotate all reNgine user passwords and force re-authentication, assuming credential exposure has occurred.
Audit the reNgine user table and revoke accounts that no longer require access, reducing the insider attack surface.
Restrict network access to the reNgine management interface to trusted administrative networks only.

Patch Information

The fix is delivered in reNgine 2.2.0 via commit a658b8519f1a3347634b04733cf91ed933af1f99. Details are published in the GitHub Security Advisory GHSA-r3fp-xr9f-wv38. The patch modifies web/api/serializers.py to use model_to_dict and exclude sensitive User model fields from API responses.

Workarounds

No vendor-supplied workarounds are available; upgrading to reNgine 2.2.0 is the only supported remediation.
As a temporary compensating control, block the /api/listVulnerability/ route at a reverse proxy for all non-administrative users until the upgrade is completed.
Limit reNgine account creation to vetted personnel and enforce strong, unique passwords to reduce the value of any disclosed hashes.

bash

# Upgrade reNgine to the patched release
git fetch --tags
git checkout v2.2.0
sudo make down
sudo make build
sudo make up

# Optional: block the vulnerable endpoint at nginx until upgrade completes
# location /api/listVulnerability/ { deny all; }