CVE-2026-110112 in Dockhand
Summary
by MITRE • 10/14/2026
Dockhand before 1.0.50 contains a privilege escalation vulnerability that allows users from another tenant to gain admin access because OIDC iss, aud, nonce and exp claims are not validated. Attackers with admin rights in another tenant of a shared provider like Microsoft Entra ID can recreate the mapped admin group and log in as Dockhand administrators.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/14/2026
The vulnerability identified in Dockhand versions prior to 1.0.50 represents a critical flaw in the implementation of OpenID Connect authentication flows, specifically concerning the validation of security claims within JSON Web Tokens. This issue stems from an incomplete verification process where the application fails to rigorously check essential identity assertions such as the issuer iss, audience aud, nonce, and expiration exp fields during the token exchange or introspection phase. In a standard OIDC implementation, these claims serve as fundamental trust anchors that ensure the authentication request originated from a legitimate provider, was intended for the specific relying party, is fresh to prevent replay attacks, and has not expired. By neglecting to validate these parameters, Dockhand inadvertently accepts tokens that do not strictly adhere to the expected security context of the requesting tenant.
This technical deficiency creates a severe privilege escalation pathway in multi-tenant environments where users share identity providers such as Microsoft Entra ID. An attacker who possesses administrative privileges within one tenant can exploit this lack of validation by crafting or manipulating authentication requests and associated tokens that mimic those generated for another tenant. Specifically, because the issuer claim is not verified against the expected domain of the target Dockhand instance, an admin in a separate organizational unit can generate valid-looking session tokens. Furthermore, the failure to validate audience claims allows these cross-tenant tokens to be accepted as legitimate access credentials for the victim organization's resources. The absence of nonce validation also removes protection against replay attacks, allowing previously captured or newly forged tokens to be reused effectively without detection by the authentication server.
The operational impact of this vulnerability is significant, enabling unauthorized administrative control over Dockhand environments belonging to other tenants sharing the same identity provider infrastructure. Once an attacker successfully authenticates using a manipulated token from their own tenant context, they are granted full administrator privileges within the victim's environment. This level of access allows for comprehensive data exfiltration, modification or deletion of critical application configurations, and potential lateral movement into connected systems if administrative credentials have broader permissions. The ability to recreate mapped admin groups further exacerbates the risk by allowing persistent backdoor access that can survive session expirations if not properly monitored. Such breaches compromise the core principle of multi-tenancy isolation, where data and operational boundaries between different organizations must remain strictly enforced regardless of shared underlying identity infrastructure.
To mitigate this vulnerability, immediate updates to Dockhand version 1.0.50 or later are required as these releases address the claim validation logic. In addition to upgrading, security teams should enforce strict OIDC compliance by ensuring that all relying parties validate the iss claim against a whitelist of trusted issuers and verify that the aud claim matches their specific client identifier. Implementing robust nonce generation and verification mechanisms is essential to prevent replay attacks during authentication flows. Organizations utilizing shared identity providers like Microsoft Entra ID should also review their conditional access policies and token lifetime settings to minimize the window of opportunity for exploitation. Regular security audits focusing on authentication middleware configurations can help identify similar oversights in claim processing logic across other integrated services within the enterprise ecosystem.
From a classification perspective, this vulnerability aligns with CWE-287 Improper Authentication as it involves failing to properly verify identity credentials during the login process. It also relates closely to CWE-613 Insufficient Session Expiration which is implied by the lack of expiration validation and replay protection. In terms of attack tactics, this scenario maps directly to MITRE ATT&CK technique T1078 Valid Accounts where adversaries leverage legitimate credentials obtained from another part of the environment to gain unauthorized access. The specific method of exploiting shared identity provider misconfigurations highlights the importance of strict tenant isolation policies in cloud-native applications that rely on federated authentication services for user management and authorization decisions.