▲

MoltBook 해킹: Supabase 설정 오류로 150만 개의 API 키 노출

 (wiz.io)
3P by GN⁺ 11시간전 | ★ favorite | 댓글 4개
  • AI 에이전트 전용 소셜 플랫폼 Moltbook의 데이터베이스가 잘못 구성되어, 150만 개의 API 인증 토큰과 3만5천 개의 이메일, 비공개 메시지가 외부에 노출됨
  • 클라이언트 측 자바스크립트에 Supabase API 키가 하드코딩되어 있었고, Row Level Security(RLS) 설정이 없어 누구나 전체 데이터베이스에 읽기·쓰기 접근 가능
  • 데이터에는 17,000명의 실제 사용자와 그들이 운영하는 150만 개의 에이전트 계정 정보가 포함되어, 인간 대 에이전트 비율이 1:88로 확인됨
  • 노출된 정보에는 OpenAI API 키 등 제3자 자격 증명, 비공개 대화, 게시물 수정 권한까지 포함되어 플랫폼 콘텐츠의 무결성 훼손 위험이 존재
  • 이번 사건은 AI 기반 ‘바이브 코딩(vibe coding)’ 의 보안 한계를 드러내며, AI 개발 환경에서 보안 기본값 자동화와 검증 절차 강화의 필요성을 보여줌

Moltbook과 보안 노출 개요

  • Moltbook은 AI 에이전트가 게시물 작성, 댓글, 투표, 평판 점수를 통해 활동하는 AI 중심 소셜 네트워크로, “에이전트 인터넷의 첫 페이지”를 표방
    • OpenAI 공동 창립자 Andrej Karpathy가 “가장 놀라운 SF적 도약”이라 평가하며 주목받음
  • 플랫폼 창립자는 “AI가 직접 코드를 작성했다”고 밝히며 ‘바이브 코딩’ 방식으로 개발했음
  • Wiz 연구팀은 Supabase 데이터베이스의 잘못된 구성을 발견, 전체 데이터에 대한 읽기·쓰기 접근이 가능했으며, 문제를 통보 후 몇 시간 내 수정 완료

노출된 Supabase 자격 증명

  • Moltbook 웹사이트의 클라이언트 자바스크립트 번들에서 Supabase 연결 정보가 하드코딩된 상태로 발견됨
    • 프로젝트: ehxbxtjliybbloantpwq.supabase.co
    • API 키: sb_publishable_4ZaiilhgPir-2ns8Hxg5Tw_JqZU_G6-
  • Supabase는 공개 키 노출 자체는 허용되지만, RLS 정책이 없을 경우 전체 데이터베이스 접근이 가능
  • Moltbook은 RLS가 비활성화되어 있었으며, 이로 인해 모든 테이블의 읽기·쓰기 권한이 공개 상태였음

인증되지 않은 데이터베이스 접근

  • 연구팀은 API 키를 이용해 REST API를 직접 호출한 결과, 관리자 수준의 응답을 받음
  • 응답에는 상위 에이전트의 API 키와 인증 토큰이 포함되어 있었으며, 이를 통해 계정 완전 탈취가 가능
  • PostgREST 오류 메시지와 GraphQL 인트로스펙션을 이용해 전체 스키마를 파악, 약 475만 건의 레코드가 노출된 것으로 확인

노출된 민감 데이터

  • 에이전트 인증 정보: 각 계정의 api_key, claim_token, verification_code 포함
    • 이를 통해 공격자는 임의의 에이전트로 로그인, 게시물 작성, 메시지 전송 가능
  • 사용자 이메일 및 신원 정보: 17,000명 이상의 사용자 이메일과 X(트위터) 핸들이 노출
    • 추가로 observers 테이블에서 29,631개의 이메일이 발견됨
  • 비공개 메시지 및 제3자 자격 증명: 4,060건의 DM이 암호화 없이 저장되어 있었으며, 일부에는 OpenAI API 키가 평문으로 포함
  • 쓰기 권한 노출: 인증 없이 게시물 수정이 가능해, 악성 콘텐츠 삽입이나 사이트 변조 위험 존재
    • 실제 테스트로 게시물 수정이 성공했으며, 이후 RLS 정책 적용으로 차단됨

AI 앱 개발을 위한 5가지 보안 교훈

  • 1. 빠른 개발 속도는 보안 기본값 부재 시 시스템적 위험 초래
    • Supabase 설정 한 줄이 전체 노출의 원인이 되었음
  • 2. 참여 지표 검증 필요
    • 1,500,000개의 에이전트 중 실제 인간은 17,000명으로, 88:1 비율의 허위 활성도 가능성
  • 3. 프라이버시 붕괴의 연쇄 효과
    • DM 노출로 인해 OpenAI API 키 등 외부 서비스 자격 증명까지 유출
  • 4. 쓰기 권한은 단순 데이터 유출보다 심각한 무결성 위협
    • 콘텐츠 조작, 프롬프트 인젝션, 내러티브 통제 등 위험 발생
  • 5. 보안 성숙도는 반복적 개선 과정
    • Wiz와 Moltbook 팀은 여러 차례 수정·검증을 거쳐 모든 테이블을 보호

바이브 코딩과 보안의 과제

  • AI가 개발 장벽을 낮추었지만, 보안 장벽은 여전히 높음
  • AI 개발 도구가 보안 기본값(RLS 활성화, 자격 증명 스캔 등) 을 자동 적용해야 함
  • 보안이 AI 개발의 기본 내장 요소로 자리 잡을 때, 안전하고 혁신적인 AI 소프트웨어 생태계 구축 가능

타임라인

  • 2026년 1월 31일 21:48 UTC: Moltbook 유지자에게 최초 연락
  • 22:06: Supabase RLS 오구성 보고
  • 23:29: 1차 수정(agents, owners, site_admins 테이블 보호)
  • 2월 1일 00:13: 2차 수정(agent_messages 등 보호)
  • 00:31: 게시물 수정 취약점 발견
  • 00:44: 3차 수정으로 쓰기 권한 차단
  • 00:50~01:00: 추가 노출 테이블 발견 및 최종 수정 완료
▲
crawler 22분전  [-]

몰트봇은 에이전트도 해킹 이슈 터지고 이젠 플랫폼까지 터지네 ㅋㅋㅋ

2026년 최악의 바이브 프로젝트 사례로 남을 것 같습니다.
아직 2월이지만 확신할 수 있어요 ㅋㅋ

답변달기
▲
bini59 1시간전  [-]

바이브로 보안을 신경안쓰고도 대규모 서비스가 개발될 수 있다는게 문제일까

답변달기
▲
GN⁺ 11시간전  [-]
Hacker News 의견들

  • Moltbot/Moltbook의 성공이 처음엔 놀라웠지만 이제는 이해가 감
    핵심은 ‘사전 패키징된 에이전트’ 라는 점임. 기술에 익숙하지 않은 일반 사용자에게 “맥 미니 사서 몇 줄 복사해 설치” 같은 접근성이 큰 매력으로 작용함
    하지만 이런 접근성은 보안 악몽을 키우는 중임. 기술적 이해 없이 유행만 좇는 사용자들이 늘어나면서, 취약한 환경이 더 오래 지속될 위험이 있음

    • 정말 성공이라 할 수 있을까 하는 의문이 있음. 실제로는 1.5백만 개의 에이전트 중 인간 소유자는 1.7만 명뿐이라는 분석도 있음. 유명 인플루언서들이 언급하면서 바이럴된 측면이 큼
    • 모든 LLM은 설계상 보안 취약함. 프롬프트 인젝션이나 보상 해킹으로 간단히 우회 가능함. 완전한 해결책은 외부 입력과 네트워크 접근을 완전히 차단하는 것뿐임
    • “맥 미니 사서 설치”는 마케팅 문구에 불과함. 실제로는 설정 오류가 잦고 컨텍스트 관리가 엉망임. 로그는 남지만 직전 대화도 잊어버림. 아이디어는 좋지만 구현은 거칠음
    • Dropbox가 처음 나왔을 때처럼 ‘포장된 접근성’이 성공 요인임. 하지만 대기업도 해킹을 막지 못하는 현실에서, misconfigured DB 정도는 대수롭지 않게 여겨짐. 보안보다 편의성이 여전히 우위에 있음
    • 단순히 화제가 된 것뿐인지, 진짜 성공인지는 아직 불분명함

  • Scott Alexander가 지적한 대로, 에이전트들이 상호작용하며 복합적 행동을 만들어내는 현상이 중요함
    이게 현실 세계에 영향을 미치기 시작하면 존재론적 문제로 이어질 수 있음.
    결국 “AGENT.md에 YES라고 쓴 모든 일”이 실제로 일어날 수 있는 구조임

    • 무슨 말인지 잘 모르겠다는 반응도 있음
    • 그래서 나는 nono.sh를 만들었음. 에이전트가 커널 격리 샌드박스 안에서 ‘제로 트러스트’로 시작하도록 함
    • 인간도 일정 부분 ‘앵무새처럼 반복’ 하는 존재임. Moltbook이 Reddit을 흉내내듯, 인간도 예측 가능한 패턴 속에서 대화함. 결국 우리는 생각보다 덜 영리할지도 모름

  • Moltbook API가 누구에게나 열려 있어서, 단순한 프롬프트로 사용자 이메일이나 데이터 유출을 유도할 수 있음
    그래서 맥 미니로 격리하려는 시도가 생기지만, 네트워크에 연결된 이상 완전한 보호는 불가능함

    • 미친 게 아님. LLM은 명령과 데이터의 구분을 확실히 못함. 일종의 ‘소셜 엔지니어링’ 취약점임
    • 결국 “위험 없이 유용한 일”을 시킬 수 있느냐가 문제임. 예를 들어 장보기나 여행 예약을 맡기려면 신용카드 접근이 필요함
    • 나는 LLM을 DMZ 환경에 격리해 사용 중임. 디스크 없는 계정으로 sudo 권한 없이 실행함. 완벽하진 않지만 그럭저럭 작동 중임
    • 사실상 완벽한 보호책은 없음. 데이터 접근, 불신 텍스트, 네트워크 통신이라는 ‘치명적 삼합체’ 가 모두 존재하기 때문임
    • 다만 감시·승인 계층을 두는 방식은 가능함. 신용카드 한도처럼 LLM의 행동을 승인·제한하는 구조를 만들 수 있음

  • OpenClaw를 써봤는데 토큰 소모량이 엄청남
    보안을 위해서는 제한된 API 권한을 가진 전용 장비(Raspberry Pi 등) 가 도움이 될 듯함. Pi가 더 강력한 모델을 돌릴 수 있다면 구매 의향 있음

  • Moltbook은 AI와 인간을 구분할 방법이 없음. ‘역 CAPTCHA’ 를 어떻게 구현하겠는가 하는 문제임

    • 재미로 Claude에게 “인간 스파이 계정을 찾아보라”는 프롬프트를 줬더니, 실제로 ‘Reverse Turing Problem’이라는 스레드를 만들었음. 하지만 지금은 스팸으로 도배되어 대화가 불가능한 수준임
    • 세션의 모든 입력·출력을 서명하고 감사 가능하게 만드는 방식이 필요함. 인간이 주입한 프롬프트도 추적 가능해야 함
    • AI에게는 쉬우나 인간에게는 어려운 작업을 짧은 시간 안에 여러 번 시키는 것도 구분법이 될 수 있음
    • 혹은 LLM이 이미 알고 있을 법한 희귀 질문을 빠르게 던지는 방법도 있음
    • 하지만 결국, 인간이 프롬프트로 유도한 행동인지 구별하기는 여전히 어려움

  • Moltbook 보안 이슈를 몇 시간 만에 고쳤다고 하지만, ‘바이브 코딩’으로 만든 프로젝트의 보안 결함을 어떻게 설명하느냐가 문제임

    • 실제로 Claude가 Supabase용 쿼리를 생성했고, 그걸 사람이 Moltbook 개발자에게 전달해 수정했다고 함. 믿기 어렵지만 사실임

  • Moltbook 내부를 분석하는 사람들이 있다는 게 놀라움. 애초에 ‘농담으로 만든 프로젝트’ 였는데 이렇게 커질 줄은 아무도 몰랐음

    • 하지만 사용자 PII가 노출된다면 농담으로 넘길 수 없는 법적 문제임. ‘바이브 코딩’ 문화가 책임 없는 개발 풍토를 만들고 있음
    • Dogecoin도 농담에서 시작했지만 지금은 수십억 달러 규모임
    • 보안 연구자들이 취약점을 찾는 것도 결국 ‘바이브’의 일부일 수 있음
    • 그러나 “농담이었다”는 변명으로 실제 피해를 덮을 수는 없음
    • 창작자가 의도적으로 만든 결과라면 ‘농담’이라는 핑계는 약함

  • OpenClaw 인스턴스가 다른 인스턴스에 OpenAI 키를 전송한 사건이 웃기면서도 불안했음.
    실제로 키를 보냈는지, 아니면 흉내만 낸 건지는 불분명함

  • Wiz의 기사 자체가 AI가 쓴 것처럼 느껴짐. 문장 구조나 대시 사용이 전형적인 LLM 스타일임.
    LLM이 만든 플랫폼의 보안을 LLM이 쓴 기사로 비판한다는 점이 아이러니함
    실제 취약점은 진짜겠지만, 인간이 썼다면 불필요한 군더더기는 줄었을 것 같음

  • 노출된 데이터로 1.5백만 에이전트 중 1.7만 명만 인간이라는 사실이 드러났음
    하지만 연구자가 직접 API 키로 테이블을 조회해 얻은 수치라, 이를 공개한 건 단순한 버그 리포트가 아니라 기업 비판 행위로 보임
    이런 방식은 연구자와 기업 간의 신뢰 협력 관계를 해칠 위험이 있음

답변달기