EUVD-2026-53320
GHSA-v65x-57rf-cpg3
Severity by source
AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N
Network-accessible V1 API requires only low-privilege authenticated ASSISTANT role; no scope change; pure integrity impact via signature record forgery with no confidentiality or availability consequence.
Primary rating from Vendor (309f9ea4-e3e9-4c6c-b79d-e8eb01244f2c).
CVSS VectorVendor: 309f9ea4-e3e9-4c6c-b79d-e8eb01244f2c
Lifecycle Timeline
1DescriptionCVE.org
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.
AnalysisAI
Signature forgery in Documenso's V1 sequential-signing workflow allows an authenticated ASSISTANT-role recipient to complete signature fields owned by any co-recipient with an equal or later signing order, bypassing per-field ownership authorization entirely. The flaw resides in sign-field-with-token.ts, which upserts Signature records against the target field's recipientId without validating field type or ownership - a guard that Documenso's own V2 path (sign-envelope-field.ts) explicitly enforces and that the project's test suite comments confirm is absent from the V1 path. No public exploit code has been identified at time of analysis, but exploitation requires only low-privilege authenticated access as a named ASSISTANT recipient within a targeted document envelope.
Technical ContextAI
Documenso is an open-source electronic document signing platform (github.com/documenso/documenso). The vulnerability resides in the V1 server action sign-field-with-token.ts, which handles field completion during the live document-signing UI flow. When an ASSISTANT recipient submits a field completion request, the handler performs a database upsert of a Signature record using the target field's recipientId without verifying that (1) the acting recipient owns the field, or (2) the field type is SIGNATURE. CWE-863 (Incorrect Authorization) precisely describes this root cause: the system does perform a partial authorization check - validating that the target recipient has an equal or later signing order - but omits the ownership and field-type checks necessary to prevent role abuse. The V2 signing path (sign-envelope-field.ts) explicitly blocks ASSISTANT recipients from completing SIGNATURE fields, and Documenso's own test suite comments acknowledge this guard is absent from the V1 path, confirming the inconsistency is a recognized architectural gap rather than an unknown omission.
RemediationAI
No vendor-released patch with a confirmed fix version has been identified at time of analysis - the sole reference is the upstream GitHub repository (https://github.com/documenso/documenso) without a linked advisory or release. The upstream fix requires adding field-type and recipient-ownership validation to sign-field-with-token.ts, specifically rejecting requests where the acting recipient's role is ASSISTANT and the target field type is SIGNATURE, mirroring the guard already present in sign-envelope-field.ts. Until a patch is released, organizations should restrict the ASSISTANT role to fully trusted internal users only, audit existing envelopes for unauthorized or unexpected ASSISTANT role assignments, and review completed documents for anomalous signing patterns. Disabling the ASSISTANT role feature entirely is the most reliable compensating control but eliminates legitimate delegation workflows. Disabling sequential signing in favor of parallel signing removes the ordering prerequisite but may not be operationally viable. Monitor the Documenso repository and issue tracker for patch releases and apply immediately upon availability.
Same weakness CWE-863 – Incorrect Authorization
View allSame technique Authentication Bypass
View allShare
External POC / Exploit Code
Leaving vuln.today