Sisukord6
- oktoobril 2026 avaldas PHP meeskond turvauuenduse, mis parandab kaks kriitilist turvanõrkust. Sotsiaalvõrgustikes kirjutati, et ohus on „80% of the internet“ ja et ründajad olevat kõigest aru saanud „in 15 minutes“. Tegelikkus on veidi vähem dramaatiline, kuid siiski tõsine. Siin on see, mis on tõsi, mida tuleb täna teha, ja küsimus, mille see hoiatus esitab kõigile, kellel on WordPressi või PrestaShopi veebileht.
Mida parandati
Kahel turvanõrkusel on numbrid CVE-2026-109618 ja CVE-2026-109619. PHP meeskond hindab neid oma teadaandes php.net-is 9,2-ga kümnest. Mõlemal juhul saab sisse logimata külastaja panna serveri käivitama oma koodi. Esimene tuleneb vigasest mäluhaldusest, kui mälu hakkab otsa saama. Teine tuleneb päringu andmetest, mis jäävad mällu ja mida järgmine päring uuesti kasutab.
Mõjutatud on kõik paigaldused, mis serveerivad veebilehti, olenemata režiimist: PHP-FPM, Apache koos mod_php-ga, LiteSpeed, FrankenPHP. php.net-i andmetel on kõige rohkem avatud mod_php, mille puhul demonstreeriti rünnakut juba enne, kui veebilehe kood käivitub.
Arv „80% of the internet“ on ümardatud ülespoole. PHP käitab suurt enamust veebilehtedest, mille tehnoloogia on teada, sealhulgas peaaegu kõiki WordPressi, PrestaShopi, Drupali ja Joomla lehti. Oht on seega lai, kuid mitte universaalne.
Mida täna teha
Uuendage PHP-d. Parandatud versioonid on 8.5.12, 8.4.27, 8.3.36 ja 8.2.35. Kui Teie majutusteenuse pakkuja haldab PHP-d Teie eest, kontrollige, kas ta on seda teinud, või paluge seda kirjalikult.
Kui Teie veebileht töötab veel PHP 8.1 või vanemal versioonil, ei avalda PHP projekt nendele harudele enam versioone. Tema meeskond on levitanud ainult tooreid parandusi, mille Teie majutaja peab ise rakendama. See on märk, et versiooniuuendus ei saa enam oodata.
Uuenduse ootel pakub php.net seadistusi, mis vähendavad riski, näiteks failide üleslaadimise edenemise jälgimise väljalülitamine. PHP meeskond ütleb seda ise: need seadistused ei muuda serverit turvaliseks, seda teeb ainult uuendus.
Miks tehisintellekt lühendab aega
Turvauuendus näitab täpselt, millised read muutusid. Ründajad võrdlevad vana ja uut versiooni, et turvanõrkus üles leida, ning kirjutavad seejärel rünnaku. See töö võttis varem päevi. Tänapäeva koodiassistentidega võib see võtta mõne tunni. Säutsu „15 minutes“ on ennustus, mitte tuvastatud fakt, kuid suundumus on tõeline: ajaaken paranduse avaldamise ja esimeste rünnakute vahel aheneb.
Ettevõtte jaoks muudab see mängureegleid. Sellise taseme turvanõrkuse puhul ei piisa enam uuendamisest „nädala jooksul“. Uuendada tuleb sama päeva jooksul ja seega peab olema keegi, kes jälgib, testib ja juurutab, ka nädalavahetusel.
Staatilise veebilehe tegelik eelis
Staatiline veebileht ehitatakse üks kord, ette. Külastaja saab valmis failid: HTML-i, pildid, veidi JavaScripti. Külastuse ajal ei tööta PHP ja ühtegi andmebaasi ei pärita. Sellisel turvanõrkusel pole lihtsalt midagi rünnata.
See on staatilise lähenemise kõige alahinnatum eelis. Räägitakse peamiselt kiirusest, kuid see vähendab ka sõltuvust konkreetsest tehnoloogiast. Teie veebileht ei sõltu enam PHP versioonist, WordPressi versioonist ega kolmekümnest laiendusest, mis kõik peavad olema korraga ajakohased. Vähem osi tähendab vähem hädaolukordi nagu tänane.
Mida staatiline lähenemine ei lahenda
Olgem ausad: staatiline veebileht ei kaota kogu turvatööd.
- Vormid vajavad endiselt väikest teenust, mis saadetisi vastu võtab. See tuleb kaitsta, kuid see on tühine võrreldes terve WordPressiga.
- Haldusliides on endiselt olemas, kui kasutate sisuhaldusvahendit nagu headless CMS. See elab eraldi, seda hooldava pakkuja juures, mitte Teie avaliku veebilehe serveris.
- API-d maksete, broneeringute või kataloogi jaoks jäävad tarkvaraks, mida tuleb uuendada.
- Täielik e-pood ostukorvi ja kliendikontodega ei muutu korraga staatiliseks. Tootelehed ja sisu võivad seda olla, makse läheb läbi spetsialiseeritud teenuse.
Erinevus seisneb selles, et avatud pind muutub väikeseks ja selgelt piiritletuks. Terve serveri asemel jälgite kahte või kolme täpset komponenti.
Õige hetk küsimuse esitamiseks
Kui see hoiatus pani Teid kiiresti oma PHP versiooni kontrollima, esitage endale lihtne küsimus: kas Teie veebileht peab tõesti igal külastusel koodi käivitama? Ettevõtte esitluslehe, blogi või kataloogi puhul on vastus peaaegu alati ei.
Alustage täna uuendamisest. Kui soovite seejärel sellest hoiatuste ringist välja tulla, säilitab meie üleminek staatilisele saidile kõik Teie aadressid ja otsingumootori positsioonid ning paneb lehe üles majutusse, mis ei käivita PHP-d. Et mõista, mis juhtub, kui uuendus tuleb liiga hilja, lugege ka, mida teha, kui WordPressi veebileht on häkitud.
Jim · Brain Plus AI asutaja
Loe veel teemal veebilehed, migratsioon ja astro

Mõista6 min Teema juhend
Üleminek Astro staatilisele lehele SEO-d kaotamata
Astroga loodud staatiline veebileht asendab vananeva WordPressi või Drupali aadresse muutmata: puhtad HTML-lehed CDN-ist, mitte ühtki pluginat, mida parandada, ja tagasipööramisvõimalusega avaldamisahel. Mis muutub, kuidas üle minnakse ja millal seda teha ei tasu.

Vali ja arvuta7 min
Astro või WordPress: kumb valida oma veebilehele?
WordPressi muudetakse halduspaneelist, Astro valmistab oma lehed ette. Mida kumbki paremini teeb, mida mõõdavad välitingimuste andmed, ja viis küsimust otsustamiseks.

Praktiline juhend5 min
Vorm ja otsing staatilisel veebisaidil: kuidas seda teha
Staatiline veebisait ei ole liikumatu sait: vorm, uudiskiri, saidisisene otsing või nõudmisel renderdatav leht ühendatakse ükshaaval. Lahendused ja reegel, mis hoiab ära päringute kadumise.
