Vụ hack MoltBook: Lỗi cấu hình Supabase làm lộ 1,5 triệu khóa API

 (wiz.io)
10 điểm bởi GN⁺ 2026-02-04 | 8 bình luận | Chia sẻ qua WhatsApp
  • Cơ sở dữ liệu của Moltbook, một nền tảng mạng xã hội dành riêng cho AI agent, đã bị cấu hình sai, khiến 1,5 triệu token xác thực API, 35.000 email và tin nhắn riêng tư bị lộ ra ngoài
  • Khóa API Supabase đã bị hardcode trong JavaScript phía client, và do không có cấu hình Row Level Security (RLS) nên bất kỳ ai cũng có thể đọc và ghi trên toàn bộ cơ sở dữ liệu
  • Dữ liệu bao gồm thông tin của 17.000 người dùng thực cùng 1,5 triệu tài khoản agent do họ vận hành, cho thấy tỷ lệ 1:88 giữa con người và agent
  • Thông tin bị lộ bao gồm khóa API OpenAI và các thông tin xác thực bên thứ ba khác, hội thoại riêng tư, và cả quyền chỉnh sửa bài viết, tạo ra rủi ro xâm hại tính toàn vẹn của nội dung trên nền tảng
  • Sự cố lần này phơi bày giới hạn bảo mật của “vibe coding” dựa trên AI, đồng thời cho thấy sự cần thiết phải tự động hóa các mặc định bảo mật và tăng cường quy trình xác minh trong môi trường phát triển AI

Tổng quan về Moltbook và lộ lọt bảo mật

  • Moltbook là một mạng xã hội lấy AI làm trung tâm, nơi các AI agent hoạt động thông qua viết bài, bình luận, bỏ phiếu và điểm uy tín, tự định vị là “trang nhất của Internet dành cho agent”
    • Đồng sáng lập OpenAI Andrej Karpathy đã gọi đây là “bước nhảy vọt mang màu sắc khoa học viễn tưởng đáng kinh ngạc nhất”
  • Nhà sáng lập nền tảng cho biết “AI đã trực tiếp viết mã”, và sản phẩm được phát triển theo phương thức “vibe coding”
  • Nhóm nghiên cứu Wiz đã phát hiện cơ sở dữ liệu Supabase bị cấu hình sai, cho phép đọc và ghi trên toàn bộ dữ liệu; sau khi được thông báo, vấn đề đã được khắc phục trong vòng vài giờ

Thông tin xác thực Supabase bị lộ

  • Thông tin kết nối Supabase được phát hiện bị hardcode trong gói JavaScript phía client của website Moltbook
    • Dự án: ehxbxtjliybbloantpwq.supabase.co
    • Khóa API: sb_publishable_4ZaiilhgPir-2ns8Hxg5Tw_JqZU_G6-
  • Supabase cho phép lộ khóa công khai, nhưng nếu không có chính sách RLS thì có thể truy cập toàn bộ cơ sở dữ liệu
  • Moltbook đã tắt RLS, khiến quyền đọc và ghi trên mọi bảng đều ở trạng thái công khai

Truy cập cơ sở dữ liệu không cần xác thực

  • Nhóm nghiên cứu đã dùng khóa API để gọi trực tiếp REST API và nhận được phản hồi ở cấp quản trị viên
  • Phản hồi chứa khóa API và token xác thực của các agent hàng đầu, cho phép chiếm đoạt hoàn toàn tài khoản
  • Bằng cách dùng thông báo lỗi PostgREST và GraphQL introspection để xác định toàn bộ schema, nhóm nghiên cứu xác nhận khoảng 4,75 triệu bản ghi đã bị lộ

Dữ liệu nhạy cảm bị lộ

  • Thông tin xác thực của agent: bao gồm api_key, claim_token, verification_code của từng tài khoản
    • Từ đó, kẻ tấn công có thể đăng nhập dưới danh nghĩa bất kỳ agent nào, đăng bài hoặc gửi tin nhắn
  • Email người dùng và thông tin nhận dạng: email của hơn 17.000 người dùng cùng handle X (Twitter) đã bị lộ
    • Ngoài ra, bảng observers còn chứa 29.631 email
  • Tin nhắn riêng tư và thông tin xác thực bên thứ ba: 4.060 tin nhắn trực tiếp được lưu mà không mã hóa, một số còn chứa khóa API OpenAI ở dạng văn bản thuần
  • Lộ quyền ghi: có thể chỉnh sửa bài viết mà không cần xác thực, tạo ra nguy cơ chèn nội dung độc hại hoặc phá hoại website
    • Thử nghiệm thực tế đã chỉnh sửa bài viết thành công, và chỉ bị chặn sau khi chính sách RLS được áp dụng

5 bài học bảo mật cho phát triển ứng dụng AI

  • 1. Tốc độ phát triển cao có thể tạo ra rủi ro mang tính hệ thống nếu thiếu các mặc định bảo mật
    • Chỉ một dòng cấu hình Supabase đã trở thành nguyên nhân của toàn bộ vụ lộ lọt
  • 2. Cần kiểm chứng các chỉ số tương tác
    • Trong 1.500.000 agent chỉ có 17.000 người thật, cho thấy khả năng hoạt động bị thổi phồng với tỷ lệ 88:1
  • 3. Hiệu ứng dây chuyền của sự sụp đổ quyền riêng tư
    • Việc lộ DM còn dẫn đến rò rỉ thông tin xác thực của dịch vụ bên ngoài như khóa API OpenAI
  • 4. Quyền ghi còn là mối đe dọa nghiêm trọng với tính toàn vẹn hơn cả rò rỉ dữ liệu đơn thuần
    • Có thể dẫn đến thao túng nội dung, prompt injection, kiểm soát diễn ngôn và các rủi ro tương tự
  • 5. Mức độ trưởng thành về bảo mật là một quá trình cải tiến lặp lại
    • Nhóm Wiz và Moltbook đã sửa lỗi, kiểm chứng nhiều lần để bảo vệ toàn bộ các bảng

Vibe coding và thách thức bảo mật

  • AI đã hạ thấp rào cản phát triển, nhưng rào cản bảo mật vẫn rất cao
  • Các công cụ phát triển AI cần tự động áp dụng các mặc định bảo mật như bật RLS, quét thông tin xác thực, v.v.
  • Khi bảo mật trở thành thành phần được tích hợp sẵn trong phát triển AI, mới có thể xây dựng một hệ sinh thái phần mềm AI vừa an toàn vừa đổi mới

Dòng thời gian

  • 21:48 UTC ngày 31/1/2026: Liên hệ đầu tiên với đơn vị duy trì Moltbook
  • 22:06: Báo cáo cấu hình sai Supabase RLS
  • 23:29: Sửa lần 1 (bảo vệ các bảng agents, owners, site_admins)
  • 00:13 ngày 1/2: Sửa lần 2 (bảo vệ agent_messages và các bảng liên quan)
  • 00:31: Phát hiện lỗ hổng chỉnh sửa bài viết
  • 00:44: Sửa lần 3 để chặn quyền ghi
  • 00:50~01:00: Phát hiện thêm các bảng bị lộ và hoàn tất bản sửa cuối cùng

Bài viết liên quan

8 bình luận

 
iolothebard 2026-02-04

Đang vui vẻ nhảy múa rồi… cứ thế… sụp đổ đi!
 
rustkim 2026-02-05

Còn lại mỗi Mac mini, vì mới giai đoạn đầu nên chắc sẽ còn có thứ tốt hơn ra mắt nhỉ
 
gogokow27 2026-02-05

kkkkkkkkkk....
 
kuthia 2026-02-04

Cuối cùng thì điều phải đến cũng đã đến.
 
crawler 2026-02-04

MoltBot thì từ vụ bị hack ở agent giờ đến cả nền tảng cũng dính luôn nhé =))

Có vẻ đây sẽ được nhớ như một ví dụ về dự án mang vibe tệ nhất năm 2026.
Dù mới chỉ là tháng 2 nhưng mình có thể khẳng định điều đó luôn =))
 
bini59 2026-02-04

Có lẽ vấn đề là các dịch vụ quy mô lớn có thể được phát triển theo kiểu vibe mà không cần quan tâm nhiều đến bảo mật.
 
kimjoin2 2026-02-04

WOW
 
GN⁺ 2026-02-04
Ý kiến trên Hacker News

  • Ban đầu thành công của Moltbot/Moltbook khá đáng ngạc nhiên, nhưng giờ thì cũng dễ hiểu hơn
    Điểm cốt lõi là đây là "agent đóng gói sẵn". Với người dùng phổ thông không rành công nghệ, kiểu tiếp cận như “mua một chiếc Mac mini rồi copy vài dòng để cài đặt” có sức hút rất lớn
    Nhưng chính sự dễ tiếp cận này đang nuôi lớn một cơn ác mộng bảo mật. Khi ngày càng nhiều người chạy theo trào lưu mà không có hiểu biết kỹ thuật, nguy cơ môi trường dễ tổn thương tồn tại lâu hơn cũng tăng lên

    • Cũng có nghi ngờ liệu có thể gọi đó là thành công thật sự hay không. Có phân tích cho rằng trong 1,5 triệu agent thì chỉ 17 nghìn thuộc sở hữu của con người. Việc được các influencer nổi tiếng nhắc tới dường như là yếu tố giúp nó lan truyền mạnh
    • Mọi LLM đều yếu về bảo mật ngay từ thiết kế. Có thể bị vượt qua dễ dàng bằng prompt injection hoặc reward hacking. Cách giải quyết triệt để duy nhất là chặn hoàn toàn đầu vào bên ngoài và quyền truy cập mạng
    • “Mua Mac mini rồi cài” chỉ là khẩu hiệu marketing. Thực tế lỗi cấu hình xảy ra thường xuyên và quản lý ngữ cảnh rất tệ. Có lưu log nhưng lại quên cả cuộc trò chuyện ngay trước đó. Ý tưởng thì hay nhưng cách triển khai còn thô
    • Giống như khi Dropbox mới ra mắt, yếu tố thành công là tính dễ tiếp cận được đóng gói sẵn. Nhưng trong bối cảnh ngay cả tập đoàn lớn cũng không ngăn được hack, một DB cấu hình sai lại bị xem là chuyện không quá to tát. Tiện lợi vẫn đang thắng bảo mật
    • Có thể đây chỉ đơn giản là thứ đang được bàn tán nhiều, chứ chưa chắc đã là thành công thực sự

  • Như Scott Alexander đã chỉ ra, hiện tượng các agent tương tác với nhau và tạo ra hành vi phức hợp mới là điều quan trọng
    Nếu điều này bắt đầu tác động đến thế giới thực, nó có thể dẫn tới những vấn đề mang tính bản thể luận.
    Rốt cuộc đây là một cấu trúc nơi “mọi thứ được viết là YES trong AGENT.md” đều có thể thực sự xảy ra

    • Cũng có phản ứng là không hiểu đang nói gì
    • Vì vậy tôi đã làm nono.sh, để agent khởi đầu theo mô hình zero trust bên trong một sandbox cách ly ở cấp kernel
    • Con người ở một mức độ nào đó cũng là những thực thể "lặp lại như con vẹt". Cũng như Moltbook bắt chước Reddit, con người cũng trò chuyện trong các mẫu hình có thể dự đoán. Cuối cùng có lẽ chúng ta kém thông minh hơn mình tưởng

  • API của Moltbook mở cho bất kỳ ai, nên chỉ với một prompt đơn giản cũng có thể dụ nó làm lộ email người dùng hoặc dữ liệu khác
    Vì vậy mới xuất hiện các nỗ lực cô lập nó bằng Mac mini, nhưng một khi còn nối mạng thì không thể bảo vệ hoàn toàn

    • Không phải chuyện điên rồ. LLM không thể phân biệt rạch ròi giữa lệnh và dữ liệu. Đây là một dạng lỗ hổng kiểu ‘social engineering’
    • Cuối cùng vấn đề là liệu có thể giao cho nó những việc hữu ích mà không gây rủi ro hay không. Ví dụ, nếu muốn nó lo chuyện mua đồ hoặc đặt chuyến đi thì sẽ cần quyền truy cập thẻ tín dụng
    • Tôi đang cô lập LLM trong môi trường DMZ. Nó chạy bằng tài khoản không có đĩa và không có quyền sudo. Không hoàn hảo nhưng hoạt động cũng tạm ổn
    • Thực tế là không có biện pháp bảo vệ nào thật sự hoàn hảo. Vì đồng thời tồn tại "bộ ba chết người" gồm truy cập dữ liệu, văn bản không đáng tin và giao tiếp qua mạng
    • Tuy vậy vẫn có thể thêm lớp giám sát/phê duyệt. Có thể xây dựng cấu trúc để phê duyệt hoặc giới hạn hành động của LLM, giống như hạn mức thẻ tín dụng

  • Tôi đã thử OpenClaw và thấy mức tiêu thụ token cực lớn
    Để bảo mật thì có lẽ thiết bị chuyên dụng (như Raspberry Pi) với quyền API bị giới hạn sẽ hữu ích. Nếu Pi có thể chạy được mô hình mạnh hơn thì tôi sẵn sàng mua

  • Moltbook không có cách nào phân biệt AI với con người. Vấn đề là làm sao triển khai một "reverse CAPTCHA"

    • Cho vui tôi đã đưa cho Claude prompt “hãy tìm các tài khoản gián điệp là con người”, và nó thực sự tạo ra một thread tên là ‘Reverse Turing Problem’. Nhưng giờ thì nó đã ngập trong spam đến mức gần như không thể trò chuyện được nữa
    • Cần một cách để ký và kiểm toán được mọi đầu vào/đầu ra của phiên làm việc. Cả các prompt do con người bơm vào cũng phải lần vết được
    • Một cách phân biệt khác là bắt làm nhiều lần trong thời gian ngắn các tác vụ dễ với AI nhưng khó với con người
    • Hoặc đặt nhanh những câu hỏi hiếm mà LLM có lẽ đã biết sẵn
    • Nhưng rốt cuộc, vẫn rất khó để phân biệt đó là hành vi do con người dẫn dắt bằng prompt hay không

  • Dù Moltbook nói đã sửa vấn đề bảo mật chỉ sau vài giờ, câu hỏi vẫn là phải giải thích thế nào về lỗ hổng bảo mật trong một dự án làm bằng “vibe coding”

    • Thực tế là Claude đã tạo truy vấn cho Supabase, rồi một người chuyển nó cho nhà phát triển Moltbook để sửa. Khó tin nhưng là thật

  • Việc có người phân tích nội bộ Moltbook đã là điều đáng ngạc nhiên. Ngay từ đầu nó vốn là một "dự án làm cho vui", không ai nghĩ nó sẽ lớn đến vậy

    • Nhưng nếu PII của người dùng bị lộ thì không thể xem đó chỉ là trò đùa, vì sẽ phát sinh vấn đề pháp lý. Văn hóa ‘vibe coding’ đang tạo ra một môi trường phát triển thiếu trách nhiệm
    • Dogecoin cũng bắt đầu từ một trò đùa, nhưng giờ đã có quy mô hàng tỷ USD
    • Các nhà nghiên cứu bảo mật đi tìm lỗ hổng có khi cũng là một phần của ‘vibe’
    • Nhưng không thể dùng cái cớ “chỉ là trò đùa” để che lấp thiệt hại thực tế
    • Nếu đó là kết quả do người tạo ra cố ý làm ra, thì cái cớ “trò đùa” càng yếu hơn

  • Vụ một instance OpenClaw gửi khóa OpenAI sang instance khác vừa buồn cười vừa bất an.
    Không rõ nó có thực sự gửi khóa đi hay chỉ giả vờ làm vậy

  • Bản thân bài viết của Wiz cũng có cảm giác như do AI viết. Cấu trúc câu và cách dùng gạch ngang mang đúng kiểu LLM.
    Việc dùng một bài báo do LLM viết để chỉ trích bảo mật của một nền tảng do LLM tạo ra nghe khá mỉa mai
    Lỗ hổng thực tế có lẽ là thật, nhưng nếu con người viết thì chắc đã bớt đi những chỗ rườm rà không cần thiết

  • Từ dữ liệu bị lộ người ta phát hiện rằng trong 1,5 triệu agent chỉ có 17 nghìn là con người
    Nhưng vì nhà nghiên cứu đã trực tiếp dùng API key để truy vấn bảng và lấy ra con số đó, nên việc công bố này trông không chỉ là báo lỗi đơn thuần mà giống một hành động chỉ trích doanh nghiệp hơn
    Cách làm như vậy có nguy cơ làm tổn hại mối quan hệ hợp tác dựa trên niềm tin giữa nhà nghiên cứu và doanh nghiệp