Cybersecurity

A Vendor Breach Your DORA Register Can't Explain

RingCentral's own July 28 disclosure blames a "sophisticated social engineering campaign" with no technical detail, after ShinyHunters leaked 1.6 million customer records - leaving EU and UK vendor-risk registers with nothing to update.

CybersecurityBy Servola Tech Desk2026-08-154 min read

AI-assisted, edited by humans. | Editor-in-Chief: Leon Soliman | Editorial standards

A Vendor Breach Your DORA Register Can't Explain

Key takeaways

RingCentral's own Trust Center security bulletin, dated 28 July 2026 and rated HIGH severity, attributes the breach to "a sophisticated social engineering campaign" and names no vulnerability, no exploited system and no compromised employee role.
ShinyHunters claimed the attack on 27 July 2026, said it stole 623GB of data, and published a 280GB archive after RingCentral declined to pay; Have I Been Pwned added the resulting 1.6 million unique email addresses, names, phone numbers and physical addresses to its database on 13 August 2026.
RingCentral says the core platform was never touched and only "a limited portion" of its customers were affected, but the company has not said which employee was targeted, which internal system the attacker reached, or which control, MFA, callback verification, help-desk identity checks, failed.
RingCentral markets RingEX, RingCentral Contact Center and RingCX directly into financial services and healthcare across Germany, France, Spain and the UK; both sectors are required under DORA and NIS2 to keep a register of ICT third-party providers and assess the risk each one carries.
The original Servola read: a disclosure this thin gives a DORA- or NIS2-regulated customer nothing to write into that register, because the standard vendor questionnaire, SOC 2 attestation, encryption certificate, penetration-test report, tests exactly the technical controls that were never in play in a breach that started with a phone call to an employee.

What RingCentral has actually confirmed

RingCentral's own Trust Center security bulletin, dated 28 July 2026 and marked HIGH severity, says the company "recently discovered that it was the target of a sophisticated social engineering campaign" and "promptly took steps to stop the unauthorized activity" with help from a third-party forensics firm. The bulletin adds: "this incident has affected data for a limited portion of RingCentral customers, and we are communicating with affected customers directly. If you are not contacted by RingCentral, you are not affected."

The extortion group ShinyHunters claimed the attack a day earlier, on 27 July 2026, saying it had taken 623GB of data, then published a 280GB archive after RingCentral did not pay. Have I Been Pwned processed that archive and added it to its database on 13 August 2026: roughly 1.6 million unique email addresses, plus names, phone numbers and physical addresses. RingCentral has been explicit that the breach did not reach RingEX, RingCentral Contact Center, RingCX or any other core service, which it says "continue to operate without disruption."

A pattern of vendors, not victims

ShinyHunters has spent 2026 running the same playbook against one SaaS vendor after another: Salesforce customer instances, Snowflake-hosted client data and Oracle PeopleSoft deployments, with the group's own claims putting the combined haul at more than 1.5 billion records across campaigns. RingCentral is the latest name on that list, and the method the company itself describes, a person persuaded to hand over access rather than a flaw an attacker had to find, matches a wider 2026 trend of vishing and social-engineering campaigns succeeding against employees who hold privileged access at the vendor, not at the customer.

That distinction matters for anyone assessing RingCentral as a supplier. A customer can patch its own software and rotate its own credentials, but it has no way to test, or even see, how well a vendor's own support and admin staff resist a convincing phone call. The target here was RingCentral's workforce, not RingCentral's code.

The gap in the vendor risk register

Financial entities under the EU's Digital Operational Resilience Act are required to keep a register of information covering every ICT third-party provider and to assess the risk each one poses to the entity's own resilience, under DORA Articles 28 to 30. Essential and important entities under the NIS2 Directive carry a parallel duty in Article 21 to manage supply-chain cybersecurity risk, including the security practices of their direct suppliers. Both frameworks assume the regulated entity can obtain enough detail from a vendor to actually assess that vendor's risk.

RingCentral's bulletin does not name the employee's role, the internal system the attacker reached, or which control, multi-factor authentication, callback verification, help-desk identity checks, failed to stop a phone call from becoming a breach. A German bank, a Dutch hospital group or a UK insurer that lists RingCentral in its ICT third-party register has nothing concrete to add to that entry beyond "a breach occurred." The standard vendor security questionnaire, a SOC 2 attestation, an encryption-at-rest certificate, a penetration-test summary, tests exactly the technical controls that were never engaged in an incident that started and ended with a conversation.

What an operator should actually change

The practical fix is not another line of encryption paperwork. Operators that rely on RingCentral, or any UCaaS or CCaaS vendor serving regulated customers, should ask the vendor directly whether it runs its own simulated social-engineering tests against support and admin staff, and should treat the answer, or the refusal to answer, as a risk-register entry in its own right.

Contracts renewed after this disclosure are the moment to add a specific clause: a right to a technical post-mortem, not a marketing statement, within a fixed number of days of any confirmed incident. Without that clause, the next vendor breach notice will read exactly like this one, complete and compliant on paper, and useless for the one document, the risk register, that regulation actually requires an operator to keep current.

Frequently asked questions

Was RingCentral's core communications platform breached?

No. RingCentral says the incident did not reach RingEX, RingCentral Contact Center, RingCX or any other core service, and that those services have continued operating without disruption.

What data was exposed?

Have I Been Pwned's processing of the leaked archive found roughly 1.6 million unique email addresses, together with names, phone numbers and physical addresses. RingCentral has not disclosed whether call content, recordings or authentication credentials were part of the stolen data.

Is this the same attack as other recent vishing incidents?

No. It is a separate incident carried out by a different group, ShinyHunters, rather than the vishing collectives that hit private-equity and financial firms earlier in 2026. The common thread is method, not identity: both used social engineering against employees rather than a software exploit.

What should EU or UK companies using RingCentral do?

Beyond the standard customer notification check, ask RingCentral directly for the technical detail its public bulletin omits, and use the answer, or the lack of one, to update the vendor's entry in your DORA or NIS2 third-party risk register rather than leaving it unchanged.

A breach notice that names no system, no role and no failed control is not more careful disclosure, it is a disclosure that regulation cannot actually use. DORA and NIS2 both assume a customer can extract enough from a vendor to reassess its risk; RingCentral's bulletin is a test of whether that assumption holds, and on the public record so far, it does not.

RingCentralShinyHuntersDORANIS2vendor risksocial engineeringdata breachUCaaS

Hugging Face Had To Ask For Its Own Breach Logs

Hugging Face could not identify the model that broke in. Its CEO then asked OpenAI publicly for the traces. Nothing compels a vendor to hand them over.

7 min read

Infrastructure

OpenAI Paid You Back in the Thing That Broke

Four incidents on 27 July alone, on OpenAI's own status page. Compensation for the weekend outage was a usage reset, which is credit on the service that failed.

4 min read

Decisions

The Third Pivot Was the Warning Magic Leap Missed

Magic Leap filed a WARN notice for 193 layoffs effective 1 October 2026, its fourth strategic pivot after $4 billion raised. The lesson is the pattern, not the pivot.