CVE-2026-53547

This CVE exposes a dangerous pattern: treating database export as a routine user utility rather than a high-privilege operation requiring explicit scope enforcement. The vulnerability isn't a missing authentication check—it's a scoping assumption that failed silently. The developer intended a user-scoped export, but bundled the global settings table because 'settings feel like user data.' That category error was baked in at design time, before any code was written, which is exactly why it left no commit trace. You can't diff your way out of a conceptual mistake. The critical architectural failure: password reset tokens were stored persistently in a settings table alongside configuration data. Reset tokens are session-equivalent secrets—they should be ephemeral, purged immediately after use or kept in memory-only. Their persistence in a table named 'settings' signaled they were user-preference data, not security-critical artifacts. The table schema itself performed the category error: it offered no metadata distinguishing high-severity data from configuration. The exploit path is chilling in its simplicity. A low-privileged user exported the database through a normal application feature, obtained admin reset tokens from the global settings table, and completed the password reset flow. The application worked exactly as designed—the design assumptions were wrong. This required no broken code, no race condition, no timing vulnerability. Just 'normal flow' with stolen tokens. What to check in your systems: Audit what tables your export endpoints can reach and ask whether any contain session-equivalent artifacts—reset tokens, session identifiers, API keys—that should never reside in user-accessible exports. The fix likely scoped the export more carefully, but verify it didn't just relocate the tokens rather than removing them from persistent storage entirely. If reset tokens are still database-resident, the vulnerability class persists in different form. The deeper question: should database export require elevated privileges with explicit data whitelisting, rather than operating on implicit 'user data' buckets? And should any table containing reset tokens be architecturally treated as a session store—requiring equivalent access controls and isolation?

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