I finished writing about TriZetto’s healthcare platform going down and taking 3.4 million patient records with it, cracked my knuckles, poured coffee number six, and thought: okay, surely that’s the last big one this week. Reader, it was not the last big one this week. Because Cybercrime Wire dropped the HungerRush story on March 9th and the number in the headline stopped me cold. Twenty-eight million. Twenty-eight million customer records from a cloud-based restaurant POS platform. Being sold on a cybercrime forum right now. While HungerRush’s customers — the actual restaurants — are receiving extortion emails. Addressed to their customers directly. From the threat actor.

That last part. Let me make sure you absorbed that. The attacker didn’t just take the data and go dark. They emailed the restaurants’ customers directly to tell them their data was stolen and HungerRush hasn’t paid up yet. That is not a breach. That is a breach plus a hostage situation plus a PR catastrophe, all happening simultaneously, in the inboxes of 28 million people who just wanted a pizza.

What Actually Happened

Per Cybercrime Wire’s March 9, 2026 report hosted by Scott Schober, citing The Daily Dark Web, HungerRush — a cloud-based restaurant management and point-of-sale platform serving pizza restaurants and fast casual brands — has allegedly been compromised by a threat actor who is now offering a database of over 28 million customer and restaurant business records for sale on a cybercrime forum. HungerRush confirmed on their website that they are “actively investigating and coordinating with appropriate authorities.”

According to Bleeping Computer’s coverage, customers of restaurants running the HungerRush POS platform began receiving emails directly from the threat actor warning that their data — and their restaurants’ data — could be made public unless HungerRush responds to the extortion demand. So the attacker has the customer email list. They used it. And now 28 million people know their data was stolen before their restaurant told them anything.

HungerRush serves over 16,000 restaurant locations. The brand list is not small: Sbarro. Jet’s Pizza. Hungry Howie’s. FAT Brands properties. Thousands of independent operators nationwide. Every one of those restaurants has customers in HungerRush’s platform. Names, emails, phone numbers, delivery addresses, order histories, loyalty programme data, and potentially payment card information depending on how each restaurant’s payment processing integration was configured. The 28 million figure is not confirmed by HungerRush directly at time of writing, but a seller on a criminal forum has the data, is listing it, and has demonstrated enough of it to Bleeping Computer and Daily Dark Web to substantiate the claim.

This is a SaaS platform breach. HungerRush is the central platform. Every restaurant client’s customer data lives in HungerRush’s infrastructure. One breach of HungerRush doesn’t compromise one restaurant. It potentially compromises every restaurant on the platform simultaneously — all 16,000 locations’ worth of customers. That’s how you get from “a restaurant POS got hacked” to 28 million records on sale before the weekend.

Why This Is Bigger Than It Sounds

I already know what some of you are thinking. “It’s pizza orders. It’s not healthcare. It’s not financial data. Who cares.” I’m going to explain why that framing is wrong.

First, the data categories. HungerRush processes online ordering, delivery, and loyalty programmes. That means the database contains: full names, email addresses, phone numbers, home delivery addresses, order histories, loyalty account data, and in many cases payment card data. The delivery address is your home address, linked to your name, email, and phone number. That combination is not “just pizza orders.” That is a social engineering package. That is the raw material for SIM-swap fraud — call the carrier, have the target’s name, their phone number, their billing address, and enough transaction history to answer security questions. That is a credential stuffing kit — email addresses plus the knowledge that these people use online food ordering platforms, which means they have accounts on DoorDash, Uber Eats, and half a dozen restaurant apps using variants of the same email. That is a phishing infrastructure — 28 million verified, active email addresses belonging to real people with real delivery addresses.

And the extortion mechanic compounds everything. The threat actor isn’t waiting for the data to age and be sold quietly six months from now. They are actively running a pressure campaign right now. Every customer who got that extortion email has now been personally contacted by a criminal who has their data. The psychological damage of that notification alone — “we have your information and we may release it” — is a harm that precedes any fraud. It erodes trust in every digital service those customers use. It causes real distress to real people. And it happened because HungerRush was a centralized custodian of those people’s data and apparently didn’t secure it adequately.

As I’ve documented in my research on how dark web extortion models and Bitcoin payments have transformed the economics of cybercrime, direct extortion contact with victims — bypassing the corporate layer entirely — is an increasingly common pressure tactic. It generates media coverage, causes immediate reputational damage to the target company, and creates external pressure on the victim organization from its own customers. The attacker isn’t just monetizing the data. They’re using the data as a weapon to extract a ransom. HungerRush’s customers are, in a very literal sense, being held hostage in this negotiation.

The sector context matters too. The restaurant industry underwent a crash digital transformation during and after the pandemic. Online ordering went from a nice-to-have to a survival mechanism for most operators. That meant rapid adoption of cloud POS platforms, loyalty apps, and third-party delivery integrations — frequently chosen on the basis of features, price, and ease of setup, not security posture. The independent restaurant operator running three locations doesn’t have a security team. Doesn’t have a CISO. Doesn’t have an incident response plan. They signed up for HungerRush because it made taking online orders easier. They did not sign up to manage a data breach affecting thousands of their customers.

As I covered in the Clop ransomware campaign against Oracle EBS and third-party managed platforms, the centralized SaaS model creates catastrophic concentration risk: breach the platform once, breach every client simultaneously. HungerRush just demonstrated that this is not exclusively a healthcare or financial services problem. It is a structural feature of how SaaS platforms work when they aggregate sensitive customer data from thousands of clients into a single infrastructure without adequate security architecture.

What Went Wrong — The SaaS Restaurant Tech Security Problem

Let me describe what restaurant technology platform security looks like in practice, because the gap between “what it should look like” and “what it typically is” explains exactly how you end up with 28 million records on a criminal forum.

Restaurant technology companies compete on features, price, and uptime. Their target customers evaluate platforms based on how easy the online ordering menu is to configure, whether it integrates with DoorDash and Uber Eats, how the loyalty programme customization works, and whether the monthly fee fits a thin-margin restaurant budget. Security does not appear as a primary criterion in any competitive win/loss analysis in restaurant tech. It is not what closes deals. It is not what loses them. It is the afterthought at the bottom of the sales conversation, briefly addressed by a checkbox on a vendor questionnaire that nobody reads carefully.

The result is platforms that process enormous volumes of consumer PII and in many cases payment data, with security investment calibrated to “not lose deals” rather than “protect 28 million people’s data.” PCI DSS compliance imposes external pressure on payment card data security because there’s an audit process with real financial consequences for failures. But customer PII — the names, emails, phone numbers, delivery addresses, order histories — has no equivalent external enforcement mechanism in the US. It sits in databases with whatever access controls the platform’s engineering team built in, under whatever log retention policy someone set once and never reviewed.

The multi-tenancy architecture makes this exponentially worse. All of HungerRush’s 16,000 restaurant clients’ customer data sits in shared infrastructure, partitioned at the application layer. A breach that crosses tenant boundaries — either through a privilege escalation vulnerability in the application layer or through a breach of the underlying database or storage infrastructure — doesn’t yield one restaurant’s customers. It yields all of them. That architecture is operationally efficient and economically rational from HungerRush’s perspective. From a security architecture perspective, it is a single point of failure with a catastrophic blast radius.

This is the same architectural vulnerability I described in the ShinyHunters SSO credential campaign: when you centralize access or data management, you create a target whose value to an attacker is multiplied by the number of clients on the platform. HungerRush became a 28-million-record target because 16,000 restaurants put their customer data in one place. That one place wasn’t adequately secured. Now everyone in that one place is in the breach.

The Fixer’s Advice — Three Audiences, All Right Now

For HungerRush restaurant operators — if you’re a restaurant running this platform:

1. Send your own breach notification to your customers immediately. Do not wait for HungerRush’s official communication. The threat actor has already emailed your customers directly. If your customers are getting breach notification emails from the attacker before they hear from you, you have lost the communication initiative in this crisis and your customers will never fully trust you again. Write an honest notification: what happened, what data was involved, what they should do to protect themselves, and what you are doing about it. Keep it short, plain-language, and free of corporate weasel words. No “we take your privacy very seriously.” Just the facts and the action steps.

2. Understand your state breach notification obligations and act on them. Every US state has breach notification law. Most require notification within 30 to 90 days of discovery. Some states — California, New York, Florida, Texas among others — have shorter windows and specific content requirements. If HungerRush’s confirmed breach scope includes your customers, you have notification obligations as the entity that collected that data from your customers in the first place. HungerRush is your data processor. You are the data controller in this relationship. The legal exposure is yours. Get a lawyer involved today.

3. Contact HungerRush’s breach response team in writing and get specific confirmation. Which data categories were affected. Whether your specific restaurant’s customer records were included in the exfiltrated dataset. What HungerRush is doing to contain and remediate. What their timeline is for providing you with an affected customer list. You need written answers to these questions to manage your own notification obligations. Verbal assurances from an account rep don’t constitute legal notice and don’t protect you in a regulatory investigation.

4. Prepare your customer-facing response for questions. Your front-of-house staff are going to start getting asked about this by customers in person. Your social media accounts are going to start receiving comments and DMs. Prepare a simple, honest response that your team can deliver consistently. Something like: “We use HungerRush for our online ordering platform and they’ve confirmed a breach. We’re working with them to understand which of our customers were affected and we’ll be notifying everyone directly. Here’s a link to the latest information.” Don’t improvise this. Get the messaging consistent before the questions start coming in.

For consumers who may be affected:

5. Treat that extortion email as confirmed notification that your data was exposed. If you received an email from the threat actor referencing your data and a restaurant you’ve ordered from, your data is in the breach. Don’t click any links in that email. Don’t respond to it. Screenshot it and keep it for records. Then take the practical steps: monitor your email address for credential stuffing attempts — new login notifications from accounts you didn’t access, password reset emails you didn’t request. Consider a credit freeze if payment card data was included. Update the password on any account that used the same email address you used for restaurant ordering, especially if you reused passwords.

6. Submit a data deletion request to HungerRush directly. Under applicable state privacy laws and as a general data hygiene measure, submit a formal request to HungerRush for deletion of your personal data. They’re required to respond under California CCPA, Colorado CPA, Virginia CDPA, and equivalent laws in other states. It won’t undo the breach, but it removes your data from future exposure on this platform.

For SaaS companies in any sector managing consumer data for small business clients:

7. If you are the security team for your entire client base, act like it. This point is not subtle. HungerRush’s 16,000 restaurant clients have no independent security capability. They cannot assess HungerRush’s security posture. They cannot detect a breach in HungerRush’s infrastructure. They cannot protect their customers’ data independently because they don’t control the infrastructure it lives in. When you build a SaaS platform that centralizes sensitive consumer data from thousands of small business clients, you become the security team for all of them and all of their customers. The security engineering, the breach detection, the incident response, and the customer notification infrastructure need to be built at a level that reflects that responsibility.

8. The extortion email to end customers is a design failure, not just a response failure. The threat actor had 28 million valid email addresses and used them. That means the email addresses were in plaintext in a database, accessible to whoever accessed the platform. Email addresses for a notification and loyalty programme platform should be hashed for purposes that don’t require the cleartext value, and access to the cleartext should be logged and controlled. If an attacker can bulk-export 28 million email addresses from your platform, your data access controls are not adequately designed for the value of the data you’re holding. Redesign them.

9. Build customer breach notification infrastructure before you need it. HungerRush serves 16,000 restaurant clients. Each of those clients has customers who may need to be notified. A breach of this scale generates a massive operational demand: notification letters, regulatory filings across potentially all 50 states for multiple separate data controller entities, credit monitoring vendor coordination, customer service scripting, and legal consultation. This is not infrastructure you can build during a breach. Build it before. Have a vendor-assisted breach notification programme for client operators. Have template notifications by state. Have a customer communication playbook. Build the infrastructure in advance or plan to fail during the crisis.

The HungerRush breach is getting less column space this week than the FBI wiretap incident and the TriZetto healthcare breach. That’s partly about perceived severity — a pizza app doesn’t feel as catastrophic as FISA warrants. But for the 28 million people whose names, home addresses, and order histories are now on sale on a criminal forum, the size of the company that lost their data is entirely irrelevant. Their data is out there. The threat actor already emailed them about it.

And for the thousands of independent restaurant operators who trusted HungerRush with their customers’ data, who never had the means to evaluate whether that trust was warranted, who are now legally exposed to breach notification obligations they’ve never thought about, this is not a minor incident. This is a crisis they didn’t create and can’t fully resolve, landing on businesses that are already operating on margins that don’t leave much room for an unplanned legal and PR emergency.

The SaaS model concentrates the risk. The small business clients bear the exposure. The customers pay the price. And the attacker is already cashing in. Somewhere there is a vendor risk contract template that would have imposed actual security obligations on HungerRush before this happened. Find it. Use it. Next time.