CVE-2026-112787 in OpenCATS
Summary
by MITRE • 10/20/2026
OpenCATS before 0.10.0 contains a missing authorization vulnerability in ReportsUI::handleRequest() that allows authenticated users to view EEO demographic reports without the canSeeEEOInfo permission. Attackers can invoke the customizeEEOReport and generateEEOReportPreview actions to view aggregate ethnicity, veteran, gender and disability statistics.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/20/2026
The identified vulnerability in OpenCATS versions prior to 0.10.0 represents a critical failure in access control mechanisms within the application's reporting module. Specifically, the ReportsUI::handleRequest() method lacks proper authorization checks for actions related to Equal Employment Opportunity (EEO) demographic reports. This architectural flaw allows any authenticated user, regardless of their assigned role or permission set, to bypass security restrictions and access sensitive aggregate data. The vulnerability is classified under CWE-285, which describes Improper Authorization, as the system fails to enforce that a principal is authorized to perform an action on a specific resource. Furthermore, this flaw aligns with MITRE ATT&CK technique T1078, Valid Accounts, because it exploits legitimate credentials to access data intended for restricted personnel only.
The technical root cause lies in the logic governing the customizeEEOReport and generateEEOReportPreview actions within the ReportsUI component. These functions are designed to retrieve and display aggregated statistics regarding ethnicity, veteran status, gender, and disability information. However, the code does not verify whether the currently authenticated user possesses the specific canSeeEEOInfo permission before executing these requests. Consequently, an attacker who has obtained valid credentials for any standard user account can directly invoke these endpoints via HTTP requests or by navigating to the corresponding URLs in a web browser. The application processes these requests and returns detailed demographic breakdowns without performing the necessary privilege verification step that should gate access to such sensitive human resources data.
The operational impact of this vulnerability is significant due to the nature of the exposed information. EEO reports contain aggregated personal identifiable information (PII) regarding employees, including protected characteristics such as race, gender, disability status, and veteran affiliation. Unauthorized disclosure of this data violates privacy regulations such as GDPR or CCPA depending on the jurisdiction and organizational policies. It also poses a severe risk to employee trust and can lead to legal liabilities for the organization hosting OpenCATS. Attackers with malicious intent could use this information for social engineering attacks, discrimination analysis against specific groups within the workforce, or simply to gain insights into the demographic composition of an organization that should remain confidential.
Mitigation strategies must focus on immediate patching and enhanced access control implementation. The primary remediation is to upgrade OpenCATS to version 0.10.0 or later, where this authorization check has been properly implemented in the ReportsUI module. For organizations unable to immediately update due to compatibility constraints, a temporary workaround involves restricting web server-level access to the specific endpoints associated with EEO reporting if possible, though this is less ideal than fixing the application logic. Additionally, security teams should audit existing user roles and permissions within OpenCATS to ensure that only HR administrators or designated compliance officers are granted high-level privileges. Implementing comprehensive logging for all report generation actions will also aid in detecting any unauthorized access attempts during the transition period until the patch is applied. Regular penetration testing focused on broken object level authorization flaws should be conducted to prevent similar vulnerabilities from persisting in other modules of the application.