WotNot's open bucket: 346,000 passports and medical records with no password

What happened

WotNot, an Indian AI chatbot startup based in Ahmedabad, exposed a misconfigured Google Cloud Storage bucket that anyone could read without authentication. Researchers at Cybernews found the bucket held 346,381 files, including passport scans and identity documents, medical records, resumes, and travel itineraries. The exposure was reported on August 27, 2024. Notification attempts began September 9, but the company took more than two months to secure the data. WotNot said the bucket served free-tier users and that its policies "were modified to accommodate a specific use case" but that it "missed thoroughly verifying its accessibility, which inadvertently left the data exposed."

Root cause

A storage bucket holding highly sensitive personal documents was set to allow public, unauthenticated reads. The application worked — files uploaded, files retrieved — while the single security invariant that mattered, "only the owner can read their own documents," was never enforced or tested. The company's own explanation names the mechanism: a policy change loosened access and no one verified who could now reach the data. This is textbook security misconfiguration (OWASP A05) combined with missing access control on the object store.

How it would have been caught

A test that requests a known object URL with no credentials and asserts the request is denied would have flipped red the moment the policy was loosened. So would an automated configuration audit that enumerates buckets and fails the build if any bucket holding user data permits allUsers or allAuthenticatedUsers read access. The reproduction is a single unauthenticated GET against a customer's file.

How to prevent it

• Deny-by-default on every storage bucket. Uniform bucket-level access with no public principals; grant reads only through signed, expiring URLs scoped to the owner.
• Run a continuous config scan that fails when any bucket containing PII/PHI is world-readable — and gate deploys on it.
• Treat "a use case needed looser access" as a red flag requiring an explicit access-control test, not a quiet policy edit.

The Breachwire test (red → green)

From an unauthenticated client, request a user's stored document by URL and confirm it returns the file — the RED control proving the bucket is open to the world. Remove all public principals and serve files only via owner-scoped signed URLs, then confirm the same anonymous request now returns 403 / access denied, while the legitimate owner still retrieves their own file through the app.