The SpeedX Leak: 840 Million Records, Photos of Your Packages, and One Wrong Setting

Somewhere in the United States, in a Microsoft Azure storage bucket that anyone with an internet connection could reach, there were 840 million files containing photographs of packages on doorsteps, scans of driver's licenses, customer addresses, and shipping labels going back months. The bucket was not hacked. There was no breach in the cybersecurity sense. It was just sitting there, configured to allow public access by anyone who happened to know the name of the container.

A team of researchers at Cybernews found it on March 13, 2026, while running automated scans for exposed cloud storage. They eventually traced the data back to SpeedX, an American last-mile delivery company that handles parcel deliveries for some of the largest online retailers on earth, including Shein, Temu, Amazon, and TikTok Shop. If you have ordered anything from any of those services in the past year and had it delivered in the United States, there is a meaningful chance your name, your address, and a photo of your front door sitting next to your latest delivery is somewhere in that 840 million file pile.

This is one of the largest delivery-sector data exposures ever discovered. It is also a textbook example of what is now the most common way major data leaks happen in 2026. Not sophisticated state-sponsored attacks. Not ransomware groups breaking through enterprise defenses. Just configuration settings nobody bothered to check, on cloud storage nobody thought to audit.

Here is exactly what was exposed, how it happened, why this pattern keeps repeating, and what it means for anyone who orders things online.

What happened: 840 million records, just sitting there

The discovery timeline is straightforward and depressing.

March 13, 2026. Cybernews researchers, conducting routine scans of publicly accessible cloud storage across the major providers, identified an Azure Blob Storage container associated with SpeedX. The container required no credentials. The team verified that the contents were authentic SpeedX delivery data, not test or dummy files. They began responsible disclosure efforts to alert the company.

Late March through May 2026. SpeedX worked through the disclosure process and eventually reconfigured the container to restrict public access. The exact date of remediation is not public, but the bucket was no longer accessible by the time Cybernews published thier findings.

May 28-29, 2026. Cybernews published the full report. The story spread through mainstream tech media over the following days. By June 1, it was being covered globally as one of the largest delivery-industry data exposures on record.

SpeedX's official response has been notably narrow. The company acknowledged the configuration issue but disputes the framing. In statements to multiple outlets, SpeedX has said that "limited responses to container metadata were possible with the previous configuration" but maintains that their investigation "has not identified any evidence of unauthorized access to customers' confidential data, any indication of data leakage, or any evidence" of malicious use. Researchers disagree, saying access to the full 840 million files required nothing more than knowing the bucket name.

What is not disputed is the contents of the bucket while it was open.

What was in the bucket

The exposed Azure storage was organized into 11 prefixes, which are essentially folders that group related files together. The breakdown is what makes this story particularly alarming:

The largest single category, the 618 million parcel photos, deserves particular attention. These are not abstract data records. They are actual photographs taken by drivers at the moment of delivery, showing packages sitting on doorsteps, in mailrooms, leaning against gates, or being handed to recipients. Each photo is essentially a confirmation that "this parcel arrived at this address at this time." Each one of those photos also captures, often inadvertently, the surrounding environment: the house number, the front door, sometimes the recipient, sometimes other parcels left at the same address, sometimes interior glimpses through open doors.

The 220 million PDF shipping labels are the next layer down. Each label contains a sender, a recipient, the recipient's full address, often a phone number, the package contents description (which can range from generic to surprisingly specific), and the route the package took through SpeedX's network.

The recipient PII section, while smaller in raw file count, is in some ways the most directly weaponizable. These are batch reports that aggregate customer names, addresses, and contact details in spreadsheet-style formats.

The driver records are the part that has received the least media attention but may be the most damaging on a per-record basis. SpeedX drivers had photos of their driver's licenses, internal identification, and other personal documents in the exposed bucket. A stolen driver's license image is essentially identity theft starter material.

The cause: it was always just a configuration setting

Here is the part that nobody likes talking about. The technical mechanism behind this leak is not interesting. It is not a vulnerability. It is not an exploit. It is a default-deny setting that was set to default-allow.

Microsoft Azure Blob Storage, like AWS S3 and Google Cloud Storage, lets administrators decide whether a given container is public or private. The default is private, which means access requires an authentication token. The choice to make a container public is a deliberate one. It is not something that happens accidentally in the modern UI of any major cloud provider, but it is something that happens routinely when:

• Developers set up "temporary" public access for testing and forget to revert it
• Storage gets migrated and the new container's permissions do not match the old one
• A vendor or contractor with admin access changes settings during an unrelated operation
• A subset of files needs to be public for a legitimate reason (CDN serving images, for example) and the entire container gets exposed instead of just the needed files held in a seperate location
• Auditing processes do not catch the misconfiguration because the bucket is not advertised anywhere

Once a container is public, anyone who can guess or discover the container name can list and download every file in it. There is no log of "unauthorized access" because every access is technically authorized. The container is configured to allow exactly this. That is what SpeedX is leaning on when they say their investigation found "no evidence of unauthorized access." Technically true. Practically meaningless.

To put this in perspective, the same configuration mistake has caused some of the biggest data exposures of the past decade. ParkMobile in 2021. Estée Lauder in 2020 (440 million records exposed). Various Indian banks, US healthcare providers, defense contractors, and at least 200 documented incidents per year across all three major cloud providers. The platforms have not changed. The pattern has not changed. People keep doing it.

SpeedX denies a breach, researchers disagree (the semantics debate)

This part of the story is worth understanding because it sets the template for how companies respond to these incidents in 2026.

SpeedX's position, in essence, is that no breach occurred because the data was not stolen in any active sense. Nobody broke in. No attacker exfiltrated records by exploiting a flaw. The configuration allowed access. Access happened (the researchers themselves accessed it to verify the contents). But there is no evidence of malicious access by anyone other than the researchers who responsibly disclosed it.

The Cybernews position, supported by most security professionals, is that "no evidence of malicious access" is essentially impossible to prove for a publicly accessible bucket. There are no access logs that distinguish "researcher" from "attacker" when the container is open to the world. Anyone, anywhere, with knowledge of the bucket name could have downloaded everything. The fact that we cannot find proof they did so is not the same as proof they did not. For a bucket of this size and sensitivity, the responsible assumption is that someone other than the researchers found it.

The semantics matter because they determine notification obligations. If a company can credibly claim "no breach occurred," many state and federal notification requirements do not trigger. Customers do not get notified. Regulators do not get involved. The company avoids the most painful consequences of a publicly disclosed breach. The data is still out there. The customers still face the same risks. But the legal and PR machinery treats it as a non-event.

This is a recurring pattern. Companies have learned that "no evidence of unauthorized access" is a defensible position even when the practical risk to customers is identical to a real breach. Until regulators or courts force a different standard, expect more of these incidents to be characterized as "configuration issues" rather than "breaches."

The SpeedX Leak: 840 Million Records, (AI grok image)

Why public cloud buckets are the #1 exposure vector in 2026

The SpeedX incident is not unique. It is part of a sustained pattern that has gotten worse, not better, as cloud adoption has matured. Some context on the trend:

In 2024, Hipshipper exposed 14 million shipping records through an open AWS bucket. The incident affected eBay, Amazon, and Shopify sellers and ran for at least a month before remediation. In late 2024 and into 2025, Coupang (the Korean e-commerce giant) revealed that 33.7 million customer records had been accessible through an exposed configuration starting in June 2024. Throughout 2025, dozens of smaller logistics, retail, and healthcare incidents followed essentially identical patterns: misconfigured cloud storage, discovery by researchers (or, less often, attackers), public disclosure, company response, sometimes a notification, often nothing.

A few things make this attack vector particularly attractive to attackers:

Discovery is automated. Tools like Shodan, BinaryEdge, Censys, and GrayhatWarfare continuously scan the internet for exposed services, including cloud storage. Finding an open bucket no longer requires luck. It requires running queries against existing databases that already index millions of misconfigured assets.

No attack signature. Because the access is technically authorized, traditional security tools do not flag it. There are no exploits to detect, no malware to scan for, no unusual network patterns to alert on. The data leaves the company through completely normal HTTPS connections to an endpoint that is supposed to be accessible.

Massive payloads. Cloud storage scales to petabytes. A misconfigured bucket can contain orders of magnitude more data than a traditional database breach. SpeedX's 840 million files would have been impossible to exfiltrate from an on-premise system in a single incident. From cloud storage, it is a download script.

Defender asymmetry. A company runs thousands of cloud resources across hundreds of services. A single misconfigured one is sometimes all an attacker needs. The defender has to be right every time. The attacker only has to find one mistake.

How attackers find these buckets

Understanding the discovery process is important for both potential victims and potential defenders. The techniques are mostly public knowledge and have been for years.

Automated cloud asset scanners. Services like Shodan and BinaryEdge index the entire IPv4 address space and a meaningful portion of IPv6, recording which services respond on which ports. Cloud storage endpoints (s3.amazonaws.com, blob.core.windows.net, storage.googleapis.com) have predictable URL structures. Automated scanners can enumerate millions of likely bucket names against these endpoints and record which ones respond with valid data.

Subdomain and asset enumeration. When attackers target a specific company, they start by mapping the company's digital footprint. Tools like Amass, Subfinder, and various commercial alternatives find subdomains, exposed services, and related cloud assets. A subdomain finder run against a target domain often reveals development environments, internal admin panels, and storage endpoints that the company never intended to be publicly enumerable. Many of those endpoints lead to misconfigured assets.

Reverse IP and infrastructure mapping. Companies that operate at SpeedX's scale typically use shared hosting infrastructure for some assets, dedicated infrastructure for others, and cloud-managed storage for bulk data. A reverse IP lookup on the company's known IP ranges can reveal sibling services and related domains that share hosting infrastructure, often leading attackers to less-protected adjacent systems.

OSINT through job postings and code repositories. Engineers post their work history on LinkedIn, sometimes mentioning specific cloud architectures. Code repositories on GitHub occasionally contain hardcoded bucket names, internal service references, or commented-out credentials. Attackers harvest these systematically to build target lists.

Pre-existing breach data correlation. When other companies in the same industry get breached, the leaked emails, employee names, and infrastructure references can be cross-referenced. If an attacker knows that SpeedX uses a particular SaaS vendor, and that vendor had a breach last year, the attacker may have credentials or internal documentation that points to SpeedX-specific resources.

None of these techniques are illegal. They are the same techniques security researchers use legitimately. The difference, again, is intent.

The downstream risks: package theft, stalking, social engineering

A leak of 840 million parcel records is not just a privacy abstraction. The data has real, practical, dangerous uses for anyone who acquires it.

Package theft becomes targeted. With photos of front doors, addresses, delivery times, and sometimes recipient names, package thieves can identify high-value targets. A photo showing an Amazon box from an expensive retailer, left outside a clearly upscale home, at a known delivery time, is essentially a thief's targeting checklist. Local porch piracy already costs Americans approximately $12 billion per year. Concentrated address data of this scale could push that meaningfully higher.

Stalking gains visual confirmation. For someone targeting a specific individual (ex-partner, harassment campaign, doxxing target), this data is uniquely useful. A photo of a package on someone's doorstep confirms that the person actually lives at the address listed on the shipping label, that the address is current and active, and gives a visual of the home for potential physical follow-up. Address verification through delivery photos is more reliable than most other OSINT methods.

Social engineering becomes hyper-specific. A scammer who knows you ordered a specific package from a specific retailer at a specific time can craft phishing messages that pass the gut-check test. "Hi, this is from [retailer], we noticed an issue with your recent order of [actual item]. Please click here to verify your address." This is exactly the kind of detail that makes recipients click. Traditional phishing tries to guess. This phishing knows.

Identity theft through driver license images. A photo of a driver's license is enough material to apply for credit accounts, open phone lines, or pass less-rigorous identity verification at financial services. SpeedX drivers, whose licenses were in the exposed bucket, face higher identity theft risk than the customers whose only exposure was an address.

Operational intelligence for organized crime. Knowing how a delivery operation handles its packages, where it concentrates volume, which routes are easiest to intercept, what its internal labeling looks like, all of this is useful for organized cargo theft groups. Cybernews specifically highlighted this risk: "Files related to parcel information paint a clear picture of how the company operates from the inside, allowing malicious actors to craft more targeted attacks and operational disruptions."

What customers can do (the unfortunate honest answer)

There is not much an individual customer can do retroactively about data that was already exposed for an unknown period. The realistic recommendations are about reducing future exposure and being alert for downstream attacks.

Watch for hyper-specific phishing in the coming weeks. If you receive an email or text referencing a specific package, retailer, or delivery time, treat it as suspicious by default. Even if the details look succesfully accurate. Go directly to the retailer's website to check order status, never click links in unsolicited messages.

Update shipping addresses for high-value orders. If you regularly receive valuable deliveries to a home where they sit unattended, consider switching to a parcel locker, an Amazon Hub, an Apple Store pickup, or a workplace delivery address. The exposed data set a target. Removing yourself from that target list is the best mitigation.

Be aware of strangers who reference your deliveries. If someone approaches you with surprising knowledge of recent orders, do not assume legitimate context. Sales scams sometimes use recent order details to create false familiarity.

Monitor your credit if you are a SpeedX driver. Driver license images in the wrong hands lead to identity-based fraud. Freezing credit, monitoring credit reports, and watching for new account openings is the standard response. The cost to attackers of opening accounts in your name is reduced significantly when they have a valid license image.

Use varied identifying information where possible. This is hard advice because most delivery requires a real name and a real address. But where alternatives exist (delivery to PO boxes, package services, work addresses), they reduce the correlation between your various online accounts.

What companies must do (the lessons that keep going unlearned)

For anyone reading this who works in IT, security, or operations at a company that uses cloud storage, the SpeedX incident is yet another data point in a pattern that should already be informing your practices. Five things matter most.

Continuous audit of cloud storage permissions. Every major cloud provider offers tools to automatically scan and report on public storage configurations. AWS has S3 Block Public Access and Trusted Advisor. Azure has Microsoft Defender for Cloud and Azure Policy. GCP has Security Command Center. These tools exist. They are usually free or cheap. They are routinely not enabled.

Default-deny for new resources. Storage that is created as part of automated infrastructure provisioning should default to private. Public access should require explicit human approval and should automatically expire if not renewed. The configuration drift that leads to leaks usually happens because public access is easier than private at the time of setup. Removing that ease eliminates the failure mode.

Periodic external attack surface assessment. A website security scanner run periodically against your own properties identifies exposed admin panels, misconfigured services, and assets you may not even know you own. Most companies are surprised by what shows up in their own attack surface scans. The first time you run one, you find things that should not be public. The third time, you find things you forgot existed.

Treat third-party SaaS as part of your attack surface. SpeedX is itself a third party to Amazon, Shein, Temu, and TikTok Shop. Those retailers' customer data is now exposed even though it was never on their systems. If you depend on a vendor that handles your data, their security is your security. Vendor risk assessment has to include cloud storage audits, not just questionnaires about whether they have a CISO.

Build a culture where "is this still needed to be public" is a regular question. The reason these misconfigurations persist is not technical. It is organizational. Public buckets that were set up for a legitimate temporary reason linger because nobody owns the responsibility of reverting them. A quarterly review of every public asset, with explicit justification required for keeping it public, catches drift before it becomes a 840 million file exposure.

Wrap up

SpeedX exposed 840 million records because someone, at some point, configured an Azure storage container to allow public access. That decision may have been intentional and legitimate at the time it was made. It became disastrous because nobody checked again, for weeks or months, whether the original justification still applied. By the time researchers found the bucket, the data inside had quietly grown to a scale that touched a meaningful percentage of every American who has ordered something online in the past year.

The pattern is now so well-established that the next major incident is essentially scheduled. Some other company, in some other industry, will discover that one of their cloud buckets has been quietly serving customer data to anyone who looked. The press cycle will run for a few days. The company will issue a careful statement about "configuration issues" and "no evidence of unauthorized access." Researchers will document the scope. Affected customers will get little to no notification. The cycle will repeat.

The lesson is not new. It has been the same lesson since the first big S3 bucket leak in 2017. What has changed is the scale and the consequences. 840 million files is no longer the kind of number that prompts industry-wide reform. It is the kind of number that prompts a paragraph in the quarterly cybersecurity recap. Until that changes, ordering a package from a major online retailer will continue to mean accepting that a photograph of your front door, your name, and your address probably lives in a cloud bucket that someone, somewhere, forgot to lock.

Sources include the original Cybernews research report on the SpeedX exposure, follow-up coverage by HackNotice, DigitalShield, and TEISS, and SpeedX's public statements as quoted by multiple outlets between May 28 and June 1, 2026. Technical context on cloud storage misconfiguration patterns draws on publicly documented incidents going back to 2017.