Any authenticated Aiven user can enumerate the platform's customer list by checking whether a project name returns 403 (exists, not a member) or 404 (does not exist), since project names frequently match company names.
The GET /v1/project/{project_name} endpoint on api.aiven.io returns differentiated HTTP responses depending on whether the requested project name exists on the platform. An existing project the requester does not belong to returns HTTP 403 with the message "Not a project member". A project name that does not exist at all returns HTTP 404 with "Project does not exist". Because Aiven project names frequently correspond to company or organization names, any authenticated Aiven user can determine which organizations are Aiven customers by iterating over a list of company names.
An attacker with any valid Aiven account can enumerate Aiven's customer base without elevated privileges. The information reveals which organizations use Aiven for their database infrastructure, enabling: - Competitive intelligence gathering (which companies use Aiven) - Targeted supply chain attacks against confirmed Aiven customers (for example, crafting Aiven-themed phishing or exploiting Aiven API vulnerabilities specifically against those organizations) - Confirming whether a specific target organization is an Aiven customer before a more targeted campaign
Verification confirmed several well-known company names as existing projects (returning 403), while random strings returned 404. Only authenticated requests are needed; no special role or project membership is required.
The endpoint applies an authorization check before returning the project data, but it returns two distinct error codes: one for authorization failure (project exists, requester not a member) and one for a missing resource (project does not exist). The correct approach is to return the same 404 response for both cases when the requester does not have access, so that the existence of the project is not revealed. This is the standard pattern for resources requiring access control: unauthorized access to an existing resource should be indistinguishable from a missing resource.
The two requests below demonstrate the 403/404 differentiation. Replace the placeholder token with any valid Aiven API token.
Reported to Aiven through their bug bounty program. The recommended fix is to return a uniform 404 "Project does not exist" response for both non-existing projects and existing projects the requester does not have access to. This eliminates the oracle by making unauthorized access indistinguishable from a missing resource. The same pattern should be audited on any other resource endpoints that return differentiated access-denied versus not-found responses.