Drupali kriitiline paik ilmub 14. oktoobril — uuenduseks tuleb aeg kohe broneerida

Drupali turvameeskonna 12. oktoobri eelteade määrab kriitilise põhivara turvaparanduse avaldamiseks 14. oktoobril 2026 ajavahemiku 16.00–21.00 UTC ehk Eesti aja järgi 19.00–järgmise päeva 00.00; parandus puudutab toetatud harusid Drupal 11.4.x, 11.3.x ja 10.6.x, mõjutatud on ka Drupal 12.0.0-beta1 ning esialgne riskihinnang on 19/25. Turvameeskond palub uuenduseks aja varuda, sest pärast avalikustamist võib ärakasutuskood valmida tundide või päevadega. Teada on avaldamisaken ja mõjutatud harud, kuid vea tehnilised üksikasjad selguvad koos turvateatega. Saidihaldaja saab juba praegu teha taastatava varukoopia, proovida olemasolevat veaparandusväljalaset ja reserveerida hooldusaja.

Georgia Techi College of Computingu tehnoloogiatalituse erakorraline hooldusteade näeb 14. oktoobril 2026 ette põhivara uuendamise 12 Drupali veebilehel. Asutus arvestab hoolduse ajal võimalike katkestustega nii külastajatele kui ka sisutoimetajatele ning palub viimastel töö enne hooldust salvestada ja välja logida. Eesti saidipidajal tasub samal põhjusel ettevalmistus teha enne paiga ilmumist: pärast avaldamist on vaja keskenduda konkreetse väljalaske paigaldamisele ja tulemuse kontrollile.

Milline Drupali paigaldus vajab ettevalmistust?

Toetatud põhivara harud saavad turvaparanduse; beetaversioonile lubatakse uus beetaväljalase pärast toetatud harude turvauuendusi. Iga saidi puhul tuleb tuvastada tootmiskeskkonnas tegelikult kasutatav põhivara versioon, mitte lähtuda üksnes projektiplaanist või varasemast uuenduspiletist. Kui haldaja vastutab mitme saidi eest, aitab lühike inventuur siduda iga veebiaadressi selle koodibaasi, paigaldusviisi ja juurutuse eest vastutava inimesega.

Vanema, toetamata haru puhul ei saa loota sama haru uut turvapaika. Sellisele saidile tuleb kavandada liikumine toetatud harule ning üle vaadata moodulite, teemade ja oma koodi sobivus. Ühise koodibaasiga saitidel võib üks uuendus puudutada korraga mitut veebilehte, kuid nende seadistus ja kasutajate põhitoimingud võivad erineda. Need erinevused tuleb inventuuris kirja panna, et paigalduse järel ei piirdutaks ainult ühe avalehe avamisega.

Drupal Stewardi kasutava saidi puhul on osa teadaolevaid ründeviise juba kaetud, kuid see kaitse ei pruugi hõlmata kõiki võimalikke ärakasutusviise. Ka selle teenuse kasutajal tuleb kavandada põhivara uuendamine. Esialgne riskihinnang ei anna enne turvateate avaldamist alust oletada, milline komponent või sisend vea põhjustab.

Mida teha enne turvaväljalaske akent?

Drupali arendaja Droptica 12. oktoobri käsitlus soovitab hoida proovikeskkonna tootmiskeskkonnaga kooskõlas, määrata paigalduse tegija ja kinnitaja, valmistada ette tagasipöördumine ning jälgida pärast paigaldust logisid. Selle turvaväljalaske jaoks peab hooldusaken katma ka proovimise ja võimaliku taastamise aja. Määra inimene, kellel on vajalikud ligipääsud, ning lepi sisutoimetajatega kokku, millal muudatused peatatakse.

Enne turvapaiga avaldamist saab oma harus paigaldada viimase juba kättesaadava veaparandusväljalaske. See aitab lahendada tavapärased sõltuvus- ja juurutusprobleemid enne kriitilist uuendusakent. Kõigepealt proovi sama muudatust keskkonnas, mis vastab tootmissaidile kasutatava PHP, andmebaasi ja moodulite poolest. Üksnes sõltuvuste loendi edukas uuendamine ei näita, kas veebilehe vormid, sisselogimine või sisutoimetamine töötavad.

Varukoopia peab võimaldama taastada omavahel sobiva andmebaasi, üles laaditud failid ja kasutusel olnud koodi. Kontrolli, kus koopia asub, kes saab seda kasutada ja kas taastamine on proovikeskkonnas läbi tehtud. Jäta alles praeguse juurutuse versioon ja sõltuvuste lukustusfail; muidu võib tagasipöördumisel tekkida koodi ning andmebaasi seisude vastuolu. Pane kirja ka olulised kasutustoimingud ja nende tavapärane käitumine, et pärast muudatust oleks võimalik probleemi tekkimise aega piiritleda.

Mis juhtub pärast turvateate ilmumist?

Uue teate avaldamisel tuleb valida oma põhivara harule mõeldud parandus ning lugeda selle väljalaske märkusi enne paigaldust. Siis selgub, milliseid samme sait lisaks põhivara koodi uuendamisele vajab. Avaldamiseelne prooviuuendus aitab lahendada juba teadaolevaid sõltuvusprobleeme, kuid uut turvapaika ennast saab proovida alles selle ilmumise järel.

Composeriga hallatavas projektis peaks tootmiskeskkonda jõudma sama kontrollitud kood ja sõltuvuste lukustusfail, mis läbis proovikeskkonna. Kui paketihaldur ei leia õiget väljalaset või mõni sõltuvus tõkestab paigaldust, tuleb tõkestuse põhjus selgitada enne tootmiskeskkonna muutmist. Eraldi käsitsi hallatava paigalduse puhul tuleb järgida selle saidi tegelikku uuenduskorda; käsud ja failivahetus ei pruugi olla samad. Hooldusrežiimi kasutamine sõltub saidi juurutusest ning sellest, kas kasutajate kirjutamistoimingud tuleb muudatuse ajaks peatada.

Pärast koodi paigaldamist tee vajalikud andmebaasiuuendused ja ehita vahemälud uuesti, seejärel vaata, kas olekuraport näitab oodatud väljalaset. Kui kood vahetus, kuid vajalik andmebaasimuudatus jäi tegemata, võib veebileht esmapilgul avaneda ja mõni sisuhalduse toiming siiski läbi kukkuda. Seepärast tuleb hooldusakna lõppu jätta ruumi ka funktsioonide läbiproovimiseks.

Millal võib hoolduse lõpetada?

Kontrolli saiti esmalt välja logitud külastajana ning seejärel sisutoimetaja õigustega. Ava need vormid, sisselogimise teed ja ühendused, mis olid enne uuendust kontrollnimekirjas; mitme saidi korral korda põhikontroll iga mõjutatud veebilehe juures. Vaata Drupali olekuraportit ja hiljutisi veateateid, et märgata probleeme, mida üks avalehe laadimine ei paljasta.

Logides tasub eristada paigaldusest tekkinud vead tavapärasest liiklusest ning uurida ebatavalisi päringuid ja ootamatuid haldusmuudatusi. Kui mõni põhitoiming ei tööta, fikseeri selle ilmumise aeg ja mõjutatud saidid ning otsusta varem ette valmistatud taastamisplaani järgi. Enne kasutajatele hoolduse lõppemisest teatamist veendu, et hooldusrežiim on välja lülitatud ja sisutoimetamine saab jätkuda.

Järgmine otsustav hetk saabub koos turvateate ning harupõhiste väljalasetega: siis selgub paiga täpne versioon ja selle paigaldusjuhis. Seni saab haldaja eemaldada uuendustee teadaolevad tõkked ning hoida hooldusakna vabana, et paigaldus saaks alata pärast avaldamist.

Loe ka:

• Webex toob Claude’i meeskonnaliikmeks, kuid funktsioon tuleb hiljem
• DMARC ilma katkestuseta: „reject“ tuleb alles pärast aruannete kontrolli
• Kaks Citrix NetScaleri nullpäeva on ründajate käes — uuendusest üksi ei piisa