CVE-2026-71247 in Documenso
Summary
by MITRE • 08/05/2026
Documenso's sign-field-with-token.ts, used by the live document-signing UI, allows a recipient with the ASSISTANT role to fetch and complete fields belonging to any later-or-equal-order, not-yet-signed recipient in the same envelope, with no restriction on field type. The handler upserts a Signature record tied to the target field's recipientId with no check that field.type is SIGNATURE and the acting recipient owns it. A newer V2 signing path (sign-envelope-field.ts) explicitly blocks assistants from completing SIGNATURE fields, and the project's own test suite comments confirm this guard is absent from the V1 path used here. In a sequential-signing document, an assistant recipient can therefore forge another signer's signature field.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 08/05/2026
This vulnerability exists in Documenso's document signing infrastructure where the sign-field-with-token.ts handler fails to properly validate field access permissions for users with ASSISTANT roles. The flaw stems from inadequate authorization checks that allow assistants to manipulate signature fields belonging to other recipients within the same envelope, regardless of their order in the signing sequence or whether they have signed yet. The system's design permits any assistant to fetch and complete fields for subsequent recipients without validating that the field type is specifically SIGNATURE or that the acting recipient has legitimate ownership over the target field. This represents a critical authorization bypass vulnerability that directly violates principle of least privilege and access control mechanisms.
The technical implementation flaw occurs in the signature record upsert operation where the system creates a new Signature record tied to the target field's recipientId without performing necessary validation checks. According to CWE-285, this constitutes an improper authorization condition where the system fails to verify that the requesting entity has adequate permissions for the requested action. The vulnerability is particularly dangerous because it operates within the sequential signing context where recipients are expected to sign in a specific order, and the assistant role should not be permitted to act on behalf of other signers. This flaw creates an attack vector where malicious assistants can manipulate document authenticity by completing signature fields intended for other parties.
The operational impact of this vulnerability extends beyond simple unauthorized access to encompass complete document forgery capabilities within sequential signing environments. An assistant recipient can effectively impersonate any subsequent signer in the envelope, potentially altering the document's meaning or validity by inserting forged signatures. This breach compromises the fundamental integrity and authenticity guarantees that digital signatures are designed to provide, making it possible for attackers to manipulate signed documents without detection. The vulnerability affects all sequential signing scenarios where multiple recipients are involved, potentially impacting sensitive legal agreements, contracts, and official documents.
The mitigation strategy requires implementing comprehensive field type validation and recipient ownership verification within the sign-field-with-token.ts handler. This includes adding explicit checks to ensure that only users with appropriate permissions can complete SIGNATURE fields, and validating that the acting recipient has legitimate authorization to act on behalf of the target field's owner. The system should enforce role-based access controls that prevent ASSISTANT users from completing signature fields entirely, similar to how the V2 signing path (sign-envelope-field.ts) correctly implements this restriction. Additionally, implementing proper logging and monitoring for signature field modifications will help detect unauthorized access attempts and provide audit trails for forensic analysis.
This vulnerability aligns with ATT&CK technique T1566 which covers credential harvesting through social engineering and privilege escalation methods. The flaw enables an attacker with minimal privileges to escalate their access level within the signing process, potentially leading to broader system compromise. Organizations should consider implementing additional security controls such as multi-factor authentication for document signing operations, enhanced monitoring of signature field modifications, and regular security assessments of their digital signature infrastructure to prevent exploitation of similar authorization bypass vulnerabilities. The presence of this flaw in a production system highlights the critical importance of comprehensive testing and validation of access control mechanisms before deployment.