Data Breach Update
Data Breach Update Alert: One Phone Call, 851,000 Records
By Nattapong Sukkasem · Published · Updated .
TL;DR — In November 2025 Harvard told the world that a phone call into its Alumni Affairs and Development office had given an intruder access to its fundraising systems. ShinyHunters published the files in February 2026 after the university declined to pay. On 3 November 2026 — nearly a year after the intrusion — Have I Been Pwned loaded the dump and attached a number to it for the first time: 850,500 unique email addresses and eighteen categories of personal detail, from dates of birth to family members' names. The useful part of this data breach update is not the theft. It is the twelve months between the disclosure and the measurement.
Every data breach update arrives in two pieces, and they almost never arrive together. The first is the notice: a statement from the organisation describing what was reached and what was not. The second is the number — how many people, which fields, how precisely they can now be identified — and that one tends to show up much later, written by somebody else entirely. Harvard's two pieces landed 350 days apart.
What the file actually contains
Have I Been Pwned counted 850,500 unique addresses, which its own write-up rounds to 851,000. The field list is the part worth reading slowly. Alongside names, email addresses, physical addresses and phone numbers, the dump carries dates of birth, places of birth, ethnicities, genders, marital statuses, citizenship statuses, education levels, occupations, job titles, employers, salutations, social media profiles, charitable donation details and the names of family members. Not every field is populated for every person, and the University of Pennsylvania set published alongside it — roughly 623,800 individuals — adds religion.
Harvard has said consistently that the affected systems did not store Social Security numbers, passwords, payment card numbers or financial account data. That is true and it matters. It is also the smaller half of the picture, because the fields that were stored are the ones nobody can reissue. A card number is replaced in a week. A date of birth, a place of birth and a list of relatives are permanent, and in combination they are an identity-verification quiz that the holder cannot retake.
A phone call, not a zero-day vulnerability
The entry method was voice phishing. Harvard describes it as a phone-based phishing attack directed at Alumni Affairs and Development, and the technique — a convincing caller walking a staff member into handing over a session or a credential — is the signature of the group that claimed it.
Place that beside what else happened to the same university in the same twelve months and the arithmetic is uncomfortable. About a month before the vishing call, Harvard was caught in the Cl0p campaign against Oracle E-Business Suite, which turned on a genuine zero-day vulnerability in a widely deployed enterprise product. That incident reportedly exposed a small amount of data from one small administrative unit. The phone call, which cost the attacker nothing and burned no research, produced 850,500 records. The exploit was the cheaper incident by a wide margin.
| When | What happened |
|---|---|
| Oct 2025 | Harvard caught in the Cl0p campaign against an Oracle E-Business Suite zero-day; reportedly a small amount of data from one unit |
| 18 Nov 2025 | Harvard identifies unauthorised access to Alumni Affairs and Development systems, attributed to phone-based phishing |
| Nov 2025 | ShinyHunters claims the intrusion and lists the University of Pennsylvania the same day |
| Feb 2026 | Ransom refused; the group publishes over 1 million Harvard records and 1.2 million from Penn |
| Early 2026 | Harvard reached again through Instructure, the vendor behind Canvas; the university takes its Canvas site offline |
| 3 Nov 2026 | Have I Been Pwned loads the data: 850,500 unique addresses across eighteen field categories |
Three incidents, three other people's platforms
Read the timeline as an estate map rather than a run of bad luck. One incident came through an Oracle product, one through a learning-platform vendor, and one through a human being with a telephone and access to a fundraising database. Only the third was reachable by anything the university itself patches.
This is where cloud security as most organisations practise it runs out of road. The discipline is good at scoring a tenant: configuration drift, over-permissioned roles, exposed buckets. It has no column for the number of separate vendors holding a copy of the same population, and no column for the number of disclosure timelines that population is therefore subject to. Harvard did not have one breach year. It had three vendors' worth of exposure, each with its own notification clock, and the one that mattered most involved no misconfiguration at all.
Disclosure is not measurement
Harvard disclosed promptly and described the incident accurately. What it did not do — what almost no organisation does — is publish the dimensions. For nearly a year, anyone trying to work out whether they were affected, and how badly, had a qualitative statement about contact details, event attendance and donation history, and no way to convert it into a risk decision.
The number arrived on 3 November 2026 from a free public service run by one person, derived from the attacker's own dump. That is the uncomfortable mechanic at the centre of this data breach update: the authoritative measurement of a breach is produced by indexing the stolen data, which means it cannot exist until the data has been published, which means the only breaches that get measured precisely are the ones where extortion failed. Every breach where the ransom was paid is, by construction, a breach nobody ever sized.
It also inverts the usual incident shape. A DDoS attack has a start, a peak and an end, and the graphs tell you when it is over. Here the intrusion ended in November 2025, the containment ended shortly after, and the exposure started in February 2026 and has no end state at all. The incident was closed long before it became dangerous.
The exposed population is not on your network
Eighteen fields about 850,500 people, with employers, job titles, donation histories and family names attached, is not merely a privacy loss. It is a targeting package. The same technique that produced the file is the technique the file most improves.
Which raises the awkward question for anyone running server infrastructure for an institution with alumni, members, donors or patients: the people now exposed are not your users. They have no managed laptop, no agent, no corporate resolver. A lure domain they are sent next month is resolved by their home router or their phone, and if that device uses DNS over HTTPS to a public provider, no policy of yours was ever in the path to begin with.
What you can control is the half of the exchange that carries your name. If attackers write to alumni as the institution — as Penn's attackers did, from addresses that looked official — then SPF, DKIM and a DMARC policy at enforcement are the only mechanism that makes the forgery fail at the receiving mail server rather than at the reader's judgement. Those are DNS records, and an email DNS checker will tell you in seconds which of the three is actually doing anything.
What to check this week
- Put the advancement database on the same footing as finance. A fundraising CRM holds more identifying detail per person than most payment systems, with none of the regulatory scaffolding that forces payment systems to prove their controls.
- Decide what the record is allowed to keep. Ethnicity, citizenship status, marital status and relatives' names are collected because a form offered the field, not because the programme needs them. Retention is the only control that reduces the size of a future dump.
- Assume the help desk is in scope. Voice phishing defeats password policy by not attacking it. Callback verification on any request that moves access, and a rule that staff never authenticate to an inbound caller, is worth more here than another training module.
- Count the vendors, not the systems. Every platform holding your constituent records has its own breach, its own clock and its own disclosure standard. That inventory is an IT security artefact, and most organisations cannot produce it in a day.
- Get DMARC to enforcement before the lures start. Monitoring-only tells you about forgery after it is delivered. Quarantine or reject stops it.
- Baseline your own answers. A network diagnostic tool run against your sending domains and their lookalikes records what normal looks like, which is the comparison you will want when a campaign using your name begins.
What it means
The hedges belong at full strength. Harvard has not named an attacker; ShinyHunters claimed the intrusion and the attribution rests on that claim and on the technique. The university says the affected systems held no Social Security numbers, passwords, card data or financial account data, and nothing published contradicts that. The field list is Have I Been Pwned's characterisation of the dump, not Harvard's notification, and the service is explicit that not every field is present for every person.
What is not in doubt is the shape. One phone call reached a database that had been quietly accumulating biography for decades, and the only reason anyone now knows how large it was is that the extortion failed and the files went public. That is the last thing worth taking from this data breach update: for the breaches you read about, the number arrives a year late and from outside. For the rest, it never arrives at all.
Sources
- The Register — ShinyHunters hit 850k alumni, donors, students and family in last year's Harvard University raid
- Have I Been Pwned — Harvard breach entry
- Cybernews — Harvard data breach exposed 850,500 unique accounts
- TechBuzz — ShinyHunters dumps 2M+ records from Harvard and UPenn breaches
Related articles
Browse every DNS news article by month →
DNS angle
Review resolver logs for the systems discussed above and compare unexpected names with your approved services. A successful lookup does not establish that a destination is safe. Use the DNS lookup tool to inspect current answers, then compare them with your own resolver and incident records.