MetaCity's Identity Verification Data — Collected From Users Who Completed Age Verification for Adult-Gated Spaces — Was Accessible via an Unauthenticated Public API Endpoint for an Unknown Period

A security researcher has disclosed that MetaCity's identity verification records — the real-world identity data collected from users who completed the platform's age verification process to access adult-gated virtual spaces — were accessible through an unauthenticated public API endpoint that required no credentials to query. The endpoint returned verification records including submission timestamps, verification status, and in some cases document type metadata for any account ID passed to it. The researcher estimated the endpoint had been publicly accessible for at least several weeks based on the API's version history. MetaCity patched the endpoint after being notified and has confirmed the vulnerability was real.

Identity verification data occupies a different category of sensitivity than most MetaCity user information. The platform collects it specifically because it is tied to real-world identity — users who completed age verification submitted documentation that links their avatar account to their actual person. The API endpoint that exposed this data did not return the documents themselves, but it did return confirmation that a specific account had submitted identity documentation, the method used to verify, and in some cases the document category. For a platform where many users maintain a deliberate separation between their avatar identity and their real-world identity, confirmation that a specific account had submitted real-world ID documentation — and what kind — is information with meaningful exposure consequences independent of what the documents themselves contained.

The unauthenticated design of the endpoint is the technical failure at the center of this disclosure. An API endpoint that returns identity verification records requires, at minimum, authentication to confirm the requester is authorized to access that data — and ideally, authorization checks to confirm they are entitled to access records for the specific account they are querying. The exposed endpoint had neither. It was accessible with a standard HTTP request, required no API key or session credential, was not rate-limited to prevent bulk querying, and returned verification data for any account ID provided. This is not a subtle configuration error — it is a missing authentication layer on a data type that regulatory frameworks in multiple jurisdictions classify as sensitive personal information. MetaCity has not explained how the endpoint reached production in this state or how long it remained there.

The Endpoint Had No Lock. The Data Was Real-World Identity. Anyone Could Query It.

MetaCity's statement that it has 'no evidence the vulnerability was exploited by malicious actors' is a formulation that warrants scrutiny in the context of what the platform has disclosed about its logging. If MetaCity has query logs for the endpoint covering the exposure window, reviewing those logs for anomalous access patterns would be a straightforward investigative step. If MetaCity does not have such logs — if the endpoint was not instrumented with access monitoring during its exposure period — then the statement that there is no evidence of exploitation is accurate but describes an absence of evidence rather than evidence of absence. MetaCity has not stated whether logs exist, whether they were reviewed, or what the review found. The security researcher who discovered the endpoint has noted that, without rate limiting, a complete bulk query of all 340 million MetaCity account IDs would have been technically feasible during the exposure window.