Notion’s 4-Year API Flaw Leaks Every Public Page Editor’s Email
Any Notion page published to the web quietly exposes its editors’ names, emails, and profile photos through an unauthenticated API — a flaw first reported in 2022 and still unpatched. The real lesson: collaboration metadata is now a phishing target list.
Every Notion page published to the web carries a hidden roster. Toggle “Publish to web,” and the platform quietly exposes the full name, email address, and profile photo of every person who has edited that page — no breach, no malware, and no login required to pull it. A single unauthenticated request turns a tidy public wiki into a ready-made target list for phishing.
What makes this more than an ordinary privacy slip is the timeline. The behavior was reported to Notion through HackerOne on July 28, 2022, triaged as merely “informative,” and closed without a fix. It sat untouched for nearly four years until security researcher @weezerOSINT disclosed it publicly on April 19, 2026 — at which point the same one-line request still worked.
|
● One Public Page, The Whole Team
How a single toggle turns editors into a target list
|
|
1 · Publish to web
Editor UUIDs stay embedded in the public page’s source code.
↓
2 · Scrape the UUIDs
Anyone pulls the editor IDs from the notion.site page HTML.
↓
3 · Unauthenticated API call
One POST to /api/v3/syncRecordValuesMain — no login, token, or cookie needed.
↓
4 · PII returned
JSON hands back each editor’s full name, email address, and profile photo.
↓
5 · Phishing target list
A verified roster for spear-phishing, BEC, and org-chart recon.
|
|
Source: @weezerOSINT public disclosure, Apr 2026; original HackerOne report, Jul 2022.
|
What’s Actually Exposed
The leak rides on the metadata Notion uses to power collaboration. When a page is published, its editors’ Universally Unique Identifiers (UUIDs) remain embedded in the public page’s source. Anyone can scrape those UUIDs from a notion.site page, then send a single POST request to Notion’s /api/v3/syncRecordValuesMain endpoint. Because that endpoint requires no cookie, token, or login for public blocks, it answers with a JSON record containing each editor’s registered name, email, and profile-image URL.
The content of the page is beside the point. An internal wiki shared “for transparency,” a public help center, a hiring board — any of them can hand over the full contributor roster of the team that maintains it.
A Flaw Notion Has Known About Since 2022
The 2022 HackerOne submission wasn’t theoretical. The original researcher tested Notion’s own public Community page, extracted 13 editor UUIDs, and resolved 12 of them to email addresses — including internal Notion employee accounts and a production service account, svc-notion-prod@makenotion.com. Notion’s security team marked the report “informative,” closed it as out of scope, and issued no patch, no CVE, and no bounty.
Four years later the endpoint behaved identically. Following the April 2026 disclosure and public criticism, a Notion representative, Max Schoening, called the current behavior “unacceptable” and said the team was working on a fix — either stripping PII from public API responses outright or introducing GitHub-style email masking (j***@company.com). As of this writing, no patch has shipped and the issue still carries no CVE.
Why This Is a Phishing Goldmine
A verified list of employee names paired with real emails and profile photos is exactly what a spear-phisher wants. It removes the guesswork from social engineering: an attacker can message a junior employee using the name and face of an executive they’ve confirmed as a collaborator, manufacturing instant, false trust. The same data feeds business email compromise and lets automated tooling rebuild an org chart straight from a company’s public documentation — no LinkedIn scraping required.
My Read
The technical bug is ordinary; the governance failure is not. A responsible disclosure triaged as “informative” and left open for four years is how a known, trivially exploitable issue becomes an ambient risk across millions of pages. The lesson for any SaaS vendor is that metadata generated for collaboration — editor histories, UUIDs, revision trails — is a live attack surface the moment sharing is made frictionless. “Public” has to mean stripped-of-PII by default, not merely stripped-of-content.
For enterprises leaning on Notion as a system of record, the takeaway is blunter: a document platform now needs the same publish-governance you’d apply to a public website, because the “Publish to web” toggle exports far more than what’s on the page.
What Defenders Should Do
- Audit what’s already public. In Settings & Members, review every page currently published to the web and unpublish anything that doesn’t need to be there.
- Anonymize before publishing. If a page must be public, rebuild it under a single generic account (e.g.,
webmaster@company.com) so no personal editor metadata is attached. - Restrict the toggle. On Enterprise plans, limit “Publish to web” to a small, trained group rather than every member.
- Assume the roster is already out. Treat any team that has maintained a public Notion page as a known spear-phishing target and brief them accordingly.
Open Questions
How many pages and accounts are affected is unknown — Notion has published no figure, and because the data is pulled on demand rather than dumped in bulk, there is no breach count to cite. It is also unconfirmed whether either proposed fix has begun rolling out, and the issue still has no CVE, which keeps it off standard vulnerability trackers. We will update this piece if Notion ships a masking or PII-stripping change.
