CVE-2025-30367: WeGIA SQL Injection Vulnerability in nextPage Parameter
Executive Summary
CVE-2025-30367 is a critical SQL Injection vulnerability affecting WeGIA, a web manager for charitable institutions. The vulnerability resides in the nextPage parameter of the /WeGIA/controle/control.php endpoint. Unauthenticated attackers can exploit this flaw to manipulate SQL queries, potentially gaining access to sensitive database information, including table names and records, and even modifying or deleting data. Versions of WeGIA prior to 3.2.6 are affected. The vulnerability has a CVSS v4.0 base score of 10.0, indicating its critical severity.
Technical Details
- Vulnerability: SQL Injection (CWE-89)
- CVE ID: CVE-2025-30367
- Affected Software: WeGIA
- Affected Versions: Versions prior to 3.2.6
- Vulnerable Parameter:
nextPage - Vulnerable Endpoint:
/WeGIA/controle/control.php - Attack Vector: Network
- Privileges Required: None
- User Interaction: None
- CVSS v4.0 Score: 10.0 (Critical)
- CVSS v4.0 Vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H
The vulnerability exists because the nextPage parameter in the /WeGIA/controle/control.php endpoint is not properly sanitized before being used in an SQL query. This allows an attacker to inject arbitrary SQL code into the query, leading to various malicious outcomes.
The specific vulnerable URL structure is:
WeGIA/controle/control.php?metodo=listarUm&nomeClasse=SaudeControle&nextPage=<payload>&id=1
The metodo parameter is set to listarUm, nomeClasse to SaudeControle, id to 1, and the nextPage parameter is where the malicious SQL injection payload is inserted.
Root Cause Analysis
The root cause of CVE-2025-30367 lies in the insufficient input validation and sanitization of the nextPage parameter within the listarUm() function of the SaudeControle.php file. The application directly incorporates the user-supplied nextPage value into a header() function call, which is executed after potentially querying the database. While the database query itself might not be directly vulnerable (depending on how $id is handled), the redirection target is directly influenced by user input, creating an opportunity for exploitation.
The original code in controle/SaudeControle.php lacked proper validation of the nextPage parameter before using it in a header() redirection. This allowed attackers to inject malicious code into the URL, leading to SQL injection or other vulnerabilities.
<?php
// ... other code ...
public function listarUm()
{
extract($_REQUEST);
$cache = new Cache();
$infSaude = $cache->read($id);
if (!$infSaude) {
try {
$SaudeDAO=new SaudeDAO();
$infSaude=$SaudeDAO->listar($id);
session_start();
$_SESSION['id_fichamedica']=$infSaude;
$cache->save($id, $infSaude, '1 seconds');
header('Location:'.$nextPage);
} catch (PDOException $e) {
echo $e->getMessage();
}
}
else{
header('Location:'.$nextPage);
}
}
// ... other code ...
?>
In this code snippet, the $nextPage variable, directly extracted from the $_REQUEST array without any sanitization or validation, is used in the header('Location:'.$nextPage) function. This allows an attacker to control the redirection target and potentially inject malicious SQL queries.
Patch Analysis
The patch addresses the SQL Injection vulnerability by implementing proper input validation and sanitization for the nextPage parameter. The patch introduces a regular expression to validate the nextPage parameter against a whitelist of allowed URLs. Additionally, the htmlspecialchars() function is used to escape any potentially malicious characters in the validated URL before using it in the header() function.
The following diff shows the changes made to controle/SaudeControle.php:
--- a/controle/SaudeControle.php
+++ b/controle/SaudeControle.php
@@ -148,113 +163,114 @@ public function alterarImagem()
$SaudeDAO = new SaudeDAO();
try {
$SaudeDAO->alterarImagem($id_fichamedica, $imagem);
- header("Location: ../html/saude/profile_paciente.php?id_fichamedica=".$id_fichamedica);
+ header("Location: ../html/saude/profile_paciente.php?id_fichamedica=" . $id_fichamedica);
} catch (PDOException $e) {
echo $e->getMessage();
}
-
}
/**
* Instancia um objeto do tipo Saude que recebe informações do formulário de cadastro e chama os métodos de DAO e Controller necessários para que uma ficha médica nova seja criada.\n
*/
- public function incluir(){\n
+ public function incluir()\n
+ {\n
$saude = $this->verificar();\n
$texto_descricao = $saude->getTexto();\n
\n
$saudeDao = new SaudeDAO();\n
$descricao = new DescricaoControle();\n
\n
- try{\n
+ try {\n
$saudeDao->incluir($saude);\n
$descricao->incluir($texto_descricao);\n
\n
- $_SESSION[\'msg\']="Ficha médica cadastrada com sucesso!";\n
- $_SESSION[\'proxima\']="Cadastrar outra ficha.";\n
- $_SESSION[\'link\']="../html/saude/cadastro_ficha_medica.php";\n
+ $_SESSION[\'msg\'] = "Ficha médica cadastrada com sucesso!";\n
+ $_SESSION[\'proxima\'] = "Cadastrar outra ficha.";\n
+ $_SESSION[\'link\'] = "../html/saude/cadastro_ficha_medica.php";\n
header("Location: ../html/saude/informacao_saude.php");\n
- \n
- }catch(PDOException $e){\n
- $msg= "Não foi possível registrar o paciente <form> <input type=\'button\' value=\'Voltar\' onClick=\'history.go(-1)\'> </form>"."<br>".$e->getMessage();\n
+
+ } catch (PDOException $e) {\n
+ $msg = "Não foi possível registrar o paciente <form> <input type=\'button\' value=\'Voltar\' onClick=\'history.go(-1)\'> </form>" . "<br>" . $e->getMessage();\n
echo $msg;\n
}\n
}\n
- \n
+
public function alterarInfPessoal()\n
{\n
extract($_REQUEST);\n
// $paciente = new Saude(\'\',$nome,$sobrenome,$sexo,$nascimento,\'\',\'\',\'\',\'\',\'\',$tipoSanguineo,\'\',\'\',$imagem,\'\',\'\',\'\',\'\',\'\',\'\',\'\',\'\');\n
- $paciente = new Saude(\'\',\'\',\'\',\'\',\'\',\'\',\'\',\'\',\'\',\'\',$tipoSanguineo,\'\',\'\',\'\',\'\',\'\',\'\',\'\',\'\',\'\',\'\',\'\');\n
+ $paciente = new Saude(\'\', \'\', \'\', \'\', \'\', \'\', \'\', \'\', \'\', \'\', $tipoSanguineo, \'\', \'\', \'\', \'\', \'\', \'\', \'\', \'\', \'\', \'\', \'\');\n
$paciente->setId_pessoa($id_fichamedica);\n
//echo $funcionario->getId_Funcionario();\n
- $SaudeDAO=new SaudeDAO();\n
+ $SaudeDAO = new SaudeDAO();\n
try {\n
$SaudeDAO->alterarInfPessoal($paciente);\n
- header("Location: ../html/saude/profile_paciente.php?id_fichamedica=".$id_fichamedica);\n
+ header("Location: ../html/saude/profile_paciente.php?id_fichamedica=" . $id_fichamedica);\n
} catch (PDOException $e) {\n
echo $e->getMessage();\n
}\n
- \n
}\n
/**
* Pega as informações do formulário de edição do prontuário e instancia um objeto do tipo DescricaoControle, chamando o método alterarProntuario e passando as informações necessárias, caso a alteração seja bem sucedida redireciona o usuário para a página de exibição das informações do paciente.\n
*/
- public function alterarProntuario(){\n
- \n
+ public function alterarProntuario()\n
+ {\n
+
extract($_REQUEST);\n
\n
$descricao = new DescricaoControle();\n
- try{\n
+ try {\n
$descricao->alterarProntuario($id_fichamedica, $textoProntuario);\n
- header("Location: ../html/saude/profile_paciente.php?id_fichamedica=".$id_fichamedica);\n
- }catch(PDOException $e){\n
+ header("Location: ../html/saude/profile_paciente.php?id_fichamedica=" . $id_fichamedica);\n
+ } catch (PDOException $e) {\n
echo $e->getMessage();\n
}\n
}\n
/**
* Extraí os dados da requisição e instancia um objeto SaudeDAO, em seguida chama a função adicionarProntuarioAoHistorico passando os parâmetros $id_fichamedica e $id_paciente, redireciona o usuário para a página profile_paciente.php e atribuí uma string para a varivável msg da sessão.\n
*/
- public function adicionarProntuarioAoHistorico(){\n
+ public function adicionarProntuarioAoHistorico()\n
+ {\n
extract($_REQUEST);\n
session_start();\n
$saudeDao = new SaudeDAO();\n
- try{\n
+ try {\n
$saudeDao->adicionarProntuarioAoHistorico($id_fichamedica, $id_paciente);\n
- $_SESSION[\'msg\']="Prontuário público adicionado ao histórico com sucesso";\n
- header("Location: ../html/saude/profile_paciente.php?id_fichamedica=".$id_fichamedica);\n
- }catch(Error $e){\n
+ $_SESSION[\'msg\'] = "Prontuário público adicionado ao histórico com sucesso";\n
+ header("Location: ../html/saude/profile_paciente.php?id_fichamedica=" . $id_fichamedica);\n
+ } catch (Error $e) {\n
$erro = $e->getMessage();\n
- $_SESSION[\'msg\']="Ops! Ocorreu o seguinte erro ao tentar inserir o prontuário público: $erro";\n
- header("Location: ../html/saude/profile_paciente.php?id_fichamedica=".$id_fichamedica);\n
+ $_SESSION[\'msg\'] = "Ops! Ocorreu o seguinte erro ao tentar inserir o prontuário público: $erro";\n
+ header("Location: ../html/saude/profile_paciente.php?id_fichamedica=" . $id_fichamedica);\n
}\n
}\n
/**
* Recebe como parâmetro o id de um paciente, instancia um objeto do tipo SaudeDAO e chama o método listarProntuariosDoHistorico passando o id do paciente informado, em caso de sucesso retorna os prontuários do histórico e em caso de falha da um echo na mensagem do erro.\n
*/
- public function listarProntuariosDoHistorico($idPaciente){\n
+ public function listarProntuariosDoHistorico($idPaciente)\n
+ {\n
$saudeDao = new SaudeDAO();\n
\n
- try{\n
+ try {\n
$prontuariosHistorico = $saudeDao->listarProntuariosDoHistorico($idPaciente);\n
return $prontuariosHistorico;\n
- }catch(PDOException $e){\n
+ } catch (PDOException $e) {\n
echo $e->getMessage();\n
}\n
- \n
}\n
/**
* Pode receber ou não o id de uma ficha médica do histórico, em caso negativo pega a informação do \'idHistorico\' da requisição do tipo GET que o chamou. \n
* \n
* Instancia um objeto do tipo SaudeDAO e chama o método listarDescricoesHistoricoPorId passando o id da ficha médica do histórico, em caso de sucesso faz um echo do JSON das descrições, em caso de falha da um echo na mensagem do erro.\n
*/
- public function listarProntuarioHistoricoPorId($idHistorico = -1){\n
+ public function listarProntuarioHistoricoPorId($idHistorico = -1)\n
+ {\n
header(\'Content-Type: application/json\');\n
- \n
- if($idHistorico == -1){\n
+
+ if ($idHistorico == -1) {\n
$idHistorico = $_GET[\'idHistorico\'];\n
}\n
@@ -266,5 +282,4 @@ public function listarProntuarioHistoricoPorId($idHistorico = -1){\n
echo $e->getMessage();\n
}\n
}\n
- \n-}\n\\ No newline at end of file\n+}\n
--- a/controle/SaudeControle.php
+++ b/controle/SaudeControle.php
@@ -108,18 +108,24 @@
public function listarUm()
{
- extract($_REQUEST);
+ $id = filter_input(INPUT_GET, 'id', FILTER_SANITIZE_NUMBER_INT);
+ $nextPage = trim(filter_input(INPUT_GET, 'nextPage', FILTER_SANITIZE_URL));
+
+ $regex = '#^(\.\./html/saude/(aplicar_medicamento|historico_paciente|profile_paciente)\.php(\?id_fichamedica=\d+)?)$#';
$cache = new Cache();
$infSaude = $cache->read($id);
if (!$infSaude) {
try {
- $SaudeDAO=new SaudeDAO();
- $infSaude=$SaudeDAO->listar($id);
+ $SaudeDAO = new SaudeDAO();
+ $infSaude = $SaudeDAO->listar($id);
session_start();
- $_SESSION['id_fichamedica']=$infSaude;
+ $_SESSION['id_fichamedica'] = $infSaude;
$cache->save($id, $infSaude, '1 seconds');
- header('Location:'.$nextPage);
+
+ if(preg_match($regex, $nextPage)){
+ header('Location:' . htmlspecialchars($nextPage));
+ }else{
+ header('Location:' . '../html/home.php');
+ }
} catch (PDOException $e) {
echo $e->getMessage();
}
@@ -127,7 +133,11 @@
else{
header('Location:'.$nextPage);
}
+ if(preg_match($regex, $nextPage)){
+ header('Location:' . htmlspecialchars($nextPage));
+ }else{
+ header('Location:' . '../html/home.php');
+ }
}
}
Explanation of the Patch:
- Input Filtering: The patch uses
filter_input()withFILTER_SANITIZE_NUMBER_INTto sanitize theidparameter, ensuring it's an integer. It also usesFILTER_SANITIZE_URLto sanitize thenextPageparameter. - Regular Expression Validation: A regular expression
$regexis defined to match allowed URL patterns for thenextPageparameter. This regex whitelists specific files within the/html/saude/directory, such asaplicar_medicamento.php,historico_paciente.php, andprofile_paciente.php, and allows an optionalid_fichamedicaparameter with a numeric value. preg_match()for Whitelisting: Thepreg_match()function is used to check if the$nextPageparameter matches the defined regular expression. This ensures that only URLs matching the whitelist are allowed.htmlspecialchars()for Output Encoding: Thehtmlspecialchars()function is used to escape any potentially malicious characters in the$nextPageparameter before using it in theheader()function. This prevents XSS attacks by encoding special characters like<,>,&,"and'.- Fallback Redirection: If the
$nextPageparameter does not match the regular expression, the code redirects the user to a safe default page (../html/home.php).
This patch effectively mitigates the SQL Injection vulnerability by validating and sanitizing the nextPage parameter, preventing attackers from injecting malicious code into the URL.
Exploitation Techniques
An attacker can exploit this vulnerability by crafting a malicious URL that injects SQL code into the nextPage parameter. This can be achieved by using tools like sqlmap or by manually crafting the URL.
Proof of Concept (PoC) using sqlmap:
The provided PoC demonstrates how an attacker can use sqlmap to exploit the SQL Injection vulnerability and dump the entire database information from WeGIA.
sqlmap -u "https://comfirewall.wegia.org:8000/WeGIA/controle/control.php?metodo=listarUm&nomeClasse=SaudeControle&nextPage=../html/saude/profile_paciente.php?id_fichamedica=1&id=1" --dbms=mysql --cookie="_ga_F8DXBXLV8J=GS1.1.1733782455.11.1.1733782568.60.0.0; _ga=GA1.1.552051356.1730893405; PHPSESSID=tc79og6t5lr33d4tjv7ct1o9pg" --dump
This command tells sqlmap to:
-u: Target the specified URL.--dbms=mysql: Specify that the database is MySQL.--cookie: Provide the necessary session cookies for authentication (if required).--dump: Dump the entire database.
Attack Scenario:
-
An attacker identifies the vulnerable endpoint
/WeGIA/controle/control.phpand thenextPageparameter. -
The attacker crafts a malicious URL with an SQL injection payload in the
nextPageparameter. For example:/WeGIA/controle/control.php?metodo=listarUm&nomeClasse=SaudeControle&nextPage=../html/saude/profile_paciente.php?id_fichamedica=1' UNION SELECT table_name FROM information_schema.tables WHERE table_schema=database()--&id=1This payload attempts to inject a
UNION SELECTstatement to retrieve table names from theinformation_schema.tablestable. -
The attacker sends the malicious URL to the server.
-
The server executes the injected SQL query, potentially revealing sensitive database information.
-
The attacker can then use the retrieved information to further exploit the database, such as extracting data from specific tables or modifying data.
Real-World Impact:
- Data Breach: Attackers can steal sensitive patient data, including personal information, medical records, and financial details.
- Data Manipulation: Attackers can modify or delete patient records, leading to incorrect medical treatments or denial of services.
- System Downtime: Attackers can inject SQL queries that cause the database server to crash, leading to system downtime and disruption of services.
- Reputational Damage: A successful attack can damage the reputation of the charitable institution, leading to loss of trust and funding.
Mitigation Strategies
To mitigate the risk of CVE-2025-30367, the following strategies are recommended:
- Upgrade to Version 3.2.6 or Later: The most effective mitigation is to upgrade WeGIA to version 3.2.6 or later, which contains the patch for this vulnerability.
- Input Validation and Sanitization: Implement strict input validation and sanitization for all user-supplied input, especially parameters used in SQL queries. Use parameterized queries or prepared statements to prevent SQL injection.
- Output Encoding: Encode all output data before displaying it to the user to prevent Cross-Site Scripting (XSS) attacks. Use functions like
htmlspecialchars()to escape special characters. - Web Application Firewall (WAF): Deploy a WAF to detect and block malicious requests, including SQL injection attempts. Configure the WAF with rules to filter out suspicious patterns and payloads.
- Regular Security Audits: Conduct regular security audits and penetration testing to identify and address vulnerabilities in the application.
- Least Privilege Principle: Grant database users only the necessary privileges to perform their tasks. Avoid using the
rootuser for application connections. - Database Monitoring: Monitor database activity for suspicious queries and access patterns. Set up alerts for unusual behavior.
- Regular Backups: Maintain regular backups of the database to ensure data can be restored in case of a successful attack.
Configuration Changes:
- Review and update the application's configuration to ensure that all security settings are properly configured.
- Disable unnecessary features and services to reduce the attack surface.
- Implement strong password policies for all user accounts.
Security Best Practices:
- Follow secure coding practices to prevent common vulnerabilities.
- Keep all software and systems up to date with the latest security patches.
- Educate users about phishing and other social engineering attacks.
- Implement a comprehensive security awareness program for all employees.
Timeline of Discovery and Disclosure
- 2025-03-21: Vulnerability reported.
- 2025-03-27: Patch released in WeGIA version 3.2.6.
- 2025-03-27: CVE-2025-30367 publicly disclosed.
References
- NVD: https://nvd.nist.gov/vuln/detail/CVE-2025-30367 (Fictional URL)
- GitHub Advisory: https://github.com/LabRedesCefetRJ/WeGIA/security/advisories/GHSA-7j9v-xgmm-h7wr
- INCIBE-CERT: https://www.incibe.es/en/incibe-cert/early-warning/vulnerabilities
- Code Patch Repository: https://github.com/LabRedesCefetRJ/WeGIA
- Vulners: https://vulners.com/cve/CVE-2025-30367
This blog post provides a comprehensive analysis of CVE-2025-30367, including technical details, root cause analysis, patch analysis, exploitation techniques, and mitigation strategies. By understanding the vulnerability and implementing the recommended mitigations, organizations can protect their WeGIA installations from potential attacks.