A threat actor claims to have stolen hundreds of gigabytes of data from Empower Group, a New York based alternative financing provider serving small and medium-sized businesses, with a subsequently discovered database allegedly tied to the incident containing roughly 6.69 million records including Social Security numbers. The claim surfaced on April 16, 2026, when the DragonForce ransomware group listed the company on its data leak site. Four months on, Empower Group has issued no public breach notification and has not confirmed the incident. A single source, databreachrights.com, carries the reporting; no primary filing, regulator notice, or vendor advisory in our source set corroborates it. Readers should treat every figure below as an actor claim or a third-party assertion, not as established fact.
What Happened
According to databreachrights.com, DragonForce added Empower Group to its leak site on April 16, 2026, claiming to have exfiltrated approximately 316 GB from the company's systems. That listing is the origin point for the entire story. More than a month later, on May 26, 2026, the same report says a publicly accessible indexed database allegedly connected to the breach was reported online, with researchers putting the record count at 6,691,415.
The gap between those two events matters. A leak-site listing is a negotiation tactic and proves nothing about what was actually taken. An exposed indexed database, if it is genuinely the same corpus, is a different class of problem: it means the data was reachable without paying anyone. The report does not identify the researchers, name the platform the database was indexed on, or describe how the linkage to DragonForce's claim was established.
No public breach notification had been issued at the time of that reporting, and none appears in the sources here. Empower Group has not publicly confirmed the breach or disclosed a count of affected individuals. The company has also not, in these sources, denied it.
One point of caution on attribution: the two LinkedIn profiles in our source set, Kim Gardner (VP and Associate General Counsel, Trust and Data Protection) and Doug Peterson (CISO), both belong to Empower, the Greenwood Village, Colorado retirement and financial services firm with 7,000 to 8,000 employees and $10B to $20B in annual revenue. That is a different organisation from the New York alternative financing provider described in the breach reporting, notwithstanding the shared name and the fact that Empower maintains a New York office. Anyone tracking this incident should confirm which entity is actually implicated before acting on the name alone. Conflating the two would be an easy and consequential error.
What Was Taken
The claimed volume is approximately 316 GB. The claimed record count is 6,691,415, commonly rounded to 6.6 million. Only one source reports either number, so there is no range to give and no second figure to weigh against the first. A breach of that size would rank among the largest publicly reported exposures of 2026, which is precisely why the absence of corroboration is worth stating rather than glossing.
The reported data categories in the indexed database are Social Security numbers, names, addresses, phone numbers, email addresses, and dates of birth. That combination is the full identity-theft starter kit: it supports synthetic identity creation, account takeover, and credit fraud without requiring anything further from the attacker. There is no reported financial account data, payment card data, or credential material in this set.
For contrast on what a confirmed, documented breach disclosure looks like, SecurityWeek's reporting on CareCloud is instructive. That healthcare IT company notified at least 350,000 people after attackers accessed an AWS environment between March 10 and March 16, 2026, filed a notification letter with the Massachusetts Office of Consumer Affairs and Business Regulation, itemised the compromised fields down to CVV data for a limited subset, stated it had no evidence of misuse, and offered 24 months of identity protection with a $1,000,000 reimbursement policy. Empower Group has produced none of that. The difference is not a detail. It is the difference between a breach the public can act on and a rumour they cannot.
Why It Matters
The exposure risk here is structural, not just personal. An alternative financing provider serving SMBs holds data on business principals: guarantors, owners, signatories. A record set combining SSN, date of birth, address, and contact details for millions of people connected to small business credit applications is a high-quality input for business email compromise and loan fraud, not merely consumer identity theft.
The downstream mechanics are already documented elsewhere. NIS notes that in 2026, Upbound Group disclosed attackers had used stolen data to generate $13 million in fraudulent contracts. That is a single OTHER-tier claim and we present it as reported rather than as a verified figure, but the pattern it describes is well established: stolen partner data becomes fraudulent instruments, and the organisations that suffer the loss are frequently not the ones that were breached.
The notification vacuum compounds this. Downstream organisations cannot execute the basic vendor-breach playbook, identifying which vendors hold their data, verifying the notice through official channels, determining what was exposed, and rotating affected credentials, when there is no notice to verify and no confirmed scope to assess. Four months of silence transfers the entire cost of uncertainty onto people who have no way to reduce it.
Note also that a leak-site listing followed by an openly indexed database is a bad sequence for victims. Whether the exposure came from the actor, a reseller, or careless staging infrastructure, the practical result is the same: the data stopped being a bargaining chip and became a public resource.
The Attack Technique
Nothing in the available sourcing describes an initial access vector, dwell time, or tooling for the Empower Group incident. DragonForce operates as a ransomware and extortion group, and the pattern of a leak-site listing with a stated exfiltration volume is consistent with double-extortion tradecraft, but no source in this set documents how the intrusion occurred. We are not going to invent one.
What our sources do supply is a live reminder that "how they got in" increasingly has no exploit at the end of it. Reco's research into the campaign it calls City-Forum, covered by BleepingComputer, The Register, and Help Net Security, tracks an operator that has been pulling records out of Salesforce and ServiceNow portals worldwide for roughly 17 months. All observed traffic originates from IP address 158.220.87.79, hosted by German VPS provider Contabo, almost always using the default Go-http-client/1.1 user agent, associated with the domain city-forum.com, which has resolved to that server since at least March 2025.
The targets span telecoms, banks and financial services firms, enterprise software vendors, security and data privacy companies, and public sector portals. Reco is not naming them. The busiest Salesforce target logged more than 560,000 events. On Salesforce the actor works Lightning Web Runtime sites through the UI API's GraphQL layer, an approach Reco says it has not found in public research or in publicly available attack tools; on ServiceNow it queries a native Service Portal search endpoint that has drawn little attention. The tooling also probes whether Salesforce sites permit self-registration, which would convert anonymous guest access into an authenticated external account with broader visibility. Reco reported seeing those checks across most Salesforce targets it examined.
Critically, this is not a platform vulnerability. As Help Net Security put it, nothing came out of these portals that they had not been configured to hand over. Salesforce Experience Cloud and ServiceNow both provision a guest user that cannot be deleted and arrives with permissions somebody configured. Reco has observed only guest activity from this actor so far but says it cannot rule out authenticated access. "This is an advanced actor," said Nitay Bachrach, senior security researcher at Reco, noting the operator built custom tooling from techniques not well documented online. The campaign is ongoing and the volume is climbing.
There is no evidence linking City-Forum to the Empower Group claim. We include it because it defines the current baseline threat to financial services data: a patient operator with custom tooling, harvesting whatever over-permissioned guest accounts will surrender, generating no exploit signature at all.
What Organizations Should Do
Audit guest user permissions on every Salesforce Experience Cloud and ServiceNow instance you run. This is the highest-value action available right now because it addresses an active, confirmed, still-escalating campaign. Enumerate what the guest profile can read on every object, and assume anything readable is already public.
Block and hunt the City-Forum indicators. Search logs for 158.220.87.79 and for Go-http-client/1.1 user agents against your portals, going back to at least March 2025. Check GraphQL query volume against LWR sites and hits on the ServiceNow Service Portal search endpoint. A single busy target in Reco's data logged over 560,000 events, so this leaves traces if you look.
Disable self-registration on external-facing Salesforce sites unless you have a business requirement for it. Reco found the actor checking for it across most targets, because it upgrades anonymous access to an authenticated account with broader read permissions.
If you are an Empower Group customer or partner, verify directly rather than waiting. Contact the company through a channel you already trust, not a link in an email. Given that no notification exists, phishing that impersonates a breach notice is a predictable follow-on, and any "Empower breach notification" arriving in inboxes right now deserves suspicion. Confirm which Empower entity you actually deal with before you escalate internally.
Treat the exposed field set as already weaponised. Names, SSNs, dates of birth, addresses, phone numbers, and email addresses support credit fraud and identity theft indefinitely. Credit freezes and monitoring are the individual-level mitigation; on the business side, tighten verification on loan applications, contract origination, and any workflow where knowledge of these fields is treated as proof of identity.
Maintain a current inventory of vendors holding your data and pre-stage the response. Know who stores what, which contacts are legitimate, and which credentials would need rotation. The organisations that respond well to vendor breaches are the ones that answered these questions before the notification arrived, which matters most in cases like this one, where the notification may never come.
Sources: Empower Group Data Breach: Was Your Data Exposed? | CareCloud Data Breach Impacts Over 350,000 - SecurityWeek | Mystery attacker spent a year raiding Salesforce and ServiceNow por... | "City-Forum" data-theft attacks target Salesforce, ServiceNow portals | A stranger has been reading Salesforce and ServiceNow portals world... | Kim Gardner | Doug Peterson | How to Respond When a Vendor Discloses a Data Breach NIS