Cơ sở dữ liệu Moltbook mở hoàn toàn: 1,5 triệu khóa API agent, 35.000 email

Moltbook là một mạng xã hội kiểu Reddit được xây dựng để chỉ các tác nhân AI mới có thể đăng bài. Người sáng lập, Matt Schlicht, đã ra mắt nó vào ngày 28 tháng 1 năm 2026 và công khai nói trên X rằng ông chưa viết một dòng mã nào của nó: “Tôi chỉ có một tầm nhìn về kiến trúc kỹ thuật, và AI đã biến nó thành hiện thực,” như Wiz trích dẫn lời ông. Ba ngày sau, vào ngày 31 tháng 1 năm 2026, 404 Media đưa tin rằng bất kỳ ai cũng có thể kiểm soát bất kỳ tác nhân AI nào trên trang. Wiz, đơn vị đã độc lập phát hiện cùng lỗi cấu hình, đã công bố bản mô tả kỹ thuật vào ngày 2 tháng 2: một khóa API Supabase được gắn cứng trong JavaScript phía máy khách của Moltbook trỏ tới một cơ sở dữ liệu production không có Row Level Security, và một yêu cầu không xác thực tới bảng agents trả về các token xác thực còn hiệu lực cho các tác nhân của nền tảng, bao gồm cả những tác nhân nổi tiếng nhất. Wiz thống kê được 1,5 triệu token API, 35.000 địa chỉ email và 4.060 cuộc trò chuyện riêng tư giữa các tác nhân có thể đọc được theo cách đó, và xác nhận rằng nó cũng có thể viết lại các bài đăng đang hoạt động. Kho lưu trữ xếp sự việc này là một sự cố thông tin xác thực mức độ nghiêm trọng tới hạn với ngày chính xác đến từng ngày là 31 tháng 1 năm 2026, mức độ tin cậy A và ghi nhận tổn hại thực tế, cùng với phần còn lại của các hồ sơ hạ tầng tác nhân trong Orca AI Incident Archive.

Điều mấu chốt chưa bao giờ là bí mật

Supabase là một dịch vụ Postgres được lưu trữ với REST API mà Wiz mô tả là phổ biến với các ứng dụng được vibe-code vì dễ thiết lập. Khóa publishable của nó được thiết kế để nằm trong mã phía client: nó xác định dự án, và kiểm soát truy cập được cho là đến từ các chính sách Row Level Security trên các bảng phía sau. Gal Nagli của Wiz nêu rõ quan điểm trong bài viết: việc lộ khóa "không tự động chỉ ra một lỗi bảo mật", và khi RLS được cấu hình đúng "khóa API công khai an toàn để lộ - nó hoạt động như một định danh dự án." Trong cách triển khai của Moltbook, Wiz viết, "lớp phòng thủ quan trọng này đã bị thiếu."

Cơ chế này là một gói tổng hợp. Theo Wiz, tệp JavaScript production tại moltbook.com/_next/static/chunks/18e24eafc444b2b9.js chứa cả địa chỉ dự án Supabase, ehxbxtjliybbloantpwq.supabase.co, lẫn khóa sb_publishable_4ZaiilhgPir-2ns8Hxg5Tw_JqZU_G6-. Wiz sau đó đã gửi một yêu cầu tới bảng agents để hỏi ba tên và khóa API, một truy vấn lẽ ra phải trả về một mảng rỗng hoặc lỗi phân quyền. Thay vào đó, nó trả về các hàng, bao gồm cả token xác thực của những agent phổ biến nhất trên nền tảng. Từ đó, Wiz đã lập bản đồ lược đồ bằng các thông báo lỗi PostgREST và introspection GraphQL, rồi đếm được khoảng 4,75 triệu bản ghi bị lộ.

Bản tóm tắt của kho lưu trữ nói Moltbook "chưa bao giờ bật" Row Level Security, còn các nguồn thì nói lỏng lẻo hơn thế. Cả hai đều không cho thấy lịch sử cấu hình, nên điều được ghi nhận là RLS không có hiệu lực trong thời gian đánh giá: Wiz phát hiện các bảng đang mở, và Implicator.ai, khi tường thuật lời kể của người phát hiện, viết rằng Moltbook "chưa bao giờ bật RLS. Hoặc nếu có bật, thì không có chính sách nào được cấu hình." Việc cài đặt đó chưa từng được bật hay đã được bật mà không có chính sách nào không được xác lập bởi cả hai tường thuật, và kết quả thực tế là như nhau.

Thực sự có gì trong các bảng

Wiz đặt tên cho các bảng và nội dung của chúng. Bảng agents chứa, trên mỗi hàng, api_key dùng để xác thực agent, một claim_token dùng để nhận quyền sở hữu nó, một verification_code được cấp khi đăng ký, cùng số karma và số người theo dõi của agent. Đó là một bộ công cụ chiếm đoạt tài khoản hoàn chỉnh chứ không phải một vụ rò rỉ dữ liệu: với một trong những khóa đó, một yêu cầu có thể đăng bài, nhắn tin và hành động như chính agent đó, và Wiz lưu ý rằng điều này bao gồm các tài khoản có karma cao và các agent nhân vật nổi tiếng.

Bảng owners lưu thông tin cá nhân của hơn 17.000 người dùng, bao gồm địa chỉ email cùng tên người dùng X và tên hiển thị đằng sau mỗi tác nhân. Một bảng mà Wiz tìm thấy sau đó thông qua điểm cuối GraphQL, observers, chứa thêm 29.631 địa chỉ email thuộc các lượt đăng ký quyền truy cập sớm cho sản phẩm "Build Apps for AI Agents" dự kiến của Moltbook. Bảng agent_messages chứa 4.060 cuộc trò chuyện nhắn tin trực tiếp riêng tư giữa các tác nhân, được lưu trữ không mã hóa hoặc kiểm soát truy cập, và Wiz báo cáo rằng một số cuộc trò chuyện chứa thông tin xác thực của bên thứ ba ở dạng văn bản thuần, bao gồm khóa API OpenAI mà các tác nhân đã chia sẻ với nhau.

Tỷ lệ giữa tác nhân và con người là phần làm lung lay câu chuyện công khai của nền tảng. Wiz báo cáo 1,5 triệu tác nhân đã đăng ký so với khoảng 17.000 chủ sở hữu là con người, tức khoảng 88 tác nhân mỗi người, và quy khoảng cách này cho việc thiếu giới hạn tốc độ hoặc xác minh danh tính: bất kỳ ai cũng có thể đăng ký tác nhân trong một vòng lặp, và một người có thể đăng với tư cách "tác nhân" bằng một yêu cầu POST cơ bản. Kết luận của Wiz thẳng thừng - "mạng xã hội AI mang tính cách mạng phần lớn là con người vận hành các đội bot."

Số lượng email không cộng lại một cách khớp rành mạch và Wiz không giải thích tại sao. Con số tiêu đề của nó là 35.000 địa chỉ email; các con số đếm ở cấp bảng của chính nó là hơn 17.000 email chủ sở hữu và 29.631 email người quan sát, tổng cộng khoảng 46.600. Cả hai con số đều là của Wiz, và bài viết này không xác định được con số 35.000 được tính ra như thế nào - liệu bằng cách khử trùng lặp giữa hai bảng hay từ một ảnh chụp nhanh được thực hiện trước khi bảng người quan sát được tìm thấy.

Nửa phần ghi của sự phơi nhiễm

Việc đọc được dữ liệu không phải là toàn bộ phát hiện. Wiz báo cáo rằng ngay cả sau vòng sửa lỗi đầu tiên đã chặn quyền đọc đối với các bảng nhạy cảm, quyền ghi vào các bảng công khai vẫn mở. Nhóm đã kiểm tra điều này bằng cách gửi một yêu cầu PATCH đến một bài đăng đang hoạt động và thay tiêu đề cùng nội dung của bài bằng chuỗi "@galnagli - responsible disclosure test", sau đó xác nhận chỉnh sửa hiển thị trên trang. Sau khi hạn chế ghi được áp dụng, Wiz không thể hoàn nguyên bài đăng thử nghiệm của chính mình nữa; nhóm Moltbook đã xóa nội dung vài giờ sau đó, Wiz viết, và cảm ơn các nhà nghiên cứu về báo cáo.

Mối quan tâm mà Wiz nêu không phải là việc bôi xấu chỉ vì mục đích tự thân. Một đường ghi không được xác thực vào các bài đăng nghĩa là bất kỳ ai cũng có thể chèn tải trọng prompt-injection vào nội dung mà các tác nhân khác đọc, và Wiz nêu tính toàn vẹn của bài đăng, phiếu bầu và karma trên nền tảng trong cửa sổ phơi nhiễm như một câu hỏi mở chứ không phải một vấn đề đã được đo lường. Không có nguồn nào được đọc cho bài viết này định lượng được lượng nội dung đã bị thay đổi hoặc bởi ai.

Ba giờ mười hai phút, bốn lần sửa riêng biệt

Dòng thời gian công bố của Wiz bắt đầu lúc 21:48 UTC ngày 31 tháng 1 năm 2026, với lần liên hệ đầu tiên tới người duy trì Moltbook qua tin nhắn trực tiếp trên X, và kết thúc lúc 01:00 UTC ngày 1 tháng 2, khi bảng cuối cùng trong số các bảng bị lộ được bảo vệ. Sau lần liên hệ đầu tiên đó, dòng thời gian ghi nhận bảy bước tiếp theo: báo cáo lúc 22:06, bản sửa lỗi đầu tiên lúc 23:29 bao gồm các bảng agents, owners và site_admins, bản thứ hai lúc 00:13 bao gồm agent_messages, notifications, votes và follows, việc phát hiện đường ghi lúc 00:31, bản sửa lỗi thứ ba đóng đường ghi này lúc 00:44, việc phát hiện các bảng observers, identity_verifications và developer_apps lúc 00:50, và bản sửa lỗi cuối cùng lúc 01:00.

Dòng thời gian đó là lập luận mạnh nhất chống lại phiên bản đơn giản nhất của câu chuyện này. Implicator.ai mô tả bản sửa lỗi bằng hai câu lệnh SQL - họ viết rằng "bản sửa lỗi cần hai câu lệnh SQL. Chúng không tồn tại," và phần tóm tắt của kho lưu trữ cũng mang cùng cách diễn đạt "hai dòng SQL". Bản sửa lỗi cốt lõi cho việc lộ dữ liệu đọc có lẽ nhỏ như vậy: bật RLS và thêm chính sách trên các bảng. Nhưng hồ sơ của chính Wiz cho thấy bốn bản sửa trong ba giờ, một lỗ hổng quyền ghi thứ hai và riêng biệt mà bản sửa lỗi đọc không khắc phục được, và ba bảng nữa - bao gồm 29,631 địa chỉ observer - chỉ lộ ra sau hai vòng đầu tiên. Bài học kết luận của Wiz là họ "đã làm việc với nhóm qua nhiều vòng khắc phục, với mỗi vòng lặp làm lộ thêm các bề mặt bị phơi nhiễm." Phiên bản hai dòng mô tả thay đổi cấu hình, không phải quá trình khắc phục.

Hai phát hiện, và một khác biệt trong hồ sơ

Phát hiện này thường được ghi công cho Jamieson O'Reilly, người sáng lập công ty bảo mật Dvuln của Úc, và là người đã trình diễn việc chiếm quyền điều khiển cho 404 Media; Implicator.ai đưa tin rằng 404 Media đã xác minh khả năng này bằng cách cập nhật tài khoản Moltbook của chính O'Reilly với sự cho phép của anh ấy. Bài đăng của Wiz do Gal Nagli thực hiện và có một ghi chú ở cuối ghi công O'Reilly: "Nhà nghiên cứu bảo mật Jameson O'Reilly cũng đã phát hiện ra lỗi cấu hình sai Supabase cơ bản, vấn đề này đã được 404 Media đưa tin." Ghi chú tiếp tục nói rằng bài đăng của Wiz chia sẻ một phát hiện độc lập về cùng vấn đề.

Phần tóm tắt của kho lưu trữ mô tả cả hai là nhà nghiên cứu của Wiz. Bài đăng của chính Wiz thì không: bài này ghi Nagli là tác giả và mô tả O'Reilly là một nhà nghiên cứu độc lập mà 404 Media đã đưa tin về phát hiện của anh ấy, còn Implicator.ai đặt O'Reilly tại Dvuln. Cách viết tên cũng chưa thống nhất giữa các nguồn - Wiz viết "Jameson", trong khi trang web của chính Dvuln liệt kê người sáng lập của mình là "Jamieson" - và bài viết này đã dùng cách viết mà trang đó sử dụng. Điều không gây tranh cãi là đã có hai phát hiện độc lập về cùng một lỗi cấu hình trong vòng vài ngày.

Lời kể về phản hồi khác nhau tùy theo nguồn, và sự khác biệt này đáng được báo cáo hơn là hóa giải. Theo lời kể của O'Reilly, được Implicator.ai chuyển lại, ông đã trực tiếp liên hệ với Schlicht và đề nghị giúp vá lỗ hổng; câu trả lời là: “Tôi sẽ giao hết mọi thứ cho AI. Vậy cứ gửi cho tôi bất cứ thứ gì anh có.” Theo lời kể đó, sau đó trọn một ngày trôi qua mà không có phản hồi tiếp theo, và Schlicht đã không trả lời yêu cầu bình luận của 404 Media. Wiz, khi liên hệ riêng với người bảo trì, ghi nhận báo cáo của mình được gửi lúc 22:06 UTC và bản sửa cuối cùng trong bốn bản sửa lúc 01:00 UTC, tức ba giờ mười hai phút sau lần liên hệ đầu tiên. Hai dòng thời gian diễn ra trên các kênh khác nhau và không nguồn nào cho biết liệu bên này có thúc đẩy bên kia hay không; cả hai đều có thể chính xác.

Những gì hồ sơ chứng minh, và những gì hồ sơ không chứng minh

Các dữ kiện đã được xác lập gồm cấu hình, các lớp dữ liệu, hai phát hiện độc lập, trình tự khắc phục và tỷ lệ người trên tác nhân của nền tảng. Mọi thứ trong danh sách đó đều đến từ bài viết kỹ thuật gốc của Wiz hoặc từ các bài báo xây dựng dựa trên lời kể của người phát hiện, và cả hai đều thống nhất về cơ chế.

Điều chưa được xác lập bắt đầu từ việc truy cập trước đó. Wiz tuyên bố rằng toàn bộ dữ liệu được truy cập trong quá trình nghiên cứu và xác minh bản sửa lỗi của mình đã bị xóa, và điều đó không nói lên gì về bất kỳ ai khác. Implicator.ai nêu rõ khoảng trống: không ai có thể biết liệu có ai đó đã tìm ra cơ sở dữ liệu trước O'Reilly hay không, hoặc có bao nhiêu bài đăng lan truyền trong tuần bùng nổ của nền tảng là đầu ra thực sự của tác nhân và bao nhiêu đến từ một khóa bị đánh cắp. Không có nguồn nào được đọc cho bài viết này báo cáo một trường hợp lạm dụng đã được xác nhận đối với bất kỳ thông tin xác thực bị lộ nào, và không nguồn nào báo cáo số lượng tài khoản thực sự bị chiếm đoạt. Cờ real_harm của kho lưu trữ là đúng vì dữ liệu cá nhân và thông tin xác thực của bên thứ ba đang hoạt động thực sự có thể được bất kỳ ai đọc, không phải vì một trường hợp lạm dụng cụ thể đã được ghi nhận.

Các con số thống kê về agent cũng không khớp nhau, và sự khác biệt này phản ánh mức tăng trưởng của nền tảng chứ không phải thực tế của vụ phơi lộ dữ liệu. Implicator.ai, viết ngày 1 tháng 2 dựa trên lời kể của người phát hiện, mô tả "hơn 32.000" agent đã đăng ký - trong một bài viết cũng nói rằng trang web đã vượt 37.000 trong tuần đầu tiên - và 1,49 triệu bản ghi bị phơi lộ. Wiz, khi rà soát ngày 2 tháng 2, đếm được 1,5 triệu agent và khoảng 4,75 triệu bản ghi. Phần tóm tắt của kho lưu trữ ghi nhận rằng nền tảng cuối cùng đã tích lũy 1,7 triệu agent đã đăng ký và gần 7 triệu bình luận; bài viết này không tự mình kiểm chứng độc lập cả hai tổng số cuối cùng đó. Con số duy nhất mà mọi tài liệu đều ủng hộ chính là hình dạng của sự việc: số agent nhiều hơn hẳn số người, và không có cơ chế nào có thể phân biệt được sự khác nhau đó.

Điều gì đã thay đổi và điều gì cài đặt chưa khắc phục

Điều đã thay đổi thì hẹp và đã được ghi nhận: các chính sách RLS trên những bảng nhạy cảm, một hạn chế ghi trên các bảng công khai, việc xóa bài đăng thử nghiệm của các nhà nghiên cứu, và theo Wiz, một nền tảng đã được vá đầy đủ trước 01:00 UTC ngày 1 tháng 2. Không có nguồn nào được đọc cho bài này mô tả việc Moltbook bổ sung giới hạn tốc độ, xác minh danh tính tác nhân hay kiểm toán nội dung được viết trong khoảng thời gian đó. Các khuyến nghị của Wiz nhắm vào công cụ chứ không phải nền tảng - các trợ lý AI tạo backend Supabase có thể bật RLS theo mặc định, và các nền tảng triển khai có thể quét thông tin xác thực bị lộ và cấu hình không an toàn.

Phần còn tồn tại lâu hơn cả SQL là tiền đề mà cơ sở dữ liệu đã phơi bày. Một mạng lưới mà điểm bán hàng là chỉ các tác nhân AI mới có thể đăng bài lại không có cách nào xác minh rằng một tác nhân là tác nhân, và lớp thông tin xác thực của nó là thứ duy nhất đứng giữa một người có script và mọi danh tính trên trang. Đó là lý do hồ sơ được xếp vào loại dấu mốc thay vì một lỗi cấu hình thông thường: sự phơi bày thì bình thường, còn thứ bị phơi bày - một lớp danh tính đã xác thực cho các tác nhân tự trị - thì không.