Exact Sciences Breach: Rebuild the Recovery Channel After Vishing
Abbott says a vishing attack reached a limited number of legacy Exact Sciences systems in its Cancer Diagnostics business and that some affected files contain personal or personal health information. The company's August 5 update says the incident did not affect business, manufacturing or laboratory operations, product availability, or its ability to serve patients.
Have I Been Pwned has separately added a verified Exact Sciences breach containing10,869,543 unique email addresses. That number describes unique addresses in the corpus HIBP analyzed; it is not an official victim count from Abbott and should not be presented as one.
Confirmed facts and qualified claims
Abbott first confirmed unauthorized access on July 16. Its updated statement says the event was vishing, not encryption malware, and that the affected legacy Exact Sciences systems are separate from other Abbott systems. Abbott has not yet completed its data review or published a final count of affected individuals.
HIBP classifies the dataset as verified and sensitive. Its listed data classes include names, email and physical addresses, phone numbers, dates of birth, gender and personal health data. That verifies the corpus HIBP received; it does not validate every earlier claim made by the extortion actor about internal systems, record counts or additional data categories.
BleepingComputer reported the actor's claims about the access path and data before Abbott's August update. At that time the publication said it had not independently verified the claimed data scope. The safe conclusion now is that vishing, unauthorized access and the presence of personal and health information are confirmed. The final population and full scope remain under review.
Vishing turns identity into part of the incident
A voice call can bypass a technically strong login when it persuades a person or help desk to approve the wrong reset, enrollment or session. Once that happens, the response problem is larger than changing one password. Active sessions, recovery methods, API tokens, application access and support workflows may all depend on the same identity plane the attacker manipulated.
That is why an incident team should not automatically distribute replacement credentials through the usual email, collaboration workspace or help-desk process. If the attacker can impersonate a user or influence recovery, the normal channel may deliver the new secret to the wrong person.
Build a clean recovery channel
- Define the identity blast radius. Identify which accounts, sessions, devices, recovery methods and connected applications relied on the manipulated workflow.
- Revoke before reissuing. Terminate active sessions and tokens, remove unauthorized recovery methods and verify that revocation actually took effect before issuing replacement access.
- Verify recipients out of band. Use a pre-arranged contact path, known-clean device or in-person verification that does not depend on the account currently being recovered.
- Issue narrow, short-lived secrets. Prefer a temporary credential for one system and one recovery action over a broadly privileged replacement.
- Separate content from access. Do not place a medical export, password, decryption key and explanatory context together in one durable thread.
- Rotate again after containment. Incident credentials are a bridge back to normal operations, not permanent production secrets.
Protect the data transfer as well as the credential
Cancer-diagnostics workflows can involve referrals, reports, support exports and files exchanged with providers. The primary clinical record may have a lawful retention requirement, but temporary transport copies should not silently inherit an indefinite lifetime in email or chat.
For an approved ad-hoc exchange, an expiring one-time encrypted link can reduce persistent plaintext copies and limit reuse. Send only the necessary fields, verify the recipient separately and keep any access credential out of the same package. For high-impact recovery material, split custody or require two verified people rather than letting one compromised identity control the full secret.
These controls have a boundary. They do not protect data displayed on a compromised endpoint, secrets captured before encryption, or content exposed after a legitimate recipient decrypts it. They reduce exposure in the delivery workflow; they do not erase endpoint or identity risk.
What organizations should record now
- Which help-desk actions can reset MFA or enroll a new authenticator?
- Which SaaS sessions survive a password reset, and how are they revoked?
- Who can authorize exports containing personal health information?
- Where do temporary diagnostic files and support attachments expire?
- Which clean channel will deliver break-glass credentials during an identity incident?
- How will custody be logged without copying the secret into the incident record?
The public evidence does not show that these exact controls failed at Exact Sciences. They are the defensible decisions prompted by a confirmed vishing event: treat identity recovery and sensitive-data delivery as separate trust problems, and avoid rebuilding access through a channel that may still be compromised.
