CVE-2026-49989

**Component:** `io.crate.protocols.http.HttpBlobHandler` **Affected:** verified against CrateDB 6.2.7 (latest at time of report; the bug has existed since the blob HTTP handler was introduced) **Impact:** any authenticated user can read or delete any blob whose SHA-1 digest they know, and can plant new blobs unconditionally, in any blob table, regardless of `GRANT`s. --- ## Summary CrateDB has two ways to access blob storage: SQL (`SELECT ... FROM blob.<table>` and friends) and the blob HTTP API (`GET|PUT|DELETE /_blobs/{table}/{digest}`). The SQL path goes through `AccessControl`, which is what enforces privilege grants; that's why `SELECT digest FROM blob.secret_blobs` fails for a user who has no grants on the table. The HTTP path authenticates the request but never asks `AccessControl` whether the authenticated user is allowed to touch the table. So a user with no grants gets `MissingPrivilegeException` from SQL and `200 OK` plus the blob bytes from `GET /_blobs/secret_blobs/<digest>`. ## Where it lives `server/src/main/java/io/crate/protocols/http/HttpBlobHandler.java`. The dispatcher: ```java // HttpBlobHandler.java:176 private void handleBlobRequest(@Nullable HttpContent content) throws IOException { if (possibleRedirect(index, digest)) { return; } if (method.equals(HttpMethod.GET)) { get(index, digest); reset(); } else if (method.equals(HttpMethod.HEAD)) { head(index, digest); } else if (method.equals(HttpMethod.PUT)) { put(content, index, digest); } else if (method.equals(HttpMethod.DELETE)) { delete(index, digest); } else { simpleResponse(HttpResponseStatus.METHOD_NOT_ALLOWED); } } ``` No `AccessControl` reference, no privilege check. Each branch goes straight to the relevant blob op (`get`/`head`/`put`/`delete`); for example: ```java // HttpBlobHandler.java:287 private void get(String index, final String digest) throws IOException { if (range != null) {