Apify says a compromised credential reached related accounts; its incident page lists no exposed data fields

Apify's first public post came 7 hours 33 minutes after the detection time it prints (derived)

Apify's status page, headed "Security incident", says the company detected the activity "on 11th November at 12:13 UTC". Its first public post is stamped 20:46 CET on 11 November 2026. The page's own machine readable stamp for that post is 19:46:21 UTC, which confirms that the printed CET is UTC plus one hour. From 12:13 to 19:46 is 7 hours 33 minutes (derived). The same page puts the access on "9 and 10 November" with no hours and no time zone, so the time between the intrusion and the detection cannot be worked out from it.

What that does not establish. The 7 hours 33 minutes is a gap between two stamps on one page. It does not show that anything was held back. The page does not say when Apify decided to post, whether customers were told by email before the post went up, or what the post was waiting for. The first post carries no field list and no promised time for the next update. A second derived figure sits in the timeline below: the fourth post came 24 hours 20 minutes after a post that promised an update within 24 hours. Both are arithmetic on stamps, not findings about conduct.

Vendor interest, once. Apify sells the platform and writes and controls this page, so every statement on it is the company's own account of itself. SecurityWeek's report is a secondary source, and the field list it prints comes from a customer's notification posted on Reddit, which this site did not read.

The four updates in order, with what each adds and what it drops

The page holds four stamped updates. The table copies the wording and sets each update against the one before it. UTC is derived from the printed CET at one hour, as the page's own stamps confirm. Apify's words are in quotation marks; the right hand column is this site's reading of what changed.

The promised windows against the stamps. Three of the updates print a time for the next one. The table sets each promise against the next stamp, using the printed minutes. All differences are derived.

Zoom

Cautions on the arithmetic. A stamp is the time of a post. A status page can be edited after posting, and this site sees only the saved copy, so a gap here is a gap between stamps, not between events. The 24 hours may have been meant loosely; the page does not say. The page's own second level stamps give 24 hours 19 minutes 27 seconds for the same gap, so the minute level figure of 24 hours 20 minutes and the second level figure both put the post just over the window. The access dates add one more calendar count: from 9 November to the fourth post on 13 November is four calendar days (derived), and the page states no end date for the access beyond "9 and 10 November".

What happened, in the order the page gives it

Apify's second update states the mechanism in one sentence: an unauthorized third party "used a compromised credential to obtain a number of account credentials and accessed related Apify accounts". That is three steps with no detail in any of them. The page does not say where the first credential came from or whose it was, how many account credentials were obtained, what "related" means, or what was done inside the accounts. The incident is tagged as affecting "API (api.apify.com), Actors, and General"; those are the page's component labels, and the page does not say what each one means for the data.

Zoom

Two wordings that may or may not be the same thing. The first post says access was gained to "parts of Apify's internal systems". The second says the access reached "related Apify accounts". The page does not say whether the internal systems and the related accounts are the same thing, one inside the other, or two findings. It also says the investigation "has not found that these connections could be used as an attack vector" about the revoked OAuth connections. That is the absence of a finding, not a finding of absence, and Apify frames the revocation as "As a precaution".

What closed, and what was added. The second update says "This access path is closed, and we have detected no further activity from the attacker since 11 November." The fourth update says Apify "Added additional security layers to block the attack paths", naming network restrictions between internal services and stronger authentication on internal systems, and describes "Continuing log analysis and monitoring for any suspicious activity." The page does not say whether there was more than one path, whether the attacker has been identified, or whether any activity before 11 November, other than on 9 and 10 November, has been ruled out.

The page names no data fields; a relayed notification does

The only sentence about what was taken is in the third update: customers were notified "whose personal information or stored data was accessed". The page adds "Details are in the email they received." It prints no field, no data class and no count. SecurityWeek, published at 12:41 UTC on 13 November, reports the same two categories and then relays a list, attributing it to a notification "According to an Apify customer who shared a breach notification on Reddit". This site did not read that notification and prints SecurityWeek's list only as SecurityWeek's relay.

The tokens, reported both ways and not resolved. The fourth update says "API tokens are now stored only as hashes, which limits the impact of any similar incident." The relayed notification lists "authentication tokens associated with Google and GitHub sign-ins". These are described as different things: one is Apify's API tokens, the other is sign-in tokens tied to Google and GitHub. The page does not say how API tokens were stored before the change, whether any plaintext token was read, or whether the sign-in tokens in the notification are among the OAuth connections it revoked. The first post does say that if tokens were affected Apify would rotate them for the customer. Whether it did for any customer is not stated. This briefing reaches no conclusion about the link.

What the page leaves to email. The third update's final sentence is the page's only answer to a customer who wants to know about their own account: "If you haven't received an email from us, we have not identified your account as affected so far." The words so far matter: the page itself says more customers may be contacted. A customer who got no email has no public list to check against.

Labels doing the work of evidence

"As a precaution." Apify uses it for the OAuth revocations and the rotated internal secrets. A precaution is an action, not a finding. The page does not say any of the rotated secrets were read.

"Stored only as hashes." The sentence is about the future: it "limits the impact of any similar incident". It says nothing about how tokens were stored on 9 and 10 November. Inference, labelled as such: hashing a token generally means a copy of the store does not directly hand over working tokens; the page does not describe Apify's scheme.

"Restricted." The advice is to set Console resource access to Restricted, because "While it's open, anyone who knows a storage ID can read that storage." The page does not say any storage was read by the attacker, whether the attacker held storage IDs, or what a given account's setting was. Inference: the setting is a hardening step for any account, and the page does not tie it to the intrusion.

"Not identified as affected so far." It describes what Apify has found, not what happened. The same applies to "we have detected no further activity from the attacker since 11 November".

What Apify's page states, and what it does not

What Apify tells customers to do, exactly as printed

Apify's advice to customers is two console instructions and an email to follow. The wording is copied below as printed, with what a customer does with each. Alongside them sits one statement about Apify's own systems, which a customer cannot check. Nothing here was visited or tested.

The storage setting. It lives in the Apify Console under account settings. A defender opens it, checks the value, and sets Restricted if it is open; the page's stated reason is that an open setting lets anyone who knows a storage ID read that storage.

Restrict access to your storages. In Console, go to Settings → General resource access and set it to Restricted. While it's open, anyone who knows a storage ID can read that storage.

The GitHub reconnect. It applies to Actors built from private GitHub repositories, because Apify revoked some OAuth connections including GitHub. A defender repeats it for each Apify account and each GitHub organization that feeds Actors, then checks that builds still run.

If you build Actors from private GitHub repos, reconnect GitHub: open an Actor built from GitHub → "Change provider" → GitHub → authorize (once per account and per organization).

The token statement. It is a claim about Apify's systems, not a setting a customer can check. A customer can use it as a question for Support (how were tokens stored before, and was any token read) and as a comparison point for their own platform.

API tokens are now stored only as hashes, which limits the impact of any similar incident.

What to do, in order

The first four items are Apify's own advice from the page. The rest are this site's suggestions, labelled as such. Nothing here assumes any of your data was read: Apify has not said that for any account that has not been emailed.

The question the page leaves open

Apify's page tells customers that no email means their account is not identified as affected so far, and that the details are in the email. So the question for a customer who received nothing is the one the page cannot answer: if no public page lists the fields and a promised post-mortem is the first place the root cause will appear, how does anyone check that not identified so far means not accessed?

Key facts