Useita PHP-versioita yhdellä palvelimella: korjatkaa jokainen erikseen

Lyhyesti: Jos palvelimella toimii useita PHP-versioita, jokainen on PHP2Shellin jälkeen tarkistettava, päivitettävä ja käynnistettävä uudelleen erikseen. Tyypillisiä lähteitä ovat käyttöjärjestelmä, hosting-paneelit kuten Plesk tai cPanel, kolmannen osapuolen lähteet kuten sury.org tai Remi, CloudLinux, LiteSpeed ja itse käännetyt versiot. Vasta paketeista, tiedostoista ja käynnissä olevista prosesseista koottu täydellinen luettelo osoittaa, ettei yhtään versiota ole jäänyt huomaamatta.

Unohtunut versio

Muutaman vuoden käynnissä ollut palvelin kerää PHP-versioita kuin ullakko vanhoja huonekaluja. Paneeli toi mukanaan kolme haaraa, yhtä asiakasta varten tuli vanhempi versio kolmannen osapuolen lähteestä, ja käyttöjärjestelmällä on oma versionsa. Jokainen niistä asennettiin aikanaan hyvästä syystä. Nyt vain kukaan ei enää tiedä, mitä niistä vielä tarvitaan.

PHP2Shellin jälkeen juuri tämä on ongelma. Korjaukset julkaistiin 21. lokakuuta 2026 versioille PHP 8.5.12, 8.4.27, 8.3.36 ja 8.2.35. Palvelimen jokainen asennus saa ne kuitenkin omaa reittiään, oman paketin ylläpitäjän kautta ja omaan aikaansa. PHP 8.1:lle ja vanhemmille on olemassa vain vähäisiä lähdekoodin backporteja. Jos päivitätte vain pääversion, muut jäävät auki.

Mistä monet versiot tulevat

Seuraava yleiskatsaus nimeää tyypilliset lähteet ja esimerkkipolut. Tarkat polut vaihtelevat version ja jakelun mukaan.

Erityisen salakavalia ovat sury.org-paketit, koska ne käyttävät samoja polkuja kuin jakelu. Se, onko php8.3 peräisin Debianilta vai sury.orgista, selviää vasta pakettilähteestä. Erityispiirteet kuvaavat artikkelit sury.org-repositorio ja Remi-repositorio. Miten Plesk hallinnoi versioitaan, kuvaa sivu Plesk-palvelin: PHP-versioiden tarkistus ja korjaus.

Kaikkien PHP-asennusten löytäminen

Luotettava luettelo syntyy kolmesta näkökulmasta. Komennot vain lukevat, ja niiden ajo voi kestää palvelimesta riippuen jonkin aikaa.

# 1. Paketit: mitä paketinhallinta tuntee
dpkg-query -W -f='${Package}\t${Version}\n' '*php*' 2>/dev/null | grep -E "fpm|cli|cgi|mod-php|lsphp"
rpm -qa 2>/dev/null | grep -iE "php.*(fpm|cli|cgi|litespeed)|^php-[0-9]|^ea-php|^alt-php" | sort

# 2. Tiedostot: suoritettavat PHP-binäärit, myös paketinhallinnan ulkopuolella
find / -xdev -type f \( -name 'php' -o -name 'php[0-9]*' -o -name 'php-fpm*' -o -name 'php-cgi*' -o -name 'lsphp*' \) -perm -u+x 2>/dev/null

# 3. Prosessit: mitä todella on käynnissä, käynnistysajan kanssa
ps -eo pid,user,lstart,cmd | grep -E "[p]hp-fpm|[p]hp-cgi|[l]sphp|[a]pache2|[h]ttpd|[f]rankenphp"

Verratkaa kolmea luetteloa keskenään. Tiedosto ilman pakettia viittaa itse käännettyyn tai käsin kopioituun versioon. Prosessi ilman vastaavaa tiedostoa voi viitata poistettuun mutta yhä käynnissä olevaan asennukseen. Tarkistakaa Apachella lisäksi, onko PHP-moduuli ladattu, esimerkiksi komennolla apache2ctl -M tai httpd -M. Kontit ja Kubernetes-podit näkyvät näissä luetteloissa vain osittain, ja niille tarvitaan oma kuvien tarkistus.

Jokaisen version korjaus erikseen

Kun jokaisella asennuksella on rivi luettelossanne, jokaiselle toistuu sama kulku:

1. Selvittäkää vastuu: Tuleeko korjaus jakelulta, paneelilta, kolmannen osapuolen lähteestä vai Teiltä itseltänne?
2. Arvioikaa tila: virallinen korjattu versio, vahvistettu backport, selvittämätön tai avoin.
3. Päivittäkää: kyseisen lähteen omaa reittiä pitkin, ei jotain toista reittiä.
4. Käynnistäkää uudelleen: kyseisen version palvelu, ei vain pääpalvelua. mod_php:ssä verkkopalvelin. Yksityiskohdat löytyvät sivulta PHP-FPM:n ja kaikkien workerien uudelleenkäynnistys.
5. Tarkistakaa: verratkaa prosessien käynnistysaikaa päivityksen ajankohtaan.
6. Dokumentoikaa: versio, paketin tila, todiste, uudelleenkäynnistyksen aika.

Versioille, joille korjausta ei ole, php.netin väliaikaiset toimet pätevät siirtymään asti. Asettakaa ne jokaiselle versiolle erikseen, sillä jokaisella asennuksella on oma php.ininsä ja omat poolinsa.

Mitä versiota komentorivi käyttää, mitä kontti?

Kaksi aluetta putoaa etsinnässä erityisen usein seulan läpi. Ensimmäinen on komentorivi. Debianilla ja Ubuntulla vaihtoehtojärjestelmä päättää, mikä binääri on komennon php takana. Komento update-alternatives --display php näyttää, mitkä versiot on rekisteröity ja mikä on voimassa. Cron-työt, jotka kutsuvat kiinteää polkua, kuten /usr/bin/php7.4, kuitenkin ohittavat tämän asetuksen. Siksi kannattaa katsoa kaikkien käyttäjien crontabit sekä sellaisten paneelien asetukset, jotka luovat omia cron-töitä.

Toinen alue ovat kontit. Palvelimella toimiva Docker-kontti tuo mukanaan oman PHP-versionsa, joka ei näy missään isäntäkoneen pakettiluettelossa. Komento docker ps näyttää käynnissä olevat kontit; sen, onko niissä PHP:tä ja mikä versio, paljastaa katsaus kuvaan tai php -v kontissa. Korjaus tehdään siellä, ei isäntäkoneella: kuva rakennetaan uudelleen ja kontti vaihdetaan.

Vähemmän on turvallisempaa

Paras tarkistus on se, jota ei tarvitse tehdä. Jokainen asennettu PHP-versio kaksinkertaistaa työmäärän seuraavan aukon kohdalla. PHP2Shellin jälkeen kannattaa siksi ottaa käyttöön selvä sääntö: jokaisella palvelimen versiolla on oltava tarkoitus ja vastuuhenkilö. Mikä ei sitä täytä, poistetaan ensin käytöstä ja seurantajakson jälkeen kokonaan. Lisää artikkelissa Vanhojen PHP-versioiden poistaminen käytöstä hosting-paneelissa.

Miten PHP SOS auttaa konkreettisesti?

• Laadimme palvelimillenne täydellisen luettelon kaikista PHP-asennuksista paketeista, tiedostoista, prosesseista ja konteista.
• Selvitämme versiokohtaisesti alkuperän, vastuun ja korjaustilan.
• PHP-päivityspalvelun puitteissa päivitämme jokaisen version, käynnistämme jokaisen palvelun uudelleen ja todistamme tilan.
• Päätämme kanssanne, mitkä versiot jäävät, ja poistamme muut hallitusti.

Usein kysytyt kysymykset

Lähteet

• php.net: tietoturvailmoitukset
• php.net: tuetut versiot
• Red Hat Security Bulletin RHSB-2026-013