The Aiven SQL query optimizer accepts queries without authentication and stores them so any authenticated user can retrieve another user's SQL by optimization ID, leaking table structures, column names, and business logic.
The Aiven SQL query optimizer endpoints (/v1/pg/query/optimize and /v1/mysql/query/optimize) accept SQL queries and store them server-side without requiring any authentication token. A stored optimization is then retrievable by any authenticated user via /v1/pg/query/optimize-by-token using only the optimization_id UUID, with no ownership check. This produces a two-part finding: missing authentication on the write path, and broken object-level access control on the read path.
The database metadata endpoints (/v1/pg/database-metadata-query and /v1/mysql/database-metadata-query) also return internal SQL that Aiven runs against customer databases without requiring authentication.
Any unauthenticated party can submit a SQL query to the optimizer and receive an optimization_id. Any authenticated Aiven user can then retrieve that stored query, including the original SQL, by calling the retrieval endpoint with the ID. SQL queries passed through the optimizer typically contain table names, column names, WHERE clause predicates with real values, and business logic. This is a cross-user information disclosure for anyone using the Aiven console's built-in query optimizer feature.
The internal metadata SQL returned by the unauthenticated metadata endpoints reveals the exact queries Aiven runs against customer databases to collect schema information, including which pg_catalog views and columns are inspected. This aids an attacker in understanding the platform's internal database inspection methodology.
The /v1/console/configuration endpoint returns feature flags and pricing variables without authentication.
The query optimizer endpoints were built as utility endpoints, likely intended for use from the Aiven console frontend, and authentication was not applied. The optimize-by-token retrieval path checks only that the caller holds a valid Aiven session token; it does not verify that the optimization was created by the same user or organization. The optimization_id is a UUID, so enumeration is impractical, but the issue is triggered in practice when any user stores a query without authentication and any other user obtains the ID.
The steps below submit a query without authentication, receive an optimization ID, then retrieve the stored query using a different account's token. All tokens have been replaced with placeholders.
Reported to Aiven through their bug bounty program. The recommended fixes are:
optimize-by-token endpoint should only return optimizations created by the requesting user or organization./v1/console/configuration.Additionally, the do_not_store parameter on the optimize endpoint should default to true so that queries are not persisted unless the user explicitly opts in.