Jawaban langsung: CVE-2026-19868 membuat SSL VPN SonicOS menerima login yang melewati SAML dan MFA. Celah ini hanya mengenai firewall yang memakai SAML untuk login SSL VPN. CISA memasukkan celah ini ke katalog KEV pada 6 November 2026. Hari ini, cek versi SonicOS, naik ke 7.3.4-7013 (Gen7) atau 8.2.3-8015 (Gen8), lalu cari login SSL VPN yang tidak lewat IdP.

Menurut advisory SonicWall SNWLID-2026-0014, user dengan kredensial sah untuk metode login lain bisa melewati kontrol SAML. MFA yang IdP minta lewat SAML ikut terlewati. SonicWall menulis bahwa tim PSIRT sudah memeriksa laporan bahwa celah ini dipakai menyerang.

Kondisi utama: Skor SonicWall untuk CVE-2026-19868 adalah 7.1, di bawah 9. Kami tetap menulis peringatan karena celah ini masuk KEV dan melewati login serta MFA. Batas: Artikel ini tidak memuat isi request, payload, atau urutan serangan.

Kami membaca advisory SonicWall SNWLID-2026-0014, catatan CVE-2026-19868, CISA KEV, catatan rilis SonicOS 7.3.4-7013, dan catatan rilis SonicOS 8.2.3-8015 pada 7 November 2026, pukul 06.35 sampai 06.57 WIB. Skrip di langkah 1 dan 5 kami jalankan di container podman dengan image resmi Debian pada tanggal yang sama. Kami tidak punya firewall SonicWall, jadi langkah di antarmuka web kami tulis dari dokumentasi SonicWall.

Masalah: SAML dan MFA tidak menjaga semua jalan masuk

Tim yang memasang SAML dan MFA untuk SSL VPN menganggap setiap login sudah lewat IdP. Celah ini mematahkan anggapan itu.

Banyak kantor memakai SAML agar login SSL VPN lewat Microsoft Entra ID, Okta, atau Google, lengkap dengan MFA. Menurut KB SonicWall SAML untuk SSL VPN, admin memilih SAML sebagai Authentication Type di pengaturan server SSL VPN. Grup bawaan untuk akses SSL VPN adalah SSLVPN Services.

Firewall yang sama juga bisa menyimpan user lokal, user LDAP, atau user RADIUS. Menurut advisory SonicWall SNWLID-2026-0014, kredensial sah untuk metode login lain bisa melewati kontrol SAML di SSL VPN. Analisa Rama Digital: password lama yang bocor dari salah satu metode itu bisa menjadi jalan masuk tanpa MFA.

Linimasa: 7.3.4-7013 rilis Oktober 2026, 8.2.3-8015 November 2026, advisory dan KEV 6 November, catatan CVE 19.03 UTC, artikel 7 November, batas CISA 20 November 2026.
Titik teal: build aman. Titik merah: advisory, laporan serangan, dan KEV. Titik amber: batas CISA. Build aman sudah ada saat advisory terbit. Sumber: SonicWall, catatan CVE, dan CISA KEV.

Advisory, catatan CVE, dan status KEV keluar pada 6 November 2026. Batas CISA untuk instansi federal AS adalah 20 November 2026. Build aman sudah tersedia saat advisory terbit: 7.3.4-7013 dari Oktober 2026 dan 8.2.3-8015 dari November 2026.

Cara kerja: login lewat jalan samping

SAML hanya menjaga pintu yang memakai SAML. Celah ini membiarkan kredensial metode lain membuka SSL VPN yang sama.

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

Ringkasan dari SonicWall dan CISA

Menurut advisory SonicWall SNWLID-2026-0014, CVE-2026-19868 adalah celah penegakan autentikasi di layanan SSL VPN SonicOS. Jenisnya CWE-308, yaitu autentikasi 1 faktor. Eksploitasi yang berhasil juga bisa melewati MFA yang SAML wajibkan.

SonicWall menulis bahwa celah ini hanya mengenai antarmuka atau layanan SSL VPN bila SAML aktif untuk login SSL VPN. CISA KEV memakai deskripsi yang sama. Status pemakaian oleh ransomware di KEV adalah "Unknown".

7 CVE di advisory yang sama

Advisory SNWLID-2026-0014 memuat 7 CVE. Upgrade yang sama menutup semuanya.

CVEJenis celahCVSS 3.1 SonicWallCatatan
CVE-2026-19868SAML dan MFA dilewati di SSL VPN (CWE-308)7.1Masuk CISA KEV, dipakai menyerang
CVE-2026-107155Kebijakan lintas domain longgar di antarmuka manajemen (CWE-942)8.8Tanpa login, butuh interaksi user
CVE-2026-107154Validasi sesi di antarmuka manajemen (CWE-291)8.8Tanpa login, butuh interaksi user
CVE-2026-82308Heap overflow di SSL VPN sebelum login (CWE-122)7.5DoS
CVE-2026-77708Stack overflow di klien TACACS+ (CWE-121)5.9DoS
CVE-2026-77709Heap overflow di klien TACACS+ (CWE-122)5.9DoS
CVE-2026-19703Hash password lemah di NSv (CWE-916, CWE-798)5.2Butuh akses lokal
Tiga kartu: CVE-2026-19868 melewati SAML dan MFA skor 7.1 masuk KEV, 2 celah antarmuka manajemen skor 8.8, 4 CVE lain DoS dan hash lemah, lalu kotak versi aman.
(1) Kartu merah: celah yang sudah dipakai menyerang. (2) Kartu amber dan abu-abu: 6 CVE lain di advisory yang sama. (3) Kotak teal: build yang menutup 7 CVE. Sumber: advisory SonicWall SNWLID-2026-0014, catatan CVE, dan CISA KEV.

Skor berbeda per sumber. SonicWall memberi CVE-2026-19868 skor 7.1 dengan syarat hak rendah (PR:L). CISA-ADP di catatan CVE-2026-19868 memberi skor 7.5 tanpa syarat hak (PR:N). Tulis skor bersama sumbernya.

Status eksploitasi per 7 November 2026

SonicWall meminta pelanggan upgrade ke rilis terbaru secepatnya. CISA mencatat status SSVC "Exploitation: active", "Automatable: no", dan "Technical Impact: partial". Advisory dan KEV tidak memuat IOC, nama pelaku, atau jumlah korban.

Analisa Rama Digital: skor 7.1 menipu bila Anda membacanya sendiri. Celah ini melewati login dan MFA di perangkat tepi, dan sudah dipakai menyerang. Pakai status KEV sebagai dasar prioritas, bukan skor tunggal.

Siapa yang paling berisiko

Kantor yang membuka SSL VPN SonicWall ke internet dan memakai SAML untuk login paling berisiko.

Tabel ini merangkum advisory SonicWall SNWLID-2026-0014 dan analisa kami.

Kondisi firewallRisikoAlasan
SAML aktif untuk login SSL VPNTinggiSyarat utama CVE-2026-19868 menurut SonicWall
Masih ada user lokal, LDAP, atau RADIUS di grup SSLVPN ServicesTinggiAnalisa Rama Digital: kredensial metode lain adalah jalan masuk
Password VPN lama atau pernah bocorPeriksaPenyerang butuh kredensial sah
Manajemen HTTPS terbuka di WANPeriksaJalan untuk CVE-2026-107154 dan CVE-2026-107155
Event 1080 tidak terkirim ke syslogPeriksaLogin lewat jalan samping tidak terlihat
SSL VPN tanpa SAML, atau SSL VPN matiRendahTidak kena CVE-2026-19868, tetap upgrade untuk 6 CVE lain
Enam kartu risiko: SAML aktif dan akun lokal atau LDAP merah, password lama, manajemen HTTPS di WAN, event 1080 mati amber, SSL VPN tanpa SAML abu-abu.
Kartu merah: syarat celah terpenuhi. Kartu amber: kondisi yang menambah risiko atau menyembunyikan tanda. Kartu abu-abu: risiko rendah. Kotak bawah: tempat melihat jenis login SSL VPN. Sumber: SonicWall, CISA KEV, dan analisa Rama Digital.

Firewall dan VPN berada di tepi jaringan. Satu login yang lolos memberi akses ke jaringan kantor dari luar. Pola yang sama muncul di rantai celah VPN Ivanti Connect Secure dan celah SAML Keycloak CVE-2026-117691: celah login di perangkat tepi menjadi target pertama.

Versi rentan dan versi aman

Advisory memakai 2 garis versi: 7.3.x untuk Gen7 dan 8.2.x untuk Gen8. Cocokkan model dan versi Anda dengan tabel ini.

ModelStatus per 7 November 2026Naik ke
Gen7 TZ, NSa, NSsp (TZ 270 sampai 670, NSa 2700 sampai 6700, NSsp 10700 sampai 15700)7.3.3-7015 dan lebih lama: rentan7.3.4-7013 atau lebih baru
Gen7 NSv 270, 470, 870 (ESX, KVM, Hyper-V, AWS, Azure)7.3.3-7015 dan lebih lama: rentan7.3.4-7013, cek ketersediaan di MySonicWall
Gen8 TZ, NSa (TZ 80 sampai 680, NSa 2800 sampai 5800)8.2.2-8015 dan lebih lama: rentan8.2.3-8015 atau lebih baru
Gen8 NSv XS, S, M, L (ESX, KVM, Hyper-V, AWS, Azure)8.2.2-8015 dan lebih lama: rentan8.2.3-8015 atau lebih baru
Gen6 dan SonicOS 6.5Tidak tercantum di advisoryCek status dukungan perangkat
Tabel versi SonicOS: Gen7 7.3.3-7015 dan lama rentan, naik ke 7.3.4-7013. Gen8 8.2.2-8015 dan lama rentan, naik ke 8.2.3-8015. NSv Gen7 diberi catatan amber.
Merah: rentan. Amber: NSv Gen7, karena catatan rilis 7.3.4 belum memuat NSv. Abu-abu: tidak tercantum. Teal: aman untuk SNWLID-2026-0014. Sumber: advisory SNWLID-2026-0014 dan catatan rilis SonicOS 7.3.4 dan 8.2.3.

Data tabel berasal dari advisory SonicWall SNWLID-2026-0014. Gen7 aman di 7.3.4-7013 dan lebih baru. Gen8 aman di 8.2.3-8015 dan lebih baru. Advisory tidak mencantumkan Gen6 dan SonicOS 6.5.

Catatan NSv Gen7: Advisory mencantumkan NSv 270, 470, dan 870 di daftar build aman 7.3.4-7013. catatan rilis SonicOS 7.3.4-7013 menulis bahwa SonicOS 7.3.4 untuk NSv belum rilis dan dijadwalkan nanti. Analisa Rama Digital: cek MySonicWall sebelum maintenance. Bila build NSv belum ada, pakai langkah 4 dan 5 sampai build tersedia.

Prasyarat sebelum mulai

  • Akses admin ke antarmuka web setiap firewall SonicWall, termasuk unit cadangan dan NSv.
  • Akun MySonicWall untuk mengunduh firmware 7.3.4-7013 atau 8.2.3-8015.
  • Jendela maintenance. Reboot memutus sesi SSL VPN yang aktif.
  • Akses ke server syslog atau SIEM yang menerima log firewall.
  • Akses ke log login IdP (Entra ID, Okta, atau Google) untuk aplikasi SSL VPN.

Langkah 1: Cek versi SonicOS setiap firewall

Masuk ke antarmuka web firewall, lalu buka Home and Dashboard | System. Catat model dan versi SonicOS di bagian General. Panduan resmi ada di KB SonicWall cek versi firmware.

Untuk banyak firewall, simpan skrip ini sebagai cek-versi-sonicos.sh. Skrip membandingkan versi dengan tabel advisory dan mencetak versi tujuan. Skrip tidak menghubungi firewall.

#!/usr/bin/env bash
# Cek versi SonicOS terhadap advisory SonicWall SNWLID-2026-0014 (CVE-2026-19868 dan 6 CVE lain).
# Data: advisory SonicWall 6 November 2026, catatan rilis SonicOS 7.3.4-7013 dan 8.2.3-8015.
# Pakai: bash cek-versi-sonicos.sh "TZ 470 7.3.3-7015" "NSa 2800 8.2.3-8015"
#    atau: bash cek-versi-sonicos.sh < daftar-firewall.txt   (1 firewall per baris: model lalu versi)
# Salin versi dari Home and Dashboard | System, bagian General.

AMAN7="7.3.4-7013"
AMAN8="8.2.3-8015"

# Benar bila versi $1 lebih rendah dari versi $2. Tanda "-" diganti "." agar sort -V membaca nomor build.
lebih_rendah() {
  local a="${1//-/.}" b="${2//-/.}"
  [ "$a" != "$b" ] && [ "$(printf '%s\n%s\n' "$a" "$b" | sort -V | head -n 1)" = "$a" ]
}

cek() {
  local asli="$1" v model status naik="" catatan=""
  v=$(printf '%s' "$asli" | grep -oE '[0-9]+\.[0-9]+\.[0-9]+(\.[0-9]+)?-[0-9]+[a-z]?' | tail -n 1)
  model=$(printf '%s' "$asli" | sed -E 's/SonicOS//I; s/[0-9]+\.[0-9]+\.[0-9]+(\.[0-9]+)?-[0-9]+[a-z]?//; s/[[:space:]]+/ /g; s/^ //; s/ $//')
  [ -z "$(printf '%s' "$asli" | tr -d '[:space:]')" ] && return
  if [ -z "$v" ]; then
    status="TIDAK DIKENAL, cocokkan manual dengan advisory SNWLID-2026-0014"
  else
    case "$v" in
      7.*)
        if lebih_rendah "$v" "$AMAN7"; then
          status="RENTAN (Gen7, SNWLID-2026-0014)"; naik="$AMAN7 atau lebih baru"
          if printf '%s' "$model" | grep -qi '^nsv'; then
            catatan="NSv Gen7: catatan rilis 7.3.4-7013 belum memuat NSv. Cek MySonicWall, pakai langkah 4 dulu."
          fi
        else
          status="AMAN untuk SNWLID-2026-0014"
        fi ;;
      8.*)
        if lebih_rendah "$v" "$AMAN8"; then
          status="RENTAN (Gen8, SNWLID-2026-0014)"; naik="$AMAN8 atau lebih baru"
        else
          status="AMAN untuk SNWLID-2026-0014"
        fi ;;
      5.*|6.*)
        status="TIDAK TERCANTUM (advisory hanya Gen7 dan Gen8), cek status dukungan perangkat" ;;
      *)
        status="TIDAK DIKENAL, cocokkan manual dengan advisory SNWLID-2026-0014" ;;
    esac
  fi
  printf '%-26s %-14s %s\n' "${model:--}" "${v:--}" "$status"
  [ -n "$naik" ] && printf '%-26s %-14s -> naik ke %s\n' "" "" "$naik"
  [ -n "$catatan" ] && printf '%-26s %-14s    %s\n' "" "" "$catatan"
  return 0
}

printf '%-26s %-14s %s\n' "MODEL" "VERSI" "STATUS"
if (( $# > 0 )); then
  for x in "$@"; do cek "$x"; done
else
  while IFS= read -r baris || [ -n "$baris" ]; do cek "$baris"; done
fi

Tulis 1 firewall per baris: model, lalu versi. Contoh isi berkas dengan data dummy:

TZ 470 SonicOS 7.3.3-7015
NSa 2700 SonicOS 7.1.3-7015
TZ 370 SonicOS 7.3.4-7013
NSv 270 SonicOS 7.3.3-7015
TZ 280 SonicOS 8.2.2-8015
NSa 2800 SonicOS 8.2.3-8015
NSv M SonicOS 8.2.1-8010
NSa 3650 SonicOS 6.5.4.15-117n
# 1 firewall per baris: model, lalu versi dari Home and Dashboard | System
nano daftar-firewall.txt
bash cek-versi-sonicos.sh < daftar-firewall.txt
# Atau langsung sebagai argumen
bash cek-versi-sonicos.sh "TZ 470 7.3.3-7015" "NSa 2800 8.2.3-8015"
Terminal: skrip cek versi membaca 8 firewall contoh. 5 rentan, termasuk NSv 270 dengan catatan build. 2 aman di 7.3.4-7013 dan 8.2.3-8015. NSa 3650 di 6.5 tidak tercantum.
Model dan versi diketik dari contoh data dummy. Skrip tidak menghubungi firewall, jadi Anda bisa menjalankannya di laptop. Sumber: uji Rama Digital di container podman Debian trixie-slim, 7 November 2026.

Cek hasil: "RENTAN" berarti firewall butuh langkah 2 dan 3 hari ini. "AMAN" berarti versi sudah menutup 7 CVE, tetapi tetap jalankan langkah 5. "TIDAK TERCANTUM" berarti advisory tidak membahas versi itu.

Lalu cek SAML. Buka NETWORK | SSL VPN > Server Settings dan lihat Authentication Type. Bila nilainya SAML, firewall ini kena CVE-2026-19868. Jalur menu ini ada di KB SonicWall SAML untuk SSL VPN.

Langkah 2: Backup konfigurasi sebelum upgrade

catatan rilis SonicOS 7.3.4-7013 menulis bahwa downgrade dari 7.3.4 tidak didukung. Jadi backup adalah jalan kembali Anda.

  1. Buka Device | Settings > Firmware and Settings.
  2. Klik Create Backup untuk membuat backup konfigurasi di firewall.
  3. Simpan juga salinan konfigurasi di luar firewall lewat menu ekspor. Beri nama dengan tanggal, model, dan versi.
  4. Catat user lokal, user LDAP, dan anggota grup SSLVPN Services. Langkah 4 dan 5 membutuhkan daftar ini.

Cek hasil: backup tampil di daftar Firmware and Settings, dan salinan konfigurasi ada di luar firewall.

Langkah 3: Upgrade ke 7.3.4-7013 atau 8.2.3-8015

Hanya build dari SonicWall yang menutup celah ini. Advisory menulis workaround: tidak ada.

  1. Unduh firmware dari MySonicWall. Pilih 7.3.4-7013 atau lebih baru untuk Gen7, dan 8.2.3-8015 atau lebih baru untuk Gen8.
  2. Buka Device | Settings > Firmware and Settings, lalu klik Upload Firmware.
  3. Klik ikon Boot pada firmware baru, lalu pilih Boot firmware with Current Configuration.
  4. Tunggu reboot. Menurut panduan upgrade SonicOS 7, proses ini makan waktu sekitar 5 sampai 8 menit.
  5. Sesudah reboot, buka lagi Home and Dashboard | System, lalu jalankan cek-versi-sonicos.sh dengan versi baru.
  6. Bila firewall gagal naik, pakai SafeMode sesuai panduan upgrade.
Tangga 6 baris: cek versi, backup konfigurasi, upgrade, 2 langkah berlabel tidak membuat aman (batasi akses SSL VPN dan hapus akun lokal), lalu cari login tanpa IdP.
(1) sampai (3): urutan perbaikan. (4a) dan (4b): langkah sementara sampai upgrade selesai. Label merah mengingatkan bahwa langkah itu tidak menutup celah. Sumber: SonicWall, panduan upgrade SonicOS 7, dan analisa Rama Digital.

Cek hasil: skrip mencetak "AMAN untuk SNWLID-2026-0014" untuk setiap firewall, termasuk unit cadangan.

catatan rilis SonicOS 7.3.4-7013 menyarankan Firmware Auto Update. Bila fitur ini aktif, sebagian firewall bisa sudah naik versi. Tetap cek versinya dengan langkah 1.

Langkah 4: Pasang mitigasi sementara sampai upgrade selesai

Langkah ini mengurangi peluang serangan, tetapi tidak menutup celah.

Analisa Rama Digital: SonicWall menulis workaround: tidak ada. Kami menyusun 3 langkah dari deskripsi celah dan fitur standar SonicOS. Kondisi: upgrade belum bisa jalan hari ini, atau build NSv belum tersedia. Batas: penyerang dengan kredensial sah dari IP yang diizinkan tetap bisa masuk.

4a. Batasi siapa yang bisa membuka SSL VPN

Pakai Geo-IP Filter atau aturan akses untuk membatasi asal koneksi ke port SSL VPN. Port bawaan SSL VPN di KB SonicWall SAML untuk SSL VPN adalah 4433. Izinkan hanya negara atau IP kantor yang Anda butuhkan.

4b. Kurangi user metode lain di grup SSLVPN Services

Celah ini butuh kredensial metode login lain. Jadi keluarkan user lokal, LDAP, atau RADIUS yang tidak perlu dari grup SSLVPN Services. Ganti password user yang harus tetap ada. Untuk 1 akun darurat, pakai password panjang yang baru dan pantau login akun itu di langkah 5.

4c. Tutup manajemen HTTPS dari WAN

CVE-2026-107154 dan CVE-2026-107155 ada di antarmuka manajemen. Matikan HTTPS management di interface WAN, lalu kelola firewall dari jaringan internal. catatan rilis SonicOS 8.2.3-8015 menulis bahwa Security Insights di 8.2.3 mendeteksi manajemen HTTPS yang terbuka di WAN.

Cek hasil: koneksi SSL VPN dari negara yang tidak diizinkan ditolak, grup SSLVPN Services hanya memuat user yang Anda butuhkan, dan halaman login admin tidak terbuka dari internet.

Langkah 5: Cari login SSL VPN yang tidak lewat IdP

Upgrade menutup celah, tetapi tidak membatalkan sesi atau password yang sudah dipakai penyerang. Jadi bandingkan login SSL VPN di firewall dengan login di IdP.

Menurut KB SonicWall tentang log login SSL VPN, event 1080 adalah "Successful SSLVPN User Login". Aktifkan event ini di Device | Log | Settings, kategori Users, lalu kirim ke server syslog.

Simpan skrip ini sebagai cek-log-sslvpn.sh. Skrip membaca event 1080 dari syslog, lalu mencari login SSL VPN yang tidak punya login IdP dari user yang sama dalam 10 menit.

#!/usr/bin/env bash
# Cari login SSL VPN SonicOS yang tidak punya pasangan login di IdP SAML (tanda CVE-2026-19868).
# Pakai: bash cek-log-sslvpn.sh SYSLOG [LOGIN-IDP.csv]
#  SYSLOG        syslog SonicOS (format kunci=nilai) dari server syslog atau SIEM.
#                Event 1080 = Successful SSLVPN User Login.
#  LOGIN-IDP.csv 2 kolom waktu_utc,user dari log login IdP (Entra ID, Okta, Google) untuk aplikasi SSL VPN.
# Syarat: waktu di kedua berkas memakai UTC. Skrip hanya membaca berkas, tidak menghubungi firewall.
set -u
[ $# -lt 1 ] && { echo "Pakai: bash cek-log-sslvpn.sh SYSLOG [LOGIN-IDP.csv]"; exit 1; }
LOG="$1"; IDP="${2:-}"; JEDA=600   # selisih waktu maksimal 10 menit
login=$(mktemp); idp=$(mktemp); trap 'rm -f "$login" "$idp"' EXIT

# Ambil waktu, user, dan IP sumber dari setiap event 1080.
awk '
function val(k,   p) {
  p = " " k "=\""
  if (match($0, " " k "=\"[^\"]*\"")) return substr($0, RSTART + length(p), RLENGTH - length(p) - 1)
  if (match($0, " " k "=[^ ]+")) return substr($0, RSTART + length(k) + 2, RLENGTH - length(k) - 2)
  return ""
}
/(^|[ \t])m=1080([ \t]|$)/ {
  t = val("time"); sub(/ UTC$/, "", t)
  u = tolower(val("usr")); if (u == "") u = "(tanpa-usr)"
  s = val("src"); sub(/:.*/, "", s)
  gsub(/[[:cntrl:]]/, "", t); gsub(/[[:cntrl:]]/, "", u); gsub(/[[:cntrl:]]/, "", s)
  if (t == "") t = "tanpa-waktu"; if (s == "") s = "tanpa-ip"
  print t "\t" u "\t" s
}' "$LOG" > "$login"

total=$(wc -l < "$login")
echo "== 1. Login SSL VPN berhasil (event 1080) per user dan IP sumber"
if (( total == 0 )); then
  echo "Tidak ada event 1080. Aktifkan event 1080 dan kirim kategori Users ke syslog, lalu ulangi."
  exit 0
fi
cut -f2,3 "$login" | sort | uniq -c | sort -rn | head -n 10
echo "Total: $total login dari $(cut -f3 "$login" | sort -u | wc -l) IP"

if [ -z "$IDP" ]; then
  echo "Hasil: belum dibandingkan dengan IdP. Jalankan lagi dengan berkas LOGIN-IDP.csv."
  exit 0
fi

# Ubah waktu IdP ke detik epoch. Baris judul dan baris rusak dilewati.
while IFS=, read -r w u _; do
  w=${w//\"/}; u=${u//\"/}; u=${u%$'\r'}
  e=$(date -u -d "$w" +%s 2>/dev/null) || continue
  printf '%s\t%s\n' "$e" "$(printf '%s' "$u" | tr '[:upper:]' '[:lower:]')"
done < "$IDP" > "$idp"

echo "== 2. Login SSL VPN tanpa login IdP dalam 10 menit"
n=0; x=0
while IFS=$'\t' read -r t u s; do
  e=""; [ -n "$t" ] && e=$(date -u -d "$t" +%s 2>/dev/null)
  if [ -z "$e" ]; then echo "$t  $u  dari $s  waktu tidak terbaca"; x=$((x + 1)); continue; fi
  if ! awk -F'\t' -v u="$u" -v e="$e" -v j="$JEDA" '$2 == u && $1 - e <= j && e - $1 <= j { f = 1 } END { exit !f }' "$idp"; then
    echo "$t UTC  $u  dari $s"
    n=$((n + 1))
  fi
done < "$login"
(( n == 0 && x == 0 )) && echo "Tidak ada"

if (( n > 0 )); then
  echo "Hasil: ADA TANDA. $n login SSL VPN tidak lewat IdP. Simpan log, putus sesi user itu, ganti password-nya."
  (( x > 0 )) && echo "Catatan: $x login lain punya waktu yang tidak terbaca. Periksa juga baris itu."
elif (( x > 0 )); then
  echo "Hasil: TIDAK BISA DIPASTIKAN. $x login punya waktu yang tidak terbaca. Perbaiki format waktu syslog, lalu ulangi."
else
  echo "Hasil: semua login punya pasangan di IdP. Log yang bersih tidak membuktikan firewall bersih."
fi

Siapkan 2 berkas. Berkas pertama: syslog firewall untuk 30 hari terakhir. Berkas kedua: ekspor log login IdP untuk aplikasi SSL VPN dengan 2 kolom, waktu UTC dan user. Contoh berkas IdP dengan data dummy:

waktu_utc,user
2026-11-05T01:01:40Z,rina@contoh.co.id
"2026-11-05T01:15:02Z","andi@contoh.co.id"
# Berkas 1: syslog firewall 30 hari terakhir dari server syslog atau SIEM
# Berkas 2: log login IdP untuk aplikasi SSL VPN, 2 kolom waktu_utc,user
bash cek-log-sslvpn.sh sonicwall-30-hari.log login-idp.csv
Terminal: skrip log menemukan 7 login SSL VPN dari 3 IP. 2 login dari 203.0.113.77 tidak punya login IdP dalam 10 menit. Hasil: ADA TANDA.
Semua baris log dan user adalah data dummy. Alamat IP memakai blok dokumentasi 198.51.100.0/24 dan 203.0.113.0/24. Sumber: uji Rama Digital di container podman Debian trixie-slim, 7 November 2026.

Batas skrip: Skrip membaca field m=, time=, usr=, dan src= dari syslog format kunci=nilai. Kami menguji skrip dengan log dummy, bukan log firewall asli. Bila log Anda memakai nama field lain, ubah nama field di fungsi val.

aturan deteksi Elastic untuk login SonicWall memakai ide yang dekat: aturan itu menandai pasangan user dan IP sumber yang baru pertama kali login. Bagian 1 dari skrip ini memberi daftar pasangan yang sama untuk Anda periksa.

Dua alur login: normal lewat IdP dan MFA lalu event 1080 dengan log IdP, dan jalan samping dengan kredensial metode lain lalu event 1080 tanpa log IdP, plus daftar tanda.
Alur teal: login normal. Alur merah: login lewat jalan samping. Kotak amber: tanda yang dicari. Kotak merah: langkah bila Anda menemukan 1 tanda saja. Sumber: SonicWall KB log SSL VPN, CISA KEV, dan analisa Rama Digital.

Cek hasil: "semua login punya pasangan di IdP" berarti tidak ada tanda di rentang log itu. Log yang bersih tidak membuktikan firewall bersih. "TIDAK BISA DIPASTIKAN" berarti ada login dengan waktu yang tidak terbaca. Perbaiki format waktu syslog, lalu jalankan skrip lagi. "ADA TANDA" berarti ikuti urutan ini:

  1. Simpan salinan syslog firewall dan log IdP sebelum log berputar.
  2. Putus sesi SSL VPN user itu.
  3. Ganti password user itu di semua metode login: lokal, LDAP, dan RADIUS.
  4. Upgrade firmware sebelum Anda membuka akses lagi.
  5. Cek server dan berkas yang user itu buka di jaringan internal.

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

Contoh: 1 pagi respons untuk 3 firewall

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

Waktu (WIB)Firewall dummyYang dicekHasilTindakan
07.00fw-pusat (NSa 2700, 7.3.3-7015)Langkah 1RENTAN, SAML aktifLangkah 4 pagi ini, upgrade malam ini
07.20fw-cabang (TZ 280, 8.2.2-8015)Langkah 1RENTAN, tanpa SAMLTutup manajemen HTTPS di WAN hari ini, upgrade besok
08.00fw-pusatLangkah 52 login SSL VPN tanpa login IdP dari 1 IP pada 5 NovemberPutus sesi, ganti password, mulai respons insiden
09.30fw-dc (NSv 270, 7.3.3-7015)Langkah 1 dan MySonicWallBuild NSv 7.3.4 belum adaLangkah 4a dan 4b, cek MySonicWall setiap hari

Pelajaran dari simulasi: MFA di IdP tidak membuktikan setiap login lewat IdP. Fw-pusat memakai SAML dan MFA, tetapi langkah 5 tetap menemukan 2 login tanpa pasangan di IdP.

Siapa yang memasang patch

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

Cara pengelolaanPemegang patchYang Anda kerjakan
Firewall fisik TZ, NSa, atau NSsp di kantorTim IT AndaLangkah 1 sampai 5
NSv di VMware, Hyper-V, KVM, AWS, atau AzureTim IT AndaLangkah 1 sampai 5, dan snapshot VM sebelum upgrade
Dikelola mitra atau MSPMitra sesuai kontrakMinta bukti versi tertulis dan hasil langkah 5
Firmware Auto Update aktifSonicWall mengirim build, tim Anda tetap memeriksaLangkah 1 dan langkah 5

Rekomendasi Rama Digital: perlakukan firewall dan VPN sebagai aset dengan prioritas patch tertinggi, setara dengan server domain. Simpan log login VPN minimal 90 hari agar langkah 5 punya bahan.

Checklist hari ini

  1. Buat daftar semua firewall SonicWall, termasuk unit cadangan dan NSv. Pemilik: tim IT. Bukti: daftar model dan versi.
  2. Cek versi dan jenis login SSL VPN dengan langkah 1. Pemilik: admin jaringan. Bukti: output skrip.
  3. Backup konfigurasi dengan langkah 2. Pemilik: admin jaringan. Bukti: backup dan salinan di luar firewall.
  4. Pasang langkah 4 di setiap firewall yang belum bisa upgrade hari ini. Pemilik: admin jaringan. Bukti: aturan akses dan daftar grup.
  5. Upgrade ke 7.3.4-7013 atau 8.2.3-8015. Pemilik: admin jaringan. Bukti: output skrip sesudah upgrade.
  6. Cari login tanpa IdP dengan langkah 5. Pemilik: admin jaringan dan admin IdP. Bukti: output skrip.
  7. Ganti password user lokal dan LDAP yang masih ada di grup SSLVPN Services, walau tidak ada tanda.

Tanya jawab

Firewall saya tidak memakai SAML untuk SSL VPN. Apakah saya aman?

Anda tidak kena CVE-2026-19868 menurut SonicWall. Tetapi 6 CVE lain di advisory yang sama tetap berlaku, termasuk 2 celah antarmuka manajemen dengan skor 8.8. Upgrade tetap wajib.

Skor CVE-2026-19868 hanya 7.1. Kenapa artikel ini peringatan kritis?

Celah ini melewati login dan MFA di perangkat tepi. CISA sudah memasukkannya ke KEV, dan SonicWall menerima laporan serangan. Status itu lebih penting untuk prioritas daripada skor tunggal.

MFA saya aktif di IdP. Apakah MFA melindungi SSL VPN?

Tidak untuk celah ini. Menurut SonicWall, eksploitasi yang berhasil juga bisa melewati MFA yang SAML wajibkan. MFA di IdP hanya menjaga login yang lewat IdP.

Saya memakai NSv Gen7. Build mana yang saya pasang?

Advisory menulis 7.3.4-7013, tetapi catatan rilis 7.3.4 menulis versi NSv belum rilis. Cek MySonicWall. Bila build belum ada, pasang langkah 4 dan jalankan langkah 5 setiap hari sampai build tersedia.

Apakah firewall Gen6 dengan SonicOS 6.5 terdampak?

Advisory tidak mencantumkan Gen6. Cek status dukungan perangkat Anda di MySonicWall, dan rencanakan pindah ke perangkat yang masih menerima patch.

Bisakah saya kembali ke versi lama bila 7.3.4 bermasalah?

Catatan rilis 7.3.4 menulis bahwa downgrade tidak didukung. Karena itu, langkah 2 wajib sebelum upgrade.

Apakah upgrade menghapus akses penyerang?

Upgrade menutup celah. Upgrade tidak mengganti password yang sudah bocor dan tidak memeriksa jaringan internal. Jalankan langkah 5, lalu ganti password user yang punya tanda.

Langkah berikutnya

Batas yang tetap berlaku: mitigasi di langkah 4 tidak menutup celah, dan upgrade tidak mengganti password yang sudah bocor. Bila firewall 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