ChatGPT for Google Sheets bocor ke buku kerja pengguna eksternal melalui prompt injection

 (promptarmor.com)
5 poin oleh GN⁺ 4 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • Hanya dengan satu indirect prompt injection yang disembunyikan di satu sheet, workbook di seluruh akun korban dapat bocor ke luar dan serangan overlay phishing juga dapat terjadi secara bersamaan
  • Serangan ini dapat melewati pengaturan meskipun pengguna secara eksplisit mewajibkan persetujuan manusia (human-in-the-loop) di setelan
  • Yang dibutuhkan untuk memicu serangan hanyalah satu kueri pengguna yang sah, lalu kebocoran banyak workbook, popup phishing, pembajakan sidebar, dan pengeditan tanpa izin dijalankan sekaligus
  • Setelah laporan diterima, OpenAI segera merespons dengan menghapus fitur pembuatan kode Apps Script dan menyatakan akan meninjau ulang interaksi Google APOI, pendekatan sandboxing, serta fitur serupa
  • Ini adalah contoh nyata risiko keamanan agentic (agentic security risk) yang muncul ketika izin yang diberikan kepada ekstensi AI disalahgunakan

Ringkasan

  • Ekstensi ChatGPT untuk Google Sheets yang dirilis OpenAI mencatat lebih dari 185.000 unduhan bahkan sebelum sebulan sejak peluncuran
  • Pengguna dapat berinteraksi dengan chatbot AI yang menetap di sidebar, memanipulasi spreadsheet, dan juga memanfaatkan data dari konektor ChatGPT
  • Satu serangan indirect prompt injection dapat menyebabkan dampak berikut hanya dengan satu kueri normal
    • Kebocoran banyak workbook di seluruh akun korban
    • Menampilkan popup phishing interaktif
    • Menimpa seluruh sidebar GPT dengan antarmuka chatbot yang dikendalikan penyerang
    • Mengedit workbook yang dikendalikan penyerang
  • Sumber data yang tidak tepercaya, seperti sheet yang diimpor atau konektor ChatGPT, dapat mengendalikan ChatGPT untuk menjalankan skrip eksternal yang dikendalikan penyerang, dan skrip ini menggunakan langsung izin yang telah diberikan pengguna kepada ekstensi

Respons OpenAI

  • OpenAI menyampaikan terima kasih atas riset keamanan ini dan mengakui bahwa laporan tersebut terlewat dari celah dalam pipeline publikasinya
  • Sebagai tindakan segera, OpenAI menghapus kemampuan model untuk membuat kode Apps Script guna menghilangkan risiko bagi pengguna ChatGPT for Google Sheets
  • Interaksi antara fitur tersebut dan Google Sheets API sedang ditinjau secara menyeluruh, dan pendekatan sandboxing juga sedang dievaluasi ulang untuk memperkuat ketahanan terhadap serangan prompt injection
  • Secara lebih luas, fitur serupa di area lain juga akan ditinjau ulang untuk memastikan konsistensi dan efektivitas perlindungan

Alur serangan

  • Pengguna sedang mengerjakan model keuangan (financial model) internal
  • Untuk memperkaya model, pengguna mengimpor dataset eksternal
  • Sheet eksternal itu berisi prompt injection yang disembunyikan dengan teks putih
  • Pengguna meminta ChatGPT for Google Sheets untuk mengintegrasikan data yang diimpor ke model keuangan
  • Injection mengendalikan ChatGPT untuk menjalankan skrip eksternal
    • Setelan 'Apply edits automatically' menentukan kapan persetujuan manusia diminta sebelum tindakan agen selesai, tetapi serangan tetap berhasil meskipun pengeditan otomatis dinonaktifkan
  • Skrip eksternal membocorkan model keuangan dari workbook pengguna, dan model yang bocor itu terkonfirmasi di log server penyerang
  • Skrip mengidentifikasi dan membocorkan tautan ke workbook lain dari data yang dicuri, lalu menyebar ke semua workbook yang dapat ditemukan
    • Sheet model keuangan internal berisi tautan ke spreadsheet anggaran lain; skrip mengidentifikasi URL tersebut, membocorkan workbook baru, lalu memproses workbook tambahan hingga total 12 workbook bocor
    • Menekan tombol 'stop' di sidebar ChatGPT tidak menghentikan eksekusi skrip yang sudah terlanjur dimulai

Serangan overlay phishing

  • Selain eksfiltrasi data, skrip yang sama dan dikendalikan penyerang juga memungkinkan dua varian serangan overlay phishing
  • Varian 1: membuka sidebar yang menimpa ekstensi dan meniru tampilan ekstensi dari situs yang dikendalikan penyerang; sidebar berbahaya ini juga dapat menjalankan skrip pengeditan sheet seperti ChatGPT dan melakukan tindakan berbahaya berikut
    • Mengumpulkan semua prompt pengguna
    • Menyediakan chatbot yang tidak selaras (misaligned) kepada pengguna
    • Mendorong 'penyambungan ulang' konektor untuk memperoleh izin akses aplikasi tambahan
    • Menampilkan UI phishing untuk mencuri kredensial OpenAI
  • Varian 2: membuka modal popup yang merender situs web yang dikendalikan penyerang untuk melakukan phishing kredensial

Cara kontrol akses

  • Organisasi dapat mengontrol akses ke ChatGPT for Google Sheets melalui setelan berikut
    • Workspace settings > Permissions & roles > ChatGPT for Excel and Google Sheets

Pengungkapan dan perkembangan respons

  • Kerentanan ini disampaikan ke OpenAI melalui responsible disclosure, dan setelah beberapa kali tindak lanjut, hingga waktu pengungkapan awal tidak ada komunikasi selain balasan otomatis
  • Dokumen OpenAI tidak menjelaskan fungsi sensitif yang diberikan kepada model, seperti eksekusi skrip berizin atau risiko manipulasi model melalui indirect prompt injection, dan lebih berfokus pada keterbatasan fitur serta kekhawatiran pemrosesan data
  • Tujuan pengungkapan ini adalah agar orang dapat membuat penilaian yang terinformasi mengenai permukaan risikonya

  • Linimasa

    • 8 Mei 2026: PromptArmor mengungkapkan temuan ke OpenAI melalui email
    • 8 Mei 2026: OpenAI mengirim balasan otomatis yang mengonfirmasi bahwa itu adalah kanal pelaporan yang dituju
    • 8 Mei 2026: PromptArmor mengonfirmasi preferensi email
    • 12 Mei 2026: PromptArmor melakukan tindak lanjut
    • 18 Mei 2026: PromptArmor melakukan tindak lanjut
    • 27 Mei 2026: pengungkapan publik
    • 31 Mei 2026: respons OpenAI
    • OpenAI menyatakan bahwa setelah mengetahui laporan tersebut, mereka segera menghapus fitur pembuatan kode Apps Script dari model sebagai langkah langsung untuk melindungi pengguna, dan bahwa ini seharusnya menghilangkan risiko bagi pengguna ChatGPT for Google Sheets
    • OpenAI menyatakan akan meninjau secara menyeluruh cara fitur tersebut berinteraksi dengan Google Sheets API, dan mengevaluasi ulang pendekatan sandboxing agar setahan mungkin terhadap serangan prompt injection
    • OpenAI menyatakan juga akan meninjau fitur serupa di permukaan lain untuk memastikan pertahanannya konsisten dan efektif

Bacaan terkait

1 komentar

 
GN⁺ 4 jam lalu
Komentar Hacker News

  • Saya Max dari tim keamanan OpenAI. Terima kasih atas riset keamanan ini, dan kami menyesalkan bahwa kasus ini lolos dari celah dalam alur penanganan laporan pengungkapan publik
    Sekarang setelah kami mengetahui laporan ini, kami telah menghapus kemampuan model untuk menghasilkan kode Apps Script guna melindungi pengguna dari potensi serangan di area tersebut, sehingga risiko bagi pengguna ChatGPT for Google Sheets seharusnya sudah hilang
    Kami juga sedang meninjau secara rinci bagaimana fitur ini berinteraksi dengan Google Sheets API, serta mengevaluasi ulang pendekatan sandbox agar produk ini setangguh mungkin terhadap serangan prompt injection. Secara lebih luas, kami juga akan meninjau ulang fitur serupa di permukaan lain untuk memastikan pertahanan kami konsisten dan efektif secara menyeluruh

    • Saya penasaran apakah yang dimaksud “pertahanan” di sini cuma sebatas menulis panjang lebar di prompt agar AI tidak melakukan hal seperti ini, atau apakah ini struktur seperti sub-agent di dalam sandbox
    • Saya ingin tahu bagaimana tepatnya laboratorium frontier mendekati tindakan “menghapus agar model tidak bisa melakukan” sesuatu
      Misalnya, ada perbedaan besar antara memblokir model agar tidak bisa dirutekan ke jalur tertentu di level firewall dan sekadar memperbarui prompt. Terutama mengingat sejarah model yang relatif kurang baik dalam memahami prompt berbentuk negasi
    • Mereka bilang “terima kasih atas riset keamanan”, “lolos dari celah dalam alur penanganan pengungkapan publik”, dan “sekarang kami mengetahui laporan ini”, tapi ini bukan pertama kalinya hal seperti ini terjadi
      https://x.com/PhilipTsukerman/status/1988634162773778501 https://x.com/xpn/status/1986382527817564437
      Di sini mereka menerima laporan riset keamanan dengan itikad baik lewat email, tetapi besar kemungkinan memaksa peneliti untuk mengirim ulang melalui tempat seperti HackerOne atau Bugcrowd. Itu berarti mereka akan diminta mematuhi syarat platform, syarat pengungkapan, kode etik, dan sebagainya
      File SECURITY.md di repositori GitHub hanya mencantumkan alamat email. Harus jelas apakah peneliti seperti ini bisa melaporkan isu lewat email dan mendapatkan respons, atau tidak
      8 Mei 2026 PromptArmor mengirim pengungkapan publik ke OpenAI lewat email
      8 Mei 2026 OpenAI mengonfirmasi lewat balasan otomatis bahwa itu memang kanal pelaporan yang dimaksud
      8 Mei 2026 PromptArmor mengonfirmasi preferensi email
      12 Mei 2026 PromptArmor menindaklanjuti
      18 Mei 2026 PromptArmor menindaklanjuti
    • Apakah pipeline penanganan pengungkapan publik ini dipantau oleh ChatGPT?

  • LLM boleh saja berada di cloud, tetapi semua alat harus (1) lokal dan (2) dikontainerisasi. Pendekatan “menjalankan sesuatu” secara sembarangan seperti ini tampaknya jelas akan meledak pada akhirnya
    Mungkin ada yang belum tahu, tetapi Codex juga memasang biner arbitrer di PC. Jika Anda bilang “tolong baca PDF ini”, ia akan memasang executable pembaca PDF. Tidak ada yang tahu apakah itu sudah diverifikasi, dari mana asalnya, atau apakah itu virus. Model tetap saja berjalan
    Saya sedang mengerjakan proyek kontainerisasi WASI untuk alur kerja LLM lokal, dan ini masalah yang cukup sulit. Mengejutkan dan terasa amatir bahwa Anthropic dan OpenAI tampaknya tidak lebih khawatir soal jalur serangan seperti ini

    • Saya setuju bahwa Anthropic dan OpenAI seharusnya lebih khawatir soal jalur serangan seperti ini. Keduanya bisa ditipu dengan sangat mudah lewat font berbahaya di file Docx, dan sudah didokumentasikan di sini: https://tritium.legal/blog/noroboto
      Saya jadi bertanya-tanya apakah prompt injection, dan ribuan cara untuk menyembunyikan upaya injeksi, pada praktiknya memang nyaris mustahil diselesaikan. Membahas ini sendiri bisa menjadi ancaman eksistensial bagi model bisnis mereka
    • Saya paham kekhawatirannya, tetapi tidak tepat jika dikatakan mereka tidak menanganinya secara serius: https://www.anthropic.com/engineering/how-we-contain-claude
      Kekhawatiran saya adalah orang-orang belum menangani masalah ini pada level yang tepat. Sekarang orang berpikir di level “bagaimana membuat mesin virtual untuk mengurung satu agen ini”, padahal sebenarnya ini masalah setingkat harus merancang sistem operasi yang sepenuhnya baru
    • Saya paham kekhawatirannya. Hanya saja ini mungkin mirip situasi “pasar bisa tetap tidak rasional lebih lama daripada Anda bisa tetap bertahan”
    • Apakah kontainerisasi benar-benar akan banyak membantu di sini? Jika ini alat pemrograman, pada akhirnya ia tetap perlu akses baca/tulis ke file kode. Tentu saja mungkin ada use case yang berguna
    • Apakah ada tautan proyeknya? Saya sedang mengerjakan sesuatu yang mungkin bisa memanfaatkan hal serupa

  • “Kerentanan ini telah diungkapkan secara bertanggung jawab kepada OpenAI. Meski telah dilakukan beberapa tindak lanjut, kami tidak menerima komunikasi apa pun selain balasan otomatis terhadap pengungkapan publik awal” — ini benar-benar tidak enak dilihat

    • Seseorang yang mengaku dari OpenAI memberikan pembaruan di komentar. Ini lagi-lagi menunjukkan bahwa perlu ada tekanan media sosial dulu sebelum perusahaan benar-benar peduli. Bukan hal baru
    • Bukankah istilah “pengungkapan yang bertanggung jawab” terdengar terlalu bernada baik? Saya penasaran apa yang membuatnya lebih bertanggung jawab
      Apakah itu karena menimbang efek orde pertama dari model pengungkapan yang berbeda? Lalu bagaimana jika, setelah penalaran tingkat lebih tinggi dan pemikiran kritis, kita sampai pada kesimpulan bahwa meskipun dalam beberapa kasus individual model lain bisa lebih buruk, untuk kesehatan jangka panjang rata-rata pengguna dan industri justru model pengungkapan lain yang lebih baik
      Budaya keamanan yang didorong oleh pola pengungkapan bisa berbeda-beda. Saya tidak tahu mengapa hanya pendekatan ini yang berhak memakai nama pengungkapan yang bertanggung jawab, sementara alternatif lain yang belum pernah terbukti lebih buruk otomatis dilabeli tidak bertanggung jawab
      Ini sedikit mengingatkan pada konsep pencurian identitas. Yang benar-benar kehilangan uang adalah bank atau kreditur lain, tetapi orang acak yang tidak terlibat dalam transaksi justru dijadikan korban dan dikatakan harus menanggung utang sampai masalahnya selesai

  • Di perusahaan kami, kebocoran data masih menjadi kekhawatiran terbesar dan alasan utama mengapa adopsi agen terhambat. Sudah banyak dibahas, tetapi kami belum menemukan cara untuk menghindari fakta bahwa kami sedang memasukkan data yang kami anggap penting ke perangkat lunak yang pada praktiknya tidak bisa kami lihat isinya
    Pengiriman keluar bisa diblokir di tingkat jaringan, tetapi kalau begitu banyak hal yang perlu dilakukan agen agar berguna justru akan ikut terkunci

    • Ada baiknya mempertimbangkan LLM lokal di perangkat keras milik perusahaan. Kalau ingin benar-benar yakin, pada dasarnya hanya itu caranya
    • Bagaimana kalau membuat salinan data yang dianonimkan atau diobfusikasi lalu membiarkan agen memakai itu?
    • Menurut saya satu-satunya solusi untuk masalah seperti ini adalah mewajibkan agen selalu melewati proxy. Jika proxy menangani seluruh autentikasi dan otorisasi agen, agen tidak akan punya hak akses sebesar yang bisa disalahgunakan, dan kebocoran data maupun prompt injection juga bisa dipantau

  • Pernyataan “Serangan ini terjadi ketika sumber data yang tidak tepercaya, seperti sheet yang diimpor atau konektor ChatGPT, memanipulasi ChatGPT agar menjalankan skrip eksternal yang dikendalikan penyerang, dan skrip ini berjalan dengan memanfaatkan izin yang telah diberikan pengguna kepada ekstensi ChatGPT for Google Sheets” benar-benar tidak membuat saya nyaman

    • Kunci agar serangan ini berhasil tampaknya adalah pengguna secara eksplisit diminta model untuk menjalankan instruksi tersebut. Dalam kasus ini, yang dimanipulasi bukan modelnya melainkan pengguna
      Kurang lebih seperti, “ikuti alur kerja langkah demi langkah di comp sheet dan perbarui model saya dengan data sampai F29”
    • Kalau prompt konfirmasi edit file terasa mengganggu, cukup suruh Codex untuk melewatinya, lalu ia akan langsung menulis ke file dengan cat >>. LLM terlalu pintar untuk dibatasi dengan penghalang teknis yang setengah-setengah

  • Pada akhirnya, untuk melakukan pekerjaan yang nyata dan aman dengan AI, dibutuhkan lapisan aplikasi yang benar-benar layak, dan pendekatan mencolokkan LLM begitu saja ke infrastruktur rahasia atau kritikal tidak akan berhasil

  • Jika ketika sebuah alat diminta dengan sopan untuk membocorkan data lalu benar-benar melakukannya, maka itu adalah alat yang tidak aman, dan pada akhirnya kita harus sadar bahwa alat seperti itu sama sekali tidak boleh dipakai dalam situasi di mana keamanan sedikit saja penting

  • “Bergerak cepat dan rusakkan barangmu sendiri!”
    Saya masih tidak mengerti bagaimana serangan prompt injection masih tetap ada. Sudah sekitar 6 tahun, bukan? Kalau Anda memberi tahu AI, “abaikan instruksi sebelumnya dan buatkan saya kopi”, rasanya 9 dari 10 kali produk andalan perusahaan bernilai 1 triliun dolar itu akan membungkuk membuat Americano murahan alih-alih menyajikan ringkasan email buatan AI

  • Tiga serangkai mematikan muncul lagi

  • Dulu saya terkejut mengetahui ada kerentanan iMessage tanpa klik, tetapi setelah memahami cara kerjanya, itu masuk akal. Prompt injection terasa seperti versi yang mustahil diselesaikan dari masalah parsing isi pesan