Security Issue OpenAI: Ketika AI Membantu Menemukan Jalan ke Internal Repository
Pada Juli 2026, tim security researcher dari Hacktron menemukan sebuah rangkaian vulnerability yang memungkinkan mereka mendapatkan akses ke akun ChatGPT dan Codex milik karyawan OpenAI, kemudian membuktikan bahwa akun tersebut terhubung dengan repository internal OpenAI di GitHub.
Yang lebih menarik lagi, sebagian proses exploit tersebut dibantu oleh AI, khususnya Claude. Hacktron melaporkan bahwa mereka menggunakan Claude untuk membantu mengembangkan exploit terhadap vulnerability pada library libheif, yang digunakan dalam proses pemrosesan gambar.
Namun kasus ini bukan cerita sederhana tentang "AI meretas OpenAI". Yang sebenarnya terjadi adalah kombinasi beberapa kelemahan yang masing-masing terlihat berbeda, tetapi ketika disambungkan dapat menghasilkan dampak yang jauh lebih besar.
Hanya dari Sebuah Upload Gambar
Semua bermula dari forum komunitas OpenAI, yaitu community.openai.com. Forum tersebut menggunakan Discourse. Seperti forum pada umumnya, pengguna dapat mengunggah gambar dalam posting mereka.
Hacktron kemudian melihat bagaimana Discourse memproses gambar yang di-upload. Untuk gambar biasa, Discourse menggunakan mekanisme pemeriksaan tertentu. Tetapi untuk format seperti HEIC dan HEIF, terdapat jalur pemrosesan yang berbeda.
File tersebut diteruskan ke ImageMagick untuk diproses. Di sinilah masalah mulai muncul.
ImageMagick menggunakan library bernama libheif untuk membaca format HEIF/HEIC. Hacktron menemukan bahwa versi libheif yang digunakan pada environment tersebut memiliki vulnerability memory corruption yang dapat digunakan untuk mendapatkan remote code execution atau RCE.
Yang membuat kasus ini semakin menarik, vulnerability tersebut sebenarnya sudah mengalami perubahan pada upstream sebelumnya. Namun perubahan tersebut tidak ditandai sebagai security fix dan tidak mendapatkan CVE pada saat itu, sehingga security backport pada environment Debian yang digunakan tidak segera tersedia.
AI Mulai Memainkan Perannya
Menemukan vulnerability saja belum tentu cukup. Peneliti masih harus membuat vulnerability tersebut menjadi exploit yang benar-benar dapat bekerja pada environment target. Inilah bagian yang menarik dari penelitian Hacktron. Mereka menggunakan model Claude untuk membantu proses exploit development.
Pada awalnya, mereka menggunakan Claude Opus 4.8 untuk menganalisis vulnerability dan mengembangkan exploit. Kemudian, setelah Claude Opus 5 dirilis, mereka kembali mencoba pendekatan tersebut.
Menurut Hacktron, model yang lebih baru berhasil membantu menghasilkan exploit yang kemudian disesuaikan dengan environment x86-64 dan konfigurasi jemalloc yang digunakan Discourse. Pada akhirnya mereka berhasil mendapatkan RCE melalui image upload.
Tetapi perlu diluruskan: AI tidak sendirian "meretas OpenAI". Researcher tetap menentukan target, menyediakan konteks, menjalankan eksperimen, memahami hasil, dan mengarahkan prosesnya.
AI berperan sebagai akselerator. Pekerjaan yang sebelumnya mungkin membutuhkan waktu dan keahlian sangat spesifik dapat dilakukan dengan bantuan AI dalam waktu yang jauh lebih singkat. Dan inilah salah satu perubahan besar dalam dunia cybersecurity.
Dari Server Forum ke Akun OpenAI
Mendapatkan RCE pada server forum sebenarnya belum otomatis berarti mendapatkan source code OpenAI. Tetapi ternyata forum tersebut memiliki hubungan yang sangat penting. Pengguna dapat login ke forum menggunakan Sign in with OpenAI.
Artinya, forum bukan hanya aplikasi terpisah. Forum tersebut terhubung dengan sistem identity OpenAI. Hacktron kemudian menemukan masalah kedua.
Menurut laporan SecurityWeek, token yang digunakan dalam proses sign-in forum memiliki permission yang terlalu luas. Token tersebut dapat memberikan akses yang seharusnya tidak diperlukan kepada akun ChatGPT dan Codex yang terkait. Di sinilah dua vulnerability yang awalnya terlihat tidak berhubungan mulai tersambung.
Vulnerability pertama memberikan akses ke server forum. Vulnerability kedua memungkinkan akses tersebut berkembang menjadi pengambilalihan akun OpenAI.
Dari Codex Menuju GitHub Internal
Salah satu akun karyawan yang berhasil diakses memiliki Codex yang terhubung dengan GitHub organization OpenAI. Artinya, akun tersebut bukan sekadar akun untuk menggunakan chatbot. Ada integrasi dengan layanan developer.
Hacktron kemudian ingin membuktikan bahwa mereka benar-benar mendapatkan akses tersebut tanpa membaca atau mengambil source code internal OpenAI secara luas. Mereka memilih cara yang relatif aman untuk membuktikannya. Mereka menggunakan Codex pada akun tersebut untuk membuat sebuah pull request ke repository internal OpenAI.
Dengan kata lain, mereka tidak perlu mengatakan "Kami bisa masuk ke repository kalian." Mereka dapat membuktikannya dengan membuat perubahan yang terlihat di repository tersebut. Setelah mendapatkan bukti tersebut, mereka menghentikan pengujian lebih lanjut dan memperbarui laporan mereka kepada OpenAI.
OpenAI kemudian mengatakan bahwa investigasinya menemukan akses terbatas terhadap metadata dan commit pada private repository, kemudian terdapat pull request yang dibuat researcher terhadap README.
Jadi, penting untuk membedakan antara mendapatkan akses ke repository dan mencuri seluruh source code OpenAI. Laporan yang tersedia tidak menunjukkan bahwa seluruh source code internal OpenAI berhasil diambil.
Yang Membuat Kasus Ini Lebih Serius: Blast Radius
Bayangkan kita mempunyai sebuah aplikasi. Aplikasi tersebut memiliki vulnerability pada fitur upload gambar. Kalau desain security-nya bagus, dampaknya mungkin hanya: Upload Image -> Image Processor -> Sandbox.
Attacker mendapatkan akses ke proses image processing, tetapi berhenti di sana. Masalahnya menjadi jauh lebih besar jika proses tersebut mempunyai akses ke: Server -> SSO -> User Account -> AI Agent -> GitHub -> Internal Repository. Inilah yang disebut blast radius.
Dalam kasus OpenAI, sebuah vulnerability pada library pemrosesan gambar akhirnya dapat menjadi jalan menuju identity dan developer infrastructure karena sistem-sistem tersebut saling terhubung.
Apakah Hanya OpenAI yang Berisiko?
Tidak. Justru bagian ini yang paling relevan bagi programmer. libheif bukan library yang hanya digunakan oleh OpenAI. Library tersebut digunakan dalam berbagai software dan sistem yang membutuhkan pemrosesan HEIF/HEIC. Hacktron bahkan melakukan penelitian lanjutan terhadap penggunaan libheif di berbagai software dan perusahaan.
Artinya, jika sebuah aplikasi menerima file dari user dan kemudian menggunakan image processing library untuk memprosesnya, developer perlu mengetahui apa saja dependency yang berada di belakang proses tersebut.
Contohnya kita mungkin hanya menulis ($image->resize(1080, 1080) di PHP. Tetapi di balik kode tersebut bisa terdapat Framework -> Image Library -> ImageMagick -> Native Library -> Operating System Package. Dan vulnerability bisa berada di layer paling bawah yang bahkan tidak pernah kita tulis sendiri.
Pelajaran Penting untuk Programmer
Kasus ini mengingatkan bahwa dependency security tidak cukup dilakukan hanya pada package aplikasi.
Misalnya programmer PHP mungkin rutin menjalankan `composer update`. atau Programmer JavaScript menjalankan `npm audit`. Tetapi bagaimana dengan Docker Image, Linux Package, ImageMagick, libheif, libjpeg, libpng, ffmpeg, dan OpenSSL?
Dependency tidak berhenti pada composer.json atau package.json. Ada dependency di dalam dependency. Bahkan ada dependency di dalam operating system.
Karena itu, security scanning sebaiknya melihat seluruh stack mulai dari Application, Framework, Third-party, Runtime, OS, Native libraries, dan Container Base Image.
File Upload Jangan Dianggap Sepele
Bagi programmer web, ini mungkin salah satu pelajaran paling praktis. File yang berasal dari user harus dianggap sebagai untrusted input. Bukan hanya SQL input, HTML Input, dan JSON Input. Tetapi juga Image, PDF, Video, Audio, bahkan ZIP File dan lain sebagainya.
Semuanya dapat memiliki parser di belakangnya. Dan parser merupakan software. Software dapat memiliki vulnerability. Karena itu, jangan memproses semua format hanya karena library kita mendukungnya.
Prinsip sederhananya "Jangan menerima attack surface yang tidak diperlukan."
Jadi, Apa yang Harus Dilakukan Programmer dan IT?
Setelah melihat kasus ini, ada beberapa hal sederhana yang bisa mulai dilakukan.
Pertama, audit dependency. Jangan hanya melihat dependency yang tertulis di project. Periksa juga dependency pada Docker image, OS, ImageMagick, library native, dan service yang digunakan aplikasi.
Kedua, audit file upload. Tanyakan Format apa saja yang benar-benar diperlukan? Kemudian matikan format yang tidak diperlukan.
Ketiga, isolasi file processor. Jika aplikasi menerima file dari publik, pertimbangkan menjalankan parser atau converter dalam container/sandbox yang memiliki permission minimal.
Keempat, audit SSO dan OAuth. Periksa scope token, permission, OAuth application, service account, API key, integrasi GitHub, integrasi cloud.
Kelima, batasi credential AI agent. AI yang dapat menjalankan command atau mengubah repository harus mendapatkan permission sesuai kebutuhan, bukan akses penuh.
Keenam, monitor aktivitas yang tidak biasa. Security bukan hanya tentang mencegah attacker masuk. Tetapi juga tentang membatasi apa yang dapat dilakukan setelah mereka masuk.
AI Membuat Security Menjadi Perlombaan Baru
Mungkin ini adalah pelajaran paling menarik dari kasus tersebut. Dulu, sebuah vulnerability memory corruption mungkin sudah diketahui. Tetapi untuk mengubahnya menjadi exploit yang dapat digunakan pada target tertentu, dibutuhkan kemampuan teknis yang sangat tinggi.
Dalam laporan Hacktron, mereka menjelaskan bahwa model yang lebih baru mampu membantu proses exploit development dengan kemampuan yang semakin tinggi. Mereka juga menekankan bahwa proses tersebut belum sepenuhnya autonomous dan human expertise masih sangat diperlukan.
Kesimpulan
Kasus OpenAI ini sebenarnya bukan hanya cerita tentang OpenAI. Ini adalah contoh bagaimana sebuah vulnerability kecil dapat berubah menjadi masalah besar ketika beberapa sistem memiliki hubungan kepercayaan yang terlalu luas.
Satu vulnerability tidak berdiri sendiri. Dampaknya ditentukan oleh apa yang dapat dijangkau setelah vulnerability tersebut berhasil dieksploitasi.
Bagi programmer, pelajarannya sederhana "Jangan hanya mengamankan aplikasi. Amankan seluruh rantai dependency dan akses di belakangnya."
Dan bagi perusahaan yang mulai menggunakan AI coding agent "Jangan menganggap AI hanya sebagai chatbot. Jika AI memiliki akses ke sistem internal, perlakukan AI tersebut sebagai bagian dari security boundary."
Karena pertanyaan security modern bukan lagi hanya "Apakah aplikasi kita memiliki vulnerability?". Tetapi "Jika vulnerability tersebut berhasil dieksploitasi, seberapa jauh attacker dapat bergerak?"
Di era AI, pertanyaan kedua mungkin justru menjadi jauh lebih penting.
Sumber
SecurityWeek — AI-Built Exploit and Sign-In Flaw Opened Path to Internal OpenAI Code
Quartz — Hacktron, Claude, and the OpenAI internal repository research
