TSMC employee data leak: what a cloud vendor exposure teaches about third-party and fourth-party risk

Short answer. On 12 November 2026, TSMC told investors that "some of our current and former employee data was made available on an external website without authorization." In the same Form 6-K filing, the company said the data "has been verified to match data stored in the system services of a cloud service provider," that it is "unrelated to the company's operations or customer-related data," and that "Currently, we have found no evidence that TSMC's systems have been compromised." TSMC did not name the provider, and neither do we.

Sellers on underground forums claim to hold about 46,000 records, roughly 6.9 GB, and reportedly set a price of 3 BTC with a one-week deadline. A posted sample is reported to contain 499 records with 19 fields, including national ID numbers, home addresses and bank details. None of those numbers come from TSMC.

This is a textbook third-party data incident. The employer's own network can be clean while its people's most sensitive data leaks from somewhere else. The rest of this post sets out what is confirmed, what is only claimed, why HR and payroll data sits at vendors in the first place, how attackers go after it, and what employees and security teams can do this week.

At a glance

What TSMC actually disclosed

TSMC is listed in Taiwan and its American Depositary Shares trade in New York, so material statements reach the US Securities and Exchange Commission as Form 6-K reports. The 12 November filing is short, titled "Statement Regarding the Unauthorized Access of Employee Personal Data", and it is the most authoritative document on this incident so far. We read the English filing on SEC EDGAR (accession 0001046179-26-000800).

Five statements in it matter.

1. The exposure. "Some of our current and former employee data was made available on an external website without authorization." Note "current and former". Former employees often forget that an old employer, and that employer's vendors, still hold their records.
2. The match. The data "has been verified to match data stored in the system services of a cloud service provider." The leaked data was checked against what the vendor held, and it matched. That's the step that ties a forum listing to a specific data store.
3. The boundary. The data "is unrelated to the company's operations or customer-related data." Several outlets add that TSMC said production data was not involved (TokenPost, AMBCrypto).
4. The qualifier. "Currently, we have found no evidence that TSMC's systems have been compromised." The word "currently" is doing honest work. It's an assessment at a point in time, as Cyber Press also pointed out.
5. The response. TSMC said "We have been informing impacted personnel and are providing them with necessary support," and that it has "engaged with both the cloud service vendor, the relevant investigating authorities, and a third-party cybersecurity agency."

What the filing does not say is just as important. It gives no count of affected people, no list of data fields, no name for the provider, no description of how the data left the provider and no date for when it happened. Those gaps are normal in a first disclosure. They also mean that every number circulating in the press, other than the date, comes from the sellers.

What the sellers claim

Every figure in this section is a claim by the people trying to sell the data, as reported by the press. We have not seen the data, and TSMC has not confirmed any of these numbers.

• Volume. About 46,000 records covering current and former employees, around 6.9 GB in total. Republic World, carrying an ANI report, attributes the figure to Taiwan's Central News Agency. Cybersecurity News attributes it to Taiwan News.
• Price. 3 BTC. AMBCrypto put that at about US$214,700 at the time of writing; BigGo Finance gave about NT$7.4 million, or roughly US$220,000.
• Venue. Listings on DarkForums and BreachForums, as reported by Cybersecurity News and TokenPost.
• Deadline. The sellers reportedly threatened to publish the full set if no buyer appeared within a week.
• Sample. A file reportedly named "tsmc.txt" with 499 records and 19 fields per record (BigGo Finance; TokenPost also reports 499 records and 19 fields).
• Fields. Reported fields include names, dates of birth, job titles, nationality, national ID numbers, home addresses, mobile numbers, email addresses, bank account details and emergency contacts' phone numbers and addresses (BigGo Finance, Republic World).

Reports disagree on one point worth noticing. Some headlines call the 3 BTC a ransom to withhold the data. Others describe an auction with a starting bid. AMBCrypto's own text says the seller was looking for a buyer rather than demanding a ransom, even though its headline says "demands". The difference matters less than it seems. A sale and an extortion demand both put a price on silence, and a buyer can always re-sell.

No threat actor name has been published, and no group has been credibly linked to the listing.

What nobody knows yet

It is easy to fill gaps with guesses. We won't. Here is what remains open, according to the filing and the outlets that covered it.

• Which provider. TSMC said "a cloud service provider". It did not say which one, or what service that provider ran for TSMC (payroll, HR system, benefits, analytics, backup or something else).
• How the data left. Stolen credentials, a misconfigured store, an exposed token, an insider, a vendor's own supplier: all are possible in principle and none has been reported. GBHackers made the same point: matching records to a provider ties the leak to that dataset but does not establish how it was compromised.
• When. We don't know when the data was taken or when the listing went up.
• How many people. TSMC has not given a count. The 46,000 figure is the sellers'.
• Which countries. TSMC employs people in Taiwan and also runs operations in the United States, Japan, China and Europe. Whether records from outside Taiwan are in the set has not been reported.
• Whether anyone bought it. Unknown.

If you are reading this as an affected employee, the practical answer is the same either way: assume the reported fields about you are in criminal hands, and act on that.

Timeline

This is not TSMC's first supplier-side incident. In June 2023, TSMC said that one of its IT hardware suppliers had been hit (SecurityWeek identified it as Kinmax Technology), after the LockBit ransomware group claimed an attack on TSMC itself and reportedly demanded US$70 million. TSMC said then that the incident "has not affected TSMC's business operations" and that it had "immediately terminated its data exchange with this concerned supplier" (SecurityWeek, 30 June 2023). Different supplier, different data, same lesson: for a company this well defended, the soft edge is often the supply chain.

Why "our systems were not breached" is not the end of the story

TSMC's statement is precise and, as far as anyone can tell, accurate. Its own network may be untouched. But the employees whose national ID numbers and bank details are reportedly up for sale are no better off for that.

Data protection law generally agrees. Under Taiwan's Personal Data Protection Act, a party that collects, processes or uses personal data on commission from another organisation is treated as acting for that organisation within the scope of the commission (PDPA Article 4), and the Enforcement Rules require the commissioning organisation to supervise its commissioned party (Enforcement Rules Article 8, discussed below). In Europe, GDPR says the same thing in different words: the controller remains responsible for what its processors do with the data it hands them.

So the right mental model is this. When you hand employee data to a vendor, you have not handed over the risk. You have moved the data to a place you can't see as well, run by people you don't employ, on infrastructure you don't control, and you still answer for it.

Why HR and payroll data lives at vendors

Almost no large employer runs every people process in-house any more. Employee records flow out to a long list of outside services, each for a sensible reason:

• Core HR system of record. Cloud HR suites hold the master employee file: identity, job history, compensation, reporting lines.
• Payroll. Payroll engines need bank account details, tax identifiers and national ID numbers to pay people and file with the authorities.
• Benefits and insurance. Health, life and pension providers need dependants, dates of birth and sometimes medical information.
• Recruiting. Applicant tracking systems hold CVs, assessments and background checks, often for people who never joined.
• Background screening and visas. Screening firms and immigration law firms hold passport numbers and family details.
• Expenses, travel and corporate cards. Bank details, travel itineraries, passport data.
• Identity and access. Single sign-on and directory services hold every user and their attributes.
• Analytics and data warehouses. HR teams increasingly copy all of the above into cloud warehouses for workforce analytics.
• Backups and archives. Every one of those systems, and every export from them, has copies somewhere.
• AI tools. HR staff paste records into assistants and summarisers, which call model providers in turn.

Each of those flows is another copy. Many of them hold the same high-value fields. That is why HR datasets are such a good target: a single vendor can hold a complete identity kit for tens of thousands of people, including family members listed as emergency contacts who never agreed to anything.

Third parties, fourth parties and beyond

A third party is a vendor you contract with directly. A fourth party is your vendor's vendor: the cloud platform your payroll provider runs on, the support desk tool it uses, the AI inference service behind a feature you turned on. You have no contract with fourth parties, often no list of them, and usually no right to audit them.

This week gave a perfect example of how long the chain gets. Notion said its AI vendor, Fireworks AI, notified it of a security incident affecting Notion AI chat transcripts used for its Insights feature, in "fewer than 1% of Notion workspaces" (Notion). TechCrunch reported that the attacker breached Fireworks' own cloud provider and used that access to reach a Fireworks development system. For a Notion customer, that cloud provider is a fifth party. Notion also said "data was retained from the Fireworks endpoints that we used", despite its zero data retention commitment. Contracts state intentions. They don't prove behaviour.

How attackers reach vendor-held data

We don't know how the TSMC-related data left its provider. What we can do is describe the paths that recur in vendor-side incidents, using cases where the facts are public. Treat this as a checklist for your own vendors, not a theory about this one.

1. A single stolen credential. Apify said an unauthorised party used one compromised credential to obtain more credentials and reach related accounts, during an intrusion on 9 and 10 November (SecurityWeek). One credential is usually all it takes when the account behind it has no second factor and broad standing access.

2. An exposed test or admin instance. Chainstack's technical update said its intruder entered through an internet-exposed Grafana test instance in a development Kubernetes cluster, still on default administrator credentials and without single sign-on or basic authentication, then used it to reach an unauthenticated internal tool server with cluster-admin rights (Chainstack). Chainstack reported no evidence that a software vulnerability was exploited. Nobody needed one.

3. Long-lived tokens and API keys. Chainstack listed "long-lived credentials" among the weaknesses the attacker chained. Chainalysis said names, usernames, password hashes and live tokens for all users were exposed (The Hacker News). A token that never expires is a permanent key to whatever it can read.

4. The vendor's own infrastructure provider. The Fireworks case shows the cloud layer under a vendor can be the entry point, with the vendor's development system as the next hop (TechCrunch).

5. A flaw in a shared product many vendors use. In 2023, the Cl0p group exploited a SQL injection flaw in the MOVEit Transfer file transfer product, CVE-2023-34362. CISA's advisory notes that the group "preferred to rely mostly on data exfiltration over encryption" and "threatened to publish the stolen files" on its leak site (CISA AA23-158A). One of the victims was UK payroll provider Zellis, and through it the staff of British Airways, the BBC and Boots, with reports listing names, addresses, National Insurance numbers and, for some, bank details (The Record, The Register). That is the closest public parallel to a payroll data leak through a supplier.

6. Data that should not have been there. Retained exports, forgotten test copies with real data, staging environments loaded from production, and AI vendors keeping prompts they promised to drop. The Notion statement about retention is the example from this week.

7. People. Help desk social engineering, password resets talked through over the phone, and insiders with legitimate access. These don't show up in a vulnerability scan at all.

The pattern across all seven is that the attacker goes where the data is, and the data is increasingly not in your building.

The economics of selling employee data

Why would anyone list a claimed 46,000 employee records for a reported 3 BTC? A few things are going on.

The price per record is low, and that's the point. Taking the sellers' figures at face value, US$215,000 for 46,000 records is under US$5 a record. A buyer who uses even a small share of the records for fraud recovers that quickly. Low prices widen the pool of buyers and make re-sale likely.

Employee data from a strategic company has more than one use. Bank details and national ID numbers serve ordinary fraud. Names, job titles, phone numbers and home addresses for engineers at the world's leading contract chipmaker also serve targeted phishing, fake recruiter approaches and pretext calls aimed at specific people. Nothing reported so far says that is happening here. It is simply why such data sells.

Samples are marketing. A 499-record sample proves the seller has real data without giving the whole set away. It's also the kind of material that lets a victim check records against its own and its vendors' systems. Samples cut both ways.

Paying buys nothing durable. Whether you call it a ransom or a purchase, nobody can verify deletion. Data that has been copied once has probably been copied more than once. Plan as if the data will be public eventually, because a lot of it usually is.

The regulatory angle

This section is general information, not legal advice. Talk to counsel about your own obligations.

Taiwan's Personal Data Protection Act today

Taiwan's PDPA already gives individuals a right to be told. Article 12 requires an organisation to notify the data subject, after investigation, when personal data is stolen, leaked, altered or otherwise infringed because of a violation of the Act. TSMC's statement that it is "informing impacted personnel" is consistent with that duty.

Two other pieces matter for vendors:

• Commissioned processing (Article 4). A party that processes personal data on commission is treated as acting for the commissioning organisation within the scope of the commission.
• Supervision (Enforcement Rules Article 8). The commissioning organisation must supervise its commissioned party. The supervision covers the agreed scope, categories, purpose and period of processing, the security measures, any sub-contracting, how violations are reported and remedied, and any instructions the commissioning party reserves (Enforcement Rules, 2016 amendment, unofficial English; see also Chambers' Taiwan cloud computing guide on supervision of cloud providers). In plain terms: you are expected to know what your vendor does with your data and to check it.

Civil damages under the PDPA can be claimed even where actual loss is hard to prove, with a statutory range per person and an aggregate cap for group actions, as summarised by DLA Piper's Taiwan entry.

The 2025 amendments

The Legislative Yuan passed amendments to the PDPA on 17 October 2025, and they were promulgated on 11 November 2025 (Baker McKenzie, K&L Gates). They create an independent Personal Data Protection Commission (PDPC). For private-sector organisations, the key changes are:

• a duty to "take immediate and effective remedial measures to prevent the escalation of the incident";
• a duty to report qualifying breaches to the PDPC, not just to individuals, with thresholds and time limits to be set by PDPC regulations;
• a duty to record the facts, impact and measures taken and keep those records for inspection;
• security rules for personal data files set by the PDPC (Article 20-1), with fines for violations; and
• fines for failing to report, per K&L Gates, of NT$20,000 to NT$200,000, repeatable for each failure to rectify.

The effective date is set by the Executive Yuan. As of the most recent law-firm summaries we could find, including DLA Piper's entry last updated in March 2026, the amendments were not yet in force and the PDPC was still a preparatory office. Check the current status before relying on either version. The direction is clear, though. Taiwan is moving toward regulator notification and documented incident handling, the model most of the world already uses.

GDPR, where it applies

If an employer, or the vendor, processes data about people in the European Union, the GDPR (Regulation (EU) 2016/679) adds its own obligations:

• Article 28. Controllers may use only processors that give "sufficient guarantees", under a written contract that covers instructions, confidentiality, security, sub-processors, assistance with breaches, deletion or return at the end, and audits.
• Article 32. Both controller and processor must apply security appropriate to the risk.
• Article 33. The controller must notify its supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of a breach, unless it's unlikely to result in a risk to people. The processor must notify the controller without undue delay.
• Article 34. Where a breach is likely to result in a high risk to people, the controller must tell them directly.

The European Data Protection Board's Guidelines 9/2022 on personal data breach notification are the practical reference. One of their points matters here: the controller is generally treated as aware once its processor has told it. A vendor that sits on a breach for weeks burns your clock.

National ID numbers combined with bank details are the kind of data that regulators usually treat as high risk. Whether GDPR applies to any of the records in this case depends on facts that have not been reported.

What affected employees should do

If you work or worked at TSMC, or at any company whose employee data is in a leak like this, here is a practical list. Start with what the employer tells you. TSMC said it is notifying affected personnel and providing support, so read that notice first and use the channels it gives.

1. Assume the reported fields are exposed. That means your name, date of birth, national ID number, home address, phone, email, bank account and your emergency contacts' details.
2. Warn your emergency contacts. Their phone numbers and addresses are reportedly in the data, and they never chose to be in an HR system. A short message to family members saves them from a convincing scam call.
3. Expect targeted calls and messages. Fraudsters will use real details to sound legitimate. Common pretexts are calls from "the bank", "the police", "the investigation team", "HR" or a "lawyer handling compensation". Hang up and call back on a number you find yourself. In Taiwan, the National Police Agency's 165 anti-fraud hotline can check suspicious contacts.
4. Talk to your bank. Ask for transaction alerts, ask whether you can add extra verification for phone requests, and watch for small test transactions and unfamiliar direct debit set-ups.
5. Check your credit file. In Taiwan, you can request your credit report from the Joint Credit Information Center (JCIC) to look for loans or cards you didn't open. If you live in the United States, freezing your credit with the three bureaus is free.
6. Be careful with "support" offers. Real breach support comes through your employer's official notice. Unsolicited offers of identity protection, legal claims or "data removal" services that arrive by text or social media are a classic follow-on scam.
7. Lock down your accounts. Use unique passwords and turn on app-based or hardware-key second factors for email, banking and government services. A phone number alone is a weak recovery method once attackers know it.
8. Keep records. Save the employer's notice and any suspicious contacts. If fraud happens, a clear record makes it easier to dispute and to report.
9. Don't go looking for the data. Downloading leaked datasets to check whether you are in them can expose you to malware and, in some places, legal risk. Rely on your employer's notification.

What security teams should do

Every organisation has a TSMC-shaped exposure somewhere: a vendor holding employee or customer data it can't see. The goal is to know where that data is, limit what each vendor holds, and hear about problems fast.

1. Build a real vendor inventory

Start from money and identity, not from procurement's list. Pull every recurring payment from finance, every application in your single sign-on catalogue, every OAuth grant in your collaboration suites and code hosts, and every vendor with an API key or service account in your cloud. Merge them. The result is always longer than the official vendor register.

For each vendor, record who owns the relationship, what business process it supports, which data categories it holds, where that data is hosted, and who its key sub-processors are. Ask for the sub-processor list in writing. That list is your fourth-party map.

2. Map the data, field by field

Tier vendors by the data they hold, not by contract value. A small benefits broker holding national IDs and bank details for every employee is a higher risk than a large design tool holding names and email addresses.

Then ask the minimisation question for every field. Does the engagement survey tool need date of birth? Does the travel booker need a national ID number, or only a passport for those who travel? Does the analytics warehouse need bank details at all? Every field you don't send is a field nobody can leak.

Former employees deserve their own line. Retention schedules for leavers are often vague, and vendors keep data long after the person has gone.

3. Put the right clauses in the contract

Contracts don't stop breaches, but they decide what you learn and when. For vendors that hold personal data, look for:

• Breach notification with a clock. A defined deadline from discovery, such as 24 or 48 hours, plus what the first notice must include and how often updates follow.
• Sub-processor control. A current list, advance notice of changes, a right to object, and flow-down of the same obligations.
• Security baseline. Multi-factor authentication for all administrative and support access, encryption at rest and in transit, logging retained for a stated period, and timely patching.
• Audit and evidence rights. Independent assurance reports such as SOC 2 Type II or ISO/IEC 27001 certificates, penetration test summaries, and the right to ask follow-up questions.
• Data location and retention. Where data is stored, how long it is kept, and certified deletion or return at the end of the contract.
• No secondary use. No training of models on your data, and no retention by the vendor's AI providers beyond what the contract allows. Ask how they verify it, given the Notion example.
• Cooperation. Access to forensic findings, help with regulator and employee notifications, and cost allocation for notification and support services.
• Software transparency. For vendors whose software you run or integrate, a software bill of materials (SBOM) and timely vulnerability statements.

4. Make breach notice SLAs real

A clause is only as good as the plumbing behind it. Give each critical vendor a named security contact and a shared, monitored mailbox on your side. Test the path once a year with a tabletop: "you have just found our employee export on a forum, what do you send us in the first four hours?"

Remember the GDPR point above. Once your processor tells you, your own clock is usually running. Have the regulator and employee notice templates drafted before you need them.

5. Monitor vendors continuously, not annually

Annual questionnaires go stale the day they are filed. Continuous monitoring means watching for changes that alter a vendor's risk between reviews: a new critical vulnerability in software they ship you, a vulnerability added to the KEV catalogue, a lapsed certification, a change of sub-processor, a public breach disclosure, or an acquisition.

Assign an owner to each alert. Monitoring that nobody reads is just a nicer-looking questionnaire.

6. Ask for SBOMs and vendor software evidence

Several of this week's incidents started with components: a "third-party component" at Chainstack, a test instance of a common open-source dashboard, and in 2023, a file transfer product used by payroll firms. If a vendor's software runs in your environment or holds your data, ask for an SBOM in SPDX or CycloneDX format, ask how they track and fix vulnerabilities in it, and ask for attestations about how it was built. When the next MOVEit-style flaw lands, you want to answer "which of our vendors run this?" in minutes, not weeks.

7. Treat vendor tokens and keys as high-value secrets

Most of this week's breaches turned on credentials. For every cloud vendor integration:

• Inventory every token, API key, OAuth grant and service account that connects your systems to a vendor, and the reverse.
• Prefer short-lived credentials. Use federation and workload identity where vendors support them. Where they don't, rotate on a fixed schedule and on every staff change.
• Scope down. Read-only where possible, one dataset per token, no tenant-wide admin keys for integrations.
• Require phishing-resistant MFA on every vendor admin console your staff use, and disable shared logins.
• Restrict by network. Many vendors support IP allowlists for API access. Chainalysis made trusted IP allowlisting a condition for customers to regain access (The Hacker News). Do it before you are forced to.
• Log and alert on use. Unusual export volumes, new IP addresses and off-hours bulk reads from an HR integration are exactly the signals that matter.
• Have a rotation runbook. When a vendor discloses a breach, you should be able to rotate every credential tied to it in an hour. Chainstack, Chainalysis and Apify all asked customers to rotate or reconnect.

8. Prepare for "your data is on a forum"

TSMC's response shows the right first move: verify the leaked data against your data stores and your vendors' before saying anything. You can make that easier ahead of time. Seed each critical vendor's dataset with a few unique, harmless canary records, such as made-up staff entries with distinctive values that exist nowhere else. If a leak contains one, you know where it came from on the first look. Keep the canary list protected and private, and agree the approach with legal so it fits your data protection obligations.

Fix it without waiting for upstream

You can't patch your vendor, and you can't make them finish their investigation faster. You can shrink your exposure, cut off the paths that matter, and protect your people today. None of these steps needs the vendor's help.

1. Rotate every credential tied to vendors that hold people data. API keys, OAuth tokens, service accounts, SFTP keys. Do the HR, payroll and benefits integrations first. If a vendor won't support rotation without downtime, that's a finding.
2. Revoke OAuth grants you can't explain. Review third-party app consents in your identity provider, collaboration suite and code hosts. Remove anything unowned or unused.
3. Turn on MFA everywhere you hold an admin seat in a vendor console, and remove shared accounts. Start with the HR suite and payroll.
4. Restrict vendor API access by IP where the vendor supports it, and set export limits or alerts on bulk downloads.
5. Stop sending fields you don't need. Edit integration mappings so national IDs, bank details and dates of birth go only to the vendors that legally need them. Change the export, not the policy document.
6. Purge old exports. Search shared drives, buckets and mailboxes for HR extracts and old payroll files, and delete what retention rules don't require.
7. Cut leavers' data. Ask each HR vendor to confirm retention for former employees, and request deletion where retention has expired.
8. Write the notification and support pack now. Draft the employee notice, a scam-warning one-pager for staff and families, and the regulator notice. Line up identity-protection support so you can offer it on day one.
9. Brief your help desk and finance team. Leaked HR data powers pretext calls to change bank details for salary payments or to reset accounts. Require call-backs on known numbers for any payroll change.
10. Add canary records to each critical vendor's dataset, as described above.
11. Ask your top ten data-holding vendors three questions this week. What is your notification deadline, who are your sub-processors, and when did you last rotate the credentials your support staff use to reach our data?

Each step works whether or not the vendor ever tells you more.

How Safeguard helps with this class of problem

TSMC disclosed this incident itself, through its own filing. Our part is to help teams manage the vendor and software supply chain risk that incidents like this expose. These are the generally available capabilities that map to the steps above.

Third-Party Risk Manager (TPRM). TPRM keeps a vendor directory with contracts, SLAs and risk tiers, and gives vendors a self-service portal. You can request SBOMs and other evidence from vendors one at a time or in bulk, track each request from sent to validated, and let automated follow-ups chase the stragglers. Each vendor gets a risk score across vulnerability, compliance, component and operational risk, enriched with EPSS and CISA KEV data. Continuous monitoring alerts on new critical vulnerabilities, KEV additions, risk changes and SBOM expiry, and sends them to email, Slack, Teams, PagerDuty or a webhook so they reach an owner.

Vendor software assurance with SBOMs. Safeguard generates and analyses SBOMs in SPDX and CycloneDX and accepts CSAF and VEX documents. When a component in a vendor's SBOM becomes known-exploited, it moves up the queue, and you can answer "which vendors ship this?" from the SBOMs you already hold.

Compliance automation. The compliance suite brings frameworks, controls, evidence, monitoring, questionnaires, risks and vendors into one place, with continuous evidence collection across major clouds and identity providers. Teams use it to map controls and gather evidence for SOC 2, ISO/IEC 27001 and GDPR, including the vendor oversight controls those frameworks expect. Safeguard itself is SOC 2 Type I and Type II audited, so we answer the same vendor questions we suggest you ask.

Policies and gates. You can write organisation-wide policies, including from plain-English prompts, and enforce them as gates at build, CI and release, with actions to block, warn, notify or require approval. One example is a rule that no release ships with a known-exploited component.

Asset discovery. Asset discovery inventories repositories, images, packages, SBOMs, vendors and workloads, and applies guardrails and enforcement to what it finds, so your vendor inventory starts from what is actually connected rather than from what procurement remembers.

You can see the platform at https://safeguard.sh.

Other breaches this week and last

Each of these comes with a reputable source. Most share a theme with the TSMC case: the data sat with a service provider, and credentials were the lever.

• Apify (intrusion 9 and 10 November). The Czech web scraping and automation company said an attacker used one compromised credential to obtain more credentials and reach related accounts. It found the activity on 11 November and confirmed on 12 November that customer data was accessed. According to a customer notice described by SecurityWeek, exposed data included salted password hashes, 2FA recovery codes, phone numbers, and authentication tokens tied to Google and GitHub sign-ins, plus limited card data (cardholder name, expiry and last four digits). Apify revoked some OAuth connections, including GitHub, and asked customers who build from private GitHub repositories to reconnect (SecurityWeek).
• Fireworks AI and Notion (reported 12 November). Fireworks AI said an attacker breached its cloud provider and reached a Fireworks development system, taking customer billing information and some datasets. Notion said Notion AI chat transcripts used for its Insights feature were affected, in fewer than 1% of workspaces. It disconnected from Fireworks, disabled Insights and told users to rotate any credentials pasted into Notion AI chats. TechCrunch notes this is the second breach affecting Fireworks in as many months (TechCrunch, Notion).
• Chainalysis (reported 6 November). The blockchain analytics firm said an external actor using "offensive agentic techniques" exposed names, usernames, password hashes and live tokens for all users. It pulled Reactor, Data Solutions, the KYT interface and API and its address screening products offline, and required trusted IP allowlisting before customers reset passwords and rotated API keys. Chainalysis said it had "no evidence that any investigations data has been accessed." An update on 7 November said Reactor, KYT and Address Screening were restored (The Hacker News).
• Chainstack (disclosed 3 November). The blockchain infrastructure provider said an attacker entered a development environment on 26 October "through a third-party component", reached parts of production by 29 October and was cut off on 31 October. Exposed data included organisation names, account holder names, member email addresses and password hashes. Node credentials sat in systems the attacker reached, so Chainstack treats them as exposed and asked customers to rotate them, regenerate API keys and change reused passwords (The Hacker News, Chainstack).

Two threads run through all five incidents, TSMC included. The data that leaked was held by a service provider rather than inside the victim's walls. And the attacker's way in, where it is known, was a credential, a token or an unprotected admin surface, not an exotic exploit.

FAQ

What happened in the TSMC data leak?

TSMC said on 12 November 2026 that data on some current and former employees appeared on an external website without authorization. The data matched records held by an unnamed cloud service provider. TSMC said it currently has no evidence its own systems were compromised, and that the data is unrelated to its operations or customer data.

How many TSMC employees are affected?

TSMC has not said. Sellers claim about 46,000 records totalling 6.9 GB, but that number is unverified and comes from the people trying to sell the data.

What data was exposed?

TSMC has not published a field list. A reported 499-record sample, said to be named "tsmc.txt", has 19 fields, reportedly including names, dates of birth, national ID numbers, addresses, phone numbers, email addresses, bank account details, job titles and emergency contacts.

Was customer data or chip technology affected?

TSMC said the exposed data "is unrelated to the company's operations or customer-related data." Reports also say TSMC stated production data was not involved.

Which cloud provider was involved?

TSMC did not name it, and we won't guess.

Did TSMC pay the 3 BTC?

There is no report that TSMC paid, and TSMC has not commented on the demand. Reports differ on whether the 3 BTC is a ransom or an auction starting price.

What should affected employees do first?

Read TSMC's notice, warn your emergency contacts, call your bank about alerts and extra verification, check your credit file, and treat any unexpected call or message that uses your details as suspect. In Taiwan, the 165 anti-fraud hotline can help verify suspicious contacts.

What does Taiwan's PDPA require after a breach like this?

Today, Article 12 requires notifying affected individuals after investigation. The 2025 amendments add reporting to a new Personal Data Protection Commission and documented remedial measures, but their effective date depends on the Executive Yuan, so check the current status.

How can companies reduce third-party data risk?

Keep a complete vendor inventory, map which vendor holds which fields, send each vendor only what it needs, put breach notice deadlines and sub-processor controls in contracts, monitor vendors continuously, ask for SBOMs, and rotate and scope every vendor token and key.

How does Safeguard help with third-party data risk?

Safeguard helps organisations manage vendor and software supply chain risk with third-party risk management, SBOM-based vendor software assurance, compliance automation, policies and gates, and asset discovery.

Sources

Primary: TSMC Form 6-K, 12 November 2026, Notion's incident notice, Chainstack's incident notice, GDPR and CISA AA23-158A. All press reporting on the sellers' claims, the Taiwan PDPA analysis and the roundup is linked inline where it is used.