CVE-2026-75106

CVE-2026-75106 is a category error, not a configuration mistake. The developer used Hashids — a library designed to generate URL-friendly identifiers like YouTube video IDs — to create submission secrets. Hashids is explicitly not a cryptographic primitive. Its empty default salt isn't an oversight; it's consistent with its design goal of producing deterministic, shareable short codes. The vulnerability exists because someone chose a cosmetic obfuscation library where a cryptographic random token was required. Even if someone adds a salt to Hashids now, the fundamental problem remains: Hashids with a salt is still a deterministic encoder, not a cryptographic secret. An attacker who knows the form ID sequence can still compute every submission secret in the system. That's not a narrow auth bypass — that's complete data plane compromise with zero per-user friction. The fix is not to configure Hashids correctly. The fix is to replace it entirely. Use `bin2hex(random_bytes(16))`, `Defuse\Key\Key::createSafeKey()`, or your framework's built-in secure token generator. Then audit the rest of the codebase for the same pattern — if a developer reached for Hashids for secrets once, the same reasoning likely produced other category errors. For defenders managing existing OpnForm instances: this vulnerability has a 9.1 CVSS and affects submission secrets, meaning respondent data is directly exposed. Because OpnForm is self-hostable, every unpatched instance is a known target. The discovery-to-disclosure window matters here — with auth bypass at this severity, exploitation typically begins within hours of publication. Check your deployed version immediately. If you're on a vulnerable release, assume exposure and review access logs for patterns consistent with sequential form ID enumeration.

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