Ubiquiti patcht UniFi Network-kwetsbaarheid die accountovername mogelijk maakte

Ubiquiti heeft een kwetsbaarheid in de UniFi Network-app gepatcht waarmee hackers potentieel de accounts van gebruikers konden overnemen. Daarvoor hebben hackers wel toegang tot het netwerk in kwestie nodig.

Ubiquiti maakte de kwetsbaarheid bekend in een beveiligingsadvies op zijn website. Het probleem zat in UniFi Network-versie 10.1.85 en eerder. In versie 10.1.89 is de kwetsbaarheid verholpen. Specifiek voor de UniFi Express-router geldt een andere versienummering: daar is de bug verholpen in versie 9.0.118. Gebruikers wordt aangeraden om de updates zo snel mogelijk te installeren.

De kwetsbaarheid wordt gevolgd onder CVE-2026-22557. Het gaat om een 'kritieke' bug met een ernstigheidsscore van 10. Hackers met toegang tot het netwerk kunnen de kwetsbaarheid gebruiken om toegang te krijgen tot bestanden op het UniFi-systeem. Die kunnen vervolgens 'gemanipuleerd worden om toegang te verkrijgen tot een onderliggend account', aldus Ubiquiti.

Ubiquiti meldt ook een tweede kwetsbaarheid. Dat gaat om een NoSQL-injectie waarmee een hacker met toegang tot het netwerk mogelijk privileges kan escaleren. Dat gaat om een minder ernstige bug, die in dezelfde UniFi Network-versies is gepatcht.

UniFi Network, ook wel bekend als UniFi Controller, wordt gebruikt om Ubiquiti-netwerkapparatuur aan te sturen. Denk daarbij aan routers, accesspoints en switches. De app draait bijvoorbeeld op Ubiquiti's UniFi Cloud Gateways, Dream Machines en Dream Routers, hoewel gebruikers het ook zelf kunnen hosten.

De UniFi Network-app. Bron: Ubiquiti

Reacties (81)

[blouweKip]

Nog geen nieuwe versie in de apt repos (die zijn al enige tijd leeg), geen migratie route naar UnifiOS, lekker dan.

[Madshark]

Even een wget doen van het gewenste script op https://glennr.nl/s/unifi-network-controller
Deze even uitvoeren, komt het allemaal wel goed

[marcel48]

Let op. Op moment van schrijven is het meest recente script voor installatie van unifi network 10.1.85. In deze versie is de kwetsbaarheid nog niet verholpen. https://community.ui.com/releases/Security-Advisory-Bulletin-062-062/c29719c0-405e-4d4a-8f26-e343e99f931b

[Madshark]

Eh? Ik heb het script gisteren nog gebruikt om een 9.x naar 10.2.97 te upgraden. 10.2.97 zou goed moeten zijn (?)

[powerboat]

Je kunt handmatig via een DEB-package update .

1. wget https://dl.ui.com/unifi/10.1.89/unifi_sysvinit_all.deb
2. dpkg -i unifi_sysvinit_all.deb
3. apt install -f (als je dependencies mist)

[blouweKip]

Klopt, dat is ook de route die ik genomen heb maar wel apart dat ze dat niet communiceren

[powerboat]

Ja, ik had gehoopt dat ze dit via de package manager hadden geregeld. Of een officiële Docker image.

[Travelan]

Daar kies je voor als je voor Self-Hosted kiest, dat is unsupported en best-effort. Als je dit belangrijk vind, dan raad ik je aan first party controllers te gebruiken. Zo duur zijn die niet meer.

[blouweKip]

Dat is wat anders dan ineens iets aanpassen zonder verdere communicatie; geen ondersteuning is niet per definitie onprofessioneel 😏

[The Lord]

Hackers met toegang tot het netwerk

In de toelichting van Ubiquiti wordt hier geen uitleg voor gegeven.

Is het ook de zelf gehoste Unifi Network Controller die via internet bereikbaar is... Of is dat niet het netwerk...

[Fenna]

Als je met de muis over network hovert https://www.first.org/cvss/calculator/3-1#CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H, krijg je te zien dat netwerk ook het hele internet "kan" zijn.

[Sfynx]

Ik ga er maar van uit dat ze bedoelen dat je een verbinding kan maken met de controller. Ik heb alles in een management VLAN hangen, dus ik ga er geen afspraken voor afzeggen.

[Drardollan]

Bij een CVS van 10 je kop in het zand steken is hetzelfde als met je ogen dicht de snelweg oversteken…. Blij dat je mijn spullen niet beheerd in ieder geval.

Als je het niet direct kan oplossen, wat helemaal niet gek is, dan neem je wel alle mitigerende maatregelen die je kan nemen. En die zijn in geval van de Unifi Controller erg eenvoudig: uitzetten of onbereikbaar maken. Dat heeft 0 impact op de devices.

[Calypso]

Wat jij aangeeft, "onbereikbaar maken", is precies wat @Sfynx al "by design" gedaan heeft zo te lezen: hang het in een apart management VLAN, zorg dat anderen er niet bij kunnen en het probleem is een heel stuk minder urgent.

Als jij vindt dat je blij bent dat hij jouw spullen niet beheert ben ik juist het tegenovergestelde van mening: dit soort tools horen in mijn ogen niet voor anderen toegankelijk te zijn zonder extra maatregelen. Moet je er vanaf buiten bij kunnen? VPN, heel specifieke firewall regels, whatever.

De meeste verstoringen die ik in mijn ICT leven heb meegemaakt zijn voortgekomen uit te snel uitrollen van patches of versies die onvoldoende uitgetest waren. Ja, sommige dingen ontkom je niet aan als het zaken zijn die door anderen bereikbaar moeten zijn, maar vaak kun je het risico van dit soort bugs al flink verminderen door erover na te denken bij het ontwerp.

[Drardollan]

De meeste verstoringen die ik in mijn ICT leven heb meegemaakt zijn voortgekomen uit te snel uitrollen van patches of versies die onvoldoende uitgetest waren. Ja, sommige dingen ontkom je niet aan als het zaken zijn die door anderen bereikbaar moeten zijn, maar vaak kun je het risico van dit soort bugs al flink verminderen door erover na te denken bij het ontwerp.

Een wijze les die ik ook geleerd heb is dat in geval van serieuze beveiligingsrisico's, zoals in dit geval maar ook bijvoorbeeld bij Exchange enkele jaren geleden, is dat je je moet afvragen wat erger is:

1) Zo snel mogelijk de patch doorvoeren met het risico op een verstoring omdat de patch iets sloopt
2) (Te lang) afwachten met het risico op een verstoring omdat kwaadwillenden het slopen

Welke situatie is beter? In beide gevallen is het kapot, maar welk geval heb je liever?

Los van allerlei maatregelen die aan te bevelen zijn, en ik ook diverse malen al genoemd heb zoals achter een VPN. Als er een CVE boven de 9 bekend wordt dan moet je dat erg serieus nemen. En als het een 10 is dan is het normaal gezien een no-brainer dat je direct actie moet ondernemen. En die actie kan gaan van vaststellen dat je geen risico hebt tot mitigerende maatregelen tot direct patchen (en alles er tussenin en voor en na).

[Calypso]

Stap 1, bij elk beveiligingsincident, is het kijken naar wat het risico is. Niet het risico wat er aan gegeven is (dat is een indicatie in het algemeen), maar naar wat het risico is in jouw situatie.

Ik kan me herinneren dat er ooit een Linux login lek was waarin je met 5x enter in het password veld als root binnenkwam. Moest je wel op console zitten.

Wat is dan het risico daarop als jij op een niet op netwerk aangesloten PC zit, op je zolderkamertje, waar verder niemand bij kan komen. Dan is het risico voor jou letterlijk 0. Dat is het eerste wat je je moet realiseren. En wanneer je Unifi controller totaal niet bereikbaar is voor anderen, wat is dan de kans dat iemand van deze bug gebruik kan maken? Nogmaals: bedenk altijd eerst wat het risico is in jouw situatie. Dat is altijd stap 1.

[closefuture]

Bij een CVS van 10 je kop in het zand steken is hetzelfde als met je ogen dicht de snelweg oversteken….

Dat is wel erg kort door de bocht. Die scores zijn niet zo zwart-wit. Je kunt een score van 10 krijgen als je een RCE hebt in een feature die standaard niet eens aan staat en praktisch niemand gebruikt. Zoals bijvoorbeeld deze SAMBA kwetsbaarheid.

[Drardollan]

Ik ben het er helemaal mee eens dat CVE scores de laatste jaren veel te makkelijk een hoge waarde krijgen. Het is helaas het enige houvast wat je als beheerder hebt op dit moment, een CVE wordt zo objectief mogelijk bepaald en heeft daarmee wel een bepaalde waarde. Natuurlijk moet je nog altijd kijken naar de situatie, want als het stuk wat geraakt wordt niet aanstaat dan is er weinig aan de hand.

Mijn strategie is dat bij een CVE hoger dan 9 ik er per direct naar kijk en beoordeel wat te doen. En dat kan gaan van vaststellen dat het voor mij niet van toepassing is tot een fix inplannen tot direct alles blindelings patchen, naar gelang de situatie.

En het is ook nog eens van belang om te kijken naar het type product. De Unifi controller is slechts ondersteunend en kan je altijd zo uitschakelen, er gebeurd helemaal niks boeiends in dat geval. Je bent enkel je inzicht kwijt en kan geen configuraties wijzigen.

In dit geval is het dus een no-brainer indien je GUI vanaf het hele internet toegankelijk is, direct patchen en als dat niet mogelijk is direct poorten dicht of controller uitzetten. En dan op een rustig moment oppakken en oplossen middels de patch.

[Sfynx]

Blij dat je mijn spullen niet beheerd in ieder geval.

Insgelijks. Dingen zouden er blijkbaar constant uit liggen anders. Jij stopt gewoon met het beheren van je netwerk tot je de patch kan installeren? Ik doe aan strikte netwerksegmentatie juist om dit soort situaties.

[Drardollan]

Ehh nee, ik beheer mijn spullen gewoon goed. En als ik patches, die een CVE van boven de 9 hebben, niet direct kan installeren dan neem ik direct mitigerende maatregelen.

Leuk (en goed) die segmentatie, maar het helpt je in dit geval niet zo veel als bescherming als de GUI open staat vanaf het netwerk en je Unifi devices (intern) met de controller kunnen praten. Het zal je misschien verrassen, maar vanaf de console kan je een SSH sessie opbouwen naar je devices, waarmee je hele segmentatie een wassen neus is geworden.

[Reactie gewijzigd door Drardollan op 20 maart 2026 08:45]

[Sfynx]

Het zal je misschien verrassen, maar vanaf de console kan je een SSH sessie opbouwen naar je devices, waarmee je hele segmentatie een wassen neus is geworden.

Wat bedoel je precies hier? Mijn controller en de UniFi devices zitten in een eigen afgeschermd netwerk waar alleen mijn eigen werkstation bij kan voor het beheer. Als dat laatste het alsnog onveilig maakt is in feite alles wat een systeembeheerder kan aanraken onveilig. Als iemand mijn werkstation overneemt houdt het inderdaad op.

[Drardollan]

Je kan er beter vanuit gaan dat alles sowieso onveilig is (ZTNA is niet voor niets een belangrijke filosofie de afgelopen jaren).

Als de Unifi controller niet met zijn GUI openstaat vanaf het internet, wat in je eerste post niet verteld is en je nu ineens aanpast naar enkel je eigen werkstation, dan maakt het niks uit wat je doet lokaal. Als ze via de GUI in je controller komen, wat in dit geval dus zonder authenticatie blijkt te kunnen, dan kunnen ze vanaf de controller naar onder andere de access points verbinden. En vanaf het access point kunnen ze door naar de rest van je netwerk. Leuk dat het in een eigen VLAN zit, de access point zullen in dit geval in meerdere VLAN's SSID's hebben om er iets mee te kunnen doen (anders is het weinig zinnig, als alles zich alsnog in het management VLAN bevind) en dus kan je vanaf het access point alles bereiken.

Maar waarom was het gisteren te moeilijk om even te updaten met 1 druk op de knop? Waarom heb je dat sowieso niet geautomatiseerd eigenlijk?

[Sfynx]

Je kan er beter vanuit gaan dat alles sowieso onveilig is (ZTNA is niet voor niets een belangrijke filosofie de afgelopen jaren).

Als de Unifi controller niet met zijn GUI openstaat vanaf het internet, wat in je eerste post niet verteld

Ok, mijn fout dan, ik dacht dat mijn opmerking in mijn eerste post dat ik het in een management VLAN heb staan dat al wel duidelijk genoeg maakte.

Maar waarom was het gisteren te moeilijk om even te updaten met 1 druk op de knop? Waarom heb je dat sowieso niet geautomatiseerd eigenlijk?

Omdat dat uiteraard ook risico's met zich meebrengt, met name voor de continuïteit. Ik zou het ook erg fijn vinden als ik gewoon blind alles kan updaten, de praktijk is helaas anders.

[Drardollan]

Dat was niet duidelijk voor mij, maar veranderd uiteraard wel mijn mening dat je niet de kop in het zand gestoken hebt. Als hij niet openstaat vanaf het internet dan is het risico, zeker in een zeer beperkte setup, nagenoeg nihil.

Continuïteit is belangrijk, maar dit is de Unifi Controller. Deze is niet noodzakelijk voor een goede werking van de Unifi devices. Het is enkel een tool voor rapportage en configuratie, zonder de controller draait alles gewoon door. Als je zorgt voor een goede backup dan kan je hem in geval van een falende update binnen korte tijd zo weer in de lucht brengen.

Los van dat Unifi op de controller een prima track-record heeft qua updates. Het zal ongetwijfeld voorgekomen zijn, maar ik kan mij geen moment herinneren waarbij een update van de controller massaal voor problemen zorgde in de wereld. Als er iets vrij risicoloos te automatiseren is qua updates dan is het de Unifi controller in mijn ogen.

[Sfynx]

Ik heb weleens gehad dat een controller update ervoor zorgde dat devices niet meer wilden verbinden omdat firmwares niet meer compatible waren, of dat ie de bestaande MongoDB niet meer leuk vond... maar toegegeven, dat was wel altijd een major controller update, niet een patch als deze

ZTNA is zeker interessant, ook om achteraf dingen te kunnen nagaan na een breach. Zouden we meer mee moeten doen. We hebben al wel zoiets met diverse software van HashiCorp gedaan voor bijvoorbeeld SSH sessies met tijdelijke credentials e.d., maar het lijkt niet heel triviaal om dat zomaar voor alle bestaande services in het netwerk te kunnen toepassen. Verder in duiken dus

[Mathijs Kok]

[...]

Insgelijks. Dingen zouden er blijkbaar constant uit liggen anders. Jij stopt gewoon met het beheren van je netwerk tot je de patch kan installeren? Ik doe aan strikte netwerksegmentatie juist om dit soort situaties.

Als je de software niet kent, waarom dan reageren? Jouw segmentatie maakt in dit geval namelijk niets uit. Niets gevaarlijker dan een netwerkbeheerder die denkt het antwoord te hebben.

[Sfynx]

Waarom maakt het precies niets uit als je alle gevoelige dingen zoals een UniFi controller in een gescheiden netwerk zet waar alleen de mensen bij kunnen die erbij horen te kunnen?

[Equator]

Dat kan wel wat vriendelijker toch?

Mitigerende maatregelen zijn er om risico te verlagen. Risico is altijd een inschatting van kans x impact. Als jij het netwerk van een multinational beheert, snap ik jouw risico, maar bij mij thuis is de impact veel kleiner.

Natuurlijk, zsm patchen is good practice en andere maatregelen nemen ook, maar vergeet niet dat elk bedrijf anders naar risico kijkt. En een afgeschermd management netwerk is al een mitigerende maatregel (tenzij je het natuurlijk openzet voor alles en iedereen, dan ben ik het met je eens)

[Reactie gewijzigd door Equator op 20 maart 2026 10:31]

[DennusB]

Assumption is the mother of all fuckups

[murkienl]

Met een cloudkey of selfhosted controller kan dat inderdaad. Met een UniFi gateway is dat een ander verhaal. Deze kan je, voor zover ik weet, niet anders dan in VLAN 1 laten. Correct me if I'm wrong.

[jbhc]

Je kunt vlan 1 dan toch als management vlan gebruiken?

[bazzi]

Idd en die standaard niet exposen aan je porten, tenzij strict noodzakelijk, want unifi device 😉

Vergeet alleen de firewall regels tussen de vlans niet 😉

[Reactie gewijzigd door bazzi op 20 maart 2026 07:39]

[murkienl]

Nee want dan komt alles default in je mgmt vlan. Een keer een poortje op een nieuwe switch configureren is makkelijker vergeten dan een apart vlan voor mgmt. Ik heb nog nooit een netwerk gezien waar vlan 1 als mgmt vlan werd gebruikt eerlijk gezegd.

[Caelestis]

De default netwerk zit inderdaad vast in VLAN 1 en dat is goed voor een aantal recovery opties maar je kan het ook blokkeren en je eigen VLANs gebruiken.

[murkienl]

Dat sowieao, maar met wen cloudkey kan de de control plane zelf ook in een vlan hangen met een gateway van UniFi, voor zover ik weet, niet. Daar zit in mijn geval altijd alles in een mgmt vlan behalve de gateway zelf.

[Caelestis]

Ik begrijp niet helemaal waarom je een cloudkey tegelijk met een Unifi gateway wil gebruiken. Een cloudkey is bedoeld voor het beheer van Unifi apparatuur op een netwerk zonder Unifi gateway.
Maar nee je kan de Gateway IP pool niet aanpassen maar wel blokkeren. Dit is ook de reden waarom je de management VLAN kan isoleren van alle andere VLANs en toch updates binnen kan krijgen.

[murkienl]

Ik zeg nergena dat ik het tegelijk gebruik. Het enige wat ik aangeef is dat je een Cloudkey wel in een vlan kan hangen maar een gateway niet. Ik heb veel omgevingen te beheren en een deel daarvan heeft een Cloudkey en een Sophos firewall. Het andere deel heeft een UniFi gateway.

Bij de netwerken met Cloudkey staan alle UniFi apparaten netjes in het mgmt vlan. Bij de netwerken met UniFi gateway staat alles behalve de gateway in het mgmt vlan omdat de gateway zelf niet native in een ander vlan dan vlan1 (b)lijkt te kunnen.

[Caelestis]

Een cloudkey is niet een router vandaar het verschil.

[murkienl]

Joh!

Je mist mijn punt structureel maar thanks voor het duidelijk maken dat een Cloudkey geen router is..

[Caelestis]

Het is eerder dat jij niet begrijpt waarom veel fabrikanten de default VLAN vast zet. Je Cloudkey is totaal irrelevant in dit verhaal omdat het enkel een netwerk apparaat is op je netwerk. Natuurlijk kan deze in elke VLAN gedropt worden net als een NAS of een camera.
Waar jij het over hebt is of de VLAN controler zijn eigen native VLAN kan aanpassen.

Technisch kan je dat vrij geven maar er is geen reden om dat te doen.
Je kan daarmee het apparaat dusdanig configureren dat je de gateway brickt. Dat is gewoon slechte service.
Wat je wil is de eerste VLAN isoleren zodat alles wat erin gestoken wordt met een kabel ongetagged blijft en pas als de netwerk admin het apparaat toewijst dat het op je netwerk mag komen.
Het is een stukje veiligheid wat vrij normaal is in bedrijfsnetwerken.

[murkienl]

Daarom kan elk zelfrespecterend merk wel zo geconfigureerd worden dat deze alleen beheerd kan worden vanuit een mgmt vlan. Vlan 1 gebruiken als mgmt vlan is gewoon niet best practice.

Dat heeft echt helemaal niks te maken met dat een fabrikant een default vlan "vast zet". En het punt dat je probeert te maken slaat ook de spijker nog steeds compleet mis.

Het zou technisch gewoon mogelijk moeten zijn om de gateway voor beheer alleen vanuit een nader te bepalen vlan bereikbaar te laten zijn.

Als iemand niet weet wat hij doet dan kan hij inderdaad de boel om zeep helpen en zal diegene het apparaat moeten resetten. Maar diegene zal dan ook niet iets moeten doen waarvan die niet weet wat hij doet. Wellicht val jij daar ook onder en probeer je een punt te maken die er niet is.

[Caelestis]

Vlan 1 gebruiken als mgmt vlan is gewoon niet best practice.

Zelfs Cisco zet de eerste VLAN vast maar jij zal beter weten toch?

[murkienl]

Voor mgmt purposes? Noem een merk waar je niet het mgmt vlan op een ander vlan dan vlan 1 kan instellen.

(Dan weet ik in ieder geval welke ik nooit naar hoef om te kijken)

[Caelestis]

Cisco

[murkienl]

Daar kan je prima alles dicht zetten behalve een specifiek vlan.

[Caelestis]

Nou heb je het over dichtzetten? Je kan ze allemaal dichtzetten. Je kan enkel de gateway niet uit VLAN 1 halen. Je gateway is je gezicht naar buiten. Wat denk je dat je staat te verbergen? Dat je interne IP eindigt met 254.1 i.p.v 0.1
Als jouw netwerk veiligheid staat of valt op een VLAN toewijzing dat heb je echte brakke netwerk apparatuur.

De grap is dat jij denkt dat er iets bestaat als een management VLAN. Geen enkel VLAN heeft een specifiek doel.
Als jij al je netwerk apparatuur in een apart VLAN zet en het mgmt noemt is het net alsof je een folder naam gewijzigd hebt, meer niet.
Een VLAN kan pas een "management" VLAN worden met de juiste firewall rules. Je focus ligt dan ook helemaal fout.

En ja zowel Ubiquiti als Cisco raden aan om je netwerk apparatuur in een apart VLAN te plaatsen. Alles behalve je gateway...
Dit zijn bedrijven gericht op remote management en elke keuze dat ze gemaakt hebben is specifiek voor dat doel.
Je hebt het over "best practices" en gaat dan een ontwerp keuze belachelijk maken van de fabrikant die de best practices heeft geschreven. Wat je niet begrijpt, is als je de Cisco apparatuur niet kan betalen dan kom je uit op de B keuze spul zoals Fortinet, Aruba, Nortel, Netgear ect...

Ubiquiti is de C keuze met de ontwerp gedachtes van de A keuze spul. Beste waar voor je geld.

[Reactie gewijzigd door Caelestis op 24 maart 2026 18:25]

[murkienl]

Mijn god. Ik heb nergens gezegd dat er een specifiek vlan bestaat. Ik heb alleen gezegd dat je bij een UniFi gateway geen network override kan doen voor het "mgmt".

Maar jij wilde een punt maken die er niet was.. slow clap..

[Z0ntar]

Ik ga er vanuit dat je je thuis situatie bedoelt, anders wel erg dom om je kop zo in t zand te steken.

[Sfynx]

Ik heb het idee dat je denkt dat ik dit soort dingen gewoon direct aan het internet hang. Alles waar alleen systeembeheer bij moet kunnen gaat per definitie in een afgeschermd netwerk. Je hebt ook genoeg van die dingen zoals BMC's/IPMI e.d. die je dezelfde behandeling geeft, juist omdat die ook regelmatig bekende lekken hebben die soms niet eens meer worden opgelost. Supermicro had daar een handje van.

Natuurlijk update je dingen zo snel mogelijk (bij deze UniFi controller inmiddels gedaan), maar in de tussentijd moet alles wel gewoon doorgaan en is het niet altijd haalbaar om het volledig offline te gooien. Dus harden je ook je netwerk zelf.

[daanb14]

Heb je een specifiek gebruiksscenario om de self hosted UniFi Network Controller via het internet bereikbaar te maken? Dat is een goed recept voor een dosis ellende bij een kwetsbaarheid als dit.

[Drardollan]

Als je het goed inricht heb je sowieso enkel poort 8080 vanaf extern open staan, dat is de poort waarop de devices communiceren. De GUI hang je netjes achter een VPN indien nodig.

Nog beter is natuurlijk ook poort 8080 beperken tot enkel bekende IP adressen, maar daar moet je dan wel de mogelijkheden en kennis voor hebben. Zeker met devices achter dynamische IP adressen is dat wat lastiger, maar het kan wel.

[daanb14]

Dat laatste is precies hoe ik het oploste. Inform-poort alleen gewhitelist vanuit bekende IPs en de GUI achter een VPN. Ik wil niet weten hoeveel partijen dom genoeg zijn om de GUI direct aan het internet te hangen. Dat zijn dezelfde partijen die de GUI van een FortiGate zonder local-in policies aan het internet hangen.

[Drardollan]

Een Forti GUI moet je zelfs met de local-in policies niet aan het internet hangen, ook daar is al genoeg mis mee gegaan. Altijd VPN is mijn motto.

[rens-br]

Ik had mijn controller eerst naar buiten open staan, omdat ik die ook gebruikte om de netwerken van andere mee te beheren. Inmiddels zit op al die plekken een Ubiquiti Cloud Gateway Ultra met eigen ingebouwde controller, dus is dat niet meer nodig.

Ik had daar overigens in de firewall wel toegang tot één IP op ingesteld.

[daanb14]

Precies. In een scenario waar dat nodig is, zoals bijvoorbeeld ook bij FortiGates als je ze op afstand wilt beheren, moet je heel goed nadenken over de implicaties daarvan. Bij FortiGate was dat met local-in policies. In het geval van een UniFi Network Controller door er goede firewall policies voor te zetten. Maar bij voorkeur natuurlijk nog liever met dedicated tunnels voor management. Verhoogt de complexiteit, maar is wel veiliger.

[par4]

Meestal wordt dat bedoelt met het netwerk ja.

[Drardollan]

Uiteraard, dat is precies het risico. Direct patchen of de virtuele stekker uit. Elke minuut telt, nu dit bekend is kan je er van op aan dat er vanavond nog een exploit gaat zijn. Mede dankzij AI gaat dit sneller dan ooit.

[robertwebbe]

Ik vond het al verdacht dat afgelopen 2 weken er zo ontzettend veel verbindingspogingen van allerlei landen werden gemaakt, vooral vanuit Brazilië en Rusland. En dan ook op beide WAN’s. Normaal gesproken komen er altijd wel wat verzoeken maar nu iedere paar seconden, 24 uur per dag door, alsof er een script van alles aan het testen was om toegang te krijgen tot mijn UDM-PM. Alles wordt geblokkeerd maar toch vond ik dit opvallend.

[CPM]

Dus ze moeten al in je interne netwerk zijn en toegang hebben tot je controller. Als ze al binnen zijn, dan is een controller niet meer interessant. Dan ga je voor data.

[Drardollan]

Heel veel controllers hangen open en bloot aan het internet. Die lopen een groot risico en zijn belangrijk om direct te patchen óf van het internet te halen.

[Marctraider]

Echt een heel slecht idee om services open en bloot aan het www te hangen.

Ik heb een self-hosted VM NextCloud instance, maar zelfs met automatische updates acht ik het niet veilig.

Neuh, dan neem ik mijn kansen wel met Wireguard om buiten mijn lokale netwerk (Dus buitenshuis) mijn LAN te bereiken.

Groot voordeel is minder attack surface (alleen Wireguard), geen gezeur met updates en mogelijkheid tot software/compatibility breakage.. Al je services zijn bereikbaar, geen gezeur met (self signed) certificates. En meest belangrijk: Geen stress.

Beveiliging laten afhangen van derden is exact tegen mijn principes en wat ik wil bereiken.

100% self-hosting containment en een statische omgeving met minimaal onderhoud.


Was met een niet-rooted phone even pielen, maar gelukkig bied Rethink app op Android tegenwoordig een half baked 'Firewall', met mogelijkheid tot system wide adblocking en als toevoeging een Wireguard tunnel.

Dit is met native niet mogelijk op Android, want maar 1 VPN slot kan per keer gebruikt worden. Deze mooie app chained alles aan elkaar ;-)

[Reactie gewijzigd door Marctraider op 20 maart 2026 07:55]

[CPM]

Specificeer open en bloot eens en op welke feiten is jouw opmerking gebaseerd?Want geen enkele controller heeft zijn management interface of controller poorten standaard aan de WAN interface hangen. En firewall rules zouden altijd NEE specifiek tenzij moeten zijn.

[Drardollan]

Ik denk dat je geen idee hebt hoeveel Unifi controllers hun GUI zonder extra maatregelen vanaf het internet beschikbaar hebben. Een management VLAN veranderd daar niks aan.

[CPM]

Nee ik heb geen idee, jij wel? En wat bedoel je dan met management VLAN? Dat heeft toch niets met mijn WAN opmerking te maken.

Naja, als je moedwillig je controller (en/of GUI) via WAN/NAT/Firewall/whatever zonder fatsoenlijke (rule) maatregelen dan ben je gewoon een slechte beheerder.

[VDB Computers]

Vanmiddag heb ik bij een aantal relaties een controle uitgevoerd op hun systemen. Mooi om te zien dat de kritieke updates overal automatisch worden geïnstalleerd.

Alle controllers draaien netjes op versie .89, wat aangeeft dat het updatebeleid goed is ingericht en ook daadwerkelijk werkt zoals bedoeld.

Er worden regelmatig kwetsbaarheden ontdekt, dus het is prettig dat de fabrikant snel met updates komt én dat deze zonder handmatige acties worden doorgevoerd. Dat scheelt risico en beheerwerk.

Tegelijkertijd is het ook begrijpelijk dat sommige beheerders ervoor kiezen om updates handmatig uit te voeren. Updates kunnen immers impact hebben op de stabiliteit of compatibiliteit van een omgeving, en in bepaalde situaties is het wenselijk om eerst zelf te testen voordat deze breed worden uitgerold. Uiteindelijk blijft het een afweging tussen snelheid, risico en controle.

[Gunner]

Mijn controller is van buiten niet bereikbaar. Nu zal ik de update morgen wel installeren maar maakt het dan in de basis minder kwetsbaar zoals ik het lees?

[EnigmA-X]

Hier staat het vrij duidelijk beschreven:

https://community.ui.com/releases/Security-Advisory-Bulletin-062-062/c29719c0-405e-4d4a-8f26-e343e99f931b

[Gunner]

Gister al gelezen Nou ja de vraag is natuurlijk omdat ik hier ook wat discussie lees over hoe "access to the network” te interpreteren valt.


Anyway gister voor het slapen gaan op update gedrukt.

[DaggerGun]

Ik gebruik zelf een Dream Machine. De UniFi controller zit daar gewoon ingebakken in de firmware, dus automatisch update is fix.

Dit is geen lek waarbij iemand zomaar van buitenaf kan inbreken. Je moet al in het netwerk zitten of via wifi, VPN of een ander apparaat dat al gecompromitteerd is voordat je er überhaupt wat mee kan.

Het risico zit dus vooral bij mensen die al toegang hebben, niet bij willekeurige aanvallen van buiten. Of zie ik dit juist verkeerd?

[EnigmA-X]

De unifi controller kan gewoon openstaan naar de buitenwereld - voor beheer van buitenaf/via je telefoon. Ook kan je hem gebruiken voor het beheer van unifi op een andere locatie, waarbij unifi devices connectie maken met de controller via publiek internet.

Kortom, is niet zo zwart/wit als je schrijft.

[DaggerGun]

Ja fair. het is niet zo zwart-wit inderdaad. Hangt er vooral vanaf hoe je UniFi hebt ingericht en of je dingen exposed hebt naar buiten.

Wat ik bedoelde is meer dat het geen simpele remote exploit is waar iemand van buitenaf zomaar in komt zonder enige toegang. Maar als je controller (bewust of via config) wel bereikbaar is, dan wordt het natuurlijk een ander verhaal.

[FBI1988]

Heb inderdaad net m'n internet exposed controller gepatcht. Had fijn geweest als hij wel in de apt libraries was gepubliceerd.

[Reactie gewijzigd door FBI1988 op 19 maart 2026 23:43]

[SG]

Ik heb edge router achter twee ISP LAN hangen. Geen remote beheer. Unifi cloudkey en unifi qnap switches Qnap NAS.

[ThinkPad]

Helaas is er nog geen update van de jacobalberty/unifi Docker container. Is al wel een issue geopend om ASAP bij te werken, maar laatste update van de container is al weer 3 maanden geleden…