Notion Email Leak: Public Pages Expose Editor Addresses to Anyone

TL;DR

If you’ve ever edited a Notion page that was later made public, your email address is sitting in that page’s metadata right now, and anyone can pull it with a single unauthenticated API call. The behaviour has been known since at least 2020 and was filed on HackerOne in July 2022. Max Schoening from Notion acknowledged the issue on Hacker News this weekend, said the warning they show publishers “is not good enough,” and confirmed no fix has shipped yet. The only reason this hasn’t been filed as a bug is that Notion calls it “documented behaviour” — a label that does nothing for anyone whose email is already scraped.

What ohryansbelt posted on April 19

On April 19, a security researcher posting on X under the handle ohryansbelt fired off a short thread that hit the front page of Hacker News with 366 points. The claim: anyone who’s edited a publicly shared Notion page, whether that’s docs, wikis, careers pages, or marketing briefs, has their full name, profile photo, and email address exposed, and pulling the list takes one API call. No auth required, and no log on your side telling you anyone looked.

I spent half an hour poking at it on my own workspace. The moment I published a page to the web, the network tab lit up with user-payload JSON that included my email. Same behaviour on a throwaway test account I set up with a secondary address, and the same on a friend’s startup handbook I asked permission to inspect.

The weird part is how long this has lived in the open. Four years in the tracker, a four-year-old HackerOne report, and Notion’s public answer is still “we warn users when they publish.”

What actually leaks

When a Notion page is made public, the rendered HTML embeds UUIDs for every user who contributed to it. The front end then hydrates those UUIDs into a panel that displays names and avatars, which is useful for collaboration and the whole reason the endpoint exists in the first place. The issue is that the backing API that turns a UUID into a user record has no idea who is asking. It serves up:

• Full display name
• Profile photo URL
• Email address

The Hacker News thread settles on a diagnosis that’s hard to argue with: the UUID-to-email endpoint has no way of knowing who’s calling it or in what context. It was designed for authenticated collaboration flows, the “invite this user by UUID” pattern, and now it’s wired to public pages that anyone on the open internet can hit.

The scraping cost is trivial. Walk the public page sitemap for any Notion-hosted domain, extract UUIDs, resolve each one. Whatever the exact latency per call, you can harvest a mid-sized company’s entire contributor list (often the whole company, since startups tend to dump everything into their Notion wiki) inside an afternoon on a laptop.

How we got to four years

From the current reporting and the HN thread, which includes a direct response from Notion:

The uncomfortable comparison is with the Notion AI data-exfiltration bug from December 2025: a different vulnerability, different team, same company. That one got turned around in roughly two weeks from disclosure to production patch. The email leak has been on the books for four years. The difference is the classification: the email leak was filed as “documented behaviour” and therefore never treated as a bug in the tracker sense.

Notion’s response, in their own words

Max Schoening from Notion posted on the thread:

This is documented and we also warn users when they publish a page. But, that’s not good enough! We don’t like this either and are looking at ways to fix this either by removing the PII from the public endpoints or by replacing it with an email proxy similar to GitHub’s equivalent functionality for public commits.

He also pushed back on the “one-minute fix” takes in the thread, saying it is “unfortunately not the case,” and acknowledged the four-year gap between the original 2022 filing and today.

Two options are on the table, per his comment:

1. Strip PII from public endpoints entirely. The cleanest fix. Public pages would render with display names only, and the contributor avatar list would resolve against an authenticated endpoint for logged-in workspace members. Downside: workspaces that rely on the current behaviour for attribution on public docs lose a feature.
2. Proxy emails like GitHub does for public commits. GitHub generates username@users.noreply.github.com addresses that preserve attribution without leaking real emails. Notion could do something similar (uuid@users.noreply.notion.so) and offer a toggle to reveal the real address only to authenticated workspace members.

Either path is a meaningful engineering effort, not a weekend’s work, which goes a long way to explaining why the issue has sat.

Why it is not a one-minute fix

Every collaborative SaaS product has some version of this problem. A contributor model that exists on both sides of the auth wall (public docs, shared links, guest editors) will eventually couple user identity to public artifacts. Untangling it means rewriting the user-resolution layer, auditing every endpoint that hits it, running a migration on existing public pages, and accepting a cohort of users who will complain that “the avatar list stopped showing real names on our handbook.”

Compare the GitHub noreply email model for why this is non-trivial. GitHub had to build the proxy addresses, wire them into the commit pipeline, expose a user preference, and educate users that octocat@users.noreply.github.com was still “them.” They still get reports of real emails leaking from historical commits. The ceiling here is high and the engineering debt compounds every day the current design stays live.

None of that excuses the four-year delay, but it does explain why the fix takes more than a single sprint.

What you should do right now

If you have published a Notion page to the web at any point, even a draft you later unpublished, assume the emails of everyone on the edit history are in the wild. Concretely:

• Audit your public pages. In the Notion desktop app, go to “Settings & members” → “Security” on paid plans, or manually walk your workspace and check the “Share → Publish” status on each doc. Anything flagged “Published to the web” is leaking.
• Unpublish pages you don’t need public. The URL stops resolving immediately; cached metadata can still linger in third-party archives, but you cut off the ongoing exposure at the source.
• Publish under a dedicated contributor account. A workspace-owned role account with a shared mailbox (like docs@yourcompany.com) doesn’t leak your personal address.
• Assume your email is already compromised for spam-list purposes. The data is trivial to scrape; bots have had years to do it. If your inbox has been unusually noisy with startup-founder spam, this is a plausible contributor.
• Don’t treat “unpublish” as remediation for past leakage. Once your address is scraped, it’s gone. Think of it the same way as a credential leak: rotate what you can, and change your expectations going forward.

What this says about Notion’s security posture

Notion is one of the most widely deployed collaboration tools in the industry, with over 100 million users and millions of paying customers on its own public numbers. They run a HackerOne bug-bounty program and have historically moved fast on vulnerabilities that are unambiguous: the December 2025 AI exfiltration patch is proof.

What this episode shows is a gap in the part of the threat model that covers designed behaviour. The email exposure is the intended output of an endpoint that was scoped for authenticated collaboration and never re-scoped when the same data started rendering on public pages. That category of issue — the “we built it this way on purpose, therefore it is not a vulnerability” kind — is where every fast-moving SaaS eventually gets burned. The way you catch it is privacy reviews of data surfaces whenever a feature moves from logged-in to public. It is not obvious that Notion has that process, or that it is funded enough to reach four-year-old edge cases.

A fix is coming — Notion said so. Whether it takes two weeks like the AI bug or another year like the last four is the thing to watch. My bet: the GitHub-style email-proxy approach, shipping in a point release inside a month, now that the story is on the front page and leadership is paying attention.

FAQ

Is the Notion email leak fixed?

No. As of April 20, 2026, Notion has publicly acknowledged the issue but has not shipped a fix. Max Schoening said on Hacker News that they are exploring two options: removing PII from public endpoints, or creating a GitHub-style email proxy.

How do I check if my Notion email is leaking?

If you have ever edited a Notion page that is currently or was previously published to the web, your email is almost certainly exposed in that page’s metadata. Open any public Notion page, inspect the network tab while it loads, and look for the user-resolution payload. You will see the UUID-to-email mapping directly.

Should I stop using Notion?

Probably not. The leak is limited to public pages; private workspace content is not affected. If you never publish pages to the web, nothing is leaking. If you do publish, switch to a dedicated account or a shared mailbox address until a fix ships.

Is this a hack?

No. This is not a breach or an intrusion. It is the documented, intended behaviour of a public API that happens to expose personally identifiable information. That distinction is why the issue has been classified as “by design” rather than a vulnerability for four years, and why it is still unfixed.

Does GDPR apply here?

Notion is subject to GDPR for its EU users. Exposing email addresses without a clear consent flow is the kind of thing regulators have fined SaaS companies over, particularly when the issue has been disclosed and left unfixed. Whether any EU data-protection authority acts is a separate question from whether there is a plausible claim.

Sources

• Notion leaks email addresses of all editors of any public page — Hacker News discussion — 366-point front-page thread with the full back-and-forth
• Max Schoening’s official response on Hacker News — Notion acknowledging the issue and outlining fix options
• Ryan (ohryansbelt) on X — the April 19 post that put the four-year-old HackerOne report back in the news
• Notion Email Leak: Why Public Pages Expose Editor Addresses — Pixels and Pulse — independent writeup of the mechanism
• Notion’s HackerOne program — public bug-bounty scope and history
• Notion AI unpatched data exfiltration writeup — PromptArmor — the separate December 2025 AI bug referenced for timing comparison

Bottom line

A four-year-old data leak in a tool this widely deployed shouldn’t be a surprise, but it is. Notion has the technical capability to fix this — they proved it on a harder bug four months ago. What they’ve lacked is the signal to prioritize it, and the signal just arrived. If the fix doesn’t land inside a month, the question stops being “when will Notion fix it” and starts being “why did it take regulatory pressure to move them.” Check your published pages today. Assume the damage is done on the ones that have been public for years.