CVE-2026-72549 is an account enumeration vulnerability in OpenSign's Parse cloud function getUserId. The function accepts an email address and returns the corresponding internal user ID. In a document signing platform, this mapping is sensitive intelligence—it reveals which individuals have accounts, enabling attackers to enumerate executives, legal contacts, and other high-value targets for follow-on document fraud.
This is not a framework bug. Parse Cloud Functions do expose an authentication context—the developers simply didn't use it. The getUserId function represents an affirmative architectural choice to expose an email-to-ID mapping in an application where account existence itself is operational intelligence. A security-aware code review should have flagged this immediately: what legitimate workflow requires mapping arbitrary emails to IDs without the requester already being authenticated? The only use case is unauthenticated email validation—essentially "check if this person can receive documents here." That's the enumeration primitive.
The deeper problem is that this function likely predates OpenSign's exposure to external attackers. It may have been written when the Parse API sat behind a network gateway or when the application was an internal tool. As the platform scaled, the function remained but never got re-evaluated. This is the forgotten-code threat: the code didn't change, but the context around it did—from internal plumbing to externally reachable API.
CVSS 5.3 misrepresents the actual risk. In a signing platform, account enumeration is the blast primer for a failure cascade: enumerate targets, craft convincing impersonation documents, exploit trust relationships, execute fraud with legal enforceability implications. The MEDIUM score creates institutional permission to deprioritize, but every week of unpatched enumeration is a week attackers can build target lists.
Remediation has two layers. First, add authentication to getUserId—require a valid session before resolving email to ID. Second, audit whether the function should exist at all. If the platform already handles recipient IDs for documents, the public-facing email-to-ID lookup is almost certainly redundant. Remove it rather than harden it. Third, treat all identifier-to-account mappings as first-class sensitive data regardless of whether they "modify" anything—lookup functions are enumeration primitives, not harmless plumbing.