Kerentanan eksekusi kode jarak jauh GitHub: analisis CVE-2026-3854

• Hanya dengan cacat protokol internal pada jalur git push, eksekusi kode jarak jauh dimungkinkan di backend; GitHub.com sudah dimitigasi, tetapi GHES memerlukan penerapan patch
• Karena push option yang merupakan input yang dikendalikan pengguna masuk apa adanya ke header X-Stat, satu titik koma saja dapat menyuntikkan field baru, dan perilaku last-write-wins di mana nilai belakangan untuk key yang sama menimpa nilai sebelumnya pun dieksploitasi
• Dengan menggabungkan field yang dapat disuntikkan seperti rails_env, custom_hooks_dir, dan repo_pre_receive_hooks, sandbox bisa dilewati dan hook pada path yang ditentukan penyerang dapat dijalankan dengan hak pengguna git
• Dengan mekanisme yang sama, bahkan flag enterprise mode di GitHub.com dapat disuntikkan, sehingga eksekusi kode terkonfirmasi pada shared storage node dan berujung pada kondisi di mana repositori pengguna dan organisasi lain pada node tersebut juga bisa dibaca
• Ini menunjukkan bahwa dalam arsitektur multiservis di mana layanan berbeda mempercayai format bersama, kombinasi kurangnya pembersihan input, jalur eksekusi non-produksi, dan absennya validasi path dapat berkembang menjadi kerentanan serius

---

Respons segera dan cakupan dampak

• Di GitHub.com, isu ini sudah dimitigasi sehingga tidak diperlukan tindakan tambahan
• GitHub Enterprise Server memerlukan respons segera, dan harus di-upgrade ke GHES 3.19.3 atau lebih baru yang mencakup perbaikan CVE-2026-3854
• Rentang versi yang rentan adalah GHES 3.19.1 ke bawah, sedangkan versi perbaikan yang disajikan adalah 3.14.24, 3.15.19, 3.16.15, 3.17.12, 3.18.6, 3.19.3
• Pada saat penulisan, 88% instance GHES masih dalam keadaan rentan
• Informasi teknis tambahan dan prosedur pemulihan dari GitHub dapat dilihat di blog keamanan GitHub
• Pelanggan Wiz dapat mengidentifikasi instance GHES yang rentan dengan kueri bawaan di Wiz Threat Center

Latar belakang investigasi dan pendekatan

• Infrastruktur git internal GitHub adalah jalur yang menangani semua git push, dan beberapa layanan internal di dalamnya ditulis dalam bahasa pemrograman yang berbeda-beda
• Dalam struktur multiservis seperti ini, perbedaan cara tiap komponen mengurai dan mempercayai data bersama dapat berujung pada kerentanan
• Sebelumnya, mengekstrak dan mengaudit banyak binary black-box terkompilasi yang membentuk pipeline ini membutuhkan waktu berlebihan dan banyak pekerjaan manual
• Dengan alat berbantuan AI dan reverse engineering otomatis berbasis IDA MCP, binary terkompilasi dapat dianalisis dengan cepat dan protokol internalnya dapat direkonstruksi
• Dalam proses itu, titik-titik di mana input pengguna memengaruhi perilaku server di seluruh pipeline dilacak secara sistematis, dan cacat mendasar pada keseluruhan aliran input pun ditemukan

Arsitektur internal dan batas kepercayaan

• Saat git push masuk melalui SSH, permintaan mengalir berurutan ke babeld, gitauth, gitrpcd, lalu pre-receive hook
• babeld menerima koneksi SSH sebagai titik masuk untuk semua operasi git, lalu meneruskan autentikasi ke gitauth
• gitauth memverifikasi kredensial pengguna dan hak push ke repositori, lalu mengembalikan kebijakan keamanan seperti batas ukuran file atau aturan nama branch
• Berdasarkan respons ini, babeld menyusun header internal X-Stat yang berisi metadata keamanan
• gitrpcd menerima header X-Stat untuk mengatur environment proses lanjutan, dan sepenuhnya mempercayai babeld tanpa autentikasi sendiri
• pre-receive hook memeriksa batas ukuran file, aturan nama branch, integritas LFS, dan custom hook yang didefinisikan admin sebelum push diterima
• Mata rantai utamanya adalah header X-Stat yang berisi pasangan key=value yang dipisahkan oleh ;
• Layanan internal membagi X-Stat berdasarkan ; lalu mengisinya ke map; jika key yang sama muncul dua kali, nilai yang datang belakangan menimpa nilai sebelumnya menurut aturan last-write-wins
• babeld juga memasukkan push options yang dikirim lewat git push -o ke dalam X-Stat sebagai field seperti push_option_0, push_option_1, dan push_option_count

Penyebab kerentanan: injeksi field X-Stat

• babeld menyalin nilai push option yang dikendalikan pengguna ke header X-Stat tanpa membersihkan titik koma
• Karena ; adalah pemisah field di X-Stat, satu titik koma di dalam push option sudah cukup untuk keluar dari field asli dan membuat field baru yang dikendalikan penyerang
• Sebagai contoh, jika large_blob_rejection_enabled=bool:false disuntikkan ke dalam push_option_0, nilai bool:true yang ditetapkan sebelumnya akan ditimpa oleh nilai yang datang belakangan
• Perilaku ini terkonfirmasi baik lewat analisis binary maupun packet capture pada instance GHES nyata
• Dengan menggabungkan reverse engineering dan analisis pada level wire, field X-Stat yang bisa disuntikkan berhasil dipetakan
• Secara khusus, field penting dari sisi keamanan yang teridentifikasi adalah rails_env, custom_hooks_dir, repo_pre_receive_hooks, large_blob_rejection_enabled, reject_sha_like_refs, user_operator_mode
• Dari semuanya, tiga field rails_env, custom_hooks_dir, dan repo_pre_receive_hooks menjadi kunci yang mengarah ke eksekusi kode jarak jauh

Jalur menuju RCE di GHES

• GHES mendukung custom pre-receive hooks yang dijalankan sebelum push diterima
• Binary pre-receive memiliki dua jalur eksekusi yang dibedakan hanya oleh nilai rails_env dari X-Stat
• Jika nilainya production, hook dijalankan di dalam sandbox; untuk nilai lainnya, hook dijalankan langsung dengan hak pengguna layanan git tanpa sandbox atau isolasi
• Karena itu, dengan menyuntikkan rails_env bernilai non-produksi, sandbox bypass menjadi mungkin
• Selanjutnya, dengan menyuntikkan custom_hooks_dir, penyerang dapat mengendalikan direktori dasar tempat skrip hook dicari
• Terakhir, jika repo_pre_receive_hooks disuntik dengan definisi hook yang berisi path traversal, resolusi path dalam binary akan menggabungkan direktori yang dikendalikan penyerang dengan payload traversal tersebut hingga menunjuk ke path arbitrer di filesystem
• Jalur eksekusi non-produksi kemudian menjalankan path yang telah diresolusikan ini secara langsung, tanpa argumen, tanpa sandbox, dan sebagai pengguna layanan git
• Dalam verifikasi nyata, hanya dengan satu git push, output uid=500(git) dikembalikan, yang mengonfirmasi RCE dengan hak pengguna git
• Dengan hak ini, penyerang dapat memperoleh kendali penuh termasuk baca-tulis filesystem instance GHES dan visibilitas terhadap konfigurasi layanan internal

Ekspansi ke GitHub.com dan paparan lintas-tenant

• Saat rantai eksploit yang sama diterapkan ke repositori GitHub.com, awalnya push berhasil tetapi custom hooks tidak dieksekusi
• Dengan menyuntikkan user_operator_mode=bool:true dan membandingkan output debug di kedua platform, terungkap bahwa GitHub.com tidak mencapai jalur kode custom hooks
• Reverse engineering tambahan mengonfirmasi adanya flag boolean di header X-Stat yang mengendalikan apakah enterprise mode server aktif
• Di GHES, flag ini secara default bernilai true sehingga jalur custom hooks selalu aktif; di GitHub.com, nilai default-nya false sehingga dalam kondisi normal jalur tersebut tidak tercapai
• Karena flag ini juga bisa disuntikkan dengan mekanisme yang sama, menambahkan satu field lagi membuat seluruh rantai eksploit bekerja di GitHub.com juga
• Setelah itu, hasil eksekusi hostname dari dalam infrastruktur GitHub.com dikembalikan, yang mengonfirmasi RCE di GitHub.com
• GitHub.com adalah platform multitenant, sehingga repositori dari banyak pengguna dan organisasi disimpan pada infrastruktur backend bersama
• Lokasi terjadinya eksekusi kode adalah shared storage node, dan di sana pengguna git memiliki hak filesystem yang luas untuk menangani semua operasi repositori pada node tersebut
• Jika pengguna ini dikompromikan, repositori milik organisasi dan pengguna lain pada node itu juga dapat dibaca terlepas dari siapa pemiliknya
• Saat entri indeks repositori yang dapat diakses pada dua node yang terkompromi dihitung, masing-masing node memiliki jutaan entri, termasuk repositori milik pengguna dan organisasi lain
• Isi nyata repositori tenant lain tidak diakses, dan hanya akun uji milik sendiri yang digunakan untuk memverifikasi bahwa hak filesystem pengguna git memang mengizinkan pembacaan semua repositori di dalam node

Pelajaran utama dan jadwal pengungkapan

• Hanya dengan satu git push, eksekusi kode jarak jauh di infrastruktur backend dimungkinkan dengan mengeksploitasi cacat protokol internal
• Ketika beberapa layanan yang ditulis dalam bahasa berbeda saling bertukar data melalui protokol internal bersama, asumsi kepercayaan tiap layanan itu sendiri menjadi permukaan serangan
• Dalam rantai ini, satu layanan menyisipkan nilai push option apa adanya, layanan lain mempercayai semua field X-Stat, dan pre-receive hook mengasumsikan bahwa rails_env akan bernilai production di lingkungan operasional
• Jalur kode non-produksi di dalam binary produksi, tidak adanya validasi path traversal pada skrip hook, dan absennya pembersihan input dalam protokol berbasis pemisah adalah pola yang dapat muncul di codebase lain juga
• Tim yang mengoperasikan arsitektur multiservis perlu secara khusus memeriksa bagaimana input yang dikendalikan pengguna mengalir mengikuti protokol internal, terutama ketika konfigurasi sensitif keamanan diturunkan dari format data bersama
• Dalam riset ini, alat reverse engineering berbantuan AI termasuk IDA MCP memungkinkan analisis binary terkompilasi dan rekonstruksi protokol internal dilakukan dengan cepat
• Seiring alat seperti ini makin matang, tampaknya perannya akan semakin penting untuk menemukan kelas kerentanan yang membutuhkan analisis lintas-komponen yang mendalam
• Dalam jadwal pengungkapan, kerentanan injeksi push option X-Stat ditemukan pada 2026-03-04; pada hari yang sama RCE dikonfirmasi di GHES 3.19.1 dan dilaporkan ke GitHub, serta perbaikan GitHub.com juga dirilis pada hari itu
• Pada 2026-03-10, CVE-2026-3854 dan CVSS 8.7 diberikan, dan patch GHES dipublikasikan
• Pada 2026-04-28, kerentanan ini diungkapkan ke publik

[GN⁺]

Opini-opini Hacker News

• Ini pada dasarnya membuat header inti keamanan yang disetel oleh layanan autentikasi internal ikut memuat string arbitrer yang dimasukkan pengguna akhir lewat git push -o
  Memang gampang ngomong setelah kejadian, tapi ini tetap terasa terlalu absurd

• Pendekatan reverse engineering berbantuan AI benar-benar menunjukkan kekuatan agen LLM saat ini
  Karena model-model ini banyak dilatih dengan kode, mereka bisa sangat mempercepat pemahaman atas bagian dalam sistem yang kompleks
  Riset keamanan biasanya merupakan gabungan dari 1) memahami perilaku internal yang rumit dan 2) menemukan celah di dalamnya,
  dan sering kali begitu mekanisme internal yang sebenarnya terungkap, kerentanannya sendiri justru terlihat lebih mudah dari dugaan
  CVE-2026-3854 bukan tipe yang langsung obvious bahkan setelah tahu isi dalamnya,
  tapi kalau terpapar ke permukaan serangan yang lebih tradisional atau lebih mudah diakses, injeksi perintah ini kemungkinan akan cepat ditemukan

  • Sebelumnya sudah ada sinyal bahwa AI kuat untuk reverse engineering C++ atau memindahkan C++ ke C yang lebih sederhana dalam skala besar
    Tapi belakangan rasanya arus itu agak terganggu, atau malah sengaja dihambat oleh pihak yang ingin mempertahankan dev/vendor lock-in yang muncul dari kompleksitas sintaks C++

• Hasilnya terlihat cukup bagus, sampai-sampai terasa seperti memang ada orang yang bekerja di Wiz
  Produknya juga masih bertahan cukup baik meski mengalami pertumbuhan ekstrem dan pembengkakan fitur,
  dan tim keamanannya sering menemukan hal-hal yang benar-benar menarik

  • Banyak yang berlatar belakang Unit 8200
  • Terlalu banyak noise, jadi kami hanya memakai pipeline kustom yang menjalankan osv-scanner dan trivy untuk melihat yang critical saja
  • Saya memang tidak kerja di sana, tapi saat dipakai di perusahaan kami, alatnya sering memberi peringatan bahkan untuk perilaku yang sepenuhnya tidak berbahaya
    Sementara untuk pekerjaan yang agak mencurigakan seperti query DC lewat CLI dan reset kredensial, justru diam saja, yang bikin agak kesal

• Saat babeld meneruskan permintaan push, ia memasukkan push options ke header X-Stat pada permintaan internal,
  dan nilainya adalah string arbitrer yang dimasukkan pengguna lewat git push -o
  Tapi karena titik koma tidak disanitasi dan nilainya disalin mentah-mentah,
  ; yang berfungsi sebagai pemisah field X-Stat membuat penyerang bisa keluar dari field semula dan membuat field baru
  Ini benar-benar setingkat melakukan kesalahan paling sederhana, seperti buah yang tergantung terlalu rendah sampai-sampai terkubur di tanah

  • Ah, ibu Bobby Tables memang sangat cerdas

• Meski ini kerentanan yang ditemukan sebelum sempat dieksploitasi,
  rasanya tidak perlu menambah kepanikan dengan ungkapan seperti BREAKING, unauthorized access, dan millions of repositories
  https://x.com/wiz_io/status/2049153209982140718

  • Tapi di sisi lain, ungkapan itu juga tidak bisa dibilang tidak akurat
    GitHub bisa dibilang beruntung karena yang menemukannya adalah fuzzing milik Wiz, bukan aktor negara

• Fakta bahwa 88% instance GHES masih belum menerapkan patch keamanan kritis yang dirilis 7 minggu lalu terlihat cukup serius
  https://docs.github.com/en/enterprise-server@3.19/admin/release-notes#3.19.3

  • GHES praktis nyaris seperti dibiarkan terlantar selama bertahun-tahun
    Menerapkan satu rilis tingkat patch saja butuh downtime berjam-jam,
    dan tidak ada metode upgrade HA yang didukung, sehingga bahkan pelanggan yang rajin pun sulit selalu mengikuti versi terbaru
    Kalau mengeluh, semua orang menyuruh pindah ke GitHub Enterprise Cloud,
    tapi di zaman seperti sekarang, berapa banyak orang yang benar-benar akan memilih itu dengan mudah juga masih dipertanyakan
    Meski begitu, GHES setidaknya punya satu kelebihan: tidak ikut tumbang saat github.com mengalami gangguan harian
  • Banyak pelanggan on-prem menaruh GHES di balik VPN,
    dan tampaknya menunggu tanggal yang dampak operasionalnya kecil untuk melakukan upgrade
    Namun kalau instance-nya publik, harus segera diperbarui
    Dari informasi di artikel dan source GitHub Enterprise yang terbuka, tampaknya tidak sulit untuk menyusun cara reproduksinya
  • Di enterprise, kalau update di luar jadwal rutin lalu semuanya rusak, bisa-bisa kita yang dimintai tanggung jawab,
    jadi sering kali yang dipilih adalah tetap mengikuti jadwal dan berharap tidak terjadi apa-apa
  • Di lingkungan yang tidak bisa memakai github.com karena keamanan dianggap sangat serius,
    produk on-prem yang hanya diperbarui setahun sekali pun tidak dianggap aneh
  • Di lingkungan instalasi besar, yang jadi inti justru seberapa rapuh proses upgrade-nya
    Pada software enterprise dengan data berskala besar, hal kecil saja sering cukup untuk merusak instalasi dan memaksa tim operasi rollback
    Upgrade SharePoint dulu rasanya seperti melempar dadu

• Ini juga pencapaian besar dari Wiz,
  dan terasa seperti titik balik yang menunjukkan seberapa besar alat AI bisa mendorong RE dan penemuan jalur kompromi

  • Ini juga sedikit meruntuhkan argumen bahwa kalau source tidak dibuka maka AI akan lebih sulit membobolnya
    Ini jadi satu data point lagi bahwa keamanan pada akhirnya tidak boleh bergantung pada security through obscurity

• Semua orang bilang kita harus mengganti GitHub, tapi lalu muncul pertanyaan: pakai apa?
  Kalau tempat sebesar GitHub saja sekarang bisa kena RCE, sulit juga dengan yakin mengatakan alternatif lain pasti lebih baik

  • Bisa juga bercanda bahwa Thomas Dohmke akan menyelesaikan semuanya dengan proyek baru
    https://news.ycombinator.com/item?id=46961345
    https://news.ycombinator.com/item?id=47712656
  • Jawaban yang paling realistis tampaknya adalah menjadikan Forgejo self-hosted sebagai forge utama,
    lalu memakai GitHub hanya sebagai mirror selama masih memanfaatkan CI gratis
    Secret bisa diserahkan ke secret-hosting provider terpisah
  • Kami pindah dari GitHub ke Forgejo self-hosted 6 bulan lalu, dan sejauh ini berjalan sangat baik
    Masih sulit dipercaya bahwa Forgejo bisa secepat ini sementara GitHub jadi selambat ini
  • Sekarang kami benar-benar memisahkan proyek internal dan proyek yang dibuka ke publik
    Yang internal ditaruh di instance Forgejo privat, dan yang publik diunggah ke GitHub sambil dimirror ke Forgejo
    Saya juga kaget karena Forgejo pada dasarnya hampir seperti binary tunggal dan sangat mudah dikonfigurasi,
    dan semua layanan internal kami sudah diarahkan ke Forgejo sehingga kalau harus meninggalkan GitHub pun gesekannya kecil
  • GitLab self-hosted di balik VPN juga cukup bagus
    Dengan image Docker all-in-one dan beberapa GitLab runner saja sudah cukup untuk tim kecil sampai menengah,
    dan tidak perlu dibuat serumit versi Kubernetes kecuali memang benar-benar perlu

• Menemukan kerentanan dengan AI dari source code saja sudah mengesankan,
  tapi bisa melakukannya sampai dari executable biner benar-benar mengejutkan
  Potensinya sangat besar, baik untuk hal baik maupun buruk
  Dan sekali lagi, ini menegaskan pelajaran bahwa data tidak boleh diperlakukan sebagai perintah
  Semua input pengguna harus disanitasi

  • Transformer pada dasarnya memang arsitektur yang dirancang untuk penerjemahan
    Jadi kalau ia kuat untuk source-to-source atau text-to-source, itu sudah cukup familiar,
    dan mungkin tidak sepenuhnya mengejutkan bahwa ia juga cocok untuk memahami versi asm
    Meski begitu, tetap mengesankan

• Saya penasaran apakah nantinya bisa ditentukan apakah ini benar-benar pernah dieksploitasi

  • Menurut saya kerentanan ini tampaknya bahkan bisa dieksploitasi oleh pengguna anonim
    Dari log protokol HTTP/git, mungkin sampai batas tertentu bisa diketahui apakah eksploitasi memang terjadi,
    tetapi besar kemungkinan tidak tercatat apa tepatnya yang diakses dan siapa yang melakukannya
    Karena jika eksploit bisa berjalan mandiri di server git, secara definisi ia bisa menghindari logging