CyphrQ
Menu

302.ai Data Leak: 17.6 Million Files in an Open Azure Bucket

Cybernews says AI aggregator 302.ai left 17.6 million files, including chat logs, in a public Azure bucket. What is confirmed and what to check.

By CyphrQ.ai

Written with AI assistance and human editorial review. Every figure linked to its source.

Incident: August 20268 min read

What was the 302.ai data leak? Researchers at Cybernews report that 302.ai, an AI aggregator (one service that lets you use many AI models), left about 17.6 million files in a publicly reachable Azure storage bucket. They included chat logs, images, video, audio and documents. Cybernews says it saw no sign that anyone malicious accessed the data. It also cannot rule that out.

This is a case file. It sets out what the researchers reported, what is unconfirmed, and what to check if your team uses AI tools that sit between you and the model.

Case file

Field Value
Organisation 302.ai, an AI aggregator (a service that gives access to many AI models in one place)
Region Not stated in the sources I read
Discovered 2 August 2026, per the Cybernews disclosure timeline (Cybernews)
Reported to the company 11 August 2026 (Cybernews)
Seen closed 8 September 2026, per the same timeline
Published 21 October 2026, as reported by Insurance Business
What was exposed An unsecured Azure storage bucket, reachable without logging in
Size About 17.6 million files, about 22.72TB (Cybernews)
Data types Chat logs, generated images, video, audio, documents; some chats held personal details
People affected Not stated. Cybernews does not give a count of users
Malicious access Not confirmed. Cybernews reports no evidence of it
Company statement None found in the sources I read
Status Bucket taken offline after Cybernews made contact

What did Cybernews find in 302.ai's storage bucket?

Cybernews reports that 302.ai's Azure storage bucket was open to anyone who found it. No password, no account. The data was just there.

The Insurance Business report of the findings gives the breakdown of what sat in the bucket:

Content Size or count (as reported)
Images about 9TB
Video about 7.7TB
Audio about 5.6TB
Chat logs (.json) more than 144,000
Zip archives of conversations, with attachments more than 26,000

The chat logs held prompts, replies, timestamps, which model was used, token costs and metadata. Documents in the bucket included files users had apparently uploaded to be analysed, plus research material on language model development. Some chats held personal details such as birth dates, contact information and home addresses, which users likely typed in themselves (Insurance Business).

One more detail matters for business readers. The bucket held conversations from a customer-service chatbot run by an unnamed sex doll maker. That means the exposed people were not only 302.ai's own users. They were also customers of a company that had built a chatbot on top of the aggregator.

Was the 302.ai data accessed by attackers?

Not confirmed. This is the point most worth getting right.

Cybernews says it saw no sign that bad actors viewed or copied the data. That statement is narrow. It means the researchers found no evidence. It does not mean the data was never accessed. Insurance Business reports Cybernews's caution that if its researchers could find the bucket, others may have as well.

Whether anyone else did is not known, and I won't guess. I also found no way, from the public record, to tell who else saw the data or whether they did. Only 302.ai's own storage logs could answer that, if they were enabled and kept.

How long was the 302.ai bucket exposed?

Not known. Three dates are reported: found on 2 August, reported on 11 August, and seen closed on 8 September 2026. That is 37 days from discovery to closure, and 28 days from the report to the closure. We don't know when the bucket first became public, so the real exposure window could be longer.

How did 302.ai respond?

Cybernews says the data was taken offline after it contacted the company. It says it asked 302.ai for comment. The coverage I read reports no reply, and I found no public statement or incident notice from 302.ai. As of 25 October 2026, I can't tell you what 302.ai says about cause, duration or notification of affected users.

Why does an AI aggregator leak matter for your organisation?

An aggregator sits in the middle. Your staff or customers send prompts to it, it forwards them to one or more model providers, and it often stores the conversation. Your data protection terms with the model vendor don't automatically apply to that middle layer.

This is the same failure pattern as the DeepSeek database exposure in 2025: the weak point was not the AI model but the storage behind it.

In practice, three things follow:

  • Chat logs are records. A prompt can contain a contract clause, a customer address or a medical detail.
  • Files travel with chats. Anything attached to a conversation may be stored next to it.
  • Your customers' chats are your problem. If you put a chatbot on a third-party platform, the platform's storage holds your customers' words.

Going deeper: for security and IT teams

Threat model. Anyone who can reach an anonymous endpoint can read it. The actor needs no credentials and no exploit. What they get is whatever the service stored: here, prompts, replies, attachments and metadata. MITRE classes this as T1530 Data from Cloud Storage, a Collection technique (TA0009), and notes that "there have been numerous incidents where cloud storage has been improperly secured." Exposed storage is found by scanning, not by targeting you, which is why a short exposure window is still a risk. I'm not describing discovery methods; the defensive point is that you should assume anything public gets found.

How Azure Blob anonymous access works. Cybernews calls it an Azure storage bucket. The sources I read do not say which access level was set, so I describe the mechanism, not this specific account. Two settings decide anonymous access, per Microsoft Learn:

  1. An account-level setting. When anonymous access is disallowed, "Azure Storage rejects all anonymous read requests against blob data" and it overrides every container setting.
  2. A container-level access level: Private (the default), Container, or Blob. A container is only anonymously readable if the account allows it and the container is set to one of the public levels.

Microsoft states that anonymous access is prohibited by default. So an open container is a deliberate or accidental change by someone with rights to make it.

Controls with specifics.

  • Set the account property AllowBlobPublicAccess to False. In the portal: storage account, Settings, Configuration, Allow Blob anonymous access set to Disabled.
  • Enforce it with Azure Policy using the deny effect on Microsoft.Storage/storageAccounts/allowBlobPublicAccess, with audit first to see what breaks. Microsoft publishes both rule definitions.
  • Find every account that still allows it with an Azure Resource Graph query on Microsoft.Storage/storageAccounts, projecting allowBlobPublicAccess. A blank result means the property was never set. Treat blank as a finding.
  • Restrict who can change the setting. It needs Microsoft.Storage/storageAccounts/write, held by Owner, Contributor and Storage Account Contributor.
  • From MITRE's mitigations for T1530: M1047 Audit (review storage permissions regularly), M1022 Restrict File and Directory Permissions, M1018 User Account Management (temporary credentials over permanent ones), M1037 Filter Network Traffic (IP allowlisting).

Detection and evidence. Turn on a diagnostic setting that sends storage logs to a Log Analytics workspace. Then query anonymous traffic with StorageBlobLogs | where AuthenticationType == "Anonymous". In Metrics Explorer, filter the Blob Transactions metric by Authentication = Anonymous and alert on it. Without logs, you can't answer the question the 302.ai case leaves open: did anyone else read it?

Logging and minimising AI chats. Decide what an AI service may keep.

  • Ask what is stored (prompts, replies, attachments, metadata), where, how long, and who can read it.
  • Prefer zero or short retention for business use, and ask for deletion evidence.
  • Strip personal data before prompts leave your network where the use case allows it.
  • Keep your own record of which tools staff use, so a leak notice can be matched to your exposure.

Vendor due diligence for AI aggregators. Ask for: the list of sub-processors and model providers behind the service; where the storage sits; whether public access is blocked at account level; how long logs and files are kept; how they would notify you of an exposure, and in what time; and whether you can export or delete your data. A SOC 2 or ISO 27001 report is a start. Ask what the scope covers.

What should you check after the 302.ai data leak?

  1. List every AI tool and aggregator your staff and customer-facing chatbots use, including free ones.
  2. For each, find out what chat history and uploaded files it keeps, and for how long.
  3. Ask each vendor whether public access to its storage is blocked at account level, and how it would tell you about an exposure.
  4. In your own Azure estate, check every storage account for anonymous access and set the account-level block.
  5. Turn on storage logging, and test that an anonymous request shows up in it.
  6. Write down a rule for what staff must not paste into any AI tool.

Learn more

Key takeaways

  • Cybernews reports that 302.ai left about 17.6 million files (about 22.72TB) in a public Azure storage bucket, including more than 144,000 chat logs.
  • Discovery was 2 August 2026, the report to the company was 11 August, and the bucket was seen closed on 8 September.
  • Malicious access is not confirmed. Cybernews found no evidence of it, which is not the same as evidence that it did not happen.
  • The number of affected users, the cause, and the start of the exposure are not stated in the sources I read. I found no public statement from 302.ai.
  • An AI aggregator is a data store as well as a gateway. Ask what it keeps, where, and for how long.
  • Block anonymous blob access at account level, log it, and test the control.

Sources