CVE-2026-91994 in Semaphore
Summary
by MITRE • 09/15/2026
Semaphore UI through 2.19.12 exempts GET and HEAD requests from project resource permission checks in GetMustCanMiddleware. Attackers with guest or task_runner roles can read all project environments including plaintext secrets, credentials, and passwords via GET requests to the environment endpoint.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/15/2026
The vulnerability identified in Semaphore UI versions up to 2.19.12 represents a critical authorization bypass within the application's middleware layer, specifically affecting the GetMustCanMiddleware component. This security flaw stems from an incomplete implementation of access control checks for HTTP GET and HEAD requests targeting project resources. In secure web applications, middleware is responsible for intercepting incoming requests to verify that the authenticated user possesses the necessary permissions before allowing access to protected data or actions. However, in this specific instance, the logic governing permission validation was incorrectly configured to skip these checks for read-oriented methods, creating a significant gap in the security architecture that allows unauthorized entities to bypass intended restrictions.
The operational impact of this vulnerability is severe due to the nature of the data exposed through Semaphore UI, which serves as an automation platform often managing sensitive infrastructure configurations and deployment pipelines. Attackers possessing either guest or task_runner roles, which are typically assigned with limited privileges for viewing status or executing specific automated tasks without full administrative control, can exploit this flaw to enumerate all environments associated with a project. By sending crafted GET requests directly to the environment endpoint, these users can retrieve detailed configuration data that includes plaintext secrets, API credentials, database passwords, and other sensitive authentication tokens. This exposure effectively elevates their privilege level from limited operational access to full visibility of critical security assets, facilitating further attacks such as credential stuffing, lateral movement within connected systems, or unauthorized deployment modifications if combined with other vulnerabilities.
From a technical classification perspective, this issue aligns closely with CWE-284 Improper Access Control and CWE-613 Insufficient Session Expiration or Termination in the context of role-based access control failures. The vulnerability allows for information disclosure that violates the principle of least privilege, as users are granted data access beyond their assigned scope. In terms of offensive security frameworks, this behavior corresponds to ATT&CK technique T1078 Valid Accounts and specifically relates to unauthorized access patterns where lower-privileged accounts exploit misconfigurations to gain higher-level visibility. The exploitation does not require complex payload injection or buffer overflow techniques but relies purely on the misuse of standard HTTP methods against an improperly secured endpoint, making it straightforward to detect in logs if proper monitoring is in place and easy to automate for reconnaissance purposes.
Mitigation strategies must prioritize immediate patching as well as architectural review of middleware configurations. The primary remediation step is upgrading Semaphore UI to a version later than 2.19.12 where the GetMustCanMiddleware has been corrected to enforce permission checks on all HTTP methods, including GET and HEAD. In environments where an upgrade cannot be performed immediately due to operational constraints, network-level controls such as Web Application Firewalls can be configured to restrict access to sensitive endpoints based on user roles or IP addresses if possible. Additionally, organizations should audit their role assignments within Semaphore UI to ensure that guest and task_runner accounts are strictly limited in scope and do not have unnecessary exposure to project environments containing high-value secrets. Regular security audits of middleware logic across all web applications are recommended to prevent similar authorization bypasses where read operations are erroneously exempted from access control validation processes.