CVE-2026-71247

The vulnerability in sign-field-with-token.ts is straightforward: missing recipient-ownership validation allows ASSISTANT role users to complete signature fields on envelopes they don't own. That's the bug. But the more important question for your environment is why this code path still exists at all. sign-envelope-field.ts already implements the correct authorization check. The team knew how to secure this — they deployed a secure V2 handler alongside the vulnerable V1 path. This turns a simple missing-check vulnerability into a governance problem. Either V1 is dead code that should have been pruned during the V2 migration, or it's active code serving a use case that wasn't ported over. Neither scenario is acceptable without a documented security justification. Your immediate actions: first, determine whether sign-field-with-token.ts is actually being called in production traffic or if it's orphaned code. Second, clarify your ASSISTANT role population — are these internal staff with other authentication layers, or external parties whose access should be more restrictive? The blast radius of a compromised ASSISTANT account depends entirely on this. If V1 is active, treat it as a distinct trust boundary from V2 until proven otherwise, because the two handlers appear to enforce different authorization models. The CVSS of 6.5 reflects the missing check, not the deployment failure that left it exploitable. Prioritize retiring V1 if it's not needed — otherwise document exactly why this broader access model exists and treat it as a documented security boundary, not an accident waiting to be exploited.

Reviewed through automated stages and approved by a human before publication.