CVE-2026-112816 LXD dan Incus: Celah Sertifikat Skor 10 Membuka API Tanpa Login, Update ke 6.10.1 atau 5.21.9

Jawaban langsung: CVE-2026-112816 membuat APIAPIPintu resmi yang dipakai 2 sistem untuk saling mengirim data, tanpa orang menyalin data secara manual.Buka glosarium HTTPS LXD dan MicroCloud menerima klien palsu tanpa login. Canonical memberi skor CVSS 10.0. Incus punya celah yang sama, GHSA-xg75-xf37-cph9. Hari ini, cek versi, cek apakah port 8443 terbuka, lalu update ke LXD 6.10.1, 5.21.9, 5.0.11, 4.0.15, atau Incus 7.6.0.

Menurut advisory Canonical, penyerang yang hanya punya sertifikat publik klien tepercaya bisa dipercaya oleh daemon. Bergantung pada hak korban, dampaknya bisa sampai akses root di host.

Kondisi utama: Celah ini hanya bisa dipakai lewat API HTTPS. Bawaan LXD hanya membuka socket lokal, tetapi cluster, MicroCloud, LXD UI, dan klien jarak jauh selalu membuka API itu. Batas: Artikel ini tidak memuat cara membuat rantai sertifikat atau urutan serangan.

Kami membaca advisory Canonical, advisory Incus GHSA-xg75-xf37-cph9, catatan CVE-2026-112816, halaman rilis LXD, catatan rilis Incus 7.6, data kanal Snap Store, dan pelacak keamanan Debian pada 1 November 2026, pukul 13.35 sampai 14.30 WIB. Kami menguji 4 skrip di container podman Debian 13 dengan Incus 6.0.4, Incus 7.6, dan LXD 5.0.2. Snap LXD tidak bisa jalan di container, jadi langkah snap kami tulis dari dokumentasi Canonical.

Masalah: API HTTPS menerima klien palsu

Server LXD atau Incus yang membuka API ke jaringan bisa dikuasai oleh orang yang tidak punya kunci klien.

LXD dan Incus memakai sertifikat TLS klien sebagai login. Klien yang sertifikatnya ada di trust store mendapat akses ke instance, VM, storage, dan cluster. Celah ini merusak pemeriksaan itu, jadi trust store tidak lagi melindungi server.

advisory Incus GHSA-xg75-xf37-cph9 menulis bahwa celah ini ada sejak rilis pertama. Canonical menulis bahwa laporan datang dari proyek Incus, lalu dikonfirmasi berlaku untuk LXD. Advisory Canonical terbit 28 Oktober 2026, dan advisory Incus terbit 29 Oktober 2026.

Data Snap Store pada 1 November 2026 menunjukkan satu hal penting. Kanal 6/stable menerima 6.10.1 pada 29 Oktober. Kanal LTS 5.21/stable, 5.0/stable, dan 4.0/stable baru menerima versi aman pada 1 November 2026, pukul 05.10 UTC.

Cara kerja: 1 celah sertifikat, akses penuh

Daemon membandingkan sertifikat yang salah dengan daftar klien tepercaya.

Bagian ini memakai ringkasan resmi. Tujuannya membantu Anda memilih langkah yang tepat, bukan menjelaskan cara menyerang.

Ringkasan dari Canonical dan Incus

Menurut advisory Incus GHSA-xg75-xf37-cph9, listener HTTPS meminta sertifikat klien tanpa memverifikasinya. Handshake TLS hanya membuktikan klien memegang kunci sertifikat pertama di rantai. Pemeriksaan login membandingkan setiap sertifikat di rantai dengan trust store, jadi klien bisa diterima sebagai klien tepercaya lain.

Menurut advisory Canonical, celah ini juga ada di MicroCloud saat anggota baru bergabung ke cluster. Incus menambah bahwa koneksi agentAgent AIProgram AI yang mengerjakan langkah pekerjaan sendiri, misalnya membaca pesan, menyiapkan balasan, lalu mencatat hasilnya.Buka glosarium antara host dan VM juga terdampak. Kelas celahnya CWE-295, verifikasi sertifikat yang tidak tepat.

Skor dari setiap sumber

Skor berbeda per versi CVSS, jadi tulis skor bersama sumbernya.

ID	Produk	Skor	Status per 1 November 2026
CVE-2026-112816	LXD, MicroCloud	CVSS 4.0 10.0, dari Canonical sebagai CNA	Terbit 30 Oktober. Belum ada di CISA KEV
GHSA-xg75-xf37-cph9	Incus	CVSS 3.1 10.0, dari tim Incus	ID CVE belum terbit
CISA ADP (SSVC)	LXD	Eksploitasi: none. Bisa diotomasi: yes. Dampak teknis: total	Update 31 Oktober

Status eksploitasi per 1 November 2026

Kami tidak menemukan laporan serangan, kode eksploit publik di sumber resmi, atau entri CISA KEV. CISA ADP menulis bahwa celah ini bisa diotomasi dan dampak teknisnya total.

Analisa Rama Digital: celah tanpa login dengan sertifikat server yang terlihat di setiap handshake TLS adalah target mudah untuk pemindai otomatis. Jangan tunggu status KEV. Update server yang API-nya terbuka hari ini.

Siapa yang paling berisiko

Risiko bergantung pada siapa yang bisa menjangkau port API, bukan hanya pada versi.

Tabel ini merangkum advisory Canonical, advisory Incus GHSA-xg75-xf37-cph9, dan dokumentasi LXD tentang akses jaringan.

Kondisi server	Risiko	Alasan
core.https_address di IP publik atau :8443	Tertinggi	Siapa pun di internet bisa menjangkau API
Cluster LXD atau MicroCloud	Tinggi	Anggota cluster selalu bicara lewat API HTTPS
API terbuka ke LAN kantor atau VPN	Tinggi	Satu laptop yang disusupi di jaringan bisa menjangkau API
Memakai LXD UI atau klien lxc remote	Periksa	Dokumentasi LXD: UI butuh LXD terbuka ke jaringan
Incus LTS atau paket Debian	Periksa	Perbaikan belum ada per 1 November 2026
Hanya socket lokal, bawaan lxd init	Rendah	Dokumentasi LXD: bawaan hanya untuk user lokal lewat socket Unix

Host LXD atau Incus sering menjalankan banyak server pelanggan sekaligus. Jadi satu host yang dikuasai membuka semua instance di atasnya. Pola risiko yang sama ada di celah kernel PwnEscape di host KVM: host virtualisasi adalah aset dengan prioritas patch tertinggi.

Versi rentan dan versi aman

Pakai tabel produk dan kanal ini, karena LXD memakai kanal snap dan Incus memakai rilis bulanan dan LTS.

Produk dan kanal	Status per 1 November 2026	Naik ke
LXD 6/stable dan latest/stable	Rentan di bawah 6.10.1	6.10.1, di kanal stable sejak 29 Oktober
LXD 5.21/stable (LTS)	Rentan di bawah 5.21.9	5.21.9, di kanal stable sejak 1 November
LXD 5.0/stable (LTS)	Rentan di bawah 5.0.11	5.0.11, di kanal stable sejak 1 November
LXD 4.0/stable	Rentan di bawah 4.0.15	4.0.15, di kanal stable sejak 1 November
MicroCloud 3/stable dan 2/stable	Rentan di bawah 3.4.1 dan 2.1.5	3.4.1 dan 2.1.5, sejak 29 Oktober
Incus 7.x rilis bulanan	Rentan di bawah 7.6.0	7.6.0, rilis 30 Oktober
Incus 7.0 LTS dan 6.0 LTS	Rentan, rilis titik dengan perbaikan belum ada	Langkah 4, lalu rilis LTS berikutnya
Paket Debian lxd 5.0.2 dan incus 6.0.4	Patch Debian belum ada	Langkah 4, lalu update Debian atau pindah ke snap atau Zabbly

Data LXD dan MicroCloud berasal dari advisory Canonical dan data kanal Snap Store pada 1 November 2026. Data Incus berasal dari advisory Incus GHSA-xg75-xf37-cph9 dan catatan rilis Incus 7.6. Advisory Incus hanya menulis versi di bawah 7.6.0 sebagai rentan.

Untuk Incus 7.0 LTS dan 6.0 LTS, tag terakhir adalah v7.0.2 (16 Oktober) dan v6.0.7. Keduanya terbit sebelum perbaikan. Menurut pelacak keamanan Debian, Debian sid sudah memasang patch di incus 7.0.2-3, tetapi trixie dan forky masih rentan. Kami tidak mengarang versi LTS yang aman.

Prasyarat sebelum mulai

• Akses sudo ke setiap server LXD atau Incus, termasuk semua anggota cluster.
• Daftar IP klien sah: laptop admin, server CI, LXD UI, dan anggota cluster.
• Jendela maintenance. Refresh snap memulai ulang daemon, dan API berhenti sebentar.
• Akses log firewall atau reverse proxy di depan server, bila ada.
• Paket nftables untuk langkah 4. Paket ini ada di Ubuntu dan Debian modern.

Langkah 1: Cek versi LXD, MicroCloud, atau Incus

Simpan skrip ini sebagai cek-versi-lxd.sh. Skrip membaca versi dari snap, paket, atau perintah incus, lalu membandingkannya dengan tabel versi aman.

#!/usr/bin/env bash
# Cek versi LXD, MicroCloud, dan Incus terhadap CVE-2026-112816 (LXD) dan GHSA-xg75-xf37-cph9 (Incus).
# Data: advisory Canonical 28 Oktober 2026 dan advisory Incus 29 Oktober 2026.
# Pakai: sudo bash cek-versi-lxd.sh              (baca versi dari mesin ini)
#        bash cek-versi-lxd.sh lxd 5.21.8 incus 7.5.1   (cek versi yang Anda ketik)

lebih_baru() { [ "$(printf '%s\n%s\n' "$1" "$2" | sort -V | head -1)" = "$2" ]; }   # $1 >= $2

nilai() {
  local produk="$1" v="${2%% *}" aman=""
  v="${v%%-*}"
  [[ $v =~ ^[0-9]+\.[0-9]+$ ]] && v="$v.0"   # 7.6 sama dengan 7.6.0
  case "$produk:$v" in
    lxd:6.*)        aman=6.10.1 ;;
    lxd:5.21.*)     aman=5.21.9 ;;
    lxd:5.0.*)      aman=5.0.11 ;;
    lxd:4.0.*)      aman=4.0.15 ;;
    microcloud:3.*) aman=3.4.1 ;;
    microcloud:2.*) aman=2.1.5 ;;
    incus:6.0.*|incus:7.0.*)
      printf '%-11s %-9s RENTAN. Rilis LTS dengan perbaikan belum ada. Batasi port API (langkah 4).\n' "$produk" "$v"
      return ;;
    incus:*)        aman=7.6.0 ;;
  esac
  if [ -z "$aman" ]; then
    printf '%-11s %-9s TIDAK DIKENAL. Cabang ini tidak didukung lagi, pindah ke cabang LTS.\n' "$produk" "$v"
  elif lebih_baru "$v" "$aman"; then
    printf '%-11s %-9s AMAN (perbaikan ada sejak %s)\n' "$produk" "$v" "$aman"
  else
    printf '%-11s %-9s RENTAN -> naik ke %s atau lebih baru\n' "$produk" "$v" "$aman"
  fi
}

if (( $# > 0 )); then
  while (( $# > 1 )); do nilai "$1" "$2"; shift 2; done
  exit 0
fi

ketemu=0
if command -v snap >/dev/null 2>&1; then
  for p in lxd microcloud; do
    v=$(snap list "$p" 2>/dev/null | awk 'NR==2 {print $2}')
    [ -n "$v" ] && { nilai "$p" "$v"; ketemu=1; }
  done
fi
if command -v lxd >/dev/null 2>&1 && ! snap list lxd >/dev/null 2>&1; then
  nilai lxd "$(lxd --version)"; ketemu=1
fi
if command -v incus >/dev/null 2>&1; then
  v=$(incus version 2>/dev/null | awk -F': ' '/^Server version/ {print $2}')
  [ -z "$v" ] || [ "$v" = unreachable ] && v=$(incus version 2>/dev/null | awk -F': ' '/^Client version/ {print $2}')
  nilai incus "$v"; ketemu=1
fi
for p in lxd incus; do
  d=$(dpkg-query -W -f='${Version}' "$p" 2>/dev/null)
  [ -n "$d" ] && echo "Paket: $p $d. Untuk paket distro, cek juga pelacak keamanan distro."
done
(( ketemu )) || echo "LXD, MicroCloud, atau Incus tidak ditemukan di mesin ini."
exit 0

# Di server: baca versi dari snap, paket, atau perintah incus
sudo bash cek-versi-lxd.sh
# Di laptop: cek versi yang Anda salin dari server lain
bash cek-versi-lxd.sh lxd 5.21.8 microcloud 2.1.4 incus 7.5.1

Cek hasil: "RENTAN" berarti lanjut ke langkah 2 dan 3 hari ini. "RENTAN. Rilis LTS dengan perbaikan belum ada" berarti langkah 4 wajib sampai rilis keluar. "AMAN" tetap berarti jalankan langkah 5, karena celah ini sudah ada sejak lama.

Langkah 2: Cek apakah API HTTPS terbuka ke jaringan

Celah ini hanya bisa dipakai lewat API HTTPS, jadi langkah ini menentukan seberapa cepat Anda harus bergerak.

Simpan skrip ini sebagai cek-paparan-lxd.sh. Skrip membaca core.https_address dan cluster.https_address, lalu menampilkan soket di port 8443.

#!/usr/bin/env bash
# Cek apakah API HTTPS LXD atau Incus terbuka ke jaringan. Celah CVE-2026-112816 hanya bisa dipakai lewat API ini.
# Pakai: sudo bash cek-paparan-lxd.sh

for c in lxc incus; do
  command -v "$c" >/dev/null 2>&1 || continue
  if ! "$c" info >/dev/null 2>&1; then
    echo "$c: daemon tidak bisa dihubungi. Jalankan skrip dengan sudo."
    continue
  fi
  for kunci in core.https_address cluster.https_address; do
    alamat=$("$c" config get "$kunci" 2>/dev/null)
    if [ -z "$alamat" ]; then
      printf '%-6s %-22s kosong\n' "$c" "$kunci"
    elif [[ $alamat == 127.* || $alamat == "[::1]"* || $alamat == localhost* ]]; then
      printf '%-6s %-22s %-18s hanya lokal\n' "$c" "$kunci" "$alamat"
    else
      printf '%-6s %-22s %-18s TERBUKA KE JARINGAN\n' "$c" "$kunci" "$alamat"
    fi
  done
done
echo "Soket yang mendengar di port 8443 (port bawaan API):"
ss -ltnH '( sport = :8443 )' | awk '{print "  " $4}'

Lalu uji dari luar. Perintah ini hanya meminta informasi publik server di /1.0.

# Jalankan dari jaringan lain, misalnya hotspot ponsel. Ganti alamat contoh.
curl -sk -o /dev/null -w '%{http_code}\n' -m 5 https://ALAMAT-SERVER:8443/1.0
# 200 = API terjangkau dari jaringan itu. 000 = tidak terjangkau.

Cek hasil: "kosong" pada kedua kunci berarti risiko rendah. "hanya lokal" berarti API hanya untuk mesin itu. "TERBUKA KE JARINGAN" dan kode 200 dari jaringan lain berarti update di langkah 3 hari ini, dan pasang langkah 4 sampai update selesai.

Langkah 3: Update ke versi aman

Hanya update yang menutup celah. Advisory Canonical meminta semua pengguna naik ke versi terbaru di kanalnya.

# LXD dan MicroCloud dari snap. Ulangi di setiap anggota cluster.
snap list lxd microcloud
sudo snap refresh lxd
sudo snap refresh microcloud
# Bila snap ditahan dari refresh otomatis, lepaskan tahanan, lalu refresh lagi.
sudo snap refresh --unhold lxd
sudo snap refresh lxd

# Incus dari repo Zabbly
sudo apt update && sudo apt install --only-upgrade incus

# Cek lagi sesudah update
sudo bash cek-versi-lxd.sh

1. Refresh semua anggota cluster dalam 1 jendela kerja. Dokumentasi cluster LXD meminta semua anggota memakai versi yang sama. Jangan upgrade bila ada anggota yang offline.
2. Cek apakah snap ditahan dengan snap refresh --list dan snap info lxd. Snap yang ditahan tidak menerima versi aman.
3. Untuk Incus dari repo resmi Zabbly, naik ke 7.6.0. Untuk Incus LTS, pasang langkah 4 dan pantau rilis titik berikutnya.
4. Untuk paket Debian lxd atau incus, pantau pelacak keamanan Debian. Bila Anda butuh perbaikan hari ini, rencanakan pindah ke snap LXD atau Incus dari Zabbly.
5. Jalankan lagi cek-versi-lxd.sh di setiap mesin.

Cek hasil: skrip mencetak "AMAN" untuk setiap mesin, termasuk anggota cluster dan server cadangan.

Langkah 4: Batasi port API sampai update selesai

Langkah ini mengurangi siapa yang bisa menjangkau API, tetapi tidak menutup celah.

advisory Incus GHSA-xg75-xf37-cph9 menulis 1 workaround: batasi akses jaringan ke listener HTTPS hanya untuk host tepercaya. Tidak ada workaround lewat konfigurasi. Analisa Rama Digital: kami mengubah workaround itu menjadi aturan nftables dan opsi mematikan API. Kondisi: update belum bisa jalan hari ini. Batas: klien sah yang disusupi tetap bisa menjangkau API.

4a. Izinkan port 8443 hanya dari IP klien sah

Simpan aturan ini sebagai lxd-8443.nft. Ganti IP contoh dengan IP klien sah dan semua anggota cluster. Bila Anda memakai port lain, ganti angka 8443.

#!/usr/sbin/nft -f
# Izinkan port API LXD atau Incus (8443) hanya dari IP klien sah dan anggota cluster.
# Ganti IP contoh dengan IP Anda. Pasang: sudo nft -f lxd-8443.nft
table inet lxd_api
delete table inet lxd_api
table inet lxd_api {
  set klien_sah {
    type ipv4_addr
    elements = { 198.51.100.10, 198.51.100.11 }
  }
  chain input {
    type filter hook input priority -10; policy accept;
    tcp dport 8443 ip saddr @klien_sah accept
    tcp dport 8443 counter drop
  }
}

sudo nft -f lxd-8443.nft
sudo nft list chain inet lxd_api input
# Uji dari IP klien sah (harus 200) dan dari jaringan lain (harus 000)
curl -sk -o /dev/null -w '%{http_code}\n' -m 5 https://ALAMAT-SERVER:8443/1.0
# Hapus aturan sesudah update selesai, bila Anda tidak mau menyimpannya
sudo nft delete table inet lxd_api

Aturan ini tidak tersimpan sesudah reboot. Untuk aturan tetap, tambahkan isinya ke /etc/nftables.conf. Bila Anda memakai firewall cloud atau security group, buat aturan yang sama di sana.

4b. Matikan API jaringan bila tidak dipakai

Server tunggal yang hanya dikelola dari mesin itu sendiri tidak butuh API jaringan. Langkah ini mematikan LXD UI dan klien jarak jauh. Jangan pakai langkah ini di anggota cluster.

# LXD
sudo lxc config unset core.https_address
# Incus
sudo incus config unset core.https_address
# Cek: alamat kosong dan tidak ada soket di port 8443
sudo bash cek-paparan-lxd.sh

Kami menguji perintah Incus di container. Sesudah perintah itu, skrip paparan menulis "kosong" dan tidak ada soket di port 8443.

Cek hasil: klien sah mendapat 200, IP lain mendapat 000, dan counter drop naik. Atau kedua alamat kosong dan port 8443 tidak mendengar.

Langkah 5: Cari tanda server sudah disentuh

Penyerang tampil sebagai klien sah, jadi bandingkan isi server dengan catatan Anda.

Simpan skrip ini sebagai cek-tanda-lxd.sh. Skrip menampilkan sertifikat tepercaya, instance di semua project, operasi terbaru, dan koneksi aktif ke port 8443 per IP.

#!/usr/bin/env bash
# Kumpulkan data untuk mencari tanda akses asing ke LXD atau Incus. Bandingkan hasilnya dengan catatan Anda.
# Pakai: sudo bash cek-tanda-lxd.sh lxc "198.51.100.10,198.51.100.11"
#        (lxc untuk LXD, incus untuk Incus; argumen kedua = IP klien sah, dipisah koma)
C="${1:-lxc}"
IZIN=",${2:-},"

echo "== 1. Sertifikat tepercaya. Hapus yang tidak Anda kenal."
"$C" config trust list --format csv
echo "== 2. Instance di semua project. Cari yang tidak Anda buat."
"$C" list --all-projects --format csv -c ens
echo "== 3. Operasi terbaru."
"$C" operation list --format csv
echo "== 4. Koneksi aktif ke port 8443 per IP."
ss -tnH state established '( sport = :8443 )' | awk '{print $4}' \
  | sed -E 's/^\[?(::ffff:)?//; s/\]?:[0-9]+$//' | sort | uniq -c \
  | while read -r jumlah ip; do
      if [[ $IZIN == *",$ip,"* ]]; then status="klien sah"; else status="TIDAK DIKENAL"; fi
      printf '   %-16s %3s koneksi  %s\n' "$ip" "$jumlah" "$status"
    done

# LXD: argumen pertama lxc. Incus: argumen pertama incus.
sudo bash cek-tanda-lxd.sh lxc "198.51.100.10,198.51.100.11"
# Cek tambahan di cluster
sudo lxc cluster list
sudo lxc cluster list-tokens
# Cari instance dengan hak istimewa atau mount dari host
sudo lxc list --all-projects -c n,e -f csv | while IFS=, read -r n p; do
  sudo lxc config show "$n" --project "$p" --expanded | grep -E 'security.privileged: "true"|source: /$' && echo "  -> $p/$n"
done

Lalu periksa host. Cari proses, user, atau kunci SSH baru, dan lonjakan CPU, disk, atau trafik keluar. Baca juga log firewall atau reverse proxy untuk akses ke port 8443 dari IP asing sejak 28 Oktober atau lebih awal.

Cek hasil: semua sertifikat, instance, dan anggota cluster Anda kenal, dan semua koneksi berasal dari klien sah. Bila ada 1 tanda saja, tutup port 8443 dari semua IP, lalu update. Simpan log dan daftar sertifikat sebagai bukti. Hapus sertifikat asing, buat ulang sertifikat klien sah, lalu bangun ulang instance atau host yang berubah dari backup bersih.

Bila instance menyimpan data pelanggan, UU 27/2022 tentang Pelindungan Data Pribadi mewajibkan pemberitahuan tertulis paling lambat 3 kali 24 jam sesudah kebocoran data pribadi. Baca juga panduan security, privacy, dan UU PDP untuk perusahaan.

Contoh: 1 siang respons untuk 3 server

Simulasi ini memakai data dummy. Nama server, waktu, dan hasil bukan data pelanggan.

Waktu (WIB)	Server dummy	Yang dicek	Hasil	Tindakan
13.00	host-a (LXD 5.21.8 snap, API :8443)	Langkah 1 dan 2	RENTAN, TERBUKA KE JARINGAN	Langkah 4a, lalu refresh
13.20	cluster-b (3 anggota, LXD 6.10.0)	Langkah 1	RENTAN di 3 anggota	Refresh ketiga anggota dalam 1 jendela
13.45	dev-c (Incus 6.0.4 Debian)	Langkah 1 dan 2	RENTAN, perbaikan LTS belum ada	Langkah 4b, API dimatikan
14.30	host-a	Langkah 5	1 sertifikat yang tidak dikenal tim	Respons insiden, hapus sertifikat, audit instance

Pelajaran dari simulasi: versi aman tidak membuktikan server bersih. Host-a sudah update, tetapi langkah 5 tetap menemukan tanda dari sebelum update.

Siapa yang memasang patch

Tanggung jawab patch berbeda per cara pemasangan, jadi tabel ini membantu Anda tahu siapa yang bergerak hari ini.

Cara pemasangan	Pemegang patch	Yang Anda kerjakan
Snap LXD atau MicroCloud di server sendiri	Canonical lewat kanal snap, tim Anda menjalankan refresh	Langkah 1 sampai 5
Incus dari repo Zabbly	Tim Incus, tim Anda menjalankan apt	Langkah 1 sampai 5
Paket Debian atau distro lain	Tim keamanan distro	Langkah 4, lalu pantau pelacak distro
VPS atau container dari penyedia hosting	Penyedia hosting	Minta bukti versi tertulis dan hasil langkah 5

Rekomendasi Rama Digital: perlakukan host virtualisasi seperti server domain. Update kernel host juga, misalnya untuk celah TCP kernel Linux CVE-2026-98432. Untuk standar pemeriksaan yang lebih luas, baca standar audit keamanan dan pentest.

Checklist hari ini

1. Buat daftar semua server LXD, MicroCloud, dan Incus, termasuk anggota cluster. Pemilik: tim infrastruktur. Bukti: daftar nama dan versi.
2. Cek versi dengan langkah 1. Pemilik: admin server. Bukti: output skrip.
3. Cek paparan API dengan langkah 2. Pemilik: admin server. Bukti: output skrip dan uji dari luar.
4. Pasang langkah 4 di setiap server dengan API terbuka yang belum bisa update hari ini. Pemilik: admin server. Bukti: uji 200 dan 000.
5. Update ke versi aman. Pemilik: admin server. Bukti: output skrip sesudah update.
6. Periksa tanda dengan langkah 5. Pemilik: admin server dan tim keamanan. Bukti: output skrip dan log firewall.
7. Catat IP klien sah dan simpan aturan port 8443 sebagai aturan tetap.

Tanya jawab

Server saya hanya memakai LXD lewat socket lokal. Apakah saya aman?

Risiko Anda rendah, karena celah ini hanya bisa dipakai lewat API HTTPS. Tetap update ke versi aman, karena konfigurasi bisa berubah dan versi lama juga memuat celah lain.

Kenapa snap LXD saya belum update otomatis?

Kanal LTS stable baru menerima versi aman pada 1 November 2026. Snap juga bisa ditahan oleh admin. Jalankan sudo snap refresh lxd, lalu cek lagi dengan langkah 1.

Apakah Incus terdampak?

Ya. Advisory Incus GHSA-xg75-xf37-cph9 menulis versi di bawah 7.6.0 sebagai rentan. Incus 7.0 LTS dan 6.0 LTS belum punya rilis titik dengan perbaikan per 1 November 2026.

Apakah celah ini sudah dipakai menyerang?

Per 1 November 2026, kami tidak menemukan laporan serangan, dan celah ini belum masuk CISA KEV. CISA ADP menulis bahwa celah ini bisa diotomasi.

Apakah aturan firewall bisa menggantikan update?

Tidak. Aturan itu mengurangi siapa yang bisa menjangkau API. Klien sah yang disusupi tetap bisa menjangkau API, jadi update tetap wajib.

Apakah instance saya mati saat refresh snap LXD?

Dokumentasi cluster LXD menulis bahwa instance yang berjalan tetap jalan saat anggota cluster menunggu anggota lain selesai upgrade. API anggota itu berhenti sampai semua anggota memakai versi yang sama. Pakai jendela maintenance.

Saya memakai VPS dari penyedia hosting. Apa yang saya kerjakan?

Bila Anda memasang LXD atau Incus sendiri di VPS, Anda yang memasang patch. Bila penyedia menjalankan LXD di bawah VPS Anda, minta bukti versi tertulis dari penyedia.

Langkah berikutnya

Batas yang tetap berlaku: aturan port di langkah 4 tidak menutup celah, dan update tidak menghapus sertifikat asing yang sudah masuk. Bila server Anda menunjukkan tanda di langkah 5, atau Anda butuh bantuan audit dan pemulihan, pakai Vibe Code Rescue. Untuk 1 kendala yang mendesak hari ini, jadwalkan sesi 30 menit.

Sumber

• advisory Canonical: produk terdampak, MicroCloud, dampak, versi aman per kanal, dan perintah refresh.
• advisory Incus GHSA-xg75-xf37-cph9: ringkasan teknis, dampak, skor CVSS 3.1 10.0, versi aman 7.6.0, dan workaround.
• catatan CVE-2026-112816: skor CVSS 4.0 10.0, CWE-295, dan penilaian CISA ADP.
• halaman rilis LXD dan catatan rilis Incus 7.6: tanggal rilis 6.10.1, 5.21.9, 5.0.11, 4.0.15, dan 7.6.0.
• dokumentasi LXD tentang akses jaringan: bawaan socket lokal, contoh core.https_address, dan kebutuhan LXD UI.
• Dokumentasi cluster LXD: versi sama di semua anggota dan status blocked saat upgrade.
• pelacak keamanan Debian: status paket incus di trixie, forky, dan sid.
• UU 27/2022 tentang Pelindungan Data Pribadi: kewajiban pemberitahuan kebocoran data pribadi.