> Notion AI conversations from 2 members of your workspace may have been affected. Their conversations stay private to them. They have not been proactively emailed. In order for them to access their affected data, you must share this page with them so they can download their own.
Yeah spending the morning figuring out which users are affected and what data is involved. Time well spent. Thanks, Notion.
Even with that, you can't really prove or provide evidence they aren't silently slinging the data elsewhere during transport anyway. Unless you're doing Homomorphic encryption, it all seems to be for show.
There's also the nvidia enclave stuff. If you trust their hardware, then you can also trust its cryptographic proof that the data was not seen by the inference provider.
Ignoring whether or not there could be backdoors, security holes in the Trusted Execution Environment stuff are still being found on a regular cadence.
I'd guess it's good enough to avoid bulk surveillance (and therefore extraction of training data, which I guess is the attack that Notion was running when they screwed up and leaked the data), but that's about it.
Apple's stuff is a similar story. (And so are VM enclaves, which have been around longer.)
Fireworks "datasets" are used for batch inference as well as training models. Notion mentioned that the leak was due to some feature they have to classify previous ai conversations. They probably uploaded these conversations as a 'dataset' to fireworks in order to take advantage of their large batch processing discount.
I like Fireworks.ai and use their APIs when I use Hermes Agent in an Apple Container. I have tried serious use of Hermes with local models, but for good results I like deepseek-4.1-flash-1027 or stronger, and I have trusted their ZDR, and will continue to trust their ZDR. (I buy tokens directly from Deepseek for my open source coding efforts where I don’t care about ZDR.)
Off topic but: strong local models work great with pi-dev and my own purpose built harnesses, but it takes a relatively strong model to make Hermes Agent shine.
the whole incident response post feels like a huge cop-out. “abundance of caution”, the vendor is one of the biggest, so ofc it’s not our fault for choosing them… etc.
Super poorly IMO. Fireworks' initial breach notification was on Oct 9 [1] and told us we were 'not impacted'. Only for us to find out we were impacted after some of our Anthropic API keys used in Fireworks were 'hijacked'. That in itself took days of investigation and response. I can only imagine Notion are in a similar boat.
To my knowledge we still haven't been formally notified as being included in the Fireworks breach. It makes me extremely skeptical of the " For a limited set of accounts, we also discovered impact to secrets, datasets, and incomplete models." that they detailed in their Nov 9 update [2].
Thank you sharing the specifics. That doesn't reflect well on them at all.
I (individual client) actually didn't get *any* communications from Fireworks about this incident. Not even a template email. Without HN I'd still be in the dark.
> Upon analysis of the new data, we discovered that it included unattributable Notion AI chat transcripts used for the Insights feature. Chats weren't labeled with who wrote them or which workspace they came from, and the transcripts did not contain any tool call results. Beyond the words in the chat transcripts themselves, the data contained no information that could specifically identify the workspace, user, or company.
> As a precaution, we recommend that you treat this unattributable data as if it were exposed. If anyone on your team pasted sensitive information like passwords, API keys, or other credentials into Notion AI during this timeframe, we recommend rotating them right away.
Okay, so the actual impact is quite interesting: they did not notify you if they could not attribute the transcripts to you! You should really treat anything sensitive sent to Notion AI as compromised because they are not sure where these transcripts came from.
Does anyone actually use the AI features? $job switched off because they spent too much time on AI features we never used, and too little time making a text editor that wasn't painful to use
I setup my own mini obsidian with openai/claude api using sqlite, and it's been really useful. I have folders/subfolders with their own schemas and conventions using plain AGENT.md files, and even setup custom agents to hold specific instruction sets and access control systems. A subset of tools to navivate, search, edit, combined with the agents plugin spec, gives me a pretty flexible workflow, and the ability to extend functionality with MCP, 3rd party providers.
I'm using vercel's ai sdk, so i can switch providers and use any AI model in openrouter or local GPU.
Ofcourse you could just use obsidian with some extension like claudian, or plain markdown files and vscode, or even claude/codex apps, but they all have their own quirks, and they'll cost alot more per token usage, subscription plans.
> “Unattributable” means the chats weren't labeled with who wrote them or which workspace they came from, and the transcripts did not contain tool call results. Beyond what’s in the chat transcript itself, there’s no information tying the chat back to a workspace, user, or company.
This is astonishing.
They’re saying “OTHER THAN THE ACTUAL CONTENTS OF YOUR CONVERSATION, NO INFORMATION WAS PRESENT”. That is not what unattributable really means and they’re trying to assert otherwise.
It’s trivial to identify the organisation or individuals involved in a conversation most of the time, but Notion are trying to make out that because the metadata wasn’t present, it’s no cause for concern.
That’s absolute bullshit and will give people a false sense of security. The contents of your conversation IS the critical information. Notion’s desktop app is very aggressive in prompting users to transcribe their calls and I imagine a large proportion do so by default. The potential for harm here is large.
I appreciate it’s Fireworks’ fault this happened, but Notion’s response destroys my confidence in them.
This is a delicious complement to the reassurances we are always given when metadata is tracked/stored/aggregated/breached that it's fine because it's just the metadata.
To give fair credit to Notion -- they have provided the raw data that was in scope (assuming you're on an Enterprise SKU). Along with the initial notification. This is quiet rare for these breaches. Fireworks definitely did not in their response.
So we've all got all the data to make our own determination on the data being 'unattributable' or not.
> So how come notion discovered that they actually stored the data?
Is there any legal consequence for stating you are ZDR but then internally you don't give a shit about it? I'm guessing that'd be between OpenRouter and the provider, not between the provider and the one triggering the inference, would that be correct? Does OpenRouter validate anything at all in regards to the providers, or it's a free-for-all "do whatever you want" kind of deal for OpenRouter and the providers?
Sorry, it's actually not clear to me how they are getting chat transcripts having read this. Were these "datasets"? ie. Notion was training on these transcripts through Firework?
Maybe prompts and prompt data only means your direct input but not the response from the model. I wonder how difficult it is to infer the prompt from the response. "We would never train on your prompts! Why would we, when they're implicitly in the content we do train on..."
I run my coding agents on a PC at home, only reachable over Tailscale for this reason. It runs an opencode server with password. Currentlyt he blast radius from all 3rd party providers is so huge and scary.
Yup. This. Two kinds of people in this context, the ones who panic before a disaster and the ones who let it happen. Bonus points to the latter for celebrating their fuckup.
Sorry, I was unclear. I’m pointing out that the “pants shitting panicking” is why Y2K was a nothingburger.
The options are panic before (in a rush to fix it) or panic after (to repair damage that could have been prevented). (Of course there is a third option, detect your problem sooner, but that isn’t always available.)
So yeah, if someone at Ford had panicked about the Pinto’s fuel system before they shipped, they wouldn’t have had to panic about it afterwards.
but good that they finally got around to posting something official ...
I asked the CISO if they can tell me if the data was accessed but they aren't answering and any communication is super slippy like "may have been accessed". I need to do some GDPR notations bc of them but I won't start running around just bc it "may have been" accessed
Damn, I dodged a bullet. My data was exposed, but looking through the transcripts of the exposed conversations, it just so happens not to include anything particularly sensitive. I'm a pretty heavy user of Notion and its agent, so I absolutely have had sensitive conversations in there in the past.
This is a really bad breach in the sense that an unlucky user could have very sensitive conversation content exposed in a way that could be attributable to them, if identifying information is in the messages. It could also expose sensitive information about 3rd parties, even if the user themselves was not exposed.
Notion is bs, they can't tell me which of my 330 employees have data in this breach, only 133 of them. I have to get each employee to click on a link, then send me what data was breached. This security response is not acceptable in any reality.
64 comments
[ 2.9 ms ] story [ 24.5 ms ] threadYeah spending the morning figuring out which users are affected and what data is involved. Time well spent. Thanks, Notion.
On the main fireworks breach page, they also say some customer weights of models and datasets to train them were leaked.
Ignoring whether or not there could be backdoors, security holes in the Trusted Execution Environment stuff are still being found on a regular cadence.
I'd guess it's good enough to avoid bulk surveillance (and therefore extraction of training data, which I guess is the attack that Notion was running when they screwed up and leaked the data), but that's about it.
Apple's stuff is a similar story. (And so are VM enclaves, which have been around longer.)
https://docs.fireworks.ai/guides/batch-inference
I like Fireworks.ai and use their APIs when I use Hermes Agent in an Apple Container. I have tried serious use of Hermes with local models, but for good results I like deepseek-4.1-flash-1027 or stronger, and I have trusted their ZDR, and will continue to trust their ZDR. (I buy tokens directly from Deepseek for my open source coding efforts where I don’t care about ZDR.)
Off topic but: strong local models work great with pi-dev and my own purpose built harnesses, but it takes a relatively strong model to make Hermes Agent shine.
They don't care. The same as Openrouter: $7bn valuation, that service feels to me like about 10 devs total.
They don't care, because it's not about providing a product. Fireworks is about inference as much as a mob nightclub is about drinks.
To my knowledge we still haven't been formally notified as being included in the Fireworks breach. It makes me extremely skeptical of the " For a limited set of accounts, we also discovered impact to secrets, datasets, and incomplete models." that they detailed in their Nov 9 update [2].
[1]: https://fireworks.ai/security/bulletins/october-2026-securit...
[2]: https://fireworks.ai/security/bulletins/october-2026-securit...
I (individual client) actually didn't get *any* communications from Fireworks about this incident. Not even a template email. Without HN I'd still be in the dark.
In the past few months, we’ve helped many customers migrate to their own on-prem setups.
No software is immune to cyberattacks, but having control over the deployment model can greatly reduce exposure to attacks like this.
GitHub: https://github.com/docmost/docmost
Website: https://docmost.com
> As a precaution, we recommend that you treat this unattributable data as if it were exposed. If anyone on your team pasted sensitive information like passwords, API keys, or other credentials into Notion AI during this timeframe, we recommend rotating them right away.
Okay, so the actual impact is quite interesting: they did not notify you if they could not attribute the transcripts to you! You should really treat anything sensitive sent to Notion AI as compromised because they are not sure where these transcripts came from.
Who is using Notion for a chat about the weather? It's chats about your content and data.
Ofcourse you could just use obsidian with some extension like claudian, or plain markdown files and vscode, or even claude/codex apps, but they all have their own quirks, and they'll cost alot more per token usage, subscription plans.
This is astonishing.
They’re saying “OTHER THAN THE ACTUAL CONTENTS OF YOUR CONVERSATION, NO INFORMATION WAS PRESENT”. That is not what unattributable really means and they’re trying to assert otherwise.
It’s trivial to identify the organisation or individuals involved in a conversation most of the time, but Notion are trying to make out that because the metadata wasn’t present, it’s no cause for concern.
That’s absolute bullshit and will give people a false sense of security. The contents of your conversation IS the critical information. Notion’s desktop app is very aggressive in prompting users to transcribe their calls and I imagine a large proportion do so by default. The potential for harm here is large.
I appreciate it’s Fireworks’ fault this happened, but Notion’s response destroys my confidence in them.
So we've all got all the data to make our own determination on the data being 'unattributable' or not.
GitHub: https://github.com/docmost/docmost
> Private: this provider does not train on prompts and does not retain prompt data.
So how come notion discovered that they actually stored the data?
> Upon analysis of the new data, we discovered that it included unattributable Notion AI chat transcripts
Is there any legal consequence for stating you are ZDR but then internally you don't give a shit about it? I'm guessing that'd be between OpenRouter and the provider, not between the provider and the one triggering the inference, would that be correct? Does OpenRouter validate anything at all in regards to the providers, or it's a free-for-all "do whatever you want" kind of deal for OpenRouter and the providers?
Fireworks informed them.
The nature of the data here is inherently stored until used. You can read the fireworks incident report at https://fireworks.ai/security/bulletins/october-2026-securit... it's linked in the first sentence of the Notion report.
https://fireworks.ai/security/bulletins/october-2026-securit...
https://fireworks.ai/security/bulletins/october-2026-securit...
/s
That is for now, I am sure there will be worse months ahead of us.
If you mean 99% pants shitting panicking in the New York Times, yes, it’s a good thing I wasn’t in charge.
Yup. This. Two kinds of people in this context, the ones who panic before a disaster and the ones who let it happen. Bonus points to the latter for celebrating their fuckup.
The options are panic before (in a rush to fix it) or panic after (to repair damage that could have been prevented). (Of course there is a third option, detect your problem sooner, but that isn’t always available.)
So yeah, if someone at Ford had panicked about the Pinto’s fuel system before they shipped, they wouldn’t have had to panic about it afterwards.
but good that they finally got around to posting something official ...
I asked the CISO if they can tell me if the data was accessed but they aren't answering and any communication is super slippy like "may have been accessed". I need to do some GDPR notations bc of them but I won't start running around just bc it "may have been" accessed
This is a really bad breach in the sense that an unlucky user could have very sensitive conversation content exposed in a way that could be attributable to them, if identifying information is in the messages. It could also expose sensitive information about 3rd parties, even if the user themselves was not exposed.