Notion Leaks Every Editor's Email on Public Pages — And It's Been There All Along

What happened

OSINT researcher @weezerOSINT disclosed that Notion's public page infrastructure leaks the email addresses of every user who has ever edited a publicly shared page. The disclosure, posted on Twitter and quickly picked up by Hacker News where it reached a score of 360, reveals that Notion's API responses for public pages include full editor email addresses in the JSON payload — no authentication required.

The mechanism is straightforward: when anyone visits a public Notion page, the browser makes API calls to Notion's backend to fetch page content and metadata. Embedded in those responses are user objects for each editor, complete with email addresses. You don't need to reverse-engineer anything. Open DevTools, look at the network tab, and the emails are right there in plaintext JSON.

This isn't a buffer overflow or an injection attack. It's a design choice — Notion's data model treats editor identity as part of the page payload, and when a page is published publicly, that payload goes with it.

Why it matters

The scale of exposure is what elevates this from a curiosity to a serious incident. Notion is used by an estimated 30+ million users across hundreds of thousands of organizations. Public Notion pages are everywhere: company wikis, engineering documentation, job boards, product roadmaps, investor updates, course materials, community resources. Every single one of these pages has been silently broadcasting the email addresses of everyone who touched them.

For a motivated scraper, this is trivial to automate. Notion's public page URLs follow predictable patterns, and the API endpoints that serve content don't require authentication. A single script could harvest millions of verified, active email addresses — each one tied to a specific organization and document context. That's not just a spam list; it's a spear-phishing goldmine. An attacker knows that jane.doe@acme.com edited a page about Q3 financial projections, which makes for a far more convincing pretext than a cold email.

The OSINT implications are equally concerning. Journalists, activists, anonymous contributors, and whistleblowers who edited Notion pages under the assumption that "Share to web" meant "share the content, not my identity" are now retroactively exposed. There is no audit log available to editors telling them which public pages have leaked their email, and no way to retroactively scrub that exposure.

This also raises questions about Notion's GDPR and CCPA compliance posture. Email addresses are personally identifiable information. Publishing them to the open internet without explicit consent from the data subjects — the editors — is at minimum a gray area under both frameworks, and likely a clear violation under stricter interpretations. Notion's privacy policy covers how they handle data you put *into* pages, but editor metadata leaking through API responses is a different category entirely.

The design flaw underneath

What makes this particularly instructive for engineers is that it's a classic case of an internal data model leaking through an external interface. Notion's architecture was presumably designed with the assumption that API consumers would be authenticated users with legitimate access to editor metadata. When the "Share to web" feature was built, the public-facing API likely reused the same response format — user objects and all — without stripping sensitive fields.

This is the same class of bug that has bitten dozens of SaaS companies: internal APIs that become external APIs without a serialization boundary review. The fix is conceptually simple — strip or anonymize user objects in public page responses — but the architectural debt that led here is worth examining. If your API responses include user objects, and you ever serve those responses to unauthenticated contexts, you have the same vulnerability.

The Hacker News discussion surfaced several related examples. Multiple commenters noted that similar issues have existed in Google Docs (resolved years ago), Confluence public pages, and various wiki platforms. The pattern is consistent: collaboration tools built for internal use bolt on public sharing as a feature, and the permission model doesn't fully account for the shift from "shared within a trusted group" to "shared with the entire internet."

What this means for your stack

If you use Notion for public pages, audit them immediately. The exposure is not theoretical — any page you've published to the web has been leaking editor emails since it was published. If those pages were edited by employees with corporate email addresses, those addresses are now in the wild. Consider:

1. Unpublish non-essential public pages until Notion confirms a fix. 2. Move public content to dedicated accounts with non-sensitive email addresses (e.g., docs@yourcompany.com) if you need pages to stay live. 3. Alert your security team — if editor emails have been scraped, expect targeted phishing attempts that reference specific Notion documents.

If you build SaaS with public sharing features, treat this as a case study. Audit every API endpoint that can be reached without authentication and verify that response payloads don't include user PII that was only intended for authenticated contexts. This means:

- Maintain separate serializers for public vs. authenticated responses - Never reuse internal user objects in public-facing payloads - Include automated tests that fetch public endpoints and assert the absence of email fields, user IDs, and other PII

If you're in security or compliance, document this as a data exposure event. Depending on your jurisdiction, you may have notification obligations if employee PII was exposed through a third-party tool.

Looking ahead

Notion has not yet issued a public response as of this writing, though the velocity of community attention — 360+ points on Hacker News and widespread social media coverage — typically accelerates vendor response timelines. The technical fix is straightforward: strip user email addresses from public API responses and replace editor identities with anonymized or first-name-only representations. The harder question is retroactive: how many emails have already been scraped, and does Notion owe its users disclosure? For the broader SaaS ecosystem, this is another reminder that "Share to web" is one of the most dangerous features you can ship — not because sharing is wrong, but because the blast radius of a permissions model mismatch scales with your entire user base.