Kalau tim Anda menyimpan image di Docker Hub dan mengotomatiskan build lewat CI/CD, ada kabar keamanan yang wajib dibaca minggu ini. Docker mengungkap kerentanan berkode CVE-2026-105445 yang membuat personal access token (PAT) bisa berpindah tangan ke akun lain tanpa sepengetahuan pemiliknya. Docker menilai ini sebagai risiko rantai pasok perangkat lunak (software supply chain) level kritis, karena token tersebut bisa dipakai mem-publish image atas nama orang lain.

Kabar baiknya: Docker sudah menambal celah ini, memeriksa kurang lebih 304.000 proses push yang melibatkan token terdampak, dan menyatakan tidak menemukan bukti eksploitasi. Kabar yang tetap perlu diwaspadai: cara kerja celah ini menyentuh kebiasaan lama banyak tim developer, yaitu memakai token pribadi untuk otomasi organisasi.

Apa yang sebenarnya terjadi

Docker Hub sejak lama tidak punya fitur memindahkan repositori antar akun. Jalur resminya adalah konversi akun pribadi menjadi organisasi, sehingga alice/app tetap bisa di-pull tanpa memutus referensi di mana-mana. Saat konversi, pengguna menunjuk satu akun Docker Hub sebagai pemilik (owner) organisasi baru itu.

Masalahnya, mulai 26 Agustus 2024 proses konversi itu ikut memindahkan PAT milik akun yang dikonversi ke pemilik baru, dengan cara mengubah catatan kepemilikan token dan tanpa merotasi atau mencabut rahasia tokennya. Pemilik baru pun tidak diminta konfirmasi dan tidak diberi notifikasi. Kombinasi dua celah itulah yang membuka peluang penyalahgunaan.

Skenario serangan: empat langkah sederhana

1. Penyerang membuat akun Docker Hub dan membuat satu PAT di akun itu.
2. Penyerang mengonversi akun tersebut menjadi organisasi, lalu menunjuk akun korban sebagai owner.
3. PAT milik penyerang dipindahkan ke akun korban, tetapi penyerang masih memegang rahasia tokennya, dan token itu kini aktif dengan scope milik korban.
4. Token tersebut kini terautentikasi ke registry sebagai korban.

Seberapa besar dampaknya?

Sesuai cakupan token, PAT yang dipindahkan bertindak sebagai pengguna sasaran di tingkat registry. Artinya penyerang berpotensi pull, push, hingga menghapus image di repositori korban dan di organisasi tempat korban punya akses. Karena itu termasuk bisa menerbitkan image atas nama yang sah, Docker menilainya sebagai risiko rantai pasok kritis.

Yang tidak bisa dilakukan celah ini: mengakses antarmuka web Docker Hub, mengubah kata sandi, alamat email, atau pengaturan dua faktor, maupun mengambil alih akun sepenuhnya. Jendela paparannya berlangsung dari 26 Agustus 2024 pukul 20.33 UTC sampai perbaikan dipasang pada 30 September 2026 sekitar pukul 19.10 UTC, kurang dari empat jam setelah laporan masuk. Untuk token yang terlanjur berpindah, Docker menonaktifkannya secara paksa pada 8 Oktober 2026, dan pengguna yang benar-benar terdampak sudah dikirimi email berjudul "Docker Hub Vulnerability Identified & Resolved" pada 2 Oktober.

Cek lima menit untuk tim Anda

1. Masuk ke Docker Hub, buka Account settings → Personal access tokens.
2. Cabut (revoke) setiap token yang tidak Anda kenali atau sudah tidak dipakai. Perhatikan kolom deskripsi dan tanggal pembuatannya.
3. Untuk otomasi yang sebenarnya milik organisasi, ganti PAT pribadi dengan organization access token. Docker sendiri merekomendasikan ini.
4. Rotasi token di pipeline CI/CD Anda (GitHub Actions Secrets, GitLab CI/CD Variables, Jenkins Credentials) dan beri scope seminimal mungkin: kalau hanya perlu push, jangan pakai izin hapus atau akses admin.
5. Aktifkan dua faktor pada akun pemilik image, dan pantau audit log organisasi untuk aktivitas push yang tidak dikenal.

Contoh: login CI dengan token organisasi

Hindari menempelkan password atau token langsung di berkas Dockerfile atau skrip. Simpan sebagai secret dan pakai variabel lingkungan:

# GitHub Actions: simpan sebagai secrets.DOCKERHUB_USERNAME dan secrets.DOCKERHUB_TOKEN
- name: Login ke Docker Hub
  run: echo "${{ secrets.DOCKERHUB_TOKEN }}" | docker login -u "${{ secrets.DOCKERHUB_USERNAME }}" --password-stdin

- name: Build dan push image
  run: |
    docker build -t "${{ secrets.DOCKERHUB_USERNAME }}/aplikasi-desa:latest" .
    docker push "${{ secrets.DOCKERHUB_USERNAME }}/aplikasi-desa:latest"

Pelajaran untuk pengelola TI

• Otomasi jangan bergantung pada akun pribadi. Kalau satu orang resign atau tokennya bocor, seluruh pipeline organisasi ikut berisiko. Gunakan token milik organisasi dan akun layanan (service account).
• Rotasi token secara berkala. Token yang tidak pernah diganti adalah pintu yang tidak pernah dikunci ulang.
• Terapkan hak akses minimum. Pisahkan token untuk build, push, dan operasi administratif, sekaligus pisahkan repositori produksi dan pengembangan.
• Catat siapa memegang akses apa. Docker kini mulai mencatat riwayat perubahan kepemilikan token dan mewajibkan konfirmasi sebelum seseorang ditunjuk sebagai owner. Kebiasaan bagus ini bisa ditiru di internal tim.

Untuk instansi dan UMKM yang aplikasinya dibangun oleh vendor luar, langkah paling praktis adalah memastikan semua token akses image registry terdokumentasi, terikat ke akun lembaga (bukan akun pribadi vendor), dan bisa dicabut sewaktu-waktu tanpa mengganggu layanan produksi.

Sumber: Docker Blog — Docker Hub Security Advisory CVE-2026-105445 (12 Oktober 2026); ghostpat.com, tulisan teknis peneliti Peter Molnar dan Krisztian Hozak (mptrdev.com).