Cloudflare has patched a vulnerability in its Containers product that could have allowed a paying customer to pull residual data out of disk storage blocks previously used by a different tenant. The company disclosed the issue on September 24, three weeks after security researcher Oren Yomtov from the firm Accomplish filed a report through Cloudflare's HackerOne bug bounty program.
The flaw was rooted in how Cloudflare configured the Linux storage subsystem underpinning its container infrastructure. Cloudflare Containers run each workload inside a dedicated virtual machine powered by the Firecracker virtual machine monitor. Each VM gets a writable root disk backed by Linux device mapper thin provisioning, known as dm-thin, a storage technology that allocates physical disk space on demand rather than upfront. When a container's thin volume was deleted, the physical 64 KiB blocks it had occupied were handed back to a shared pool that served workloads from multiple customer accounts.
The problem was a single configuration option: `skip_block_zeroing`. With this flag set, dm-thin does not wipe a block before reassigning it. That is a performance trade-off operators sometimes make deliberately, but in a multi-tenant environment the consequences were significant. A freshly assigned block would carry the previous tenant's data intact unless the incoming workload happened to overwrite every byte of it.
Yomtov and his team worked out a way to exploit this behavior without needing any privileged access. A tenant with a standard Workers Paid account could open their container's raw root disk at `/dev/vdc` and identify regions that the guest ext4 filesystem had marked as free space. Writing a small 4 KiB block into a 64 KiB-aligned free region would force dm-thin to pull a physical block from the shared pool. Because zeroing was disabled, only the 4 KiB the attacker wrote got replaced. The remaining 60 KiB stayed exactly as the previous owner had left it. A subsequent raw-device read could then pull those bytes out.
What the researchers found across production runs was striking in scope. They tested the technique across 24 placements and found residual data on 18 of them, across 20 of 22 underlying nodes and spanning four continents. The recovered material included directory structures, database pages, and structurally complete SQLite databases. Using ext4's `metadata_csum` checksum feature, the team was able to confirm that recovered directory blocks did not originate from their own test filesystem. Across six placements they identified 2,700 distinct foreign directory inodes. All proof-of-concept materials submitted to Cloudflare were scrubbed of third-party identifiers and content values, and the researchers confirmed they securely deleted the recovered data after submission.
The vulnerability carried real limits. An attacker could not pick a target. Which blocks dm-thin reassigned to a new container depended entirely on Cloudflare's workload scheduler, so exploitation was opportunistic rather than directed. The technique also could not touch any actively mounted disk or modify another tenant's live data.
Cloudflare moved fast. Yomtov filed the report on September 4 at 15:26 UTC. The engineering team opened a security incident and confirmed the production setup behind the flaw within about three hours. A runtime fix was merged by 21:27 UTC the same day. Rolling out the change across the fleet began by 23:15 UTC. But removing `skip_block_zeroing` only stops future misallocation. Blocks already mapped into running containers or cached in pre-built snapshot layers were unaffected. To clean those up, Cloudflare drained hosts during off-peak hours, restarted their VMs, and wiped each host's image cache so every disk would be rebuilt using zeroed allocations. That final cleanup finished on September 19. The researchers confirmed their proof of concept stopped working on September 14.
Cloudflare said it reviewed all available historical disk I/O telemetry and found no activity consistent with the exploit technique other than what came from the researchers and from Cloudflare engineers during authorized validation. No customer-side action is needed.
The disclosure adds to a recent pattern in cloud infrastructure research. Yomtov's team at Accomplish has a track record of finding platform-level flaws; they also reported a sandbox escape in Anthropic's Cowork tool this year. In the wider cloud industry, Wiz researchers disclosed a separate cross-tenant issue in Microsoft Azure Cosmos DB this year, called CosmosEscape, which could have let attackers escalate from a crafted Gremlin query to retrieving primary account keys for other customers' databases. Microsoft said it found no evidence of customer impact in that case either.
Cloudflare co-authored its disclosure with Yomtov and the Accomplish research team, a relatively transparent move for a company of its size. The company's bug bounty sits on HackerOne and remains open for further researcher submissions.
BigCommerce has started alerting merchants that customer data was stolen from their stores after attackers got hold of API credentials belonging to Ribon, a third-party storefront optimization app used by retailers across the platform.
The stolen credentials gave attackers access to customer records inside merchant accounts on BigCommerce between September 13 and September 17. For those four days, they pulled data page by page until the compromised key was revoked. Names, email addresses, phone numbers, and shipping addresses were taken. Passwords and payment card details were not, because BigCommerce stores that information in a separate system.
The breach did not originate inside BigCommerce. It traced back to a system compromise at Fastr, the parent company of Be A Part Of, the firm that develops and operates Ribon and its updated version, Ribon 1.5. Fastr's internal compromise exposed the API credentials those apps held, and attackers used them to walk directly into merchant environments without triggering any alarm at BigCommerce's own infrastructure level.
"On September 17, 2026, Commerce confirmed that API credentials belonging to third-party applications Ribon and Ribon 1.5, owned and operated by 'Be A Part Of,' a Fastr company, had been compromised due to a Fastr system compromise," BigCommerce told SecurityWeek. "This was not a breach of Commerce systems or the BigCommerce platform."
Ribon's own developers noticed the key was being misused on September 16. The access was cut on September 17, and BigCommerce uninstalled the app from all affected stores the same day. Merchants started receiving notifications from BigCommerce on September 18. In some stores, attackers also injected malicious scripts, though BigCommerce has only said this affected a small number of storefronts and has not specified what those scripts were designed to execute.
UK spirits retailer Master of Malt confirmed publicly it was among the merchants notified. In a statement on its website, the company said the attacker accessed its customer database and described what happened in plain terms. "It looks like hackers were able to compromise a BigCommerce Application key held by Ribon, which they were able to use to gain access to customer data held on their system." Master of Malt has reported the incident to the UK Information Commissioner's Office and said the impact may extend to hundreds of other retailers that had Ribon installed on their stores.
That point matters. This was not a breach contained to one retailer or to one retailer's mistakes. Every merchant that had Ribon connected to its BigCommerce store shared the same exposure risk, because every one of them relied on the same third-party credentials that Fastr failed to protect. The total number of affected merchants has not been disclosed. Fastr and Be A Part Of have not issued any public statement. Neither company had responded to media requests for comment as of the time of reporting.
BigCommerce hosts over 1,200 third-party apps and integrations. It told BleepingComputer it is providing log data to support Fastr's investigation. Seattle-based law firm Emery Reddy is already seeking potential claimants, noting that several retailers have begun sending breach notifications to their customers. The firm confirmed the exposed information matches what Master of Malt reported: names, email addresses, phone numbers, and physical addresses.
This incident is not the first time BigCommerce has had to yank a third-party app after attackers used it to reach merchant customers. In late 2024, electronics accessories maker ZAGG disclosed that unknown actors had breached FreshClick, another third-party BigCommerce integration, and injected payment-skimming code into its checkout. That attack ran from October 26 through November 7, 2024, and resulted in the theft of names, addresses, and live payment card data from customers completing transactions on ZAGG's site.
The two incidents differ in method. The FreshClick attack used malicious JavaScript to capture card details at the point of entry, in real time, as customers typed. The Ribon attack used a compromised backend key to query stored customer records directly, without any customer interaction required. No payment data changed hands this time, but the attacker had persistent, authenticated access to customer databases for four consecutive days before anyone pulled the key.
For shoppers at any retailer that used Ribon, names, email addresses, phone numbers, and home addresses are now in someone else's hands. That combination is more than enough to build convincing phishing messages or to attempt account takeover on other services where those same details appear. Affected customers should treat any unsolicited emails referencing their account details or recent orders with skepticism until the full scope of the incident is established.
Modu-ui stores participants’ personal details such as email addresses, names, and startup ideas, and the platform also supports a nationwide startup audition overseen by SMEs and Startups (MSS) of the South Korean Ministry.
Suspicions were already raised a month prior to the reported data breach that applicants’ personal data could be structured and exposed via API responses inside the platform. The government said it had taken prompt action but did not reveal if it had upgraded Modu-ui’s security infrastructure.
In June, the Ministry of SMEs and Startups disclosed that summaries of startup ideas and personal details had been exposed. Later, it started a detailed enquiry along with National Police Agency, National Intelligence Service, and the Cyber Security Center.
In July, the agencies confirmed that the leak of encoding keys via an API was the reason for the startup idea and personal data leak.
The exposed data had already been encoded but the encoded data needs an encoding key decoding.
In this case, the encoding key was leaked along with the API data, causing in the leak of evaluation comments, startup idea summaries and email addresses related to 5000 successful applicants.
According to the Ministry, the encoding key had been included inside the API and a third party retrieved API data via methods like web crawling, causing the exposure of the key.
Private email addresses were not shown on the public-facing interface but officials believed they could be retrieved via AI-based web crawling.
The incidents also demonstrate the dangers of hard-coding encoding keys as fixed values inside databases, application code, similar environments, or databases.
When businesses follow this method, the keys can become vulnerable in addition to the data or systems they are meant to protect. The main reason for this incident can be viewed as security infrastructure failure in incorporating robust encoding key management.
Officials found 39 IP addresses related to the access of the exposed data coming from South Korea. Authorities also said that investigations led to more details such as potential connections to AI solution providers.
The recent news has notably increased the number of consumers potentially exposed in the incident. “We're deeply saddened to share the news that the recent data breach affects more customers than originally thought,” Trezor said on X.
As per Trezor, the additional 67000 customers placed orders from November 2019 to August 2021.
The leaked data consists of customers' email, phone numbers, names, addresses, order numbers, and shipping addresses. According to Trezor, the data was stored by ShipMonk even though Trezor had earlier received assurance that previous consumer data had been erased.
“Throughout our entire relationship with ShipMonk, we repeatedly requested and received written assurance confirming the deletion of the data, in line with our contract, data policy, and past communications. We are very disappointed that, despite receiving this confirmation, the data was not deleted in their systems,” Trezor said.
According to experts, the breach is not impacting Trezor’s own systems.
Trezor said its hardware wallets are safe and there are no signs that customers’ recovery seed phrases or private keys were breached in the leak.
As per Trezor, “All affected customers have been emailed directly. If you didn’t receive an email, then you are not affected.”
But Trezor and cybersecurity experts are worried that the stolen data could be exploited for social engineering and targeted phishing attacks. Threat actors could misuse customers’ details regarding their Trezor purchases to create scam phone calls or fraud messages.
This can be a serious problem for cryptocurrency users. A threat actor could mimic a company employee if they know someone owns a Trezor wallet and ask the target to verify their wallet or account.
If successful, the attacker could steal the target’s recovery seed phrase, which can allow access to cryptocurrency funds. “Trezor systems were not compromised, and your device is secure. But please be alert for fake emails, phone calls, fraudulent letters, and potential risks to physical security,” the company added.
The announcement comes after the August incident when 13,689 customers had been impacted by the same shipping-provider. At the time, Trezor estimated around 14,000 customers to have been affected by the breach. The recent disclosure of 67,000 suggests the scope of the incident was larger than expected.
Dropbox has confirmed that hackers broke into roughly 5,000 user accounts last month by exploiting a weakness in how Lenovo verifies email addresses, allowing intruders to log into victims' cloud storage without ever knowing their passwords.
The cloud storage company began notifying affected users this week, telling them that an "unauthorized party" had accessed their accounts between August 4 and August 21. In some cases, the notification said, the attacker viewed or downloaded files stored in the account.
What makes the incident unusual is that Dropbox's own systems were never breached. The company lets users sign in with a Lenovo ID, a login credential tied to Lenovo's Identity Provider Services, as an alternative to a Dropbox password. According to Dropbox, a flaw in Lenovo's email verification process let an outside party register a Lenovo ID using someone else's email address. Once that fraudulent ID was created, the attacker could use it to log straight into the Dropbox account tied to that same email, bypassing the account's actual password entirely.
Dropbox's system trusted Lenovo's confirmation that the attacker owned the email address and did not ask for any additional check through the user's normal Dropbox login. Some of the people affected told Dropbox they had never signed up for a Lenovo ID in the first place, yet their accounts were still reachable through the integration.
A handful of users noticed something was off before Dropbox sent out its warning. One person, posting on Hacker News under the handle xaphod, said they had gotten alerts about suspicious sign-ins roughly two weeks earlier and changed their password and turned on two-factor authentication right away. They also noted that the Dropbox login page had started showing a "Continue with SSO" option tied to their email, despite never having created a Lenovo account.
Dropbox told Reuters that about 5,000 accounts were affected in total, and that none of them had two-factor authentication switched on, which is part of why the fraudulent logins went through unchallenged. Files were viewed or downloaded in fewer than a third of those accounts, a company spokesperson said. Bloomberg, which first reported the breach, cited Dropbox statements and internal records describing hackers browsing and pulling material that users had stored on the platform. Shares of Dropbox slipped about 2.4% in after-hours trading once the news broke.
Lenovo, for its part, described the problem as tied to a "legacy integration" between Lenovo ID and Dropbox that could be misused to improperly authenticate certain Dropbox accounts. A company spokesperson said Lenovo and Dropbox worked together to contain the issue once it was identified, and that Lenovo's own customer accounts were not compromised as a result. Both companies said their investigations are continuing.
Once it understood what was happening, Dropbox expired every session that had been authenticated through a Lenovo ID and cut the link between the two systems altogether. Going forward, anyone signing in through a Lenovo ID will also have to enter their Dropbox password, closing the gap that let the fraudulent logins succeed without one. The company said it has reported the incident to data protection regulators, as required in jurisdictions covered by breach notification rules.
For affected users, Dropbox's advice mirrors standard breach guidance: change the Dropbox password, change the password on the linked email account, and enable two-step verification if it isn't already on. Security researchers reviewing the incident have also suggested checking active sessions, connected third-party apps, shared links, and recent file activity for anything unfamiliar, along with account recovery settings that an attacker could have altered while inside.
The breach adds to a run of recent incidents built around federated login systems rather than direct server intrusions. Security teams have flagged this pattern for years: as more services link their sign-in process to outside identity providers to make logging in more convenient, a flaw in any one partner can end up exposing accounts across the whole chain, even for users who never signed up with that partner directly.
Dropbox has not said whether it plans to end the Lenovo ID integration entirely or continue it under the new password requirement. The company said users who did not receive a direct notification from Dropbox were not affected by the incident.
The FBI has opened an investigation into an apparent breach involving identity verification provider IDScan.net after a newly launched dark web service began advertising access to more than 153 million U.S. and Canadian driver’s license records.
The service, named Nexus, appeared on the Russian cybercrime forum Exploit on August 31, claiming access to identity documents belonging to more than 170 million people across North America. Its advertised database includes more than 153 million driver’s licenses, over 10 million identification cards, more than three million travel or international identity documents, and at least 579,000 medical cards.
An examination of the service indicates that the claimed volume may be credible. A search without filters reportedly produced about 11.5 million pages of records, with approximately 15 results per page. Canadian licenses accounted for roughly 1.1 million results, including 473,673 records from Ontario, while most listings originated from the United States.
The dataset also contains marijuana dispensary cards, commercial driver’s licenses and records marked “CAC,” potentially referring to U.S. government Common Access Cards. Nexus operators claim the information is being obtained through an ongoing compromise of a major identity verification company serving Fortune 500 customers. They claim to have continuously extracted new records for more than a year.
Evidence examined by KrebsOnSecurity also indicates that the database may still be receiving stolen information. The number of available driver’s license records reportedly increased by nearly 400,000 within 24 hours.
The exposed records are unusually detailed. One license examined by Krebs contained six image files showing the front and back of the document, including standard, infrared and ultraviolet captures. Each file carried a timestamp. In several cases, those timestamps corresponded closely with victims’ real-world activities.
Krebs tested the apparent pattern by obtaining permission to search for licenses belonging to more than a dozen acquaintances. Nine licenses were located, and each individual confirmed travelling on or around the dates associated with the image timestamps. Further comparison with rental records indicated the timestamps appeared consistent with Greenwich Mean Time.
The evidence initially pointed toward airports, but that theory weakened because the database contained no passports and several individuals had not presented their licenses at airport security. Two federal employees who appeared in the dataset said they used other government identification at airport checkpoints, but later handed their state licenses to Hertz when renting vehicles.
A particularly revealing comparison involved Krebs’ own license and his mother’s. Their records carried timestamps only seconds apart, corresponding to the time both licenses were handed to a Hertz representative. Another exposed license belonged to security researcher Zach Edwards, whose timestamp matched a trip to Las Vegas for DEF CON. Edwards said he showed his license to TSA, his hotel and Planet 13, but identified the dispensary as the only location that definitely scanned it.
That connection is notable because Planet 13 announced in 2022 that it had deployed IDScan.net’s VeriScan technology across 16 check-in stations at its Las Vegas SuperStore. The system captures government-issued identification, performs document authentication and can use white-light, infrared and ultraviolet imagery. IDScan.net says its technology performs more than 21 million identity verifications each month across more than 20,000 locations.
IDScan.net also publicly lists major organizations using its technology, including Hertz, Target, FedEx and Caesars Entertainment. Its current platform supports ID scanning, document authentication, data parsing and integrations through APIs and software development kits.
IDScan.net told KrebsOnSecurity that it was investigating but had not provided a substantive public explanation of the suspected incident. Its documentation shows that its systems can retain raw files generated during scans, while its security documentation describes encryption for data at rest and in transit.
The FBI’s New Orleans field office subsequently opened an official investigation into the suspected breach. The development adds a law-enforcement dimension to an incident that could expose highly sensitive identity information at unprecedented scale.
The potential consequences extend beyond conventional credential theft. Driver’s license information is legally recognized as identifying information, and stolen identity data can be used to open accounts, obtain services, commit financial fraud or impersonate victims.
The incident also exposes a difficult security trade-off in modern identity verification. Organizations increasingly depend on third-party systems to scan government credentials for travel, rentals, retail, financial services and age verification. TSA began enforcing REAL ID requirements for domestic air travel in May 2025, further embedding government-issued identification into everyday verification processes.
For now, the precise intrusion path, affected customers and total number of compromised individuals remain unconfirmed. However, the combination of detailed document images, matching timestamps, apparent fresh data collection and the FBI investigation makes Nexus a serious warning about the risks created when sensitive identity documents are concentrated within third-party verification infrastructure.