Kung gumagamit ang iyong negosyo ng SonicWall firewall, o kung ipinapasa-labas mo ang IT sa isang managed service provider (MSP) na naglo-log in nang remote para panatilihing naka-patch at may backup ang iyong mga sistema, may dalawang magkahiwalay na dahilan ka para tumawag ngayong linggo. Parehong may kinalaman sa mga kahinaan (vulnerabilities) na aktibong sinasamantala ng mga umaatake ngayon mismo, hindi teoretikal na panganib sa isang bulletin ng vendor na walang nagbabasa. Wala sa dalawa ang nangangailangan sa iyong maging eksperto sa seguridad. Ang kailangan mo lang ay magtanong ng mga tiyak na tanong at umasa ng mga tiyak na sagot — mga petsa, numero ng bersyon, kumpirmasyon — hindi pang-aliw lamang.

Narito ang nangyayari sa bawat isa, at isang checklist na puwede mong kopyahin, i-paste, at ipadala sa sinumang namamahala sa iyong network.

Problema 1: Ang Iyong SonicWall Firewall (CVE-2026-15409 at CVE-2026-15410)

Inilantad at na-patch ng SonicWall ang dalawang kahinaan noong Hulyo 14, 2026 — ngunit ayon mismo sa timeline ng kompanya, halos tatlong linggo na itong sinasamantala ng mga umaatake bago pa man ito ipinahayag nang publiko. Ibig sabihin, hindi awtomatikong pareho ang "na-patch na ngayon" at "ligtas na ngayon" para sa isang device na nakalantad sa internet sa loob ng panahong iyon.

Ang threat actor na pinaka-madalas banggitin kaugnay ng chain ng kahinaang ito ay ang INC, isang ransomware-as-a-service operation na inilalarawan ng mga mananaliksik sa Rapid7 bilang isa sa mga pinaka-aktibong grupo ng ganitong uri sa buong mundo sa kasalukuyan (bagama't hindi lahat ng pag-atake na gumagamit ng mga depektong ito ay tiyak na naiugnay sa INC — halos tiyak na may kasangkot ding ibang opportunistikong umaatake). Bukod dito, iniulat ng security firm na Huntress ang isang mabilis na siklo ng pag-atake kung saan 30 kustomer ng SonicWall ang na-compromise sa loob ng wala pang dalawang araw. Hindi ito isang unti-unting panganib.

May kaugnay ding kasaysayan dito: dati nang inilantad ng SonicWall ang isang insidente kung saan ninakaw ng isang grupong suportado ng estado (state-sponsored) ang mga configuration file ng firewall mula sa bawat kustomer ng SonicWall na gumagamit ng cloud backup feature nito. Ang isang ninakaw na configuration file ay maaaring maglaman ng mga kredensyal ng local account at mga setting ng VPN. Kung na-backup man noon ang configuration ng iyong firewall sa cloud service ng SonicWall bago pa na-contain ang insidenteng iyon, ang pag-patch sa kasalukuyang mga depekto ay hindi na nakababawi sa anumang nailantad na — maaaring kailangan pa ring i-rotate ang mga kredensyal mula sa configuration na iyon.

Checklist na Ipapadala sa Iyong IT Provider o MSP:

  • "Anong modelo ng SonicWall at bersyon ng firmware ang kasalukuyan naming ginagamit, at naaayos ba ng bersyon na iyon ang CVE-2026-15409 at CVE-2026-15410?" (Hilingin sa kanilang kumpirmahin ito laban sa sariling advisory ng SonicWall — huwag tanggapin ang "nasa pinakabagong bersyon na kami" kung walang binigay na numero ng bersyon.)
  • "Anong petsa namin inilapat ang patch?" Kung pagkatapos ng Hulyo 14, 2026, hilingin sa kanilang suriin ang mga log mula sa mga nakaraang linggo para sa mga palatandaan ng hindi awtorisadong pag-access — hindi inaasahang admin login, bagong local account, o SSLVPN session mula sa hindi kilalang IP address.
  • "Nakalantad ba sa internet ang aming SSLVPN o remote-access portal sa loob ng panahong iyon?" Kung oo, humingi ng sapilitang pag-reset ng password para sa bawat account na nag-a-authenticate dito, hindi lang basta patch.
  • "Na-backup ba noon ang configuration ng aming firewall sa cloud service ng SonicWall, at kung oo, na-rotate na ba mula noon ang mga kredensyal sa config file na iyon?"
  • "Naka-enable ba ang multi-factor authentication sa lahat ng remote-access account sa pamamagitan ng firewall?" Kung hindi, hilingin sa kanilang i-on ito ngayong linggo.

Problema 2: Ang Remote-Management Tool ng Iyong MSP (CVE-2026-18577 sa N-able N-central)

Naiiba ang isang ito dahil hindi ito kagamitan mo — ito ay isang tool na maaaring gamitin ng iyong IT provider para pamahalaan ang dose-dosena o daan-daang negosyong kliyente, kabilang na marahil ang sa iyo, mula sa iisang sentral na console. Ang N-able N-central ay isa sa ganitong platform, at idinagdag ng CISA (ang U.S. Cybersecurity and Infrastructure Security Agency) ang isang kahinaan dito — ang CVE-2026-18577, na may severity rating na 8.2 sa 10 — sa kanilang Known Exploited Vulnerabilities catalog matapos kumpirmahin ang aktibong pagsasamantala dito simula Hulyo 31, 2026. Umano'y pinapahintulutan ng depektong ito ang isang umaatake na makakuha ng ganap na administratibong access sa mismong N-central console.

Mahalaga ito dahil sa magagawa ng umaatake mula roon. Iniulat ng Huntress na ang matagumpay na mga pag-atake ay lumipat mula sa na-compromise na console patungo sa mga endpoint na pinamamahalaan dito — ibig sabihin, ang paglabag sa tool ng MSP ay maaaring maging paglabag din sa iyong mga sistema kahit hindi ka direktang tinarget ng umaatake. Natuklasan din ng Huntress na gumagawa ang mga umaatake ng mga Cloudflare tunnel sa mga na-compromise na sistema, isang teknik na nagbibigay sa kanila ng patuloy at naka-encrypt na paraan ng pagbalik na maaaring magmukhang ordinaryong web traffic sa mata ng isang firewall.

Hindi mo kailangang malaman kung ginagamit ng iyong partikular na provider ang N-central. Kailangan mong magtanong, at magtanong nang mas malawak kaysa sa iisang pangalan ng produkto lamang.

Checklist na Ipapadala sa Iyong IT Provider o MSP:

  • "Ginagamit ba ninyo ang N-able N-central, o anumang iba pang produkto ng N-able, para pamahalaan ang aming mga sistema?" Kung oo: "Na-patch na ba ito laban sa CVE-2026-18577, at kailan?"
  • "Na-audit na ba ninyo ang aktibidad ng admin account at mga access log sa inyong management console mula noong Hulyo 31, 2026, para sa anumang hindi ninyo maipaliwanag?"
  • "Sinuri ba ninyo nang partikular ang aming mga sistema para sa hindi inaasahang outbound connection — lalo na ang mga proseso ng Cloudflare tunnel (minsan lumilitaw bilang 'cloudflared') o mga tunnel domain na hindi ninyo itinakda?"
  • "May mga bagong local admin account, scheduled task, o remote-management policy ba na na-push sa aming mga sistema na hindi ninyo maiuugnay sa sarili ninyong team?"
  • "Kung hindi ninyo ginagamit ang N-central, anong remote-management tool ang ginagamit ninyo sa halip, at may mga kahinaan ba itong naidagdag kamakailan sa Known Exploited Vulnerabilities catalog ng CISA?"

Ano ang Gagawin sa mga Sagot

Sasagutin ng isang mahusay na IT provider ang mga ito nang may petsa at mga detalye, kadalasan sa loob ng isang araw, dahil dapat ay alam na nila ang impormasyong ito o kayang kunin agad mula sa mga log. Ang isang malabong sagot — "nababantayan namin," "ligtas ang aming mga sistema," walang binigay na petsa — ay kapaki-pakinabang na impormasyon din mismo: sinasabi nito sa iyo na kailangang ulitin ang usapang ito, sa nakasulat na anyo, na may kalakip na deadline.

Kung ikaw mismo ang namamahala sa iyong SonicWall nang walang MSP, direktang naaangkop pa rin sa iyo ang checklist sa itaas — mag-log in mismo sa management console, suriin ang bersyon ng firmware, at tingnan ang advisory page ng SonicWall para sa bersyon na naaayos sa parehong CVE.

Wala sa dalawang kahinaang ito ang nangangailangan sa iyo na bunutin ang isang vendor o tanggalin ang isang provider. Ang kailangan ay pagpapatibay na ang partikular na butas ay naisara na at wala nang lumusot dito habang bukas pa ito. Itanong ang mga tanong, kunin ang mga petsa, at maglagay ng paalala sa iyong kalendaryo na magtanong muli sa susunod na pagkakataon na may isiwalat ang isang vendor na "aktibong pinagsasamantalahan." Mangyayari ulit ito.