CVE-2026-49989 is an authorization bypass in CrateDB's HTTP blob API. The SQL interface to blob tables correctly enforces AccessControl and returns MissingPrivilegeException when a user lacks permissions. The HTTP blob API authenticates the requestor but never invokes AccessControl at all — an authenticated user with zero grants can read, write, or delete any blob table in the cluster.
The practical blast radius is wider than the low EPSS suggests. This is not a vulnerability for external attackers exploiting unauthenticated networks. It is an insider-threat and credential-compromise vulnerability: any authenticated user, including low-privilege service accounts or compromised credentials, effectively gains admin-level access to all blob storage. Treating authentication as an attenuator here is dangerous. The HTTP path looked secured — it authenticated — which actually suppresses the paranoia that would catch the gap.
The root cause is not complex. The HTTP blob API predated AccessControl's existence or was added before security mandates required all paths to route through it. The SQL path received proper security scrutiny over time; the HTTP path did not. This is the predictable output of organizations that build security controls for the paths they actively think about and never build a forcing function to retroactively audit legacy entry points.
The fix is trivial: route the HTTP blob API through AccessControl. But the existence of a trivial fix doesn't make this a minor issue — it makes it a damning example of how authorization gaps go unnoticed. There's no test suite that verifies 'authenticated + no grants = HTTP 403,' and that's exactly why this persisted.
For defenders: audit your CrateDB deployments for blob table usage, verify that HTTP blob endpoints are either behind proper network isolation or are accessed only by fully-trusted identities, and treat any HTTP API that exposes the same resources as a SQL interface as a priority for authorization parity verification. The low EPSS likely reflects that blob tables are niche and deployments are often legacy configurations that nobody actively audits — precisely the 'sediment layer' where authorization failures hide longest.