Czech automation platform Apify has confirmed that an intruder spent two days inside its systems and reached customer accounts, after turning one stolen credential into many. A customer breach notice suggests the haul included two-factor recovery codes plus sign-in tokens for Google and GitHub, so UK teams that rely on the service should act now rather than wait for the post-mortem.
What happened
Apify runs a cloud platform that businesses use to scrape websites, automate browsers and collect data from search results and social media. It says it has around 91,000 customers. On the evening of 11 November 2026 it posted a security incident notice on its status page. The notice said an unauthorised third party had been inside parts of its internal systems on 9 and 10 November, and that the activity was spotted at 12:13 UTC on 11 November, when access was cut off.
An update the following day was more specific. One stolen credential had been used to harvest more account credentials, which in turn opened related Apify accounts. By the afternoon of 12 November Apify said it had emailed every customer whose personal information or stored data had been accessed, and that anyone without an email had not been identified as affected so far. On 13 November it promised a post-mortem within a week.
Apify has not said how many accounts were reached, whose credential was stolen first or how it was obtained. It says it has informed the relevant authorities. This is the company’s second security incident of 2026: in March an employee’s GitHub account was hijacked and used to force-push malicious commits to repository branches, although Apify said at the time that branch protection kept them out of protected branches and it found no evidence customer data was affected.
The technical picture
The confirmed facts come from Apify’s own status page. Everything about specific data types comes from elsewhere, and that distinction matters. Apify has not published an inventory of what was exposed. The most detailed list available is a breach notification that one customer posted on the r/apify subreddit, which SecurityWeek and SQ Magazine have both reported. According to that notice, the accessed data included names, email and IP addresses, phone numbers, billing information, account activity logs, salted password hashes, 2FA recovery codes and tokens tied to Google and GitHub logins. The same notice reportedly limits card data to cardholder name, expiry date and the last four digits.
Other notices appear to differ. SQ Magazine reports that one letter said no sign was found that data stored on the platform was affected, while another sample notice said the affected customers’ API tokens and proxy passwords for Apify had been rotated, and a third told recipients to reset their 2FA. Customers were probably exposed to different degrees; Apify has not said.
On remediation, Apify says it rotated critical internal secrets, added monitoring, tightened network restrictions between internal services and strengthened authentication on internal systems. As a precaution it revoked some OAuth connections to external integrations, GitHub included, while stating that its investigation has not found those connections were an attack vector. Customer API tokens are now kept in hashed form only. It has also warned customers that storage left on open access can be read by anyone who knows its ID, and recommends switching general resource access to Restricted.
Why it matters for UK organisations
Scraping and automation platforms rarely appear on supplier risk registers, yet they often sit in the middle of marketing, pricing, research and AI data pipelines. A UK team using Apify may have connected it to GitHub repositories, Google accounts, cloud storage and webhook endpoints, and may have stored the output of scraping jobs, some of which can contain personal data, on the platform itself. If the reported data types are accurate, a stolen token or recovery code is a route into those connected systems, not just into an Apify account.
There is also a data protection angle. Where an organisation used Apify to collect or hold personal data, it is likely to be the controller and Apify a processor. A supplier’s notice does not discharge your own UK GDPR obligations: you still need to assess the risk to individuals, record the incident and decide within 72 hours of becoming aware whether it must be reported to the ICO.
Expert view
The pattern here is one we keep meeting: a single credential, almost certainly a high-privilege one, becomes a key ring. In my experience, the gap is rarely the perimeter. It is that an internal identity can reach secrets stores or account data it never needed, with nothing alerting on unusual bulk reads. Apify caught the activity within about two days, which beats the dwell times many breached firms report, but two days is still plenty of time to copy a lot of tokens.
The item that worries me most on the reported list is the 2FA recovery codes. They exist precisely to bypass a second factor, so a cracked or reused password combined with a valid recovery code defeats MFA outright. If those codes were exposed, customers should treat their second factor as compromised until they regenerate it. Third-party OAuth tokens are the other concern: when we test cloud estates, long-lived integration tokens with broad repository or drive scopes are among the easiest paths from a peripheral tool to source code and documents.
Credit where it is due: Apify’s updates have been regular and specific, and hashing API tokens is the right structural fix. Until the post-mortem explains the initial access route and whether stolen tokens have been used, assume the worst for any account that received a notice.
What to do now
- Check for a notice. Confirm whether any Apify account in your organisation, including ones set up by individual teams, received an incident email, and follow its instructions first.
- Reset second factors. Regenerate 2FA and recovery codes in the Apify Console and change the account password, plus anywhere it was reused (Cyber Essentials: user access control).
- Rotate integration secrets. Replace Apify API tokens and proxy passwords in scripts, CI pipelines and secrets managers, and reconnect GitHub with the narrowest scope that works.
- Review connected apps. In Google Workspace and GitHub, audit third-party OAuth grants, revoke anything unused and check audit logs from 9 November onwards for unfamiliar activity.
- Lock down storage. Set Apify resource access to Restricted and review what scraped data is held on the platform and whether it needs to be there.
- Assess UK GDPR duties. If personal data was stored or processed through Apify, run a risk assessment, log the incident and decide promptly on ICO notification.
- Warn staff. Brief finance and engineering teams to expect phishing that references Apify billing or security resets; Apify says it will never ask for passwords, 2FA codes or card details.
Bottom line
Apify has confirmed a breach that reached customer accounts, but not yet the full extent of it. The worrying details, recovery codes and sign-in tokens, come from a customer notice rather than the company, and may not apply to everyone. That uncertainty is a reason to act, not to wait: rotate, reset and review integrations now, and read the post-mortem when it lands.
