Apify Data Breach: What Happened and What Your Company Should Do

The Apify data breach involves a platform that many companies use without knowing it: behind an n8n, Make or Zapier workflow that collects leads, competitor prices or reviews there is often an Apify Actor. On 9 and 10 November 2026 an attacker got into parts of Apify's internal systems. The Prague-based company detected the access on 11 November and has since rotated every customer API token. If your company uses Apify, directly or through a supplier, there are a few things to do today.

We are also writing this as customers. Selli uses Apify to enrich the data in two CRMs, and on 12 November we received both the email about the token rotation, sent to all customers, and the one about viewed account data, sent only to affected users. On the morning of the 13th our automated job failed with a 401 error on its first call: the stored token no longer existed.

What happened at Apify

Apify is a web scraping and browser automation platform. Users run Actors, small programs either ready-made or written in-house, that read websites, search engines and social networks and return structured data. According to its company page it has 91,000 customers worldwide.

The timeline, as told on Apify's status page:

• 9 and 10 November 2026: an unauthorised third party accesses parts of the internal systems;
• 11 November, 12:13 UTC: Apify detects the activity, cuts off access and opens an investigation;
• 11 November, evening: first public notice and precautionary revocation of some OAuth connections, including GitHub;
• 12 November: Apify explains that the attacker used a compromised credential to obtain further account credentials and access linked accounts, says it has closed that path and has notified the relevant authorities;
• 12 November, afternoon: emails go out to customers whose data was viewed. If you did not receive one, for now you do not appear to be affected.

The investigation is still open and Apify has promised a post-mortem. What follows is based on the official communications released up to 13 November and on coverage by BleepingComputer, so some details may change.

What data was exposed

In its email to affected users, Apify splits the data seen by the attacker into four groups:

According to Apify, full card numbers, security codes, secret environment variables and secret Actor inputs were not exposed. The company also says it found no evidence of access to Actors, runs and datasets, meaning the data customers collect with the platform.

The sensitive part is the two-factor authentication recovery codes. With those, an attacker who knows the password can bypass the second factor. That is why Apify has reset the 2FA settings of the affected accounts and is asking users to set them up again.

Apify API token: why the automations stopped

Many small and mid-sized businesses have never opened the Apify console. They get there through a marketing consultant who built a Make scenario to pull leads from LinkedIn or Google Maps, through an agency that tracks prices on Amazon, or through an integration built by an outside developer. In all these cases the Apify token is stored somewhere: in an n8n node, in a Zapier variable, in a .env file on a server, in a spreadsheet of "the keys" shared with the supplier.

Since 12 November those tokens, and the Apify Proxy passwords, no longer work. There are two practical consequences.

The first is operational: the workflows have stopped. The trouble is that someone doesn't always notice. A scenario that runs overnight and writes to the CRM can fail silently for days, and the first person to spot it is the salesperson who doesn't see Monday's leads come in. If your automation doesn't send alerts when a call returns 401, today is a good day to check it by hand.

The second is phishing. Anyone who has seen your name, billing address, VAT number, last card digits and subscription plan can write very convincing emails: a fake Apify invoice with the right details, a "failed renewal" with the correct last four digits, a link to "reactivate your token". Apify states clearly that it will never ask for your password. Warn your accounts team: with this data it is easy to put together a fake invoice that looks real.

What to do right now: the checklist

If you use Apify, or if one of your suppliers uses it on your behalf:

1. Find out who uses Apify and where. Do a quick round with marketing, sales and outside suppliers. The account is often registered to a consultant rather than the company: in that case they have to carry out the steps below, but it's up to you to check.
2. Get the new token and the new Proxy password from the Apify console and replace them everywhere: scripts, CI/CD pipelines, n8n, Make and Zapier credentials, server environment variables. If the token was written in several places, now is the time to keep it in just one.
3. If you received the email about viewed data, set up two-factor authentication again by following Apify's instructions, and store the new recovery codes outside your inbox and outside shared documents.
4. Reconnect GitHub if you build Actors from private repositories: from the Actor, "Change provider", then GitHub and authorise, once for each account and organisation. Also review recent activity on GitHub, as Apify suggests.
5. Reconnect the integrations for which Apify sent you a separate email.
6. Rerun by hand the jobs skipped from 12 November onwards (from the 11th if they depend on GitHub), if the data they produce is still needed (leads, price lists, reports).
7. Tell whoever pays the invoices to be wary of "Apify" emails asking for payments, credentials or urgent action, and to always check the sender.

For further updates, follow the status page, where Apify will publish the post-mortem.

Supplier data breach and GDPR: when the incident becomes yours too

The data seen by the attacker belongs to your account with Apify: for that data the controller is Apify, which says it has already notified the authorities. The data your company collects with the platform is a different matter, for example contacts of individuals extracted from public profiles. There you are normally the controller and Apify acts as the processor, under the data processing agreement (DPA) you accept with the service.

The Garante Privacy, Italy's data protection authority, sums up the GDPR rules: a processor that discovers a breach must inform the controller without delay, and the controller must notify the supervisory authority without undue delay and, where feasible, within 72 hours, unless the breach is unlikely to result in a risk to people. Every breach must still be recorded in the internal register, even when no notification is needed.

As of today Apify says it has found no access to datasets. Unless you have been told otherwise, there is probably nothing to notify for the data collected with the platform. Still, write down in the register what happened, what the supplier told you, when, and what you did: if Apify's investigation reaches a different conclusion, you will have everything ready. For doubtful cases the decision belongs with your DPO or privacy adviser, not with a blog post.

The lesson for anyone building automations

The token for an external service is a house key. In many small businesses that key is copied in five places, it is known to a consultant who has since changed jobs, and nobody can say which workflows would stop if it were changed. The Apify incident made many people find that out in a single day.

The rules we apply in our systems integration projects are few and boring:

• every external service has an account registered to the company, not to a person;
• every key lives in one place only (a vault or the server's environment variables) and the code reads it from there;
• there is an up-to-date list of which keys exist, who can see them and which workflows use them;
• every automation that calls an external API sends an alert when it gets a 401 or 403, instead of failing silently;
• a key can be changed in a few minutes without stopping everything, and this is tested at least once before it is really needed.

These are the same things required by an information security management system like the one described in our guide to ISO 27001: knowing what assets you have, who controls them and how you react when a supplier has a problem. For a wider view, we have also written a guide to cybersecurity for small businesses and a plain explanation of how APIs work.

In our case the stalled job was flagged by its own log on the first run. Not every automation put together in a hurry with no-code tools has this level of control, which is why it pays to check them again now, while the problem is still fresh.

Let's talk

If the Apify incident has turned up automations where you aren't sure who built them, where they keep their keys or what they do when they break, we can help you map them and put them in order. Selli works with ISO 27001 certification and designs integrations with centralised keys, alerts and ready-made rotation procedures. Write to us and we'll set up a half-hour call to look at your workflows together.