CVE-2026-92794 in OpenSign
Summary
by MITRE • 09/16/2026
OpenSign through 2.41.3 fails to validate caller identity in the getDocument cloud function when one-time-password verification is disabled. Attackers can supply a document identifier from guest signing links to retrieve complete document details including all signers' information, sender identity, and valid download tokens without authentication.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/16/2026
The vulnerability identified in OpenSign versions up to 2.41.3 represents a critical failure in access control mechanisms within the application's cloud-based architecture. Specifically, the getDocument function lacks proper validation of the caller's identity when one-time-password verification is disabled for signing workflows. This architectural flaw allows an unauthenticated or unauthorized actor to bypass intended security boundaries by exploiting the way document identifiers are processed and resolved against user permissions. The core technical issue stems from a logic error where the system fails to distinguish between requests originating from authenticated session contexts versus those derived from public-facing guest links, leading to a breakdown in authorization checks that should restrict access to sensitive metadata.
From a technical perspective, this flaw constitutes an Insecure Direct Object Reference vulnerability as defined by CWE-639. The application exposes internal object references—specifically document identifiers associated with signing workflows—to the client side without enforcing strict ownership verification on every API call. When one-time-password authentication is disabled, which is often done for convenience in certain enterprise or high-volume signing scenarios to reduce friction for signers, the security model incorrectly assumes that possession of a valid document ID from a guest link implies sufficient authorization to view full details. This assumption ignores the principle of least privilege and fails to verify whether the requesting entity has legitimate administrative rights or ownership over the specific document instance being queried.
The operational impact of this vulnerability is severe due to the sensitivity of the data exposed. An attacker who obtains a valid document identifier from any guest signing link can retrieve comprehensive details about that document. This includes personally identifiable information of all signers, such as names and email addresses, which violates privacy regulations like GDPR or CCPA depending on jurisdiction. Furthermore, the exposure of sender identity compromises organizational integrity by revealing internal personnel involved in sensitive transactions. Most critically, the disclosure of valid download tokens allows an attacker to access the actual signed documents themselves. These tokens act as temporary authentication credentials that grant full read and potentially write access to the document content, effectively rendering any other security controls around the signing process moot for those specific files.
This vulnerability aligns with several tactics in the MITRE ATT&CK framework, particularly T1078 Valid Accounts if an attacker leverages stolen tokens or T1530 Data from Cloud Storage Object Discovery where they enumerate and access cloud-based data objects without proper authorization. The exploitation path is straightforward: once a guest link is obtained through phishing, social engineering, or public exposure of URLs, the associated document ID can be extracted and fed into the vulnerable getDocument endpoint. Since no additional authentication factors are required when one-time-password verification is disabled, the attack requires minimal effort to achieve full data exfiltration capabilities for any document configured with this specific workflow setting.
Mitigation strategies must address both immediate remediation and long-term architectural improvements. The primary fix involves patching OpenSign to version 2.41.4 or later where this identity validation logic has been corrected to enforce strict ownership checks regardless of the one-time-password configuration state. For organizations unable to immediately upgrade, a critical compensating control is to ensure that one-time-password verification remains enabled for all signing workflows involving sensitive data. Additionally, administrators should review access logs to identify any instances where document download tokens were accessed by unauthorized parties and rotate those tokens if compromise is suspected. Implementing stricter input validation on the getDocument endpoint to verify that the requesting user's session matches the document owner or authorized signer list would also mitigate this risk in custom deployments.