CVE-2026-6990: projeto-siga siga XSS Vulnerability

CVE-2026-6990 Overview

A stored cross-site scripting (XSS) vulnerability has been identified in projeto-siga siga version 11.0.3.18. The vulnerability exists in an unknown function of the file /sigawf/app/responsavel/novo, where improper input validation allows attackers to inject malicious scripts through the Nome (Name) and Descrição (Description) arguments. As a stored XSS vulnerability, malicious payloads are persisted in the application database and executed whenever other users access the affected page, potentially leading to session hijacking, credential theft, or unauthorized actions on behalf of legitimate users.

Critical Impact
Attackers can inject persistent malicious scripts that execute in victim browsers, enabling session theft, credential harvesting, and unauthorized actions within the Siga workflow management system.

Affected Products

Projeto-Siga Siga version 11.0.3.18
Siga Workflow Management System (sigawf module)
/sigawf/app/responsavel/novo endpoint

Discovery Timeline

2026-04-25 - CVE-2026-6990 published to NVD
2026-04-29 - Last updated in NVD database

Technical Details for CVE-2026-6990

Vulnerability Analysis

This stored cross-site scripting vulnerability (CWE-79) affects the Siga workflow management application, specifically targeting the responsible party creation functionality. The vulnerability stems from inadequate input sanitization in the /sigawf/app/responsavel/novo endpoint. When users submit data through the Nome (Name) or Descrição (Description) fields, the application fails to properly encode or sanitize the input before storing it in the database and subsequently rendering it back to users.

The exploit has been publicly disclosed and documented through a GitHub Stored XSS Report. The projeto-siga team was notified through GitHub Issue #2491, but as of the last update, no response has been received from the maintainers.

Root Cause

The root cause of this vulnerability is insufficient input validation and output encoding in the Siga application. When processing user-supplied data for the Nome and Descrição fields, the application fails to:

Sanitize user input on the server-side before database storage
Properly encode output when rendering stored data back to users
Implement Content Security Policy (CSP) headers to mitigate script execution

This allows HTML and JavaScript code submitted by attackers to be stored in the application database and later executed in the browsers of other users who view the affected content.

Attack Vector

The attack is network-based and can be initiated remotely by any authenticated user with access to the /sigawf/app/responsavel/novo endpoint. The attacker crafts a malicious payload containing JavaScript code and submits it through the Nome or Descrição form fields when creating a new responsible party entry.

The typical attack flow involves:

Attacker authenticates to the Siga application with low-privileged credentials
Attacker navigates to the responsible party creation page at /sigawf/app/responsavel/novo
Attacker enters a malicious JavaScript payload in the Name or Description field
The payload is stored in the application database without proper sanitization
When other users (including administrators) view the responsible party list or details, the malicious script executes in their browser context

The vulnerability requires user interaction as victims must navigate to a page that renders the stored malicious content. For detailed technical information about the exploitation technique, refer to the security research report.

Detection Methods for CVE-2026-6990

Indicators of Compromise

Unusual JavaScript patterns in database records for the responsible party table, particularly in Nome and Descrição columns
HTTP requests to /sigawf/app/responsavel/novo containing script tags, event handlers, or encoded JavaScript payloads
Client-side error logs indicating blocked script execution or CSP violations
Unexpected outbound requests from user browsers after accessing the Siga workflow module

Detection Strategies

Implement web application firewall (WAF) rules to detect and block XSS payloads in POST requests to the /sigawf/app/responsavel/ endpoints
Configure database monitoring to alert on suspicious content patterns being inserted into user-facing text fields
Deploy browser-based XSS detection through Content Security Policy headers with report-uri directives
Regularly audit database content for stored XSS patterns using automated scanning tools

Monitoring Recommendations

Monitor HTTP request logs for the /sigawf/app/responsavel/novo endpoint, filtering for requests containing <script>, JavaScript event handlers (e.g., onerror, onload), or encoded variants
Enable verbose logging on the Siga application to capture all form submissions to sensitive endpoints
Implement real-time alerting for CSP violation reports if Content Security Policy is deployed as a mitigation

How to Mitigate CVE-2026-6990

Immediate Actions Required

Restrict access to the Siga workflow management system to trusted users only until a patch is available
Implement a web application firewall (WAF) with XSS filtering rules in front of the Siga application
Review existing database records in the responsible party table for malicious content and sanitize any identified payloads
Consider temporarily disabling the /sigawf/app/responsavel/novo functionality if not critical to operations

Patch Information

As of the last update, no official patch has been released by the projeto-siga maintainers. The project was notified through GitHub Issue #2491 but has not yet responded. Organizations using this software should monitor the Siga project repository for security updates and consider implementing workarounds until an official fix is available.

Workarounds

Implement server-side input validation to reject or sanitize HTML and JavaScript content in user-supplied fields before database storage
Apply output encoding (HTML entity encoding) when rendering stored user content back to the browser
Deploy Content Security Policy (CSP) headers to restrict script execution to trusted sources only
Consider implementing a custom patch to add input sanitization to the affected endpoint if the organization has development resources

bash

# Example Apache configuration to add CSP headers as a temporary mitigation
# Add to your Apache virtual host or .htaccess configuration
Header always set Content-Security-Policy "default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data:; frame-ancestors 'self';"
Header always set X-XSS-Protection "1; mode=block"
Header always set X-Content-Type-Options "nosniff"