Moltbook 데이터베이스 전면 공개: 에이전트 API 키 150만 개, 이메일 35,000개

Moltbook is a Reddit-style social network built so that only AI agents can post. Its founder, Matt Schlicht, launched it on 28 January 2026 and said publicly on X that he had not written a single line of its code: "I just had a vision for the technical architecture, and AI made it a reality," as Wiz quotes him. Three days later, on 31 January 2026, 404 Media reported that anyone could take control of any AI agent on the site. Wiz, which had found the same misconfiguration independently, published the technical account on 2 February: a Supabase API key hard-coded into Moltbook's client-side JavaScript pointed at a production database with no Row Level Security, and an unauthenticated request to the agents table returned live authentication tokens for the platform's agents, including its best-known ones. Wiz counted 1.5 million API tokens, 35,000 email addresses and 4,060 private agent-to-agent conversations readable that way, and confirmed it could also rewrite live posts. The archive files the episode as a critical-severity credential incident with a day-precision date of 31 January 2026, a confidence grade of A and recorded real harm, alongside the rest of its agent-infrastructure records in the Orca AI Incident Archive.

열쇠는 결코 비밀이 아니었다

Supabase is a hosted Postgres service with a REST API that Wiz describes as popular with vibe-coded applications because it is easy to set up. Its publishable key is designed to sit in client-side code: it identifies the project, and the access control is supposed to come from Row Level Security policies on the tables behind it. Wiz's Gal Nagli states the point explicitly in the write-up: exposing the key "does not automatically indicate a security failure," and when RLS is configured correctly "the public API key is safe to expose - it acts like a project identifier." In Moltbook's implementation, Wiz writes, "this critical line of defense was missing."

이 메커니즘은 번들이었다. Wiz에 따르면, moltbook.com/_next/static/chunks/18e24eafc444b2b9.js의 프로덕션 JavaScript 파일에는 Supabase 프로젝트 주소인 ehxbxtjliybbloantpwq.supabase.co와 키인 sb_publishable_4ZaiilhgPir-2ns8Hxg5Tw_JqZU_G6-가 모두 들어 있었다. 그런 다음 Wiz는 agents 테이블에 세 개의 이름과 API 키를 요청하는 요청을 보냈는데, 이 쿼리는 빈 배열이나 권한 오류를 반환했어야 했다. 대신 플랫폼에서 가장 인기 있는 에이전트들의 인증 토큰을 포함한 행들이 반환되었다. 그런 다음 Wiz는 PostgREST 오류 메시지와 GraphQL 인트로스펙션을 사용해 스키마를 매핑했고, 약 475만 개의 노출된 레코드를 집계했다.

아카이브의 요약은 Moltbook이 Row Level Security를 "한 번도 활성화하지 않았다"고 말하지만, 출처들은 그보다 느슨하다. 어느 쪽도 구성 이력을 보여주지 않으므로, 문서화된 것은 검토 중 RLS가 적용되지 않았다는 점이다: Wiz는 테이블이 열려 있음을 발견했고, 발견자의 설명을 보도한 Implicator.ai는 Moltbook이 "RLS를 켠 적이 없다. 또는 켰다면 구성된 정책이 없었다"고 쓴다. 그 설정이 한 번도 활성화되지 않았는지, 아니면 정책 없이 활성화되었는지는 어느 설명으로도 확립되지 않으며, 실질적 결과는 같다.

표에 실제로 무엇이 들어 있었는지

Wiz는 테이블과 그 내용을 밝혔다. agents 테이블에는 행마다 해당 에이전트를 인증하는 api_key, 그 소유권을 주장하는 데 사용되는 claim_token, 등록 시 발급된 verification_code, 그리고 에이전트의 karma 및 팔로워 수가 저장되어 있었다. 이는 데이터 유출이라기보다 완전한 계정 탈취 키트다. 그 키 중 하나만 있으면 요청이 해당 에이전트로서 게시하고 메시지를 보내는 등 행동할 수 있으며, Wiz는 여기에 높은 karma 계정과 잘 알려진 페르소나 에이전트도 포함되어 있었다고 지적한다.

owners 테이블에는 17,000명 이상 사용자의 개인정보가 저장되어 있었으며, 여기에는 이메일 주소와 각 에이전트에 연결된 X 핸들 및 표시 이름이 포함되었습니다. Wiz가 나중에 GraphQL 엔드포인트를 통해 발견한 observers 테이블에는 Moltbook의 계획된 "Build Apps for AI Agents" 제품 얼리 액세스 가입자의 이메일 주소 29,631개가 추가로 들어 있었습니다. agent_messages 테이블에는 에이전트 간 비공개 다이렉트 메시지 대화 4,060건이 암호화나 접근 제어 없이 저장되어 있었으며, Wiz는 일부 대화에 에이전트들이 서로 공유한 OpenAI API 키를 포함한 타사 자격 증명이 평문으로 들어 있었다고 보고합니다.

에이전트와 사람의 비율은 플랫폼의 대외적 스토리를 약화시킨 부분이다. Wiz는 등록된 에이전트가 150만 개인 반면 사람 소유자는 약 1만 7,000명으로, 사람 한 명당 약 88개의 에이전트에 해당한다고 보고하며, 그 격차를 속도 제한이나 신원 확인의 부재 탓으로 돌린다. 누구나 반복문으로 에이전트를 등록할 수 있었고, 사람이 기본적인 POST 요청만으로 "에이전트"로서 게시물을 올릴 수 있었다. Wiz의 결론은 단도직입적이다. "혁명적인 AI 소셜 네트워크는 대부분 봇 함대를 운영하는 사람들이었다."

이메일 수는 깔끔하게 맞아떨어지지 않으며 Wiz는 그 이유를 설명하지 않는다. 대표 수치는 35,000개의 이메일 주소이고, 자체 표 수준 집계는 소유자 이메일 17,000여 개와 관찰자 이메일 29,631개로, 합하면 약 46,600개이다. 두 수치 모두 Wiz의 것이며, 이 글은 35,000이 어떻게 산출되었는지, 즉 두 표에 걸친 중복 제거에 의한 것인지 아니면 관찰자 표가 발견되기 전에 찍은 스냅샷에 의한 것인지를 밝히지 않았다.

노출의 쓰기 절반

데이터를 읽은 것만이 발견의 전부는 아니었다. Wiz는 민감한 테이블에 대한 읽기 접근을 차단한 첫 번째 수정 라운드 이후에도 공개 테이블에 대한 쓰기 접근은 계속 열려 있었다고 보고한다. Wiz는 라이브 게시물에 PATCH 요청을 보내 제목과 본문을 "@galnagli - responsible disclosure test" 문자열로 바꾼 뒤, 해당 편집이 사이트에 표시되는 것을 확인하는 방식으로 이를 테스트했다. 쓰기 제한이 적용된 뒤 Wiz는 자신의 테스트 게시물을 더 이상 되돌릴 수 없었고, Moltbook 팀은 몇 시간 후 해당 콘텐츠를 삭제했으며 연구자들에게 보고서를 감사했다고 Wiz는 쓴다.

Wiz가 제기한 우려는 그 자체를 위한 훼손이 아니다. 게시물에 대한 인증되지 않은 쓰기 경로가 있다는 것은 누구나 다른 에이전트가 읽는 콘텐츠에 프롬프트 인젝션 페이로드를 주입할 수 있다는 뜻이며, Wiz는 노출 기간 동안 플랫폼의 게시물, 투표, 카르마의 무결성을 측정된 사실이 아닌 미해결 질문으로 제기한다. 이 기사를 위해 검토한 어떤 출처도 얼마나 많은 콘텐츠가 누구에 의해 변경되었는지 정량화하지 않았다.

3시간 12분, 네 건의 개별 수정

Wiz의 공개 타임라인은 2026년 1월 31일 21:48 UTC에 X 다이렉트 메시지로 Moltbook 유지관리자에게 처음 연락하면서 시작되어, 노출된 테이블 중 마지막 테이블이 보호된 2월 1일 01:00 UTC에 끝난다. 첫 연락 이후 일곱 가지 추가 단계를 기록한다. 22:06의 보고, agents, owners, site_admins 테이블을 다루는 23:29의 첫 번째 수정, agent_messages, notifications, votes, follows를 다루는 00:13의 두 번째 수정, 00:31의 쓰기 경로 발견, 이를 차단하는 00:44의 세 번째 수정, observers, identity_verifications, developer_apps 테이블을 발견한 00:50, 그리고 01:00의 최종 수정이다.

That timeline is the strongest argument against the simplest version of this story. Implicator.ai describes the fix in two SQL statements - it writes that "the fix required two SQL statements. They didn't exist," and the archive's summary carries the same "two lines of SQL" framing. The core repair for the read exposure probably was that small: enable RLS and add policies on the tables. But Wiz's own record shows four fixes across three hours, a second and separate write-access gap that the read fix did not close, and three further tables - including the 29,631 observer addresses - that surfaced only after the first two rounds. Wiz's closing lesson is that it "worked with the team through multiple rounds of remediation, with each iteration surfacing additional exposed surfaces." The two-line version describes the configuration change, not the remediation.

두 가지 발견, 그리고 기록의 차이

The find is usually credited to Jamieson O'Reilly, who founded the Australian security firm Dvuln, and who demonstrated the takeover to 404 Media; Implicator.ai reports that 404 Media verified the capability by updating O'Reilly's own Moltbook account with his permission. Wiz's post is by Gal Nagli and carries a note at the end crediting O'Reilly: "Security researcher Jameson O'Reilly also discovered the underlying Supabase misconfiguration, which has been reported by 404 Media." The note goes on to say that Wiz's post shares an independent discovery of the same issue.

The archive's summary describes both as Wiz researchers. Wiz's own post does not: it names Nagli as its author and describes O'Reilly as an independent researcher whose find 404 Media reported, and Implicator.ai places O'Reilly at Dvuln. The spelling is also unsettled across sources - Wiz writes "Jameson", while Dvuln's own site lists its founder as "Jamieson" - and this piece has used the spelling that site uses. What is not in dispute is that there were two independent discoveries of the same misconfiguration within days.

The account of the response differs by source, and the difference is worth reporting rather than resolving. On O'Reilly's account, relayed by Implicator.ai, he approached Schlicht directly and offered to help patch the flaw; the reply was: "I'm just going to give everything to AI. So send me whatever you have." A full day then passed without follow-up, according to that account, and Schlicht did not respond to 404 Media's request for comment. Wiz, contacting the maintainer separately, records its report filed at 22:06 UTC and the last of four fixes at 01:00 UTC, three hours and twelve minutes after first contact. The two timelines run on different channels and neither source says whether one prompted the other; both can be accurate.

기록이 입증하는 것과 입증하지 못하는 것

확인된 사실은 구성, 데이터 클래스, 두 건의 독립적인 발견, 수정 순서, 그리고 플랫폼의 인간 대 에이전트 비율이다. 그 목록의 모든 항목은 Wiz의 1차 기술 보고서 또는 발견자의 설명을 바탕으로 한 보도에서 나왔으며, 두 출처는 메커니즘에 대해 일치한다.

입증되지 않은 부분은 사전 접근에서 시작된다. Wiz는 자사의 조사 및 수정 검증 과정에서 접근한 모든 데이터가 삭제되었다고 밝히며, 이는 다른 누구에 대해서는 아무것도 말해주지 않는다. Implicator.ai는 이 공백을 명확히 지적한다. O'Reilly가 발견하기 전에 누군가 그 데이터베이스를 찾았는지, 플랫폼의 바이럴 주간에 유포된 게시물 중 얼마나 많은 것이 진짜 에이전트 출력이고 얼마나 많은 것이 도난당한 키에서 나온 것인지는 아무도 알 수 없다. 이 글을 위해 읽은 어떤 출처도 노출된 자격 증명의 확인된 오용을 보고하지 않으며, 실제로 탈취된 계정 수를 보고한 곳도 없다. 아카이브의 real_harm 플래그가 true인 것은 특정 오용이 기록되었기 때문이 아니라, 개인 데이터와 활성 제3자 자격 증명을 누구나 실제로 읽을 수 있었기 때문이다.

에이전트 수 집계도 서로 어긋나며, 그 불일치는 노출의 사실관계보다는 플랫폼의 성장을 따라간다. Implicator.ai는 2월 1일 발견자의 설명을 바탕으로 글을 쓰면서 "3만 2,000개 이상"의 등록 에이전트와 149만 건의 노출 기록을 언급했는데, 같은 글에서는 해당 사이트가 첫 주에 3만 7,000개를 넘어섰다고도 말한다. Wiz는 2월 2일 검토에서 150만 개의 에이전트와 약 475만 건의 기록을 집계했다. 아카이브의 요약에는 플랫폼이 결국 170만 명의 등록 에이전트와 거의 700만 건의 댓글을 축적했다고 기록되어 있으나, 이 글은 두 최종 총계 중 어느 것도 독자적으로 확인하지 않았다. 모든 설명이 뒷받침하는 숫자는 하나, 즉 사안의 윤곽이다. 인간보다 훨씬 많은 에이전트가 있었고, 그 차이를 구별할 수 있는 메커니즘은 없었다.

무엇이 바뀌었고, 그 설정이 해결하지 못한 것

바뀐 것은 범위가 좁고 문서화되어 있습니다. 민감한 테이블의 RLS 정책, 공개 테이블에 대한 쓰기 제한, 연구진의 테스트 게시물 삭제, 그리고 Wiz에 따르면 2월 1일 01:00 UTC까지 완전히 패치된 플랫폼입니다. 이 글을 위해 읽은 자료 중 어디에도 Moltbook이 속도 제한, 에이전트 신원 검증, 또는 해당 기간에 작성된 콘텐츠에 대한 감사를 추가했다는 내용은 없습니다. Wiz의 권고는 플랫폼보다는 도구를 겨냥합니다. Supabase 백엔드를 생성하는 AI 어시스턴트가 기본적으로 RLS를 활성화할 수 있고, 배포 플랫폼은 노출된 자격 증명과 안전하지 않은 구성을 스캔할 수 있습니다.

SQL보다 오래 남는 것은 그 데이터베이스가 드러내 준 전제다. 판매 포인트가 오직 AI 에이전트만 게시할 수 있다는 것이었던 네트워크는 에이전트가 에이전트인지 확인할 방법이 없었고, 그 자격 증명 계층이 스크립트를 가진 인간과 사이트의 모든 신원 사이에 놓인 유일한 방어선이었다. 그래서 이 기록이 일상적인 설정 오류가 아니라 이정표로 분류되는 것이다. 노출 자체는 평범했지만, 그것이 드러낸 것—자율 에이전트를 위한 인증된 신원 계층—은 평범하지 않았다.