AI aitas avastada PHP-s kriitilised turvaaugud: mida veebilehe omanik peab teadma?

1. aasta oktoobris avalikustatud PHP turvanõrkused tõid esile ebamugava tõsiasja: ka aastakümneid arendatud tarkvara võib sisaldada kriitilisi vigu, mis jäävad tavapärases kontrollis märkamata.

2. oktoobril avalikustati kaks kriitilist PHP haavatavust — CVE-2026-109618 ja CVE-2026-109619. Need võivad teatud tingimustel võimaldada ründajal serveris koodi käivitada ilma autentimiseta. Turvauuringutes kasutati ka tehisintellekti.

Mis PHP-s avastati?

PHP on serveripoolne programmeerimiskeel, millel põhinevad muu hulgas WordPress, WooCommerce, Drupal ja Joomla.

Seekord ei leitud turvaauke mõnest konkreetsest WordPressi pluginast. Probleemid puudutasid PHP enda päringute töötlemist ja mäluhaldust.

Esimese nõrkuse puhul võib mälu eraldamise tõrge katkestada päringu töötlemise ajal, mil sisemised andmed on alles osaliselt ette valmistatud. Hilisem puhastustoiming võib neid vigaseid andmeid käsitleda kehtivatena. Teise nõrkuse korral võib PHP pärast tõrget kasutada viiteid juba vabastatud mälule.

Mõlemal juhul võib tagajärjeks olla mälu rikkumine ja teatud tingimustel koodi kaugkäivitamine.

PHP arendajate hinnangul on eriti kõrge riskiga Apache mod_php keskkonnad, kus on demonstreeritud rünnet enne rakenduse koodi käivitumist. Tähelepanu vajavad siiski ka PHP-FPM, php-cgi, FrankenPHP ja LiteSpeed.

Milline oli tehisintellekti roll?

Turvauuringutes kasutati AI-mudeleid keerulise lähtekoodi ja võimalike ründestsenaariumide analüüsimiseks. See näitab, kuidas tehisintellekt saab turvaspetsialistide tööd kiirendada.

Oluline on aga eristada AI panust inimese juhitud turvauuringust. AI kasutamine ei tähenda, et mudel üksinda turvaaugu avastas, selle mõju kinnitas ja paranduse valmis tegi.

Selle uudise laiem tähendus on selge: tehisintellekt võib aidata leida probleeme ka väga küpses ja palju kontrollitud tarkvaras. Sama areng suurendab vajadust kiiremate paranduste ja korraliku serverihalduse järele.

Kas kõik PHP veebilehed on ohus?

Mitte tingimata ühtemoodi. Eristada tuleb kolme asja:

• veebileht kasutab PHP-d;
• serveris töötab mõjutatud PHP versioon või parandamata pakett;
• konkreetne konfiguratsioon võimaldab turvaauku praktiliselt ära kasutada.

Kriitiline turvahoiatus ei tähenda, et iga WordPressi veebileht oleks juba kompromiteeritud. Küll aga tuleb mõjutatud serverid kiiresti üle kontrollida ja parandada.

Millised versioonid on parandatud?

1. oktoobril avaldatud parandatud PHP väljalasked on:

PHP haru	Parandatud versioon
8.5	8.5.12
8.4	8.4.27
8.3	8.3.36
8.2	8.2.35

Vanemate PHP harude puhul tuleb kontrollida, kas operatsioonisüsteemi või majutusteenuse pakkuja on väljastanud tagasiportitud turvaparanduse. Üksnes versiooninumber ei pruugi sellisel juhul kogu olukorda kirjeldada.

PHP arendajad rõhutavad, et täielikku ajutist leevendusmeetodit nende kahe haavatavuse jaoks ei ole — turvaparanduste paigaldamine on vajalik.

Veel üks seotud turvanõrkus

1. oktoobril täiendati avalikku teavet ka kolmanda seotud nõrkuse, CVE-2026-115560, kohta. See puudutab teatud PHP sessioonide ja üleslaadimise edenemise funktsiooni kasutamise olukordi.

See probleem vajab eraldi hindamist: 21. oktoobri kahe põhilise haavatavuse parandused ei tähenda automaatselt, et kõik seotud riskid on lahendatud.

Mida peaks veebilehe omanik tegema?

1. Kontrolli PHP versiooni ja turvaparandusi. WordPressi puhul näeb PHP versiooni saidi tervise infost, kuid vajaduse korral küsi majutajalt ka serveripaketi paranduste kohta.
2. Paigalda turvauuendused. Oma VPS-i puhul vastutab uuendamise eest serveri haldaja; jagatud majutuses kontrolli teenusepakkuja tegevust.
3. Vaata üle logid ja failimuudatused. Kui on põhjust kahtlustada rünnet, tuleb hinnata ka võimaliku kompromiteerimise jälgi.
4. Ära piirdu WordPressi uuendamisega. Pluginate ja teemade uuendamine ei paranda PHP käituskeskkonna turvaauke.
5. Kontrolli varukoopiaid ja taastevõimalusi. Turvalisus tähendab ka valmisolekut probleemide korral teenus taastada.

Mida see tähendab veebiturvalisuse tulevikule?

AI aitab turvaspetsialistidel üha keerulisemaid probleeme leida. Samal ajal võivad samad võimalused jõuda ka ründajateni. Seetõttu ei piisa veebilehe turvalisuse hindamisel üksnes sellest, kas leht avaneb ja haldusliides töötab.

Veebilehe turvalisus sõltub tervest ahelast: serverist, PHP-st, andmebaasist, rakendusest ja kolmandate osapoolte komponentidest.

Turvaline veebileht ei ole lihtsalt veebileht, mis täna töötab. See on süsteem, mille tehnilist seisukorda järjepidevalt kontrollitakse ja uuendatakse.

Allikad

• PHP ametlik turvahoiatus ja versioonide väljalasked
• PHP 8 muudatuste ajalugu
• Red Hat: PHP2Shell turvanõrkuste ülevaade
• Google Cloud: AI ja PHP turvanõrkuste analüüs