Notion Leaks the Emails of Every Editor on Public Pages

I spent three years dumping sensitive information into Notion without asking myself even once who else could see it. No security configuration, no access audits, nothing. Notion was my second brain — and you don't pentest your second brain.

When I came across the report documenting how Notion exposes the emails of every editor on any public page, my first reaction was to check how many public pages I had with collaborators. I found more than I expected. But what really got to me wasn't the number — it was that in three years, it never even crossed my mind to think of Notion as an attack surface.

And that, as a developer, is exactly the kind of mistake I shouldn't be making.

What's actually happening with Notion's data leak

The problem is both technical and straightforward. When you have a Notion page with public visibility ("Anyone with the link can view"), anyone who accesses that page can extract the emails of every user who ever edited that document.

This isn't some obscure bug that requires reverse engineering. It's a request to the Notion API that returns collaborator profiles — including email addresses — without requiring any additional authentication. If the page is public, the data of its editors is too.

The flow looks roughly like this:

# A public Notion page exposes this through its API
# You don't need to be authenticated — just have the link

curl 'https://www.notion.so/api/v3/loadPageChunk' \
  -H 'Content-Type: application/json' \
  --data '{
    "pageId": "PUBLIC_PAGE_ID",
    "limit": 100,
    "cursor": { "stack": [] },
    "chunkNumber": 0,
    "verticalColumns": false
  }'

# In the response you'll find objects of type "notion_user"
# with fields: email, name, profile_photo
# For every person who has ever edited that page
# Regardless of whether that person wanted their email to be public

The practical attack vector: someone shares a public company wiki on Notion. Anyone with the link can enumerate every corporate email of whoever edited that wiki. Those emails are perfect input for targeted phishing, credential stuffing, or simply mapping out an organization's team.

This isn't science fiction. It's an HTTP request.

Why this hit differently as a developer

There's a category of tools that developers use without applying the same level of analysis we apply to our technical stack. I call them productivity tools, but the more accurate name would be security blind spots.

Notion falls into that category alongside Slack, Figma, Linear, and any other SaaS you use to get work done but didn't install yourself, didn't configure yourself, and assume "the vendor takes care of it."

The problem is that assumption is fundamentally wrong for any tool that handles real people's data.

I wrote recently about how Emacs gave me something AI agents still can't: trust in my own configuration environment. The core idea was that understanding the tools you use changes your relationship with them. Notion is exactly the counter-example: I used it without understanding it, and here we are.

I learned this the hard way in infrastructure. My first week on a production Linux server, I took down an entire server with a badly aimed rm -rf. From that day on, before running anything in prod, I think twice. But that mental discipline — I apply it to code and infra, not to the SaaS I use for taking notes.

That's a modeling error. I'm applying different standards of analysis to systems that have the exact same level of access to sensitive information.

// How I think about my code:
interface SystemWithDataAccess {
  requiresAccessAudit: boolean;    // always true
  requiresPermissionReview: boolean; // always true
  requiresThreatModel: boolean;    // always true
}

// How I (unconsciously) think about my SaaS:
interface ProductivityTool {
  requiresAccessAudit: boolean;    // never even ask myself
  requiresPermissionReview: boolean; // assume it's fine
  requiresThreatModel: boolean;    // why bother, it's just Notion
}

// The problem: both interfaces handle real data about real people
// The difference exists only in my head, not in the reality of the system

This inconsistency is the underlying problem. Not Notion specifically.

The concrete mistakes you're probably making right now

1. Public pages you forgot were public

Notion lets you change a page's visibility in two clicks. The problem is it also lets you forget you did it. If at some point you published something to share with someone external and never set it back to private, that page is still out there, exposing your whole team's emails.

Audit your workspace now: Settings → Members → Guest access. Then check each important page and verify its visibility settings. There's no automated way to do this on the free tier.

2. Assuming "Anyone with the link" means security through obscurity

A lot of people think sharing a long, random Notion link is safe because "nobody's going to guess that link." That's security through obscurity, and it works exactly until someone has the link — which happens every time you send it via email, Slack, or it gets indexed by Google because you dropped it somewhere public.

Reliability in systems doesn't come from obscurity but from explicit design. Japan's trains aren't reliable because the tracks are secret — they're reliable because the system is designed for reliability. Apply that to your tools.

3. Not knowing what data each tool exposes in each visibility state

This is the most important one and the hardest. For every SaaS tool you use with sensitive data, do you know exactly what information is accessible from the outside when you set visibility to public? Probably not. I didn't know it about Notion.

The minimum viable move is reading the permissions documentation for every tool that touches people's data. Not the "how to use Notion" tutorial — the security and permissions documentation.

4. Mixing personal and work information without separation

A lot of us developers have a single Notion workspace where personal notes, client documentation, and team resources all coexist. If any of those pages ends up public, the exposure surface is enormous.

Separating workspaces by data context isn't paranoia — it's basic information hygiene. Same thing you apply when thinking about the semantic overhead of what you include in a prompt: not everything needs to be in the same place.

# Minimum audit for public Notion pages
# No official command for this, but you can do:

# 1. Go to Settings & Members > Connections
# 2. Review any integration with access to your workspace

# 3. For each important page, check Share settings:
#    - "Only people invited" = private ✓
#    - "Anyone at [workspace]" = internal access ✓ (if you trust your org)
#    - "Anyone with the link" = public ⚠️  check if actually necessary
#    - "Public on web" = indexable by Google ⚠️⚠️  review urgently

# 4. Find pages with external collaborators (guests)
#    Settings > Members > Guests — list and audit all access

FAQ: Notion privacy, the data leak, and what to do about it

Has Notion fixed this?

As of writing this post, the documented behavior is still reproducible on public pages. Notion hasn't published a CVE or a formal security advisory acknowledging this as a vulnerability. The implicit stance seems to be: if a page is public, the information about its editors is public too. That's arguable from a privacy standpoint — editors don't necessarily consent to their email being public just because the page is.

Who's actually at risk?

Primarily teams using Notion for public documentation — wikis, changelogs, knowledge bases — with multiple collaborators editing those pages. Also anyone who has ever edited a page that was later made public without their knowledge. If you work at a company that uses Notion and someone on the team published documentation, your email could be exposed without you ever knowing.

Is this a bug or a feature?

That's the uncomfortable question. From Notion's perspective, showing who edited what is part of the product's transparency. The problem is that the granularity of control doesn't match that design decision: there's no way to say "the page is public but the editors' emails are not." It's all or nothing, and that's a privacy design problem.

What do I do with my existing public pages?

Step one: audit them. Step two: for every public page with collaborators, ask yourself whether it actually needs to be public or whether "Anyone with the link" is sufficient (even with the limitations I described). Step three: for pages that must be public and have sensitive collaborator data, consider publishing that content somewhere else — a blog, a static wiki — where you have better control over what data gets exposed.

Does this apply to other productivity tools?

Yes, and that's the most important point in this whole post. Figma exposes collaborator data on files with public links. Google Docs has similar behaviors depending on configuration. Confluence, Coda, and almost every collaborative tool has some version of this problem. The difference is how much you know about it before someone exploits it. AI agents that pass all your tests without being correct and SaaS tools that expose data without you knowing share something in common: you trust them because they've never visibly failed you. Yet.

Is Notion insecure and should I stop using it?

No. Notion is a useful tool with a specific privacy design problem you need to understand. "Stop using Notion" is the easy answer and the wrong one. The right answer is: use it knowing how it works, with appropriate visibility for each type of content, and audit periodically what's exposed. Same applies to any SaaS. The problem isn't the tool — it's the absence of a mental model for what it actually does.

The real problem isn't Notion

This story has a lesson that goes way beyond a privacy setting.

As developers, we apply asymmetric technical rigor. To code: security reviews, static analysis, tests, code review. To infra: threat modeling, principle of least privilege, access audits. To the SaaS tools we use every single day: nothing.

That inconsistency is expensive. Not always in a dramatic way — sometimes it costs the privacy of collaborators on a wiki you forgot was public.

Brunost exists as a programming language in Nynorsk and that says something about who decides what's readable and what isn't. In the same way, the fact that almost no developer audits their productivity tools says something about what we've decided deserves technical attention and what doesn't. That implicit decision has real consequences.

Here's what I'm doing differently from now on:

1. Quarterly audit of public pages in Notion — not as a formal security process, but as basic hygiene
2. Separate internal vs. external documentation — if something is for public consumption, it goes in a tool designed for that, not Notion with public visibility
3. Before making any collaborative page public, explicitly ask myself what collaborator data I'm exposing
4. Extend the threat model I apply to my code and infra to the tools I use daily

I never thought of Notion as an attack surface. Now I do. That doesn't make Notion dangerous — it makes me more careful. Which is exactly where I should have been all along.

Audit your public pages. Now.