Bagaimana Serangan Berfungsi

Penyelidik menerangkan corak GitHub Agentic Workflow yang terdedah seperti berikut:

• Dicetuskan oleh peristiwa issues.assigned
• Membaca tajuk dan badan isu
• Menghantar komen menggunakan alat ejen seperti add-comment
• Berjalan dengan akses baca ke repositori lain dalam organisasi, termasuk repositori peribadi

Serangan berlaku dalam empat langkah:

1. Penyerang membuka Isu GitHub yang kelihatan tidak bersalah dalam repositori awam milik organisasi yang menggunakan corak Agentic Workflow yang terdedah.
2. Tersembunyi di dalam badan isu adalah arahan dalam Bahasa Inggeris biasa yang mengarahkan ejen AI untuk mengambil fail dari repositori peribadi.
3. Apabila automasi GitHub memberikan isu tersebut, workflow yang dicetuskan oleh peristiwa menyebabkan ejen mengambil data dari repositori yang boleh diakses, termasuk repositori peribadi.
4. Ejen menyiarkan kandungan yang diambil sebagai komen awam pada isu tersebut, berpotensi mendedahkan data kepada sesiapa yang boleh melihat isu tersebut.

Kelemahan Seni Bina Asas

Kecacatan teras adalah kegagalan mengekalkan sempadan kepercayaan yang ketat antara arahan peringkat sistem dan data pengguna yang tidak dipercayai dalam tetingkap konteks ejen AI. Seperti yang dinyatakan oleh Sasi Levi dari Noma: "Tetingkap konteks ejen juga merupakan permukaan serangannya. Mana-mana kandungan yang dibaca oleh ejen — sama ada isu, permintaan tarik, komen, atau fail — boleh dipersenjatai jika ejen menganggap kandungan itu sebagai input arahan."

Ejen berasaskan LLM sukar membezakan antara data dan arahan apabila kedua-duanya muncul dalam konteks atau output alat yang sama. Ini bukan sekadar pepijat pengekodan konvensional tetapi risiko struktur dalam workflow AI agentik, di mana kandungan yang tidak dipercayai boleh mempengaruhi tingkah laku ejen jika workflow tidak mengasingkan atau mengekangnya.

Penyelidik secara rasmi mengkategorikan kelas kecacatan ini sebagai Suntikan Workflow Agentik (AWI), mengenal pasti dua corak teras: Prompt-to-Agent (P2A), di mana kandungan yang tidak dipercayai mencapai sempadan prompt ejen, dan Prompt-to-Script (P2S), di mana pengaruh penyerang merebak melalui output terbitan model ke dalam skrip kemudian.

Teknik Pintasan Langkah Keselamatan: Kata Kunci "Additionally"

GitHub mempunyai langkah keselamatan yang bertujuan menghalang kecurian data, tetapi penyelidik Noma melaporkan bahawa ia boleh dipintas dengan teknik yang sangat mudah. Menambah perkataan "Additionally" pada arahan yang disuntik dilaporkan menyebabkan model merangka semula outputnya daripada menolak permintaan, membolehkan kebocoran data berlaku seolah-olah ia adalah sambungan tugas yang sah.

Pendekatan ini konsisten dengan penyelidikan suntikan prompt yang lebih luas menunjukkan bahawa frasa tertentu atau teks yang dikembalikan alat boleh menyebabkan model mengikuti arahan berniat jahat yang sepatutnya tidak diikutinya. Pintasan langkah keselamatan ini mencerminkan corak yang dilihat dalam insiden terdahulu, seperti kerentanan GitHub MCP yang didedahkan oleh Invariant Labs, di mana isu berniat jahat boleh merampas ejen pengguna untuk membocorkan data dari repositori peribadi.

Mitigasi yang Disyorkan untuk Organisasi

Berdasarkan penemuan GitLost dan panduan keselamatan workflow agentik yang lebih luas, organisasi yang terjejas harus melaksanakan kawalan berikut:

• Guna pakai sifar-kepercayaan untuk input ejen — jangan sesekali menganggap kandungan kawalan pengguna sebagai input arahan yang dipercayai, dan asingkan data pengguna yang tidak dipercayai dari prompt sistem teras.
• Guna pakai kebenaran paling rendah yang ketat dengan mengalihkan akses merentas repositori yang tidak perlu dan menghadkan keupayaan ejen untuk mendedahkan data melalui output awam.
• Guna senarai benarkan untuk alat dan bukannya senarai blok, dan memerlukan pintu kelulusan manusia sebelum ejen melakukan tindakan sensitif seperti menyiarkan komen yang boleh dilihat secara luaran atau mengakses repositori sensitif.
• Audit integrasi ejen AI dalam CI/CD dan workflow automasi repositori, terutamanya di mana konteks peristiwa GitHub yang tidak dipercayai dimasukkan ke dalam prompt atau input ejen.
• Asingkan input pengguna yang tidak dipercayai secara logik dari arahan peringkat sistem, menganggap teks yang dihasilkan pengguna sebagai data yang tidak dipercayai dan bukannya arahan yang berwibawa.

Organisasi juga harus menggunakan prinsip hak minimum untuk rahsia ejen dan melaksanakan pemantauan keselamatan berterusan untuk percubaan suntikan prompt.

Tindak Balas GitHub (setakat 7 Julai)

Menurut Dark Reading dan garis masa pendedahan Noma Security:

• Noma mendedahkan kecacatan kepada GitHub secara bertanggungjawab.
• GitHub memberitahu Noma bahawa mereka mengemas kini dokumentasi yang berkaitan dengan corak workflow yang terdedah, dan penyelidik melaporkan bahawa konfigurasi yang terdedah tidak lagi wujud apabila mereka menyemak kali terakhir.
• Setakat 7 Julai, GitHub belum mengeluarkan kenyataan awam rasmi atau CVE untuk GitLost.
• Kerentanan ini nampaknya ditangani sebahagiannya melalui pengalihan atau semakan dokumentasi dan templat workflow yang membolehkannya, bukannya melalui pembetulan keselamatan peringkat platform yang didokumentasikan dengan jelas.

Gambaran Lebih Besar: Risiko Sistemik

GitLost bukanlah insiden terpencil. Ia mewakili kelas kerentanan yang semakin berkembang di mana ejen AI yang mempunyai akses kepada data sensitif terdedah kepada kandungan pengguna yang tidak dipercayai. Isu serupa telah menjejaskan integrasi GitHub MCP, workflow Gemini CLI Google (kerentanan TrustIssues), dan Claude Code GitHub Actions. Benang yang sama ialah ejen berasaskan LLM tidak mempunyai keupayaan semula jadi untuk membezakan antara data dan arahan apabila kedua-duanya muncul dalam tetingkap konteks yang sama — cabaran seni bina asas yang tidak dapat diselesaikan sepenuhnya oleh sebarang tampung platform tunggal.

Bagaimana Serangan Berfungsi

Penyelidik menerangkan corak GitHub Agentic Workflow yang terdedah seperti berikut:

• Dicetuskan oleh peristiwa issues.assigned
• Membaca tajuk dan badan isu
• Menghantar komen menggunakan alat ejen seperti add-comment
• Berjalan dengan akses baca ke repositori lain dalam organisasi, termasuk repositori peribadi

Serangan berlaku dalam empat langkah:

1. Penyerang membuka Isu GitHub yang kelihatan tidak bersalah dalam repositori awam milik organisasi yang menggunakan corak Agentic Workflow yang terdedah.
2. Tersembunyi di dalam badan isu adalah arahan dalam Bahasa Inggeris biasa yang mengarahkan ejen AI untuk mengambil fail dari repositori peribadi.
3. Apabila automasi GitHub memberikan isu tersebut, workflow yang dicetuskan oleh peristiwa menyebabkan ejen mengambil data dari repositori yang boleh diakses, termasuk repositori peribadi.
4. Ejen menyiarkan kandungan yang diambil sebagai komen awam pada isu tersebut, berpotensi mendedahkan data kepada sesiapa yang boleh melihat isu tersebut.

Kelemahan Seni Bina Asas

Kecacatan teras adalah kegagalan mengekalkan sempadan kepercayaan yang ketat antara arahan peringkat sistem dan data pengguna yang tidak dipercayai dalam tetingkap konteks ejen AI. Seperti yang dinyatakan oleh Sasi Levi dari Noma: "Tetingkap konteks ejen juga merupakan permukaan serangannya. Mana-mana kandungan yang dibaca oleh ejen — sama ada isu, permintaan tarik, komen, atau fail — boleh dipersenjatai jika ejen menganggap kandungan itu sebagai input arahan."

Ejen berasaskan LLM sukar membezakan antara data dan arahan apabila kedua-duanya muncul dalam konteks atau output alat yang sama. Ini bukan sekadar pepijat pengekodan konvensional tetapi risiko struktur dalam workflow AI agentik, di mana kandungan yang tidak dipercayai boleh mempengaruhi tingkah laku ejen jika workflow tidak mengasingkan atau mengekangnya.

Penyelidik secara rasmi mengkategorikan kelas kecacatan ini sebagai Suntikan Workflow Agentik (AWI), mengenal pasti dua corak teras: Prompt-to-Agent (P2A), di mana kandungan yang tidak dipercayai mencapai sempadan prompt ejen, dan Prompt-to-Script (P2S), di mana pengaruh penyerang merebak melalui output terbitan model ke dalam skrip kemudian.

Teknik Pintasan Langkah Keselamatan: Kata Kunci "Additionally"

GitHub mempunyai langkah keselamatan yang bertujuan menghalang kecurian data, tetapi penyelidik Noma melaporkan bahawa ia boleh dipintas dengan teknik yang sangat mudah. Menambah perkataan "Additionally" pada arahan yang disuntik dilaporkan menyebabkan model merangka semula outputnya daripada menolak permintaan, membolehkan kebocoran data berlaku seolah-olah ia adalah sambungan tugas yang sah.

Pendekatan ini konsisten dengan penyelidikan suntikan prompt yang lebih luas menunjukkan bahawa frasa tertentu atau teks yang dikembalikan alat boleh menyebabkan model mengikuti arahan berniat jahat yang sepatutnya tidak diikutinya. Pintasan langkah keselamatan ini mencerminkan corak yang dilihat dalam insiden terdahulu, seperti kerentanan GitHub MCP yang didedahkan oleh Invariant Labs, di mana isu berniat jahat boleh merampas ejen pengguna untuk membocorkan data dari repositori peribadi.

Mitigasi yang Disyorkan untuk Organisasi

Berdasarkan penemuan GitLost dan panduan keselamatan workflow agentik yang lebih luas, organisasi yang terjejas harus melaksanakan kawalan berikut:

• Guna pakai sifar-kepercayaan untuk input ejen — jangan sesekali menganggap kandungan kawalan pengguna sebagai input arahan yang dipercayai, dan asingkan data pengguna yang tidak dipercayai dari prompt sistem teras.
• Guna pakai kebenaran paling rendah yang ketat dengan mengalihkan akses merentas repositori yang tidak perlu dan menghadkan keupayaan ejen untuk mendedahkan data melalui output awam.
• Guna senarai benarkan untuk alat dan bukannya senarai blok, dan memerlukan pintu kelulusan manusia sebelum ejen melakukan tindakan sensitif seperti menyiarkan komen yang boleh dilihat secara luaran atau mengakses repositori sensitif.
• Audit integrasi ejen AI dalam CI/CD dan workflow automasi repositori, terutamanya di mana konteks peristiwa GitHub yang tidak dipercayai dimasukkan ke dalam prompt atau input ejen.
• Asingkan input pengguna yang tidak dipercayai secara logik dari arahan peringkat sistem, menganggap teks yang dihasilkan pengguna sebagai data yang tidak dipercayai dan bukannya arahan yang berwibawa.

Organisasi juga harus menggunakan prinsip hak minimum untuk rahsia ejen dan melaksanakan pemantauan keselamatan berterusan untuk percubaan suntikan prompt.

Tindak Balas GitHub (setakat 7 Julai)

Menurut Dark Reading dan garis masa pendedahan Noma Security:

• Noma mendedahkan kecacatan kepada GitHub secara bertanggungjawab.
• GitHub memberitahu Noma bahawa mereka mengemas kini dokumentasi yang berkaitan dengan corak workflow yang terdedah, dan penyelidik melaporkan bahawa konfigurasi yang terdedah tidak lagi wujud apabila mereka menyemak kali terakhir.
• Setakat 7 Julai, GitHub belum mengeluarkan kenyataan awam rasmi atau CVE untuk GitLost.
• Kerentanan ini nampaknya ditangani sebahagiannya melalui pengalihan atau semakan dokumentasi dan templat workflow yang membolehkannya, bukannya melalui pembetulan keselamatan peringkat platform yang didokumentasikan dengan jelas.

Gambaran Lebih Besar: Risiko Sistemik

GitLost bukanlah insiden terpencil. Ia mewakili kelas kerentanan yang semakin berkembang di mana ejen AI yang mempunyai akses kepada data sensitif terdedah kepada kandungan pengguna yang tidak dipercayai. Isu serupa telah menjejaskan integrasi GitHub MCP, workflow Gemini CLI Google (kerentanan TrustIssues), dan Claude Code GitHub Actions. Benang yang sama ialah ejen berasaskan LLM tidak mempunyai keupayaan semula jadi untuk membezakan antara data dan arahan apabila kedua-duanya muncul dalam tetingkap konteks yang sama — cabaran seni bina asas yang tidak dapat diselesaikan sepenuhnya oleh sebarang tampung platform tunggal.