Backdoor trong Postmark đang tải xuống email

• Gần đây đã phát hiện hành vi độc hại trong mô-đun postmark-mcp
• Từ phiên bản 1.0.16, mã sao chép email sang máy chủ bên ngoài của nhà phát triển đã được thêm vào
• Một lỗ hổng mang tính cấu trúc khiến email nhạy cảm của hàng trăm tổ chức có thể bị rò rỉ đã bị phơi bày
• Do thiếu mô hình tin cậy cho máy chủ MCP, rủi ro tấn công chuỗi cung ứng đang gia tăng
• Tất cả người dùng MCP cần kiểm tra và gỡ bỏ ngay lập tức

---

Bản chất của máy chủ MCP và tổng quan vụ việc postmark-mcp

• Máy chủ MCP là công cụ giúp trợ lý AI tự động xử lý các tác vụ lặp lại như gửi email, chạy truy vấn cơ sở dữ liệu
• Các công cụ này hoạt động với đặc quyền rất cao, nhưng mã do nhà phát triển tạo ra gần như được cài đặt chỉ dựa trên niềm tin và thực tế hầu như không có cơ chế xác minh
• Gói phổ biến postmark-mcp lấy mã nguồn từ kho GitHub chính thức của Postmark, thêm một dòng BCC độc hại rồi phát hành lên npm với cùng tên
• Từ phiên bản 1.0.16, một dòng được thêm vào đoạn mã trông vẫn bình thường, khiến mọi email bị sao chép sang máy chủ cá nhân của nhà phát triển (giftshop.club)
• Nói cách khác, đây là sự cố làm lộ toàn bộ thông tin email, từ đặt lại mật khẩu, hóa đơn, ghi chú nội bộ đến tài liệu mật

Phát hiện hành vi bất thường và cấu trúc tấn công

• Risk Engine của Koi đã phát hiện dấu hiệu bất thường ở phiên bản 1.0.16
• Danh tính của nhà phát triển trên GitHub và các nền tảng khác trông bình thường, và 15 phiên bản đầu hoạt động không vấn đề gì để xây dựng lòng tin
• Ở bản 1.0.16, chỉ với một dòng mã, chức năng làm rò rỉ thông tin quan trọng ra bên ngoài đã được thêm vào
• Kẻ tấn công đồng thời dùng kỹ thuật mạo danh nhà phát triển hiện có (Classic impersonation) khi sao chép mã
• Một công cụ vốn được dùng ổn định, hợp pháp đã dần trở thành hạ tầng dựa trên niềm tin, rồi sau đó thực hiện hành vi độc hại

Tác động và cách thức rò rỉ email

• Với khoảng 1.500 lượt tải mỗi tuần, giả định khoảng 20% được sử dụng tích cực thì hàng trăm tổ chức nằm trong diện phơi nhiễm
• Ước tính có khoảng 3.000 đến 15.000 email mỗi ngày bị gửi tới giftshop.club
• Người dùng không tự xác minh từng hành vi của công cụ mà giao phần lớn việc thực thi tự động cho trợ lý AI
• Hoàn toàn không có mô hình bảo mật, sandbox hay quy trình xác minh riêng biệt
• Dù nhà phát triển đã xóa gói khỏi npm, việc đó không có tác dụng với các môi trường đã cài đặt nên dữ liệu vẫn tiếp tục bị rò rỉ

Phân tích các giai đoạn tấn công

• Giai đoạn 1: Phân phối công cụ bình thường

  • Từ 1.0.0 đến 1.0.15 hoạt động bình thường, tích lũy lòng tin

• Giai đoạn 2: Chèn mã độc

  • Ở 1.0.16, thêm một dòng BCC để sao chép email ra bên ngoài

• Giai đoạn 3: Thu thập thông tin

  • Mật khẩu, khóa API, dữ liệu tài chính/khách hàng... bị rò rỉ tới giftshop.club

• Không thể liên hệ được với nhà phát triển; dù gói đã bị xóa khỏi npm, thiệt hại trong các môi trường đã cài đặt vẫn đang tiếp diễn

Khiếm khuyết mang tính cấu trúc của hệ sinh thái MCP

• Không giống gói npm thông thường, máy chủ MCP là công cụ rủi ro cao mà trợ lý AI tự động gọi hàng trăm, hàng nghìn lần
• AI hay các giải pháp bảo mật hiện tại không phát hiện được mã độc hại, và hệ thống chỉ đang dựa vào niềm tin
• Toàn bộ hệ sinh thái MCP có cấu trúc rủi ro khi ủy toàn bộ quyền với tài sản nhạy cảm cho các nhà phát triển ẩn danh
• Cần có cơ chế kiểm soát bảo mật như nhận diện tấn công thông qua phát hiện thay đổi hành vi và gateway chuỗi cung ứng
• Koi đang thúc đẩy việc chặn và xác minh các gói độc hại tương tự bằng Risk Engine và gateway của mình

Biện pháp ứng phó và IOC

• Gói độc hại: postmark-mcp (npm)
• Phiên bản độc hại: 1.0.16 trở lên
• Email rò rỉ: phan@giftshop[.]club
• Tên miền: giftshop[.]club

Cách phát hiện

• Kiểm tra log email để tìm dấu vết gửi BCC tới giftshop.club
• Kiểm tra các tham số chuyển tiếp email ngoài dự kiến trong cấu hình máy chủ MCP
• Rà soát kỹ lịch sử cài đặt postmark-mcp phiên bản 1.0.16 trở lên

Ứng phó và khôi phục

• Gỡ bỏ postmark-mcp ngay lập tức
• Xoay vòng toàn bộ thông tin xác thực đã chia sẻ qua email trong thời gian bị xâm nhập
• Điều tra toàn bộ log email chứa thông tin nhạy cảm đã bị đánh cắp
• Nếu xác nhận có thiệt hại, báo cáo ngay cho cơ quan có thẩm quyền

Kết luận và khuyến nghị

• Với mọi máy chủ MCP, bắt buộc phải triển khai quy trình xác minh danh tính nhà phát triển, kiểm chứng mã và kiểm tra bảo mật
• Do đặc tính của MCP (hạ tầng hỗ trợ AI tự động), cần áp dụng tối thiểu mô hình không tin cậy và giám sát liên tục
• Người dùng postmark-mcp từ phiên bản 1.0.16 trở lên phải xóa ngay và thực hiện các biện pháp bảo mật
• Cần ghi nhớ rằng việc sử dụng dựa trên niềm tin đồng nghĩa với việc đối mặt với rủi ro tấn công chuỗi cung ứng
• Xem Paranoia (không tin tưởng/nghi ngờ) là nguyên tắc mặc định là chiến lược hợp lý khi sử dụng MCP

[GN⁺]

Ý kiến trên Hacker News

• Tôi tự hỏi vụ này khác gì với vụ backdoor trong tiện ích mở rộng Thunderbird. Trước đây tôi từng duy trì một tiện ích Thunderbird, rồi sau khi mất hứng thú, có một người đóng góp thật vài lần rồi đột nhiên liên tục gây sức ép đòi tiếp quản dự án. Cuối cùng tôi từ chối vì nghĩ rằng giao hàng chục nghìn khóa hộp thư cho một người xa lạ thì thật vô lý. Nghĩ lại thì ngay từ đầu việc mọi người tin tôi đến vậy cũng buồn cười, dù ít nhất tôi cũng là người tử tế
  • Tôi cũng nghĩ y hệt. Đây không phải vấn đề riêng của MCP mà là vấn đề áp dụng như nhau cho mọi phần mềm. Cuối cùng thì vẫn phải tin nhà phát triển và nhà cung cấp. Tôi không thể ngăn Microsoft sao chép email Outlook của mình, cũng không thể ngăn Google sao chép Gmail. Dù là mã nguồn mở và có thể nói rằng “nhiều con mắt” sẽ rà soát mã, điều đó có thể đúng với các dự án phổ biến, nhưng rủi ro vẫn còn. Rốt cuộc đa số chỉ đơn giản là tin lập trình viên. Đây là vấn đề cố hữu lâu đời như chính phần mềm vậy
  • Trong tình huống bạn nói, tôi cứ nhớ mãi một phát biểu của Zuckerberg về quyền riêng tư. Chúng ta cần nghĩ lại vì sao lại vô điều kiện giao dữ liệu và quyền riêng tư cho ai đó
  • Tôi từng nhiều lần cho người lạ say xỉn đi nhờ xe về nhà. Tôi luôn nói với họ rằng việc lên xe người lạ như vậy thực sự rất nguy hiểm. Nói thật thì họ chỉ may mắn tình cờ gặp đúng một người tốt bụng như tôi đang rảnh thôi. Chắc vì tôi hay đến quán nhỏ trong khu vào giờ muộn nên chuyện này xảy ra khá thường xuyên
• Tôi không đồng ý với giả định rằng một lượt tải trên NPM tương đương với một tổ chức duy nhất. Con số đó bị thổi phồng rất nhiều. Một lượt tải trên npm chỉ có nghĩa là ai đó (npm i) hoặc thứ gì đó (môi trường tự động hóa) đã cài nó. Trong thực tế, nếu CI được cấu hình sơ sài thì npm i có thể chạy mỗi lần thực thi, thậm chí mỗi bước. Vì vậy 1.500 lượt tải thực ra có thể chỉ đến từ 2 công ty. Một nơi có lập trình viên dùng cho PoC, nơi kia thì CI được cấu hình tệ. Ngay cả repo chính thức cũng chỉ có 1 watch, 0 fork, 2 star https://github.com/ActiveCampaign/postmark-mcp. MCP và các vấn đề chuỗi cung ứng tự thân là nghiêm trọng, nhưng trường hợp này gần như không có tác động thực tế
  • Theo cùng logic đó, số lượt tải các gói python phổ biến chẳng bao lâu nữa sẽ đạt mức tương đương toàn bộ nhân loại trên Trái Đất — từ trẻ em, người già cho đến những người còn không biết máy tính là gì — mỗi người tải một bản. https://pypistats.org/top
• Bài này tự thân thì ổn, nhưng tôi không hiểu vì sao lại phải đọc một bản dịch AI tóm tắt bằng ChatGPT. Thà cứ cho xem prompt gốc còn hơn. Cách này vừa chậm một cách không cần thiết vừa tạo cảm giác coi thường người dùng
  • May là không chỉ mình tôi thấy vậy. Tôi cực ghét văn phong có mùi AI nhúng tay, nhưng trong nhóm bạn tôi có người hoàn toàn không nhận ra hoặc không để tâm
• Dạo này thấy chuyện này xuất hiện nhiều, nhưng có vẻ chúng ta chưa nói đủ về việc đang giao quyền năng kiểu thần thánh cho các công cụ này. Toàn là công cụ do những người mình chẳng biết mặt làm ra mà cứ thế tin và giao phó. Trợ lý AI cũng vậy. Mọi người đều mặc nhiên tin 100%. Có những bài viết chỉ ra điều này, nhưng cảm giác như kiểu “bạn có biết nếu chĩa súng vào chân rồi bóp cò thì bạn sẽ bắn trúng chân mình không??”. Quá hiển nhiên, như thể họ đang cố nặn nội dung từ chuyện chẳng có gì mới. Tôi tự hỏi có thật là nhiều người không biết đến vậy, hay chỉ là cố viết cho có bài
  • Cách đây không lâu cũng có bài về việc một trợ lý code AI xóa sạch cơ sở dữ liệu production của công ty https://fortune.com/2025/07/23/ai-coding-tool-replit-wiped-database-called-it-a-catastrophic-failure/. Vấn đề có nhiều tầng: 1) nhà sáng lập đó đã hoàn toàn tin vào công cụ AI rồi tự lãnh hậu quả, tức là thực sự rất thiếu hiểu biết. 2) Hơn nữa còn mở cho môi trường phát triển truy cập trực tiếp vào DB production. Kiểu gì thì môi trường đó sớm muộn cũng gặp sự cố
  • Điều hiển nhiên với người dùng HN lại hoàn toàn không hiển nhiên với phần lớn thế giới. Những bài như vậy là nội dung cần thiết cho các đối tượng đó. Thực tế, thiết kế của MCP server và AI agent vốn dĩ không an toàn vì bảo mật thậm chí chưa từng được đem ra bàn từ đầu. Sau này có thay đổi hay không thì chưa biết, nhưng trước mắt cứ liên tục cảnh báo vẫn là cách tốt nhất
  • “Mọi người thật sự thiếu nhạy cảm đến vậy sao?” Ngay cả SQL injection cơ bản cũng vẫn gây thiệt hại khổng lồ mỗi năm và vẫn nằm trong nhóm đầu của OWASP. SQL injection rốt cuộc cũng là việc trao quyền kiểu thần thánh cho cơ sở dữ liệu mà không hiểu cơ chế vận hành. Quyền hành động của AI agent cũng có thể không hiển thị rõ với người dùng
  • Việc kiểu truy cập bừa bãi này đang diễn ra ở quy mô lớn qua MCP cần được bàn luận rộng rãi hơn. Ngay cả người vốn cẩn trọng cũng thường không nhận thức đầy đủ mức độ rủi ro
  • Ngày xưa việc email client chạy các email có nhúng script do bất kỳ ai trên internet gửi đến từng được gọi là “cuộc cách mạng tự động hóa”. Và ngày xưa người ta cũng từng nghĩ để trẻ em dùng internet thay vì TV sẽ lành mạnh hơn, nhưng ai mà chẳng biết chuyện đó kết thúc thế nào?
• Có đoạn nói rằng “việc cài công cụ do một ai đó ngẫu nhiên tạo ra đã trở thành chuyện bình thường”, nhưng thật ra từ thời Windows XP chúng ta đã cài đủ thứ như phần mềm rip CD hay Bonzi Buddy mà chẳng bận tâm gì. Tiện lợi lúc nào cũng được ưu tiên hơn bảo mật. Bài học lớn nhất rốt cuộc là: tại sao đến giờ “sandbox, sandbox, sandbox” vẫn chưa thành hiện thực? Trong vụ này, AI dường như đã đưa toàn bộ các nguyên tắc bảo mật cũ về trạng thái xuất xưởng
  • Với câu hỏi “mọi người dễ chọn tiện lợi hơn bảo mật, vậy tại sao sandbox vẫn chưa thành hiện thực”, câu trả lời là vì triển khai sandbox không hề dễ. Và chữ “dễ” ở đây có nghĩa là phải được OS cung cấp mặc định
• Người dùng còn có thể nhận email spam cài prompt injection gửi đến AI trong GMail mà không cần con người mở ra https://www.linkedin.com/posts/eito-miyamura-157305121_we-got-chatgpt-to-leak-your-private-email-activity-7372306174253256704-xoX1/
• Bài blog này rất khó đọc. Có cảm giác đã bị AI can thiệp. Quá nhiều câu chữ thừa và trang trí không cần thiết. Tiếc là chủ đề thì lại thú vị
• Trong các vấn đề bảo mật chuỗi cung ứng, gói npm gần như lúc nào cũng bị nhắc tên. Có lẽ vì npm được dùng rộng rãi nhất và từ góc nhìn kẻ tấn công thì động cơ cũng lớn nhất, nhưng dù vậy vẫn khó tránh cảm giác chua chát
  • OpenAI cũng phân phối Codex CLI qua npm. Dù nó được viết bằng Rust mà vẫn dùng gói npm. Cá nhân tôi thấy điều đó vô lý. Nhưng chắc các phương án thay thế còn bất tiện hơn
  • Vì lý do đó tôi không chạy stdio MCP server. Mọi MCP đều chạy trên host VM được cô lập bằng container Docker, đặt trên VLAN không tin cậy. Và tôi chỉ kết nối bằng SSE. Tất nhiên vẫn dễ dính prompt injection, nhưng tôi không kết nối nó với profile trình duyệt chính, email hay tài khoản đám mây. Tôi tách hoàn toàn khỏi dữ liệu nhạy cảm
  • Không nên để bình luận trên được upvote quá nhiều đến mức bị hiểu lầm như là hàm ý chính của bài viết này. Nếu tiếp nhận theo hướng đó thì sẽ bỏ lỡ bản chất vấn đề
• Cũng có thể lập trình viên thật ra không cố ý làm vậy. Tôi cũng từng phát hành bản release còn sót mã debug. Nếu chỉ là plain bcc thì rất có thể đúng là mã debug
  • Tôi cũng vào đây để nói điều này. Thật lòng mà nói thì khó tin là họ lại để nguyên email cá nhân lộ liễu như vậy nếu có chủ đích. Đến năm 2025 mà vẫn dùng Gmail cá nhân cho mục đích test thì cũng chẳng có gì đáng xấu hổ. Và đây không phải vấn đề riêng của MCP, gói nào cũng có thể xảy ra
  • Phản ứng kiểu xóa luôn package cũng thành thật mà nói là cách xử lý điển hình của một lập trình viên mới lần đầu gặp sự cố bảo mật. Nếu đó chỉ là lỗi debug vô tình chứ không có ác ý, thì giao tiếp mới là cốt lõi: gỡ bỏ phiên bản có vấn đề, phát hành bản vá, và trao đổi công khai trên blog/chỗ này trên HN/mạng xã hội để khôi phục niềm tin. Một dòng thời gian sự cố chính xác (và không phải bản tóm tắt do AI viết như OP) cũng sẽ giúp khôi phục niềm tin
• Vấn đề của MCP server thì nguy hiểm thật, nhưng tôi nghĩ kiểu tấn công này có thể xảy ra trong mọi tình huống dùng phụ thuộc bên ngoài như gói smtp
  • Nhưng với gói smtp thì người ta thường dùng các thư viện lâu đời đã được kiểm chứng và có độ tin cậy cao. Còn MCP thì mọi thứ đều mới, chưa có lịch sử tích lũy niềm tin nên đó mới là vấn đề. Nó giống một vùng hoang địa phần mềm, nơi bạn phải luôn mang sẵn khẩu ổ quay 6 viên để tự vệ vậy