Syyskuun puolivälissä 2026 kaksi maailman käytetyintä DNS-resolveriohjelmistoa sai lähes samaan aikaan vakavan tietoturvakorjauksen. Ensin ISC julkaisi BIND 9:lle päivityksen, joka tukki 14 haavoittuvuutta. Viikon sisällä myös toinen keskeinen toimija, hollantilainen NLnet Labs, myönsi oman ongelmansa: Unbound-resolverin DNS-over-HTTPS-toteutuksesta löytyi CVE-2026-82720, muistivirhe joka voi kaataa palvelun etänä ilman tunnistautumista. Kahden itsenäisen projektin haavoittuvuudet samalla viikolla eivät ole sattumaa. Ne ovat oire siitä, että DoH-protokollan monimutkaisuus koettelee jopa kokeneita C-kielen kehittäjiä.
Unbound on yksi eniten käytetyistä avoimen lähdekoodin DNS-resolvereista. Sitä ajetaan muun muassa pfSense- ja OPNsense-palomuureissa, yksityisyyttä korostavissa DNS-palveluissa ja lukemattomissa Linux-jakeluissa oletusresolverina. Kun tällaisesta ohjelmistosta löytyy etänä laukaistava muistivirhe, vaikutuspiiri ei rajoitu suuriin operaattoreihin vaan ulottuu kotireitittimiin ja pienten yritysten palvelinhuoneisiin asti.
Suomalaisille ja pohjoismaisille lukijoille tapaus on ajankohtainen kahdesta syystä. Ensinnäkin DNS over HTTPS on viime vuosina yleistynyt juuri yksityisyyssyistä: selaimet, reitittimet ja mobiilikäyttöjärjestelmät tarjoavat sen yhä useammin oletuksena, jotta operaattori tai kolmas osapuoli ei näkisi selväkielisiä DNS-kyselyjä. Toiseksi moni pieni palveluntarjoaja ja yritys on rakentanut oman DoH-yhdyskäytävänsä juuri Unboundin päälle, koska se on ilmainen, hyvin dokumentoitu ja helposti integroitavissa olemassa olevaan verkkoinfrastruktuuriin. Sama työkalu, joka piti DNS-liikenteen piilossa ulkopuolisilta, muuttuu nyt itse riskitekijäksi jos päivitystä ei asenneta.
Mikä CVE-2026-82720 on
NLnet Labs julkaisi haavoittuvuustiedotteen 16. syyskuuta 2026. Yhtiön oma advisory kuvaa CVE-2026-82720:n käytä-vapautuksen-jälkeen-virheeksi (use-after-free, CWE-416) Unboundin DNS-over-HTTPS-virtojen siivouslogiikassa. Haavoittuvuus koskee Unbound-versioita 1.12.0–1.26.0, mutta vain silloin kun ohjelmisto on käännetty DoH-tuella eli --with-libnghttp2-asetuksella. Korjaus tuli versiossa 1.26.1, joka julkaistiin samana päivänä advisoryn kanssa.
Käytännön vaikutus on palvelunestohyökkäys. Vialliset muistiluvut eivät ole hyökkääjän hallittavissa, joten koodin suorittaminen etänä ei vaikuta advisoryn perusteella todennäköiseltä. Sen sijaan koventunut muistinhallinta (hardened allocator) voi havaita virheen ja sulkea prosessin hallitusti, mikä johtaa palvelun katkeamiseen. Julkisesti saatavilla olevista lähteistä ei löydy vahvistettua CVSS-pistemäärää tälle CVE:lle, joten organisaatioiden kannattaa arvioida riski oman ympäristönsä altistuksen perusteella eikä pelkän pisteytyksen mukaan.
CWE-416-luokan virheet, eli use-after-free-tyyppiset ongelmat, ovat perinteisesti kuuluneet vakavimpien muistiturvavikojen joukkoon, koska pahimmillaan ne voivat johtaa mielivaltaisen koodin suorittamiseen jos hyökkääjä pystyy hallitsemaan mitä vapautettuun muistiin kirjoitetaan sen jälkeen. NLnet Labsin oman kuvauksen mukaan tässä tapauksessa luetut arvot eivät ole hyökkääjän ohjattavissa, mikä rajaa vaikutuksen käytännössä kaatumiseen. Tämä ero on tärkeä ylläpitäjille: kyseessä ei ole tiedon vuotamisen tai etäkoodin suorittamisen riski parhaan tämänhetkisen tiedon valossa, vaan saatavuuteen kohdistuva uhka. Saatavuuskin voi kuitenkin olla liiketoiminnalle kallis, jos DNS-resolveri on kriittisen palvelun edessä.
Näin virhe laukeaa teknisesti
Ongelma piilee kohdassa, jossa Unbound siivoaa yhden DoH-virran (stream) HTTP/2-yhteydeltä. Kun yksi virta pudotetaan virhetilanteessa, esimerkiksi RPZ-torjuntasäännön (Response Policy Zone) takia tai raskaan kuormituksen aiheuttaman karsinnan yhteydessä, koko DoH-istunto voidaan sulkea virheellisesti. Siivouskoodi ei tällöin ota huomioon muita samalla HTTP/2-yhteydellä kulkevia virtoja oikein. Myöhempi koodi yrittää käyttää jo vapautettua muistialuetta, mikä on juuri use-after-free-virheen määritelmä.
NLnet Labsin advisoryn mukaan hyökkäys on mahdollista käynnistää yhdellä hyvin ajoitetulla DoH-yhteydellä ja sopivalla liikennekuviolla, jos edellä mainitut ehdot (RPZ-pudotus tai kuormituksesta johtuva karsinta) täyttyvät. Hyökkääjä ei tarvitse tunnuksia eikä erityisoikeuksia palvelimelle.
Mitä –with-libnghttp2 tarkoittaa käytännössä
--with-libnghttp2 on käännösaikainen asetus, joka liittää Unboundiin nghttp2-kirjaston HTTP/2-tuen. Tätä tarvitaan, jotta resolveri voi tarjota tai käyttää DNS-over-HTTPS-liikennettä. Jos oma Unbound-asennus on käännetty ilman tätä optiota, DoH-toiminnallisuus puuttuu kokonaan eikä haavoittuvuus koske asennusta. Pelkkä versionumeron tarkistus ei siis riitä: ylläpitäjän pitää varmistaa myös käännösasetukset ja se, onko DoH ylipäätään päällä palvelimen konfiguraatiossa.
Kuka löysi haavoittuvuuden
NLnet Labsin tiedotteessa haavoittuvuuden löytäjiksi mainitaan Yuqi Qiu ja Xiang Li Nankain yliopiston AOSP-laboratoriosta Kiinasta. Vastuullinen ilmoitusprosessi eteni tavanomaista reittiä: tutkijat raportoivat löydöksen valmistajalle, NLnet Labs vahvisti ongelman, rakensi korjauksen ja julkaisi sen yhdessä julkisen advisoryn kanssa. Julkisista lähteistä ei löydy mainintaa siitä, että haavoittuvuutta olisi hyödynnetty aktiivisesti ennen korjauksen julkaisua.
Korjaus: päivitä Unbound versioon 1.26.1
NLnet Labsin 1.26.1-julkaisutiedote mainitsee suoraan korjaavansa “CVE-2026-82720, Use-after-free in DoH stream cleanup code path”. Ylläpitäjän kannattaa ensin tarkistaa käytössä oleva versio ja sen jälkeen päivittää lähdekoodista tai jakelun paketinhallinnasta riippuen. Debianilla ja Ubuntulla komennot näyttävät tyypillisesti tältä:
unbound-control status | grep version
sudo apt update
sudo apt install --only-upgrade unbound
sudo systemctl restart unbound
unbound -VJos päivitys ei ole heti mahdollista, väliaikainen lieventämiskeino on poistaa DoH-kuuntelija käytöstä palvelimen konfiguraatiosta tai varmistaa, ettei DoH-liikennettä ohjata kyseiselle instanssille ollenkaan. Tämä ei korjaa itse ohjelmistoa, mutta pienentää hyökkäyspintaa siihen asti kunnes päivitys voidaan asentaa hallitusti.
Ketkä ovat vaarassa: vaikutusala
Haavoittuvuus koskee sekä auktoritatiivisia palvelimia että rekursiivisia resolvereja, kunhan DoH-tuki on käännetty mukaan ja aktivoitu. Käytännössä riskiryhmään kuuluvat yritysten ja operaattoreiden omat DNS-infrastruktuurit, palomuurit joissa Unbound toimii resolverimoottorina, sekä yksityishenkilöiden pystyttämät DoH-yhdyskäytävät kotiverkoissa. Julkisesti internetissä avoinna olevat DoH-päätepisteet ovat luonnollisesti alttiimpia kuin sisäverkkoon rajatut resolverit, koska hyökkääjän pitää pystyä lähettämään muotoiltu DoH-pyyntö suoraan palvelimelle.
Konkreettisia esimerkkejä alttiista ympäristöistä löytyy yllättävän läheltä arkea. OpenWrt-pohjaiset reitittimet, joihin käyttäjä on itse asentanut Unboundin DoH-tuella yksityisyyden parantamiseksi, kuuluvat riskiryhmään yhtä lailla kuin operaattoritason resolveriklusterit. Sama koskee pienten ja keskisuurten yritysten VPN-yhdyskäytäviä, joissa DNS-liikenne halutaan salata työntekijöiden liikkuessa etätöissä. Koska Unbound on kevyt ja ilmainen, se on päätynyt osaksi hyvin monenlaista laitteistoa aina IoT-yhdyskäytävistä pilvipalveluiden sisäisiin resolvereihin, mikä tekee kattavasta inventaariosta erityisen työlästä mutta myös erityisen tärkeää.
Sama viikko, kaksi haavoittuvuutta: Unbound vastaan BIND 9
ISC julkaisi 16. syyskuuta 2026 BIND 9:lle korjauksen, joka tukki 14 haavoittuvuutta yhdellä kertaa. Merkittävin niistä oli CVE-2026-77692, joka mahdollistaa named-prosessin kaatamisen yhdellä muotoillulla DoH-pyynnöllä. ISC:n oman kuvauksen mukaan kaatuminen laukeaa, kun DoH-pyyntö sisältää kryptografisesti virheellisen SIG(0)-tietueen ja yhteys suljetaan ennenaikaisesti. Korjaus tuli versioihin BIND 9.20.29 ja 9.21.26. Samassa päivityksessä korjattiin myös erillinen CVE-2026-3593, joka on niin ikään use-after-free-virhe BIND:n DoH-toteutuksessa ja laukeaa muotoillulla HTTP/2-liikenteellä.
Alla oleva taulukko kokoaa syyskuun 2026 keskeisimmät DoH-liitännäiset muistiturvahaavoittuvuudet kahdessa eri projektissa.
| Ohjelmisto | CVE | Virhetyyppi | Vaikutus | Korjattu versiossa |
|---|---|---|---|---|
| Unbound (NLnet Labs) | CVE-2026-82720 | Use-after-free (CWE-416) DoH-virran siivouksessa | Palvelunesto, prosessi voi kaatua | 1.26.1 |
| BIND 9 (ISC) | CVE-2026-77692 | Kaatuminen virheellisellä SIG(0)-tietueella | named-prosessin kaatuminen | 9.20.29 / 9.21.26 |
| BIND 9 (ISC) | CVE-2026-3593 | Use-after-free DoH-toteutuksessa | Muistin korruptio, palvelunesto | 9.20.29 / 9.21.26 |
| BIND 9 (ISC) | CVE-2026-80274, -76163, -19666, -81563, -19667, -81736 | Muun muassa SVCB/HTTPS AliasMode, TKEY, NOQNAME-todisteet | Vaihtelee, osa palvelunestoa | 9.20.29 / 9.21.26 |
Onko kyse samasta bugista? Ei
Vaikka ajoitus näyttää epäilyttävältä, saatavilla oleva näyttö osoittaa kahden itsenäisen ongelman esiintyneen samana viikkona. Unboundia ylläpitää NLnet Labs, BIND 9:ää ISC. Koodikannat ovat erilliset, CVE-tunnisteet omansa ja haavoittuvuudet omissa advisoryissaan. Yhteys on arkkitehtuurin tasolla, ei koodin tasolla: molemmat projektit ovat lisänneet DNS-ytimeen HTTP/2-pohjaisen web-protokollapinon, ja juuri se yhdistelmä tuottaa uudenlaisia elinkaari- ja muistinhallintavirheitä joita perinteinen DNS-viestien jäsennys ei koskaan altistanut.
DoH:n kasvu ja sen hinta: yksityisyys monimutkaisuuden kustannuksella
DNS over HTTPS syntyi alun perin ratkaisuksi yksinkertaiseen ongelmaan: selväkielinen DNS-kysely paljastaa jokaiselle välissä olevalle verkkolaitteelle mitä verkko-osoitetta käyttäjä on hakemassa, vaikka itse sivun sisältö kulkisi HTTPS:n suojaamana. Salaamalla myös DNS-kysely operaattorit, julkiset WiFi-verkot ja muut väliin asettuvat osapuolet menettävät näkyvyyden käyttäjän selailukohteisiin. Selainvalmistajat ja käyttöjärjestelmät ajoivat protokollaa aktiivisesti eteenpäin viime vuosina, ja se on nyt vakiovarustusta uusimmissa Firefox-, Chrome- ja Windows-versioissa.
Se yksinkertainen tavoite, DNS-kyselyn piilottaminen, vaati kuitenkin koko HTTP/2-protokollapinon tuomista DNS-palvelimen sisään. Ennen DoH:ta DNS-palvelinohjelmiston tehtävä oli jäsentää tiukasti määritelty binäärimuotoinen DNS-viesti UDP:n tai TCP:n päällä. DoH:n myötä sama ohjelmisto joutuu käsittelemään TLS-kättelyjä, HTTP-otsikoita, moninkertaistettuja virtoja ja virtakohtaista peruutuslogiikkaa. Jokainen näistä lisäyksistä kasvattaa koodin määrää ja sitä kautta myös mahdollisten virheiden määrää. Syyskuun 2026 tapaukset ovat konkreettinen esimerkki siitä, että yksityisyyshyöty ja hyökkäyspinnan kasvu kulkevat käsi kädessä, eikä kumpaakaan pidä tarkastella ilman toista.
Miksi DNS over HTTPS synnyttää jatkuvasti muistivirheitä
Perinteinen DNS on yksinkertainen: kysely lähetetään, vastaus jäsennetään, yhteys sulkeutuu. DoH sen sijaan tuo mukaan koko HTTP/2-pinon: TLS-yhteydet, moninkertaistetut virrat samalla yhteydellä, virtojen peruutuslogiikan ja vuonhallinnan. Yhdellä HTTP/2-yhteydellä voi kulkea kymmeniä rinnakkaisia DNS-kyselyitä, ja yhden niistä siivoaminen ei saa koskaan rikkoa muiden tilaa.
C-kielellä kirjoitetuissa resolvereissa tämä tarkoittaa käsin hallittua muistinvarausta ja -vapautusta jokaiselle oliolle erikseen. Onnistuneet polut testataan yleensä perusteellisesti, mutta virhetilanteet, kuten RPZ-torjunnat, aikakatkaisut tai kuormituksesta johtuva karsinta, jäävät testauksessa helposti vähemmälle huomiolle. Juuri niissä poluissa CVE-2026-82720 ja BIND:n vastaavat virheet piilivät. C ei itsessään ole ainoa syy virheisiin, mutta se ei myöskään pakota kehittäjää todistamaan muistin omistajuutta kääntäjän tasolla, toisin kuin esimerkiksi Rust tekisi.
Historiallinen konteksti: resolverien tietoturva ei ole uusi ongelma
DNS-ohjelmistojen muistiturvahistoria ulottuu vuosikymmenten taakse, mutta DoH:n tulo protokollaan on avannut uuden hyökkäyspinnan viime vuosina. Shattered.io on aiemmin raportoinut sekä BIND 9:n syyskuun DoH-haavoittuvuuksista että laajemmasta DNS over HTTPS -asennuksesta käytännön oppaana. Molemmat tekstit korostavat samaa asiaa: DoH parantaa yksityisyyttä salaamalla DNS-liikenteen, mutta jokainen lisätty protokollakerros on myös lisätty koodimäärä, jota pitää ylläpitää ja testata.
Sama ilmiö näkyi myös aiemmin tänä vuonna, kun Venäjä esti Googlen ja Cloudflaren DoH-palvelut maan sisäisessä liikenteessä, ja kun cPanel-haavoittuvuus jätti puolitoista miljoonaa palvelinta alttiiksi lähes kaksi kuukautta ennen korjausta. DNS-infrastruktuuri on jatkuvasti hyökkääjien ja tutkijoiden tutkan alla, koska se on internetin selkäranka. Jos resolveri kaatuu, kaikki sen takana olevat palvelut näyttävät olevan poissa käytöstä.
Pohjoismainen ja suomalainen näkökulma
Toisin kuin BIND 9:n syyskuun päivityksen yhteydessä, julkisista lähteistä ei löydy tätä kirjoitettaessa erillistä Traficomin Kyberturvallisuuskeskuksen tai muiden Pohjoismaiden CERT-yksiköiden tiedotetta nimenomaan CVE-2026-82720:stä. Se ei tarkoita, ettei riskiä olisi Suomessa tai muissa Pohjoismaissa, vaan pikemminkin sitä, että kansallinen tiedotus seuraa usein perässä muutaman viikon viiveellä tai julkaistaan vain suoraan operaattoreille suunnatuissa kanavissa.
Suomalaisten yritysten ja operaattoreiden kannattaa tarkistaa oma Unbound-jalanjälkensä itse sen sijaan, että odottaisi kansallista varoitusta. Moni pieni ja keskisuuri yritys ajaa Unboundia tietämättään esimerkiksi pfSense- tai OPNsense-palomuurin sisällä, koska molemmat projektit käyttävät sitä oletusresolverinaan. Kyberturvallisuuskeskuksen haavoittuvuustiedotteita kannattaa seurata joka tapauksessa, sillä ne päivittyvät usein jälkikäteen kun kansainväliset CVE-tietokannat on käyty läpi.
Markkinavaikutus operaattoreille ja yrityksille
Kahden suuren DNS-resolveriprojektin haavoittuvuudet samalla viikolla nostavat esiin kysymyksen, joka on vaivannut IT-osastoja jo pitkään: kuinka moni DoH-päätepiste on ylipäätään ylläpidetty ja seurattu yhtä huolellisesti kuin vaikkapa verkkopalvelimet? DNS-resolverit mielletään usein taustainfrastruktuuriksi, joka pystytetään kerran ja unohdetaan. Nyt nähdyt haavoittuvuudet muistuttavat, että resolveri on yhtä kriittinen komponentti kuin mikä tahansa julkisesti auki oleva palvelu, ja sitä pitää päivittää samalla kurinalaisuudella.
Palveluntarjoajille, jotka tarjoavat julkisia DoH-resolvereita asiakkailleen, tapaus on erityisen kiusallinen. Palvelunestohaavoittuvuus julkisessa DoH-päätepisteessä voi katkaista nimenselvityksen kaikilta sitä käyttäviltä asiakkailta yhdellä hyökkäyksellä, vaikka itse hyökkääjä ei pääsisi käsiksi mihinkään dataan. Yrityksille tämä tarkoittaa käytännössä sitä, että DNS-resolverin päivityssykli pitää nostaa samalle tasolle kuin verkkopalvelimien tai VPN-yhdyskäytävien.
DNS-katkoksen taloudellinen hinta ei rajoitu pelkkään nimenselvitykseen. Kun resolveri kaatuu, kaikki sen taakse riippuvaiset sovellukset, sähköpostijärjestelmät ja sisäiset palvelut alkavat tyypillisesti epäonnistua lähes samanaikaisesti, koska nimenselvitys on yksi harvoista todella universaaleista riippuvuuksista modernissa IT-ympäristössä. Tukipyyntöjen määrä kasvaa nopeasti, ja vika voi aluksi näyttää täysin erilliseltä ongelmalta esimerkiksi sovelluspalvelimella, kunnes juurisyy jäljitetään DNS-tasolle asti. Tämä hidastaa vasteaikaa juuri niissä organisaatioissa, joissa DNS-infrastruktuuria ei ole erikseen valvottu omana kokonaisuutenaan.
Mitä tapaus opettaa haavoittuvuudenhallinnasta
CVE-2026-82720 ja BIND 9:n syyskuun korjaukset paljastavat saman aukon, joka toistuu organisaatiosta toiseen: DNS-resolveri jää usein järjestelmähallinnan ja tietoturvatiimin väliin siten, ettei kumpikaan omista sen päivityssykliä täysin. Verkkotiimi asentaa resolverin osana palomuuria tai reititinlaitteistoa, ja sen jälkeen ohjelmisto elää usein vuosia ilman erillistä tietoturvakatselmusta, koska se mielletään osaksi verkkolaitteen laiteohjelmistoa eikä erilliseksi ohjelmistoksi jota pitäisi seurata CVE-tietokannoista.
Toinen opetus koskee versionumeroiden luotettavuutta. Kuten aiemmin mainittiin, monet jakelut taustapaikkaavat korjauksia muuttamatta näkyvää versiomerkintää, mikä tarkoittaa että automaattinen versiontarkistus voi antaa väärän turvallisuuden tunteen. Kolmas opetus liittyy käännösasetusten näkyvyyteen: haavoittuvuus koskee vain DoH-tuella käännettyjä asennuksia, joten organisaatioiden pitäisi ylläpitää tarkkaa kirjanpitoa siitä, millä asetuksilla mikäkin resolveri-instanssi on rakennettu, eikä olettaa että kaikki asennukset ovat identtisiä.
DNS-resolveriohjelmistojen kilpailukenttä
Yhtä kattavaa, julkisesti vahvistettua markkinaosuustilastoa neljälle suurimmalle avoimen lähdekoodin resolverille ei ole olemassa, koska mittaustavat (internetiin avoinna olevat palvelimet, jakelupaketit, sisäiset asennukset) eivät ole keskenään vertailukelpoisia. Yleiskuva alan seurannasta on kuitenkin selkeä ja auttaa hahmottamaan miksi juuri Unbound ja BIND nousivat otsikoihin samalla viikolla.
| Ohjelmisto | Ylläpitäjä | Tyypillinen käyttökohde | DoH-tuki | Muistiturva-CVE syyskuussa 2026 |
|---|---|---|---|---|
| Unbound | NLnet Labs | Palomuurit (pfSense, OPNsense), yksityisyysratkaisut, paikalliset resolverit | Kyllä, –with-libnghttp2 | CVE-2026-82720 |
| BIND 9 | ISC | Operaattorit, auktoritatiiviset palvelimet, yritysinfrastruktuuri | Kyllä | CVE-2026-77692, CVE-2026-3593 ym. |
| PowerDNS Recursor | PowerDNS.COM | Hosting-yhtiöt, operaattorit | Kyllä | Ei syyskuun 2026 tapauksia tässä katsauksessa |
| Knot Resolver | CZ.NIC | Tutkimusverkot, tietyt operaattorit | Kyllä | Ei syyskuun 2026 tapauksia tässä katsauksessa |
Taulukon viimeinen sarake ei tarkoita, että PowerDNS Recursor tai Knot Resolver olisivat vapaita muistiturvariskeistä pysyvästi. Se kertoo vain, ettei tämän katsauksen taustatutkimuksessa noussut esiin niitä koskevia vastaavia syyskuun 2026 tapauksia. Molemmat projektit ovat toteuttaneet DoH:n samalla HTTP/2-pohjaisella arkkitehtuurilla, joten sama virheluokka on niissäkin teoriassa mahdollinen.
Jakelujen ja pilvipalveluiden reagointi
Suurimmat Linux-jakelut reagoivat nopeasti. Sekä Debianin tietoturvaseuranta että Ubuntun tietoturvasivusto listasivat CVE-2026-82720:n omiin seurantajärjestelmiinsä samana päivänä kuin NLnet Labsin advisory julkaistiin. Myös Red Hat päivitti oman CVE-tietokantansa vastaavasti. Yleinen käytäntö on, että jakelut taustapaikkaavat (backport) korjauksen omaan pakettiversioonsa muuttamatta näkyvää versionumeroa, mikä tarkoittaa että pelkkä unbound -V ei aina kerro koko totuutta. Ylläpitäjän pitää tarkistaa myös oman jakelunsa muutosloki (changelog) varmistuakseen, että korjaus on todella asennettu.
Kansainväliset CVE-viitetietokannat, kuten CVE.org:n oma tietue, toimivat keskitettynä lähteenä joka kokoaa valmistajan advisoryn, jakeluiden tilan ja muun julkisen tiedon yhteen paikkaan. Yritysten kannattaa liittää nämä lähteet omaan haavoittuvuudenhallintaprosessiinsa, jotta vastaavat tapaukset havaitaan jatkossa nopeammin kuin pelkän mediaseurannan varassa.
Ennusteet: mitä DoH-tietoturvalle tapahtuu seuraavaksi
Toimituksemme analyysin perusteella syyskuun 2026 tapahtumat viitoittavat muutaman todennäköisen suunnan lähikuukausille. Ennusteet perustuvat havaittuun kuvioon, ei vahvistettuihin ilmoituksiin valmistajilta, joten niitä kannattaa lukea suuntaa-antavana analyysinä eikä varmana tienä.
- Fuzz-testaus laajenee virhepolkuihin. DNS-resolveriprojektit todennäköisesti lisäävät automatisoitua fuzz-testausta juuri niihin koodipolkuihin, joissa virhetilanteet (RPZ-torjunnat, aikakatkaisut, ylikuormitus) yhdistyvät HTTP/2-virtojen elinkaareen, koska juuri nämä polut jäivät aiemmin vähemmälle testaukselle.
- Lisää DoH-CVE:itä on odotettavissa myös muissa toteutuksissa. Koska PowerDNS Recursor ja Knot Resolver käyttävät rakenteellisesti samantyyppistä HTTP/2-pinoa, on todennäköistä että vastaava virheluokka löytyy niistäkin ennemmin tai myöhemmin.
- Yritykset alkavat harkita DoH:n oletusarvoista pois kytkemistä palvelininstansseilta, joilla sitä ei aktiivisesti tarvita, kunnes koodikanta on osoittanut vakautensa pidemmällä aikavälillä.
- Nordic CERT-yksiköt, mukaan lukien Traficomin Kyberturvallisuuskeskus, todennäköisesti julkaisevat oman haavoittuvuustiedotteensa CVE-2026-82720:stä viiveellä, samaan tapaan kuin aiempien BIND-tapausten yhteydessä on nähty.
- Muistiturvallisempien kielten, erityisesti Rustin, käyttö uusissa verkkoprotokollaparsereissa yleistyy edelleen resolverikehityksessä, vaikka olemassa olevien C-pohjaisten koodikantojen uudelleenkirjoitus etenee hitaasti niiden koon ja kriittisyyden vuoksi.
Näin suojaudut nyt
Käytännön toimenpiteet kannattaa aloittaa inventaariosta: mihin kaikkiin palvelimiin, palomuureihin ja verkkolaitteisiin Unbound on asennettu organisaatiossa, ja onko DoH-tuki niissä käytössä. Sen jälkeen jokainen DoH-tuella käännetty asennus pitää päivittää versioon 1.26.1 tai uudempaan mahdollisimman pian. Jos päivitystä ei voida asentaa heti tuotantoikkunan ulkopuolella, DoH-kuuntelija kannattaa väliaikaisesti sulkea tai rajata pääsy siihen palomuurisäännöillä.
On myös hyvä varmistaa, että lokitus on päällä resolverin kaatumisten havaitsemiseksi. Toistuvat odottamattomat uudelleenkäynnistykset voivat olla merkki siitä, että joku yrittää aktiivisesti laukaista haavoittuvuutta, vaikka onnistunut hyökkäys johtaisikin vain palvelunestoon eikä tietovuotoon. Samalla kannattaa käydä läpi myös BIND-asennukset, jos organisaatiolla on molempia resolvereita käytössä, sillä syyskuun 2026 korjaukset koskevat molempia projekteja erikseen.
Vikasietoisuuden kannalta kannattaa myös harkita useamman resolveri-instanssin ajamista kuormantasauksen takana, jotta yhden prosessin kaatuminen ei katkaise koko organisaation nimenselvitystä. Automaattinen uudelleenkäynnistys (esimerkiksi systemd:n restart-politiikalla) lieventää yksittäisen kaatumisen vaikutusta, mutta ei poista itse haavoittuvuutta eikä estä toistuvia hyökkäysyrityksiä. Pitkällä aikavälillä paras suoja on pysyä ajan tasalla sekä Unboundin että muiden käytössä olevien resolveriohjelmistojen tietoturvatiedotteista ja rakentaa päivitysprosessi, joka ei ole riippuvainen yksittäisen ylläpitäjän muistista.
Usein kysytyt kysymykset
- Mikä on CVE-2026-82720? Se on NLnet Labsin 16. syyskuuta 2026 julkaisema use-after-free-haavoittuvuus Unbound-resolverin DNS-over-HTTPS-virtojen siivouskoodissa. Se voi johtaa palvelun kaatumiseen etänä ilman tunnistautumista.
- Mitkä Unbound-versiot ovat haavoittuvia? Versiot 1.12.0–1.26.0, mutta ainoastaan jos ohjelmisto on käännetty DoH-tuella (–with-libnghttp2). Korjaus tuli versiossa 1.26.1.
- Onko haavoittuvuutta hyödynnetty aktiivisesti? Julkisista lähteistä ei tätä kirjoitettaessa löydy näyttöä aktiivisesta hyväksikäytöstä ennen korjauksen julkaisua.
- Miten päivitän Unboundin turvallisesti? Tarkista nykyinen versio komennolla unbound -V, päivitä jakelun paketinhallinnan kautta tai lähdekoodista, ja käynnistä palvelu uudelleen. Tarkista myös jakelusi muutosloki, jos versionumero ei suoraan näytä 1.26.1:tä.
- Liittyykö tämä BIND 9:n syyskuun haavoittuvuuksiin? Ei suoraan. Kyseessä ovat kahden eri valmistajan (NLnet Labs ja ISC) itsenäiset haavoittuvuudet, jotka paljastuivat samalla viikolla. Yhteys on arkkitehtuurin tasolla: molemmat lisäsivät DNS-ytimeen HTTP/2-pohjaisen DoH-tuen.
- Vaikuttaako tämä Pi-hole- tai OPNsense-asennuksiin? Kyllä, jos taustalla ajetaan haavoittuvaa Unbound-versiota DoH-tuella. pfSense ja OPNsense käyttävät Unboundia oletusresolverinaan, joten ylläpitäjien kannattaa tarkistaa oma versionsa erikseen.
- Onko Suomen viranomaisilla varoitusta asiasta? Julkista, erillistä Traficomin Kyberturvallisuuskeskuksen tiedotetta juuri tästä CVE:stä ei ollut tätä kirjoitettaessa saatavilla. Kansallinen tiedotus usein seuraa kansainvälisiä advisoryja viiveellä.
- Miten tunnistan, onko oma DNS-resolverini altis? Selvitä käytössä oleva resolveriohjelmisto ja versio, tarkista onko DoH-tuki käännetty ja aktivoitu, ja vertaa versiota valmistajan julkaisemaan korjattuun versioon ennen kuin oletat asennuksen olevan turvassa.
