Notion 공개 페이지에서 모든 편집자의 이메일 주소가 노출되는 문제

Who Should Read

Notion을 팀 협업 도구로 사용하면서 공개 페이지를 운영하거나 직원들이 편집에 참여하는 기업의 개발자 또는 IT 담당자. 특히 이메일 주소 노출이 스팸, 피싱, OSINT(공개 출처 정보 수집) 공격으로 이어질 수 있어 보안을 신경 쓰는 팀에게 즉시 확인이 필요하다.

Core Mechanics

• Notion에서 페이지를 웹에 공개(publish to web)하면, 그 페이지의 HTML 메타데이터에 해당 페이지를 편집한 모든 Notion 사용자의 이름, 프로필 사진, 이메일 주소가 자동으로 포함된다.
• 이 동작은 Notion 공식 문서(help/public-pages-and-web-publishing)에 작은 주석 형태로 문서화되어 있었으나, 사용자들이 인지하기 매우 어려운 위치에 묻혀 있었다.
• Notion의 Max라는 직원이 HN에 직접 댓글을 달아 '문서화되어 있고 게시 시 경고도 하지만, 그것만으로는 충분하지 않다'고 인정했다. 현재 공개 API 엔드포인트에서 개인정보(PII)를 제거하거나 GitHub처럼 이메일 프록시 방식으로 대체하는 방향을 검토 중이라고 밝혔다.
• 이 문제는 최소 5년 이상 존재해 온 것으로, HN 커뮤니티의 한 사용자는 5년 전에 자신의 Notion 공개 페이지를 통해 익명이 해제(deanonymized)된 경험이 있다고 공유했다.
• Notion 측은 '1분짜리 수정'이라는 일부 추측에 대해 그렇지 않다고 직접 해명했다. 내부적으로 수정이 간단하지 않음을 시사한 것으로, 데이터 구조나 API 호환성 문제가 얽혀 있을 가능성이 있다.
• 이 문제는 단순히 Notion만의 이슈가 아니라, 서버가 사용자 데이터를 중앙 집중적으로 저장하는 구조 자체의 근본적인 한계라는 시각도 있다. 한 사용자는 '데이터를 애초에 저장하지 않는 것이 올바른 해결책'이라며, 사용자별로 데이터를 분산 저장하는 아키텍처를 고민했으나 그룹 협업, 오프라인 대응, 스크래핑 방지 등의 문제로 현실적으로 매우 어렵다고 분석했다.

Evidence

• Notion의 직원 Max가 직접 HN에 댓글을 달아 문제를 공식 인정했다. '문서화되어 있고 게시 시 경고도 하지만 그것만으로는 충분하지 않다'며, 공개 엔드포인트에서 PII(개인 식별 정보)를 제거하거나 GitHub의 이메일 프록시 방식을 도입하는 방향을 검토 중이라고 밝혔다.
• 이 문제가 최소 5년간 존재했다는 경험담이 공유됐다. 한 HN 사용자는 5년 전 자신의 Notion 공개 페이지를 통해 익명이 해제된 적이 있다고 직접 언급했으며, 이는 이 취약점이 오래된 문제임을 보여준다.
• 공식 문서에 이미 안내가 되어 있다는 점을 두고 '그럼 괜찮은 거 아니냐'는 시각과, '아무도 못 보는 구석에 숨겨놓은 건 고지라고 볼 수 없다'는 반론이 맞섰다. 대부분의 커뮤니티 반응은 후자 쪽에 동의하는 분위기였다.
• '1분이면 고칠 수 있는 것 아니냐'는 의견에 대해 Notion 직원이 직접 그렇지 않다고 해명했다. 구체적인 이유는 밝히지 않았지만, 이미 공개된 API나 데이터 구조와의 호환성 문제가 있을 것으로 추측되었다.
• 일부 사용자들은 이번 사건을 계기로 Notion이 'AI 올인원 앱'으로 방향을 바꾼 것에 대한 실망감을 표출했고, 보안과 프라이버시보다 기능 추가에 집중하는 SaaS 서비스 전반의 문제를 지적하는 댓글도 달렸다.

How to Apply

• 현재 Notion 공개 페이지를 운영 중이라면, 해당 페이지의 HTML 소스나 메타데이터를 직접 확인해서 편집자들의 이메일 주소가 노출되고 있는지 즉시 점검해야 한다. 노출이 확인되면 해당 페이지를 비공개로 전환하거나, 편집자를 별도의 워크스페이스 계정으로 분리하는 조치를 먼저 취하는 것이 안전하다.
• 회사 직원들이 편집한 Notion 페이지가 외부에 공개되어 있다면, 직원들의 회사 이메일 주소가 수집되어 스피어 피싱(특정 대상을 노린 피싱)이나 스팸 공격에 악용될 수 있다. 공개 페이지 목록을 감사(audit)하고, 불필요한 공개 설정을 즉시 비공개로 되돌리는 것을 권장한다.
• Notion API나 공개 페이지를 활용한 서비스를 개발 중이라면, 현재 API 응답에 포함된 사용자 정보 필드를 재확인하고, 이 정보를 외부에 그대로 노출하는 코드가 없는지 점검해야 한다. Notion이 향후 이메일 프록시 방식으로 변경할 경우 API 응답 구조가 바뀔 수 있으므로, 관련 변경 공지를 주시할 필요가 있다.

Terminology

관련 논문

• Claude가 rsync의 버그를 증가시켰는가? 데이터 분석

  rsync 프로젝트에 Claude AI가 도입된 이후 버그가 늘었다는 소셜 미디어 주장을 실제 데이터와 통계 분석으로 검증한 글로, 결론적으로 Claude 도입 후 릴리즈가 역사적 분포에서 유독 버그가 많다는 통계적 근거는 없었다.

• 취약한 앱을 직접 만들고 LLM이 해킹할 수 있는지 $1,500 써서 실험해봤다

  Firebase 취약점을 가진 앱을 직접 제작하고 GPT-5.5, Claude, Deepseek 등 주요 LLM이 자율적으로 해킹할 수 있는지 실험한 결과, GPT-5.5가 70% 성공률로 압도적이었고 Claude는 보안 거부 정책 때문에 능력과 무관하게 낮은 점수를 기록했다.

• Clustered Self-Assessment: LLM 불확실성 정량화를 위한 간단하고 효과적인 방법

  LLM이 여러 답변을 의미 단위로 묶어 객관식으로 만들고 스스로 채점해서 '이 답 얼마나 확신해?'를 수치로 뽑아내는 기법.

• SkillHarm: 자동 생성 기반의 Skill-Use Lifecycle 전반을 다루는 Agent Skill 공격 벤치마크

  AI 에이전트가 사용하는 'Skill 패키지'에 악성 페이로드를 심으면 최신 모델도 86%까지 뚫린다는 보안 벤치마크.

• MemTrace: LLM Memory System의 오류를 추적하고 원인을 찾아내는 프레임워크

  RAG, Mem0 같은 LLM 메모리 시스템이 왜 틀린 답을 내는지 자동으로 찾아주는 디버깅 프레임워크

• DeepSWE: 오염 없는 장기 코딩 에이전트 벤치마크

  기존 SWE-bench의 데이터 오염 및 검증 오류 문제를 해결하기 위해 처음부터 새로 만든 코딩 에이전트 벤치마크로, GPT-5.5가 70%로 1위를 차지하고 모델 간 성능 격차가 훨씬 뚜렷하게 드러난다.

• Constraint Decay: LLM 에이전트가 백엔드 코드 생성에서 구조적 제약을 못 따라가는 이유

Related Resources

• 원본 트윗 (weezerOSINT)
• Notion 공식 문서 - Public pages and web publishing