CVE-2026-72544

The CVSS 7.5 score for CVE-2026-72544 fundamentally misrepresents this vulnerability. This isn't a medium-severity data integrity flaw—it is an existential threat to the non-repudiation infrastructure that makes digital signatures legally defensible. The core issue: OpenSign's cloud function accepts viewer identity and IP address as caller-supplied parameters without deriving them from the authenticated security context. That architectural decision transforms the vulnerability from a patchable bug into a retroactive provenance crisis. When a signing platform accepts identity claims from callers rather than deriving them from authenticated context, every historical audit entry becomes suspect retroactively. Even if version 2.37.1 patches this specific vector, any document signed under the vulnerable architecture carries an unresolvable ambiguity: how do you prove which entries were legitimate versus fabricated during the exposure window? Non-repudiation isn't merely a technical property—it requires audit trails to function as trustworthy evidence in legal proceedings. An adversary who exploits this during litigation doesn't need to breach the signing ceremony itself; they can retroactively alter the documentary evidence of what happened. The attack requires no credentials, no pre-existing access, and no specialized knowledge beyond understanding that this endpoint exists. This vulnerability follows a documented recurrence pattern in document management systems—CVE-2019-16147, CVE-2021-21972, and Confluence injection series all share the same failure mode where caller-supplied metadata gets accepted without verification. The recurrence isn't coincidental: the platform's security primitives make deriving identity from authenticated context harder than accepting caller attestation. The insecure pattern remains the path of least resistance because tooling, documentation, and examples all steer toward caller-supplied identity. The remediation posture differs sharply between theoretically forgeable versus actively exploited audit entries. Legal systems typically require demonstrated exploitation and demonstrable harm before invalidating signed documents. If this was never exploited before disclosure, past documents may be legally intact even if technically suspect. However, the patch itself creates a demarcation point that defense attorneys will weaponize—post-patch audit logs showing anomalous entries won't indicate active exploitation, but rather that the platform knew about the compromise window. For defenders: prioritize upgrading to 2.37.1 immediately, but recognize that patching alone doesn't restore trust in historical signatures. Implement tamper-evident logging with cryptographic continuity proofs for post-patch state. Treat every document signed under vulnerable versions as potentially under legal hold until the architecture can provide verifiable audit integrity. The real remediation timeline isn't patch urgency—it's the trust half-life of documents signed under this architecture, and that timeline extends indefinitely if cryptographic continuity cannot be demonstrated.

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