Internet Systems Consortium eli ISC julkaisi 16. syyskuuta 2026 hätäkorjauksen, joka paikkaa 14 haavoittuvuutta suositussa BIND 9 -nimipalvelinohjelmistossa. Seitsemän niistä luokitellaan korkean vakavuusasteen vioiksi. Yksi nousee ylitse muiden: CVE-2026-77692, jonka avulla tunnistautumaton hyökkääjä voi kaataa nimipalvelun yhdellä ainoalla DNS over HTTPS -pyynnöllä. Vika osuu suoraan siihen tekniikkaan, jota miljoonat selaimet ja käyttäjät luottavat suojaamaan DNS-kyselynsä salakuuntelulta.
Check Point Research nosti asian esiin 21. syyskuuta julkaistussa uhkakatsauksessaan, ja tietoturvamediat kuten The Hacker News ja SecurityWeek ovat sittemmin käsitelleet tapausta laajasti. Tämä artikkeli käy läpi, mitä täsmälleen paikattiin, ketä vika koskee ja mitä se kertoo laajemmasta ongelmasta: salattu yhteys ei auta, jos itse palvelinohjelmisto kaatuu ensimmäisenä.
Tapaus osuu suoraan suomalaisten ja pohjoismaisten käyttäjien arkeen kahdella tavalla. Ensinnäkin yhä useampi selain ja reititin tarjoaa DNS over HTTPS -asetuksen oletuksena, ja moni yksityisyystietoinen käyttäjä on ottanut sen käyttöön juuri operaattorin DNS-seurannan välttämiseksi. Toiseksi moni kotimainen palveluntarjoaja, oppilaitos ja viranomainen rakentaa oman resolveri-infrastruktuurinsa avoimen lähdekoodin ohjelmistojen, kuten BIND:n, varaan, jolloin syyskuun korjauslista ei ole vain kansainvälinen uutinen vaan suora tehtävälista kotimaisille ylläpitäjille.
Mitä tapahtui 16. syyskuuta: ISC:n hätäkorjaus lyhyesti
ISC ylläpitää BIND 9:ää, joka on yksi maailman vanhimmista ja laajimmin käytetyistä avoimen lähdekoodin nimipalvelinohjelmistoista. Syyskuun 16. päivä julkaistussa neuvossa yhtiö listasi 14 erillistä haavoittuvuutta, jotka koskevat sekä vakaata 9.20-sarjaa että kehitysversiota 9.21. Korjaukset julkaistiin samana päivänä versioina 9.20.29 ja 9.21.26.
Seitsemän 14 viasta sai korkean vakavuusluokituksen, koska ne voivat johtaa palvelunestoon etäältä ilman tunnistautumista. Käytännössä tämä tarkoittaa, että hyökkääjä ei tarvitse käyttäjätunnusta, salasanaa tai pääsyä sisäverkkoon. Riittää, että kohde kuuntelee julkista verkkoliikennettä, jolloin haitallinen paketti kelpaa suoraan.
ISC:n oma tietokanta merkitsi myös vanhemman 9.18-haaran elinkaarensa päähän tämän neuvon yhteydessä. Se tarkoittaa, ettei kyseiseen versioon tule enää erillistä korjausta, vaikka sama koodikanta saattaisi sisältää samoja heikkouksia. Ylläpitäjien on siis siirryttävä tuettuun haaraan, ei vain odotettava paikkaa.
CVE-2026-77692 lähikuvassa: yksi pyyntö kaataa named-prosessin
Kaikista 14 viasta eniten huomiota on saanut CVE-2026-77692, jonka CVSS-pisteytys on 7,5 eli korkea. Kansallinen haavoittuvuustietokanta NVD ja ISC:n oma tietoturvaneuvoja kuvaavat vian samalla tavalla: hyökkääjä lähettää DNS over HTTPS -pyynnön, joka sisältää kryptografisesti virheellisen SIG(0)-allekirjoituksen, ja katkaisee yhteyden ennenaikaisesti ennen kuin palvelin ehtii käsitellä virhetilanteen loppuun. Tämä ajaa named-prosessin niin sanottuun null-osoitin-virheeseen, joka on luokiteltu tunnisteella CWE-476.
Miten hyökkäys toimii teknisesti
DNS over HTTPS pakkaa tavallisen DNS-kyselyn HTTPS-yhteyden sisään, yleensä HTTP/2- tai HTTP/3-kuljetuksella. Tavallisesti tämä nostaa yksityisyyttä, koska ulkopuolinen tarkkailija näkee vain salatun HTTPS-liikenteen, ei itse kyselyn sisältöä. BIND-palvelimen tapauksessa ongelma syntyy virheenkäsittelyssä: kun asiakas sulkee yhteyden kesken allekirjoituksen tarkistuksen, palvelin yrittää käsitellä jo poistunutta yhteysobjektia. Seuraus ei ole tietovuoto vaan saatavuusongelma. Named-prosessi kaatuu, ja DNS-kyselyt kyseisellä palvelimella pysähtyvät, kunnes prosessi käynnistetään uudelleen.
Vaikutus rajoittuu siis palvelun saatavuuteen, ei salaisuuksien paljastumiseen. Se ei tee tilanteesta vähäpätöistä. Yksi ainoa hyökkääjä voi toistaa pyynnön automaattisesti ja pitää nimipalvelun alhaalla niin kauan kuin haluaa, jos korjausta ei ole asennettu.
Haavoittuvuus koskee ISC:n mukaan versioita 9.20.0–9.20.27, 9.21.0–9.21.25 sekä tuettua esikatseluversiota 9.20.9-S1–9.20.27-S1. Kaikki nämä on päivitettävä versioon 9.20.29 tai 9.21.26 ongelman poistamiseksi.
Muut kuusi korkean vakavuuden haavoittuvuutta
CVE-2026-77692 ei ole ainoa merkittävä löydös. ISC:n neuvo listaa yhteensä seitsemän korkean vakavuusasteen tunnistetta, ja loput kuusi liittyvät muun muassa virheellisiin NOQNAME-todisteisiin, erikoisesti muotoiltuihin QTYPE/TKEY-kyselyihin, auktoritatiivisilta palvelimilta tuleviin vääristyneisiin vastauksiin, SVCB- ja HTTPS-tietueiden AliasMode-käsittelyyn sekä ylisuuriin negatiivisiin vastauksiin, joiden koko voi nousta 65 536 tavuun asti. Yhteistä näille on sama lopputulos: palvelun kaatuminen tai muistin loppuminen etäältä käynnistettynä.
| CVE-tunniste | Vakavuus | Vaikutus | Korjattu versiossa |
|---|---|---|---|
| CVE-2026-77692 | Korkea (CVSS 7,5) | DoH-pyyntö kaataa named-prosessin ilman tunnistautumista | 9.20.29 / 9.21.26 |
| CVE-2026-80274 | Korkea | Etänä käynnistettävä palvelunestoehto | 9.20.29 / 9.21.26 |
| CVE-2026-76163 | Korkea | Etänä käynnistettävä palvelunestoehto | 9.20.29 / 9.21.26 |
| CVE-2026-19666 | Korkea | Etänä käynnistettävä palvelunestoehto | 9.20.29 / 9.21.26 |
| CVE-2026-81563 | Korkea | Etänä käynnistettävä palvelunestoehto | 9.20.29 / 9.21.26 |
| CVE-2026-19667 | Korkea | Etänä käynnistettävä palvelunestoehto | 9.20.29 / 9.21.26 |
| CVE-2026-81736 | Korkea | Etänä käynnistettävä palvelunestoehto | 9.20.29 / 9.21.26 |
Loput seitsemän tunnistetta ISC luokitteli matalammaksi tai keskitasoiseksi riskiksi. Niitäkin kannattaa korjata samalla päivityksellä, koska sama julkaisu sisältää molemmat korjaussarjat kerralla eikä osittaista päivitystä ole tarjolla.
Miksi BIND 9 on niin tärkeä osa internetin selkärankaa
BIND, lyhenne sanoista Berkeley Internet Name Domain, on peräisin 1980-luvulta ja on yhä yksi harvoista nimipalvelinohjelmistoista, jotka kattavat sekä auktoritatiivisen palvelun että rekursiivisen resolverin saman koodikannan alla. Operaattorit, yliopistot, valtionhallinnon verkot ja suuret yritykset käyttävät sitä laajasti, koska se tukee lähes kaikkia DNS-laajennuksia: DNSSEC-allekirjoitusta ja -validointia, vyöhykesiirtoja ja nykyään myös DNS over HTTPS -kuljetusta.
Juuri tämä laajuus tekee jokaisesta BIND-haavoittuvuudesta merkittävän uutisen. Kyse ei ole kapeasta erikoisohjelmasta vaan infrastruktuurin osasta, joka toimii usein näkymättömissä käyttäjän arjessa. Kun nimipalvelu kaatuu, mikään sen taakse riippuvainen sivusto, sähköposti tai sovellus ei enää löydy verkosta, vaikka itse palvelu olisi muuten täysin toiminnassa.
DNS over HTTPS selitettynä: salaus ei estä palvelimen kaatumista
DNS over HTTPS eli DoH kehitettiin ratkaisemaan yksi vanha yksityisyysongelma: perinteinen DNS-kysely kulkee verkossa selväkielisenä, jolloin internetoperaattori, julkisen wifin ylläpitäjä tai kuka tahansa samassa verkkosegmentissä voi nähdä, mitä verkko-osoitteita käyttäjä hakee. DoH kääntää saman kyselyn HTTPS-yhteyden sisään, jolloin ulkopuolinen näkee vain salatun liikenteen selaimen ja valitun resolverin välillä.
Tämä on hyödyllistä yksityisyyden kannalta, mutta se ei tee resolveripalvelusta haavoittumatonta. BIND-tapaus osoittaa juuri sen: salaus suojaa siirron sisältöä, mutta ei suojaa itse ohjelmiston virhekäsittelyä. Jos resolverin koodissa on virhe, joka laukeaa erikoisesti muotoillusta pyynnöstä, salauskerros ei estä hyökkääjää lähettämästä sitä. Yksityisyys ja saatavuus ovat kaksi eri asiaa, ja tämä tapaus muistuttaa, ettei kumpaakaan voi olettaa toisen mukana tulevan ilmaiseksi.
Ketkä käyttävät DoH:ta ja koskeeko tämä heitä
Suurimmat julkiset DoH-tarjoajat, kuten Cloudflaren 1.1.1.1, Googlen julkinen DNS, Quad9 ja NextDNS, ajavat yleensä omaa resolveriohjelmistoaan, eivät suoraan BIND:iä. Riski ei siis kohdistu ensisijaisesti niihin. Se kohdistuu sen sijaan tuhansiin operaattoreihin, yliopistoihin, yrityksiin ja julkishallinnon toimijoihin, jotka ovat itse pystyttäneet BIND-pohjaisen resolverin ja kytkeneet siihen DoH-tuen omaa verkkoaan tai asiakkaitaan varten. Mozilla Firefox ja monet muut selaimet tukevat DoH-asetusta, ja käyttäjä voi valita resolverikseen minkä tahansa yhteensopivan palvelun, mukaan lukien organisaation oman sisäisen palvelimen.
Juuri tämä oma-pystytetty kerros on riskialttein. Moni pienempi operaattori tai yritys on ottanut DoH-tuen käyttöön viime vuosina vastatakseen käyttäjien yksityisyysodotuksiin, mutta ei välttämättä seuraa ISC:n julkaisuja yhtä tiiviisti kuin suuret pilvitoimijat. Näille organisaatioille syyskuun päivitys on juuri se tilaisuus, joka jää helposti huomaamatta ilman systemaattista haavoittuvuudenhallintaa.
| Palvelu / ohjelmisto | Rooli | Tukee DoH:ta | Suora BIND-riippuvuus |
|---|---|---|---|
| Cloudflare 1.1.1.1 | Julkinen resolveri | Kyllä | Ei, oma resolveriohjelmisto |
| Google Public DNS | Julkinen resolveri | Kyllä | Ei, oma resolveriohjelmisto |
| Quad9 | Julkinen resolveri | Kyllä | Ei, oma resolveriohjelmisto |
| NextDNS | Julkinen resolveri | Kyllä | Ei, oma resolveriohjelmisto |
| Mozilla Firefox | Selain, DoH-asiakas | Kyllä (asetuksena) | Ei, riippuu valitusta resolverista |
| Operaattorin / yrityksen oma BIND-resolveri | Sisäinen tai asiakasresolveri | Vaihtelee, jos käyttöön otettu | Kyllä, suora riippuvuus tästä päivityksestä |
Korjaus vaatii version päivityksen, ei vain asetusmuutosta
Toisin kuin monissa aiemmissa DNS-haavoittuvuuksissa, tätä ongelmaa ei voi kiertää pelkällä palomuurisäännöllä tai DoH-tuen sammuttamisella väliaikaisesti, sillä sammuttaminen samalla poistaa juuri sen ominaisuuden, jonka vuoksi palvelu on alun perin otettu käyttöön. ISC suosittelee suoraa päivitystä. Ylläpitäjä voi tarkistaa käytössä olevan version yksinkertaisella komennolla.
named -v
# Tulosteen tulisi näyttää versio 9.20.29 tai uudempi,
# tai 9.21.26 tai uudempi kehityshaarassa.
# Jos versio on vanhempi, päivitä paketinhallinnalla:
apt update && apt install --only-upgrade bind9
# tai lataa lähdekoodi ISC:n virallisilta sivuilta ja käännä uudelleen.Vanhaa 9.18-haaraa käyttävien on siirryttävä kokonaan tuettuun sarjaan, koska erillistä korjausta ei enää tule. Tämä on hyvä muistutus siitä, että ylläpidon aikataulu kannattaa sitoa ohjelmiston omaan elinkaareen, ei vain siihen, milloin viimeksi jokin meni rikki.
Suomen ja Pohjoismaiden näkökulma
Suomen Kyberturvallisuuskeskus, joka toimii Traficomin alaisuudessa, julkaisee säännöllisesti viikkokatsauksia havaituista haavoittuvuuksista ja uhkista. Tämänkaltaiset laajalti levinneet infrastruktuurihaavoittuvuudet ovat juuri sitä materiaalia, jota keskus tyypillisesti nostaa esiin toimijoille suunnatuissa tiedotteissaan. Suomalaisille operaattoreille, yliopistoille ja julkishallinnon organisaatioille kannattaa muistaa, että moni kotimainen palveluntarjoaja rakentaa DNS-infrastruktuurinsa juuri avoimen lähdekoodin ratkaisujen, kuten BIND:n, varaan.
Pohjoismaissa yleisemminkin DNS over HTTPS on ollut ajankohtainen aihe muista syistä: Venäjä esimerkiksi esti pääsyn useisiin ulkomaisiin DoH-palveluihin elokuussa 2026. Tämä syyskuun BIND-tapaus on eri luonteinen ongelma, sillä kyse ei ole valtiollisesta estosta vaan ohjelmistovirheestä, mutta molemmat tapaukset korostavat samaa asiaa: DNS-kerros on muuttunut poliittisesti ja teknisesti yhä herkemmäksi osaksi verkkoinfrastruktuuria, eikä sitä enää voi pitää pelkkänä taustajärjestelmänä.
Tämä pätee myös laajempaan EU-tason valvontaan. NIS2-direktiivin kansallinen toimeenpano on tuonut Suomeen tiukemmat ilmoitusvelvollisuudet kriittisen infrastruktuurin häiriöistä, ja DNS-palvelut kuuluvat monessa organisaatiossa juuri siihen luokkaan, josta merkittävät häiriöt on ilmoitettava viranomaiselle määräajassa. Jos BIND-pohjainen resolveri kaatuisi toistuvasti hyväksikäytön seurauksena ja aiheuttaisi näkyvän palvelukatkon, kyse ei olisi enää pelkästä teknisestä ylläpitoasiasta vaan mahdollisesti myös sääntelyn piiriin kuuluvasta tapahtumasta. Tämä nostaa päivityksen kiireellisyyttä entisestään niille organisaatioille, joita NIS2-velvoitteet koskevat.
Yksityisyysnäkökulma: mitä tämä tarkoittaa DoH:n käyttäjille
Yksityisyyden kannalta kiinnostavin osa tätä tapausta ei ole itse kaatumisvirhe, vaan se, mitä se kertoo koko DoH-ekosysteemin luottamusketjusta. Kun käyttäjä valitsee selaimeensa DNS over HTTPS -resolverin yksityisyyden parantamiseksi, hän luottaa siihen, että valittu palvelu pysyy sekä luottamuksellisena että toiminnassa. Tämä tapaus erottaa nämä kaksi lupausta toisistaan konkreettisesti: luottamuksellisuus pysyi ennallaan, koska kyse ei ole tietovuodosta, mutta saatavuus voi horjua, jos ylläpitäjä ei ole päivittänyt palvelintaan.
Käytännön neuvo yksityisyydestään huolehtivalle käyttäjälle on yksinkertainen: jos oma organisaatio tai kotireititin käyttää itse ylläpidettyä DoH-resolveria, kannattaa varmistaa ylläpitäjältä, että BIND on päivitetty. Jos taas käytössä on jokin suurista julkisista DoH-palveluista, kuten Cloudflaren tai Quad9:n tarjoama resolveri, tilanne ei todennäköisesti muutu, koska nämä toimijat eivät yleensä aja BIND:iä tuotannossaan. Tämä ero on syytä pitää mielessä, ettei tapausta yleistetä koskemaan koko DoH-tekniikkaa, vaan yhtä tiettyä palvelinohjelmiston toteutusta siinä.
Historiallinen konteksti: BIND:n pitkä suhde haavoittuvuuksiin
Miksi juuri BIND kerää näin paljon huomiota
BIND on ollut osa internetin DNS-infrastruktuuria jo neljän vuosikymmenen ajan, ja pitkä ikä näkyy sekä vahvuutena että heikkoutena. Koodikanta on laaja ja tukee poikkeuksellisen montaa ominaisuutta, mikä tarkoittaa myös suurempaa hyökkäyspintaa kuin kevyemmillä, kapeampaa tehtävää hoitavilla vaihtoehdoilla. ISC on vuosien varrella julkaissut säännöllisin väliajoin tietoturvaneuvoja, ja suuri osa niistä on koskenut juuri palvelunestotyyppisiä vikoja, joissa erikoisesti muotoiltu kysely kaataa prosessin tai kuluttaa muistia hallitsemattomasti.
Syyskuun 2026 päivitys erottuu silti kokoluokaltaan: 14 haavoittuvuutta yhdessä julkaisussa on poikkeuksellisen suuri määrä, ja se, että yksi niistä osuu nimenomaan DoH-toiminnallisuuteen, tekee tapauksesta ajankohtaisen juuri nyt, kun DoH-käyttö on kasvanut merkittävästi selaimissa ja yksityisyystietoisten käyttäjien keskuudessa viime vuosina.
Kilpailija-asetelma: BIND vastaan muut nimipalvelinratkaisut
BIND ei ole ainoa vaihtoehto DNS-infrastruktuurin pystyttämiseen, ja tämä tapaus on nostanut uudelleen esiin keskustelun siitä, kannattaako organisaation keskittää koko DNS-kerroksensa yhden, ominaisuuksiltaan laajan ohjelmiston varaan. Vaihtoehtoja on useita, ja niiden filosofia eroaa selvästi BIND:stä.
Unbound keskittyy puhtaasti rekursiiviseen resolverointiin ja on suunniteltu tietoturva edellä, kapeammalla ominaisuusjoukolla kuin BIND. PowerDNS taas on suosittu erityisesti auktoritatiivisena palvelimena ja tarjoaa modulaarisen tietokantapohjaisen arkkitehtuurin, joka erottaa sen selkeästi BIND:n tiedostopohjaisesta perinteestä. Knot Resolver puolestaan on CZ.NIC:n kehittämä, moderni ja kevyt rekursiivinen resolveri, joka on suunniteltu alusta asti tukemaan DoH:n ja DoT:n kaltaisia salattuja kuljetuksia natiivisti. Yhteistä näille kilpaileville ratkaisuille on, että kapeampi tehtäväkenttä vähentää samalla mahdollisten virhetilanteiden määrää, mikä on juuri se argumentti, jota moni ylläpitäjä nostaa esiin tämän kaltaisten laaja-alaisten BIND-neuvojen jälkeen.
Tämä ei tarkoita, että BIND olisi huonompi valinta yleisesti. Sen laaja ominaisuuskirjo ja pitkä tuki tekevät siitä yhä oletusarvon monessa organisaatiossa, ja ISC:n nopea reagointi, korjaus julkaistiin samana päivänä kuin haavoittuvuudet paljastettiin, kertoo toimivasta ylläpitoprosessista. Kilpailija-asetelma kannattaa silti tuntea, kun DNS-arkkitehtuuria suunnitellaan uudelleen tämän tapauksen jälkeen.
Miksi DoH-pino on vaikeampi turvata kuin perinteinen DNS
Perinteinen DNS kulkee UDP:n yli yksinkertaisella, kevyellä protokollalla, jonka virhetilat on testattu ja tunnettu vuosikymmenten ajalta. DoH sen sijaan tuo mukaan koko HTTPS-pinon: TLS-kättelyn, HTTP/2- tai HTTP/3-kerroksen, yhteydenhallinnan ja usein myös monimutkaisemman virhepolun, jos yhteys katkeaa kesken käsittelyn. Jokainen näistä kerroksista on oma mahdollinen virhelähteensä, ja CVE-2026-77692 osuu juuri siihen saumaan, jossa kuljetuskerroksen katkeaminen ja sovelluslogiikan virheenkäsittely eivät kohdanneet odotetusti.
Tämä ei ole ainutlaatuista BIND:lle. Sama ilmiö toistuu käytännössä jokaisessa ohjelmistossa, joka on lisännyt DoH-tuen olemassa olevaan, alun perin muuta kuljetusta varten suunniteltuun koodikantaan. Analyytikot ovatkin nostaneet esiin, että DoH:n turvallisuustestaus vaatii oman testikattavuutensa juuri katkenneiden yhteyksien ja virheellisten kryptografisten kenttien osalta, koska nämä reitit jäävät helposti vähemmälle huomiolle normaalissa toiminnallisessa testauksessa.
Markkinavaikutus: mitä tämä tarkoittaa operaattoreille ja pilvipalveluille
Suoraa taloudellista vahinkoa tästä haavoittuvuudesta ei ole vielä raportoitu, eikä saatavilla olevien tietojen perusteella hyväksikäyttöä ole vahvistettu luonnossa syyskuun 2026 loppuun mennessä. Markkinavaikutus näkyy silti toisella tavalla: jokainen tällainen laaja neuvo pakottaa ylläpitotiimit käyttämään aikaa ja resursseja päivitysten testaamiseen ja käyttöönottoon kiireellisellä aikataululla, mikä on epäsuora mutta todellinen kustannus etenkin pienemmille operaattoreille ja hostingyhtiöille, joilla ei ole omaa täysiaikaista tietoturvatiimiä.
Pidemmällä aikavälillä tapaus todennäköisesti vauhdittaa keskustelua siitä, pitäisikö kriittisen DNS-infrastruktuurin nojata harvempiin, tarkemmin rajattuihin ohjelmistoihin sen sijaan, että yksi laaja-alainen projekti kantaa koko kuorman. Se ei tarkoita BIND:n hylkäämistä, mutta se tarkoittaa, että vaihtoehtojen, kuten Unboundin, PowerDNS:n ja Knot Resolverin, markkina-asema saattaa vahvistua juuri tämänkaltaisten tapausten jälkeen, kun organisaatiot arvioivat DNS-arkkitehtuurinsa riskiprofiilia uudelleen.
On myös syytä huomata, mitä ISC:n reaktionopeus kertoo avoimen lähdekoodin ylläpitomallista laajemmin. Neuvo ja korjaus julkaistiin samana päivänä, mikä tarkoittaa, että haavoittuvuudet oli käsitelty koordinoidusti ennen julkistusta eikä paikkaa jouduttu odottamaan viikkoja hyväksikäytön uhalla. Tämä on juuri se malli, jota säätiöpohjaiset ylläpitäjät, kuten ISC, ovat pyrkineet vahvistamaan vuosien varrella: rahoitus tulee suurelta osin operaattoreiden ja yritysten tuesta, ja vastineeksi kriittinen infrastruktuuriohjelmisto saa nopean, ennakoitavan päivityssyklin ilman kaupallisen toimittajan lisenssimaksuja.
Ennusteet: mitä seuraavaksi tapahtuu
- Odotettavissa on, että tietoturvatutkijat julkaisevat lähiviikkoina yksityiskohtaisempia teknisiä purkuja CVE-2026-77692:sta, mikä nostaa riskiä opportunistisesta hyväksikäytöstä niillä palvelimilla, joita ei ole vielä päivitetty.
- Suuret Linux-jakelut ja pilvialustat julkaisevat todennäköisesti omat paketoidut päivityksensä nopeasti syyskuun ja lokakuun 2026 aikana, mikä helpottaa massapäivityksiä automatisoiduissa ympäristöissä.
- Kansalliset CSIRT-toimijat Euroopassa, mukaan lukien Pohjoismaissa, todennäköisesti nostavat tämän neuvon osaksi omia haavoittuvuuskatsauksiaan seuraavien viikkojen aikana, koska kyseessä on laajalti käytetty infrastruktuuriohjelmisto.
- Keskustelu DoH-toteutusten erillisestä turvallisuustestauksesta todennäköisesti voimistuu muissakin DNS-ohjelmistoprojekteissa, ei vain BIND:ssä, koska sama arkkitehtuurinen riski koskee periaatteessa jokaista DoH:ta tukevaa palvelinta.
- On todennäköistä, että osa organisaatioista käyttää tätä tilaisuutta hyväkseen arvioidakseen uudelleen, tarvitsevatko ne todella BIND:n koko ominaisuuskirjon, vai riittäisikö kapeampi, pienemmän hyökkäyspinnan tarjoava vaihtoehto niiden käyttötapaukseen.
Näin tarkistat ja suojaat oman palvelimesi
Käytännön toimenpidelista on lyhyt mutta kiireellinen. Ensin selvitä, ajaako organisaatiosi BIND 9:ää ja onko siihen kytketty DoH-tuki. Jos vastaus on kyllä, päivitys pitää ajaa mahdollisimman pian tuotantoympäristöön testauksen jälkeen. Jos palvelin käyttää vanhaa 9.18-haaraa, siirtymä tuettuun sarjaan on tehtävä joka tapauksessa, koska erillistä korjausta siihen ei enää tule.
Kannattaa myös tarkistaa lokit epätavallisen suurista määristä katkenneita DoH-yhteyksiä ennen päivitystä, koska se voi olla merkki siitä, että joku on jo yrittänyt hyödyntää heikkoutta. ISC:n virallinen neuvo osoitteessa kb.isc.org sisältää täydellisen teknisen kuvauksen ja on ensisijainen lähde, johon ylläpitäjän kannattaa tukeutua asennuskomentojen ja täsmällisten versionumeroiden osalta. Tapausta ovat seuranneet myös SecurityWeek, The Hacker News, Check Point Research sekä virallinen CVE-tietokanta.
Usein kysytyt kysymykset
Mikä CVE-2026-77692 tarkalleen on?
Se on BIND 9:n haavoittuvuus, jonka avulla tunnistautumaton hyökkääjä voi kaataa named-prosessin lähettämällä yhden DNS over HTTPS -pyynnön, jossa on virheellinen SIG(0)-allekirjoitus, ja katkaisemalla yhteyden ennenaikaisesti.
Vaarantaako tämä haavoittuvuus tietojani, esimerkiksi selaushistoriaani?
Ei suoraan. Kyseessä on palvelunestohaavoittuvuus, joka kaataa palvelun, ei tietovuoto. Vaikutus näkyy DNS-palvelun katkeamisena, ei salassapidon murtumisena.
Koskeeko tämä minua, jos käytän Cloudflaren tai Googlen julkista DNS-palvelua?
Suorat julkiset DoH-tarjoajat ajavat yleensä omaa resolveriohjelmistoaan eivätkä BIND:iä, joten riski kohdistuu ensisijaisesti organisaatioihin, jotka ylläpitävät omaa BIND-pohjaista nimipalvelinta.
Mihin versioon minun pitää päivittää?
Vakaan 9.20-sarjan käyttäjien tulee päivittää versioon 9.20.29 tai uudempaan. Kehityshaaran 9.21 käyttäjien tulee päivittää versioon 9.21.26 tai uudempaan. Vanhan 9.18-haaran käyttäjien tulee siirtyä kokonaan tuettuun sarjaan.
Onko haavoittuvuutta jo hyödynnetty hyökkäyksissä?
Saatavilla olevien tietojen mukaan syyskuun 2026 loppuun mennessä ei ole vahvistettua näyttöä laajamittaisesta aktiivisesta hyväksikäytöstä, mutta tekninen yksityiskohtien julkisuus nostaa riskiä lähiviikkoina.
Voinko kiertää ongelman sammuttamalla DoH-tuen väliaikaisesti?
Se poistaisi hyökkäyspinnan, mutta samalla myös sen yksityisyyshyödyn, jonka vuoksi DoH otettiin alun perin käyttöön. ISC suosittelee suoraa versiopäivitystä kiertotien sijaan.
Mitä vaihtoehtoja BIND:lle on olemassa, jos haluan vähentää riskiä jatkossa?
Unbound, PowerDNS ja Knot Resolver ovat yleisimmin mainitut vaihtoehdot, joista jokainen keskittyy kapeampaan tehtäväkenttään kuin BIND:n laaja ominaisuuskirjo.
Onko Suomen viranomaisilla erillistä ohjeistusta tähän tapaukseen?
Suomen Kyberturvallisuuskeskus julkaisee säännöllisiä viikkokatsauksia haavoittuvuuksista, ja tämänkaltaiset laajalti levinneet infrastruktuurineuvot kuuluvat tyypillisesti niiden seurantaan. Ajantasaisin tieto kannattaa tarkistaa suoraan keskuksen omilta sivuilta.
