Backdoor Postmark sedang mengunduh email

• Baru-baru ini ditemukan aktivitas berbahaya pada modul postmark-mcp
• Mulai versi 1.0.16, ditambahkan kode yang menyalin email ke server eksternal milik pengembang
• Terungkap kelemahan struktural yang menyebabkan email sensitif dari ratusan organisasi berpotensi bocor
• Karena tidak adanya model kepercayaan untuk server MCP, risiko serangan rantai pasok makin besar
• Semua pengguna MCP perlu segera melakukan pemeriksaan dan penghapusan

---

Hakikat server MCP dan ringkasan insiden postmark-mcp

• Server MCP adalah alat yang memungkinkan asisten AI menangani otomatis tugas berulang seperti mengirim email dan menjalankan kueri database
• Alat-alat ini berjalan dengan hak akses yang sangat tinggi, dan kode buatan pengembang dipasang nyaris hanya berdasarkan kepercayaan, tanpa sistem verifikasi yang memadai
• Paket populer postmark-mcp mengambil source code dari repositori GitHub resmi Postmark, lalu menambahkan satu baris BCC berbahaya dan menerbitkannya di npm dengan nama yang sama
• Mulai versi 1.0.16, satu baris ditambahkan ke kode yang tampak normal, sehingga semua email disalin ke server pribadi pengembang (giftshop.club)
• Artinya, ini adalah insiden yang mengekspos seluruh informasi email, termasuk reset kata sandi, invoice, memo internal, hingga dokumen rahasia

Deteksi perilaku anomali dan struktur serangan

• Risk Engine milik Koi mendeteksi tanda-tanda anomali pada versi 1.0.16
• Identitas pengembang tampak normal di GitHub dan tempat lain, dan 15 versi awal berfungsi tanpa masalah sehingga membangun kepercayaan
• Pada 1.0.16, hanya dengan satu baris kode, ditambahkan fungsi untuk membocorkan informasi penting ke luar
• Penyerang memakai teknik peniruan pengembang yang sudah ada (Classic impersonation) sambil menyalin kode
• Alat yang sebelumnya dipakai secara normal pada suatu titik menjadi infrastruktur berbasis kepercayaan, lalu mulai menjalankan perilaku berbahaya

Dampak dan cara kebocoran email

• Dengan sekitar 1.500 unduhan per minggu, dan jika diasumsikan sekitar 20% benar-benar aktif digunakan, maka ratusan organisasi berpotensi terdampak
• Diperkirakan 3.000–15.000 email per hari dikirim ke giftshop.club
• Pengguna tidak memverifikasi perilaku alat satu per satu, dan sebagian besar eksekusi otomatis diserahkan ke asisten AI
• Tidak ada model keamanan, sandbox, maupun proses verifikasi sama sekali
• Pengembang memang menghapus paket dari npm, tetapi pada lingkungan pengguna yang sudah memasangnya, penghapusan itu tidak berdampak sehingga data terus bocor

Analisis tahapan serangan

• Tahap 1: Distribusi alat normal

  • Dari 1.0.0 hingga 1.0.15, alat berfungsi tanpa masalah dan membangun kepercayaan

• Tahap 2: Penyisipan kode berbahaya

  • Pada 1.0.16, satu baris BCC ditambahkan untuk menyalin email ke pihak luar

• Tahap 3: Pengumpulan informasi

  • Kata sandi, API key, serta data keuangan/pelanggan bocor ke giftshop.club

• Pengembang tidak dapat dihubungi, dan meski paket telah dihapus dari npm, dampak pada lingkungan yang sudah terpasang masih terus berlangsung

Cacat struktural ekosistem MCP

• Tidak seperti paket npm biasa, server MCP adalah alat berisiko tinggi yang dipanggil otomatis ratusan hingga ribuan kali oleh asisten AI
• AI maupun solusi keamanan yang ada tidak mampu mendeteksi apakah kode itu berbahaya, dan semuanya bergantung pada kepercayaan
• Seluruh ekosistem MCP memiliki struktur berbahaya yang mendelegasikan seluruh kewenangan atas aset berisiko kepada pengembang anonim
• Diperlukan kontrol keamanan seperti identifikasi serangan melalui deteksi perubahan perilaku dan supply chain gateway
• Koi mendorong pemblokiran masuknya paket berbahaya serupa dan verifikasi melalui Risk Engine serta gateway-nya

Langkah penanganan dan IOC

• Paket berbahaya: postmark-mcp (npm)
• Versi berbahaya: 1.0.16 ke atas
• Email eksfiltrasi: phan@giftshop[.]club
• Domain: giftshop[.]club

Cara mendeteksi

• Periksa jejak pengiriman BCC ke giftshop.club di log email
• Tinjau parameter penerusan email yang tak terduga di pengaturan server MCP
• Audit secara teliti riwayat pemasangan postmark-mcp versi 1.0.16 ke atas

Tindakan dan pemulihan

• Segera hapus postmark-mcp
• Rotasi semua kredensial yang dibagikan melalui email selama periode kompromi
• Selidiki seluruh log email terkait informasi sensitif yang mungkin dicuri
• Jika dampak insiden terkonfirmasi, segera laporkan ke otoritas terkait

Kesimpulan dan rekomendasi

• Untuk semua server MCP, prosedur verifikasi identitas pengembang, validasi kode, dan pemeriksaan keamanan wajib diterapkan
• Karena sifat MCP sebagai infrastruktur pembantu AI untuk otomasi, perlu diterapkan setidaknya model ketidakpercayaan minimum dan pemantauan berkelanjutan
• Pengguna postmark-mcp versi 1.0.16 ke atas wajib segera menghapusnya dan melakukan langkah pengamanan
• Perlu diingat bahwa penggunaan berbasis kepercayaan berarti langsung berhadapan dengan risiko serangan rantai pasok
• Menjadikan Paranoia (ketidakpercayaan/kecurigaan) sebagai prinsip dasar adalah strategi yang masuk akal dalam pemanfaatan MCP

[GN⁺]

Komentar Hacker News

• Saya penasaran apa bedanya dengan backdoor pada ekstensi Thunderbird dan insiden ini. Dulu saya pernah memelihara ekstensi Thunderbird, lalu setelah saya kehilangan minat, ada seseorang yang beberapa kali memberi kontribusi sungguhan lalu tiba-tiba sangat memaksa untuk terus mengambil alih proyek. Pada akhirnya saya menolak karena menurut saya tidak masuk akal menyerahkan puluhan ribu kunci mailbox kepada orang yang tidak saya kenal. Memang lucu juga orang-orang dulu bisa begitu memercayai saya, tapi setidaknya saya orang baik
  • Saya juga berpikir sama. Ini bukan karena MCP, melainkan masalah yang berlaku sama pada semua perangkat lunak. Pada akhirnya kita memang tidak punya pilihan selain memercayai pengembang dan penyedianya. Saya tidak bisa mencegah Microsoft menyalin email Outlook saya, dan tidak bisa mencegah Google menyalin Gmail saya. Walaupun open source memungkinkan kode ditinjau oleh 'banyak mata', itu mungkin berlaku untuk proyek populer, tapi risikonya tetap ada. Pada akhirnya kebanyakan orang hanya percaya begitu saja pada pengembang. Ini masalah menahun yang sudah setua perangkat lunak itu sendiri
  • Dalam situasi yang kamu ceritakan, saya terus teringat ucapan Zuckerberg soal privasi. Kita memang perlu memikirkan kenapa kita begitu saja menitipkan data dan privasi kita kepada orang lain
  • Saya sering mengantar pulang orang mabuk yang tidak saya kenal dengan mobil. Saya selalu bilang bahwa menumpang kendaraan orang asing itu benar-benar berbahaya. Sejujurnya mereka cuma beruntung kebetulan bertemu orang baik yang punya waktu luang seperti saya. Mungkin ini sering terjadi karena saya tipe yang datang terlambat ke bar kecil di lingkungan saya
• Saya tidak setuju dengan asumsi bahwa satu download NPM berarti satu organisasi unik. Angka itu sangat dibesar-besarkan. Satu download di npm hanya berarti seseorang (npm i) atau sesuatu (lingkungan otomatis) memasangnya. Dalam praktik kerja, kalau CI disusun asal-asalan, npm i bisa berjalan setiap eksekusi, atau setidaknya setiap tahap. Jadi 1.500 download sebenarnya bisa saja hanya berasal dari 2 perusahaan. Satu tempat dipakai pengembang untuk PoC, dan satu lagi punya konfigurasi CI yang berantakan. Bahkan kalau lihat repo resminya pun cuma ada 1 watch, 0 fork, dan 2 star https://github.com/ActiveCampaign/postmark-mcp. MCP dan masalah supply chain memang serius, tapi untuk kasus ini dampak nyatanya nyaris nol
  • Dengan logika yang sama, jumlah download paket Python populer sebentar lagi akan setara dengan seluruh umat manusia di bumi—anak-anak, lansia, bahkan orang yang tidak tahu apa itu komputer—masing-masing satu download. https://pypistats.org/top
• Artikelnya sendiri bagus, tapi saya tidak paham kenapa kita harus repot membaca versi terjemahan AI yang diringkas dengan ChatGPT. Lebih baik tampilkan saja prompt aslinya. Dalam bentuk sekarang, rasanya cuma memperlambat tanpa perlu dan terkesan meremehkan pengguna
  • Syukurlah ada juga yang merasa begitu. Saya sangat tidak suka gaya bahasa yang terasa disentuh AI, tapi ada teman-teman saya yang sama sekali tidak menyadarinya atau tidak peduli
• Belakangan ini saya sering melihat hal seperti ini, tapi rasanya kita belum cukup membicarakan soal menyerahkan kekuasaan setingkat dewa kepada alat-alat seperti ini. Kita bahkan tidak tahu wajah pembuatnya, tapi tetap saja percaya penuh. Hal yang sama berlaku untuk asisten AI. Semuanya dipercaya 100%. Memang ada artikel yang menyoroti ini, tapi rasanya seperti, "Tahukah Anda bahwa jika Anda mengarahkan moncong pistol ke kaki sendiri lalu menarik pelatuk, kaki Anda akan tertembak??" Terlalu jelas, dan artikelnya terasa seperti dibuat dari hal yang sebenarnya tidak banyak isinya. Saya jadi penasaran, apakah memang ada banyak orang yang benar-benar tidak tahu ini, atau cuma dipaksakan demi menulis artikel
  • Beberapa waktu lalu juga ada artikel tentang asisten kode AI yang menghapus database produksi perusahaan https://fortune.com/2025/07/23/ai-coding-tool-replit-wiped-database-called-it-a-catastrophic-failure/. Ada beberapa lapisan di sini: 1) pendirinya memercayai alat AI sepenuhnya lalu kena batunya sendiri. Jadi memang benar-benar tidak paham. 2) Selain itu, database produksi dibiarkan bisa diakses langsung dari lingkungan pengembangan. Dalam kondisi seperti itu, cepat atau lambat insiden memang pasti terjadi
  • Hal yang terasa jelas bagi pengguna HN sama sekali tidak jelas bagi sebagian besar orang di dunia. Artikel seperti ini memang dibutuhkan untuk mereka. Faktanya, desain server MCP dan agen AI sejak awal bahkan tidak membahas keamanan, jadi secara mendasar memang tidak aman. Apakah nanti akan berubah atau tidak, saya tidak tahu, tapi sampai saat itu, terus mengingatkan orang adalah yang terbaik
  • “Apakah orang memang sebegitu tidak peka?” Bahkan SQL injection dasar pun masih terus menimbulkan kerugian besar setiap tahun, dan masih tetap masuk daftar teratas OWASP. SQL injection pada akhirnya juga memberi database kekuasaan setingkat dewa, dan itu terjadi karena orang tidak memahami cara kerjanya. Hak tindakan agen AI juga bisa tidak terlihat jelas bagi pengguna
  • Fakta bahwa akses serampangan seperti ini sedang terjadi dalam skala besar lewat MCP perlu dibahas lebih luas. Bahkan orang yang biasanya berhati-hati pun sering kali tidak benar-benar menyadari bahayanya
  • Dulu, klien email yang menjalankan email berisi skrip dari siapa pun di internet disebut “revolusi otomatisasi”. Dulu juga orang mengira menyuruh anak-anak memakai internet alih-alih menonton TV itu lebih sehat; kita semua tahu bagaimana akhirnya, bukan?
• Ada bagian soal “situasi ketika memasang alat buatan orang acak sudah dianggap normal”, padahal sebenarnya sejak era Windows XP kita memang sudah terbiasa memasang apa saja tanpa banyak pikir panjang, mulai dari software CD ripping sampai Bonzi Buddy. Kenyamanan memang selalu mengalahkan keamanan. Pada akhirnya pelajaran terpenting adalah: kenapa sampai sekarang 'sandbox, sandbox, sandbox' masih belum jadi kenyataan? Dalam kejadian ini, AI terasa seperti mengembalikan semua prinsip keamanan yang sudah ada ke setelan pabrik
  • Untuk pertanyaan “orang lebih mudah memilih kenyamanan daripada keamanan; kenapa sandbox masih belum jadi kenyataan”, jawabannya adalah karena membuat sandbox itu tidak mudah. Dan yang dimaksud ‘mudah’ di sini adalah tersedia secara bawaan dari OS
• Pengguna juga bisa dikirimi email spam yang berisi prompt injection ke AI tanpa perlu dibuka manusia di GMail https://www.linkedin.com/posts/eito-miyamura-157305121_we-got-chatgpt-to-leak-your-private-email-activity-7372306174253256704-xoX1/
• Postingan blog ini sangat sulit dibaca. Terasa seperti disentuh AI. Terlalu banyak kalimat yang tidak perlu dan hiasan berlebihan. Sayangnya topiknya sendiri menarik
• Dalam isu keamanan supply chain, paket npm hampir selalu disebut. Memang masuk akal karena npm paling luas dipakai dan motivasi penyerang juga besar, tapi tetap saja rasanya pahit
  • OpenAI juga mendistribusikan Codex CLI lewat npm. Padahal dibuat dengan Rust, tetapi tetap memakai paket npm. Secara pribadi saya rasa itu tidak masuk akal. Tapi mungkin opsi alternatifnya memang lebih merepotkan
  • Karena alasan inilah saya tidak menjalankan server MCP stdio. Semua MCP saya diisolasi dalam container Docker di atas host VM yang ditempatkan pada VLAN tak tepercaya. Dan saya hanya terhubung lewat SSE. Tentu saja masih rentan terhadap prompt injection, tetapi saya tidak menghubungkannya ke profil browser utama, email, atau akun cloud saya. Benar-benar dipisahkan dari informasi sensitif
  • Tidak ideal kalau komentar di atas mendapat terlalu banyak upvote sampai disalahartikan sebagai poin utama artikel ini. Kalau ditangkap seperti itu, inti persoalannya jadi tidak terlihat
• Mungkin saja pengembangnya sebenarnya tidak sengaja melakukan itu. Saya sendiri pernah beberapa kali merilis sesuatu dengan kode debugging masih tertinggal. Kalau cuma plain bcc, itu bisa saja benar-benar kode debugging
  • Saya juga datang untuk mengatakan hal yang sama. Jujur saja, rasanya dia tidak mungkin sengaja meninggalkan email pribadinya begitu terang-terangan. Di tahun 2025 pun memakai Gmail pribadi untuk pengujian tidak terasa memalukan. Dan ini bukan masalah khusus MCP; ini bisa terjadi pada paket apa pun
  • Reaksi menghapus paket juga, sejujurnya, adalah respons khas pengembang pemula yang baru pertama kali menghadapi masalah keamanan. Kalau ini sekadar kesalahan debugging tanpa niat jahat, maka yang penting adalah komunikasi: hapus versi berbahaya, rilis patch, dan berkomunikasi lewat kanal publik seperti blog, HN, media sosial, dan sebagainya untuk memulihkan kepercayaan. Linimasa insiden yang akurat (dan bukan ringkasan buatan AI seperti yang ditulis OP) juga membantu memulihkan kepercayaan
• Masalah server MCP memang berbahaya, tetapi menurut saya tipe serangan seperti ini juga bisa terjadi dalam situasi apa pun yang memakai dependensi eksternal seperti paket smtp
  • Tapi paket smtp biasanya adalah library lama yang sudah terbukti dan dipercaya. MCP bermasalah karena semuanya serba baru dan belum punya sejarah kepercayaan yang terbentuk. Semacam tanah liar perangkat lunak, tempat Anda harus berjalan sambil menenteng revolver (6-shooter) yang sudah terisi penuh