Dalam artikel ini
Pada 25 Agustus 2026, Badan Keamanan Siber dan Keamanan Infrastruktur Amerika Serikat (CISA) menambahkan CVE-2026-60004 ke katalog Kerentanan yang Diketahui Telah Dieksploitasi (Known Exploited Vulnerabilities) dan menetapkan 28 Agustus sebagai tenggat perbaikan bagi lembaga sipil federal. Celah ini terdapat di Gitea, server sumber terbuka untuk meng-hosting repositori kode yang dijalankan banyak tim di infrastruktur mereka sendiri alih-alih menggunakan layanan cloud.
Pengenal itu sendiri tidak berarti apa-apa bagi pemilik bisnis. Maknanya ada di tempat lain. Ini bukan celah di situs web yang dilihat pelanggan Anda atau di aplikasi seluler Anda. Ini adalah celah di alat internal yang tidak pernah dibuka oleh siapa pun di luar tim teknis. Dan membobolnya membuka pintu-pintu yang tidak akan pernah terbuka dengan membobol situs web Anda.
Apa yang sebenarnya terjadi
Menurut imbauan keamanan yang diterbitkan oleh para pengelola Gitea, celah ini memungkinkan pengguna dengan akses tulis biasa ke repositori mana pun untuk mengirim patch yang dibuat secara khusus ke endpoint diffpatch. Patch itu menanamkan Git hook yang dapat dieksekusi di server lalu menjalankan perintah shell sebagai akun yang menjalankan layanan tersebut. Versi 1.17 hingga 1.27.0 terdampak, dan perbaikannya hadir di versi 1.27.1.
Detail krusialnya adalah betapa rendahnya ambang masuk. Akses tulis ke sebuah repositori bukanlah hak istimewa yang langka, dan dalam konfigurasi bawaan, di mana pendaftaran mandiri terbuka, siapa pun dapat membuat akun dan mencapai ambang itu sendiri. Itulah sebabnya Basis Data Kerentanan Nasional Amerika Serikat (NVD) memberinya nilai 9.8 dari 10 pada skala CVSS, skor yang dikhususkan bagi celah yang dapat dieksploitasi dari jarak jauh, tidak memerlukan autentikasi yang rumit, dan sepenuhnya membobol kerahasiaan, integritas, serta ketersediaan.
Imbauan yang sama mencatat bahwa eksploitasi yang berhasil membuka jauh lebih banyak daripada kode: kredensial, rahasia, basis data, repositori yang di-mount, token OAuth, dan layanan internal yang dapat dijangkau server. Penyerang tidak pergi membawa berkas teks. Mereka mewarisi posisi server di dalam jaringan Anda.
Mengapa server kode lebih berbahaya daripada situs web Anda
Situs web Anda menyimpan apa yang ingin Anda tunjukkan kepada orang lain. Server kode Anda menyimpan apa yang menjalankan segala hal lainnya. Dalam praktiknya, sistem internal semacam ini cenderung memusatkan:
- Kode sumber sistem Anda, termasuk logika harga, aturan diskon, dan pemeriksaan izin.
- Berkas konfigurasi dan variabel lingkungan yang memuat kata sandi basis data, kunci gateway pembayaran, dan kredensial API pemerintah.
- Kunci deployment yang dapat mengirim pembaruan langsung ke server produksi.
- Jangkauan jaringan internal ke mesin-mesin lain yang sama sekali tidak terekspos ke internet.
Kombinasi itu berarti server kode yang dibobol bukanlah insiden yang terisolasi, melainkan landasan peluncuran. Penyerang yang memegang kunci deployment Anda tidak perlu membobol sistem akuntansi Anda. Mereka cukup mengirimkan pembaruan yang mereka tandatangani sendiri ke sistem itu.
Celah sesungguhnya: sistem yang tidak dimiliki siapa pun
Di sebagian besar perusahaan menengah, daftar sistem yang menjalani tinjauan keamanan adalah daftar yang diketahui manajer: situs web, aplikasi, ERP, email. Server repositori, runner continuous integration, dasbor pemantauan internal, dan server berkas sementara yang dipasang seseorang dua tahun lalu untuk uji coba singkat adalah sistem tanpa penanggung jawab yang ditetapkan. Tidak ada yang bertanggung jawab menerapkan patch padanya, tidak ada yang tahu siapa yang memiliki akses ke sana, dan sistem itu tidak tercantum di inventaris mana pun.
Di situlah tepatnya para penyerang beroperasi. Alat yang tidak dimiliki siapa pun adalah alat yang tidak diperbarui siapa pun, dan alat yang tidak diperbarui siapa pun tetap terekspos selama berbulan-bulan setelah perbaikan dirilis. Lihat linimasanya di sini: perbaikan dirilis di versi 1.27.1, dan pencantumannya sebagai kerentanan yang aktif dieksploitasi baru terjadi beberapa minggu kemudian. Jeda antara tersedianya perbaikan dan diterapkannya perbaikan adalah ruang tempat pembobolan hidup.
Apa yang perlu dilakukan minggu ini
Menutup pintu ini tidak memerlukan program keamanan yang besar. Yang diperlukan adalah empat langkah yang dapat diselesaikan tim teknis atau vendor Anda dalam hitungan hari:
- Mintalah inventaris tertulis dari setiap sistem internal yang berjalan di server Anda, masing-masing dengan penanggung jawab yang disebutkan namanya, seorang individu, bukan sebuah departemen.
- Tanyakan nomor versi setiap alat sumber terbuka yang Anda jalankan dan kapan terakhir kali diperbarui. Jika Anda menjalankan Gitea, memastikan bahwa Anda berada di versi 1.27.1 atau yang lebih baru adalah pertanyaan dua menit.
- Matikan pendaftaran mandiri di setiap alat internal. Tidak ada alasan operasional bagi halaman pendaftaran di server kode untuk terbuka ke internet.
- Ajukan satu pertanyaan yang tidak nyaman: jika rahasia di server ini dicuri hari ini, berapa hari yang dibutuhkan untuk mengganti semuanya? Jika tidak ada jawaban, jawabannya adalah Anda tidak bisa.
Tambahkan dimensi regulasi pada hal itu. Sistem internal perusahaan biasanya memuat data pribadi milik pelanggan atau karyawan, dan melindungi data tersebut adalah kewajiban hukum organisasi berdasarkan Undang-Undang Pelindungan Data Pribadi (PDPL). Pembobolan yang bermula di alat pengembang dan berakhir di basis data pelanggan Anda tidak diperlakukan sebagai urusan teknis internal.
Pandangan Origami
Kami membaca insiden ini sebagai penegasan atas hal yang kami ulangi di setiap proyek: keamanan bukanlah fitur yang ditambahkan pada produk jadi, melainkan sifat dari cara produk itu dibangun. Perbedaan antara perusahaan yang bertahan dan perusahaan yang tumbang bukanlah berapa banyak alat perlindungan yang dibelinya, melainkan apakah ia tahu apa yang sedang dijalankannya, siapa penanggung jawabnya, dan kapan terakhir kali diperbarui.
Itulah sebabnya kami memperlakukan inventaris sistem, penunjukan penanggung jawab, dan kebijakan patch sebagai bagian dari penyerahan pekerjaan, bukan tambahan opsional. Perusahaan yang dapat menjawab dalam satu jam versi mana dari setiap alat yang dijalankannya memiliki keunggulan operasional yang nyata, karena ketika pengumuman seperti yang muncul minggu ini datang, ia langsung tahu apakah pengumuman itu berlaku baginya, alih-alih menghabiskan seminggu untuk mencari tahu.
Kesimpulan
Celah yang mendorong regulator menetapkan tenggat yang tegas tidak berada di antarmuka yang berhadapan dengan pelanggan. Celah itu ada di alat internal yang dianggap tersembunyi dari pandangan. Itulah pelajarannya: sistem yang tidak pernah muncul dalam presentasi adalah sistem yang memegang kunci. Mulailah dengan inventaris, berikan setiap sistem seorang penanggung jawab, dan jadikan patch sebagai rutinitas, bukan reaksi terhadap sebuah berita utama. Perusahaan yang selamat dari insiden semacam ini tidak lebih pintar. Mereka hanya tahu apa yang mereka miliki.
Sumber
- CISA — Katalog Kerentanan yang Diketahui Telah Dieksploitasi (CVE-2026-60004 ditambahkan pada 25 Agustus 2026, tenggat 28 Agustus 2026)
- Imbauan keamanan resmi Gitea (GHSA-rcr6-4jqh-j84m)
- NVD — skor dasar CVSS 3.1 sebesar 9.8
- Otoritas Data dan Kecerdasan Buatan Saudi (SDAIA) — Undang-Undang Pelindungan Data Pribadi (PDPL)
Tanya jawab
Kami tidak menggunakan Gitea. Apakah berita ini berlaku bagi kami?
Ya, karena masalahnya bukan nama alatnya, melainkan kategori alatnya. Setiap sistem internal yang berjalan di server Anda tanpa penanggung jawab yang ditetapkan dan tanpa jadwal patch menghadapi skenario yang sama, baik itu server repositori, runner CI, dasbor pemantauan, maupun alat transfer berkas. Pertanyaan praktisnya bukan apakah Anda menggunakan Gitea, melainkan berapa banyak alat internal yang Anda jalankan yang versinya saat ini tidak dapat Anda sebutkan.
Bagaimana saya tahu apakah server kode kami terdampak?
Mintalah nomor versi saat ini kepada tim teknis Anda. Versi 1.17 hingga 1.27.0 terdampak dan perbaikannya ada di versi 1.27.1 atau yang lebih baru. Jika server terdampak dan terekspos ke internet selama periode apa pun, menerapkan patch saja tidak cukup: server harus diperiksa untuk mencari tanda-tanda pembobolan dan setiap kunci serta rahasia yang tersimpan di dalamnya harus diganti, karena penyerang mungkin telah menyalinnya sebelum perbaikan diterapkan.
Apakah memindahkan kode kami ke layanan cloud menyelesaikan masalah ini?
Langkah itu mengalihkan sebagian beban patch ke penyedia, yang merupakan keuntungan nyata bagi tim kecil. Namun, itu tidak menghapus tanggung jawab Anda atas kontrol akses, siapa yang memegang izin tulis, dan rahasia yang tersimpan dalam konfigurasi Anda. Hosting cloud mempersempit ruang kesalahan alih-alih menghilangkannya, dan pilihan antara hosting sendiri dan cloud sebaiknya didasarkan pada apakah tim Anda dapat berkomitmen pada jadwal patch yang rutin.
Apa hal tercepat yang bisa dilakukan pemilik bisnis hari ini?
Meminta inventaris tertulis dari setiap sistem internal yang berjalan di server perusahaan, dengan penanggung jawab yang disebutkan namanya, nomor versi, dan tanggal pembaruan terakhir untuk masing-masing. Satu dokumen itu biasanya memunculkan sistem yang sudah dilupakan semua orang, dan tanpanya setiap pengumuman kerentanan hanyalah berita yang tidak bisa Anda pastikan berlaku bagi Anda atau tidak.
Ikuti Origami di Google
Jadikan Origami sumber pilihan dan artikel kami akan muncul lebih dulu untuk Anda di Google Penelusuran dan Berita Utama.








