Skip to main content
CVE Vulnerability Database
Vulnerability Database/CVE-2025-61606

CVE-2025-61606: Wegia Open Redirect Vulnerability

CVE-2025-61606 is an open redirect flaw in Wegia web manager that allows attackers to redirect users to malicious domains for phishing or credential theft. This article covers technical details, affected versions, and mitigation.

Published:

CVE-2025-61606 Overview

WeGIA is an open source web manager designed for charitable institutions. CVE-2025-61606 is an Open Redirect vulnerability [CWE-601] affecting WeGIA versions 3.4.12 and below. The flaw resides in the control.php endpoint, specifically in the nextPage parameter used by the metodo=listarUmnomeClasse=FuncionarioControle request. Attackers can craft URLs that redirect authenticated users to arbitrary external domains. This behavior enables phishing campaigns, malicious payload delivery, and credential theft when victims trust the WeGIA origin. The vendor addressed the issue in version 3.5.0.

Critical Impact

Authenticated attackers can weaponize trusted WeGIA URLs to redirect users to attacker-controlled domains, facilitating credential harvesting and malware distribution.

Affected Products

  • WeGIA versions 3.4.12 and earlier
  • Component: controle/FuncionarioControle.php
  • Component: html/funcionario/profile_funcionario.php

Discovery Timeline

  • 2025-10-02 - CVE CVE-2025-61606 published to NVD
  • 2026-06-17 - Last updated in NVD database

Technical Details for CVE-2025-61606

Vulnerability Analysis

The vulnerability is a classic Open Redirect [CWE-601] in the WeGIA employee management workflow. The control.php endpoint accepts a nextPage parameter that determines where the user is sent after processing the listarUmnomeClasse=FuncionarioControle action. The application does not validate that nextPage points to an in-application resource. An attacker can supply a fully qualified external URL and cause the server to issue a redirect to that destination. Because the initial URL originates from a legitimate WeGIA host, users and email filters may trust the link. This trust enables convincing phishing pages, drive-by download stages, and credential-collection sites hosted on attacker infrastructure.

Root Cause

The root cause is missing validation of user-controlled redirect targets. The affected scripts also relied on extract($_REQUEST), which imports arbitrary request variables into the local scope. This pattern makes it trivial to overwrite variables used in subsequent header("Location: ...") calls. The absence of an allowlist for destination URLs allows any absolute URL to be honored by the redirect logic.

Attack Vector

Exploitation requires network access to the WeGIA application and a low-privileged authenticated session, with user interaction on a crafted link. An attacker distributes a URL such as https://victim-wegia.example/control.php?metodo=listarUmnomeClasse=FuncionarioControle&nextPage=https://attacker.example/login. When the victim clicks, WeGIA redirects the browser to the attacker-controlled site.

php
<?php
// Patch excerpt: controle/FuncionarioControle.php
// Replaces recursive config discovery and hardens include path resolution
require_once dirname(__FILE__, 2) . DIRECTORY_SEPARATOR . 'config.php';
include_once ROOT . "/dao/Conexao.php";
include_once ROOT . '/classes/Funcionario.php';
include_once ROOT . '/classes/QuadroHorario.php';

// Patch excerpt: html/funcionario/profile_funcionario.php
// Session handling is hardened before variable extraction
if (session_status() === PHP_SESSION_NONE) {
  session_start();
}

if (!isset($_SESSION['usuario'])) {
  header("Location: ../index.php");
  exit();
} else {
  session_regenerate_id();
}

extract($_REQUEST);

// Sanitize input for id_funcionario
$idFuncionario = filter_input(INPUT_GET, 'id_funcionario', FILTER_SANITIZE_NUMBER_INT);

Source: WeGIA commit 85051ad

Detection Methods for CVE-2025-61606

Indicators of Compromise

  • Web server access logs containing requests to control.php where the nextPage parameter includes an absolute URL with a scheme (http://, https://, //) pointing to an external host.
  • Referer chains showing users leaving the WeGIA origin and landing on unrelated domains immediately after hitting control.php.
  • Outbound HTTP 302 responses from WeGIA with Location headers targeting non-allowlisted hostnames.

Detection Strategies

  • Parse web access logs for the pattern control.php?metodo=listarUmnomeClasse=FuncionarioControle&nextPage= followed by URL-encoded external URLs.
  • Alert when the nextPage value fails to match the application's canonical hostnames or relative-path allowlist.
  • Correlate authenticated session identifiers with anomalous redirect targets to identify targeted users.

Monitoring Recommendations

  • Ship WeGIA HTTP access and error logs to a centralized analytics platform for URL parameter inspection.
  • Monitor phishing intelligence feeds for lookalike domains being paired with WeGIA redirect URLs.
  • Track user reports of suspicious login prompts appearing after clicking internal WeGIA links.

How to Mitigate CVE-2025-61606

Immediate Actions Required

  • Upgrade WeGIA to version 3.5.0 or later, which contains the official fix from commit 85051ad.
  • Audit web server logs for prior exploitation attempts against control.php involving the nextPage parameter.
  • Notify users of the potential for phishing links referencing the organization's WeGIA URL and reinforce credential-verification practices.

Patch Information

The fix is delivered in WeGIA 3.5.0 via commit 85051ad14b1e7fa14116e74a90c0bd5480b2ec84. The patch hardens include-path resolution, enforces session initialization and regeneration before request-variable extraction, and applies input filtering to controller parameters. Refer to the GitHub Security Advisory GHSA-m64v-hm7q-33wr and the WeGIA security commit for full details.

Workarounds

  • Deploy a web application firewall rule that strips or rejects nextPage values containing :// or a leading //.
  • Restrict access to the WeGIA /controle/ endpoints via network ACLs while patch deployment is planned.
  • Enforce a redirect allowlist at the reverse proxy so only relative paths or approved hostnames are returned in Location headers.
bash
# Example NGINX guard to block external redirect targets on control.php
location = /control.php {
    if ($arg_nextPage ~* "^(https?:)?//") {
        return 400;
    }
    try_files $uri =404;
    include fastcgi_params;
    fastcgi_pass unix:/run/php/php-fpm.sock;
}

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Default Legacy - Prefooter | Experience the World’s Most Advanced Cybersecurity Platform

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.