Lyhyesti: RHELillä, AlmaLinuxilla ja Rocky Linuxilla tarkistatte PHP-päivityksen PHP2Shelliä vastaan kolmea tietä: jakelun tietoturvailmoitukset (dnf updateinfo), paketin muutosloki (rpm -q --changelog) ja PHP-prosessien käynnistysaika. Red Hat luettelee RHEL 7–10:n alttiiksi ja ilmoitti haun hetkellä, että osa päivityksistä on saatavilla ja lisää on työn alla. Päivityksen jälkeen pätee: käynnistäkää kokonaan uudelleen, älkää vain lataako uudelleen.
Mitä Red Hat on julkaissut PHP2Shellistä
Red Hat on julkaissut PHP2Shellistä tietoturvatiedotteen RHSB-2026-013. Haimme sen 25. lokakuuta 2026. Tärkeimmät kohdat ylläpitäjille:
- Alttiita ovat RHEL 10, 9, 8 ja 7 sekä niiden päälle rakennetut tuotteet ja RHEL- tai UBI-kuviin perustuvat kontit.
- RHEL 7:ää koskee Red Hatin mukaan vain CVE-2026-109619; CVE-2026-109618:n koodia siinä ei ole.
- Alttiita eivät ole järjestelmät ilman PHP:tä tai ilman PHP:tä, joka käsittelee epäluotettavia HTTP-pyyntöjä.
- Päivitykset: Osa oli haun hetkellä saatavilla, lisää työn alla. Konkreettisia errata-numeroita tiedote ei maininnut vaan viittasi errata-sivuihin.
Red Hat arvioi CVE-2026-109618:n omalla menetelmällään tasolle ”Important” ja huomauttaa, että RHEL 8:sta alkaen vakioasennukset käyttävät PHP-FPM:ää mod_php:n sijaan. Se on arvio, ei hälytyksen purku. PHP-projekti arvioi molemmat aukot CVSS v4.0 -pisteillä 9,2, ja BSI (Saksan liittovaltion tietoturvavirasto) suosittelee välitöntä päivitystä.
AlmaLinux ja Rocky Linux: sama lähde, oma tahti
AlmaLinux ja Rocky Linux rakentavat pakettinsa uudelleen Red Hatin lähteistä. Korjaukset saapuvat siksi yleensä sisällöltään samoina mutta omana ajankohtanaan ja omissa tietoturvailmoituksissaan. Viittaus Red Hatin errataan ei tarkoita, että paketti on jäljennöksessänne saatavilla samana päivänä.
Ratkaiseva on siksi tila omassa järjestelmässänne. Tarkistakaa se paketinhallinnan työkaluilla älkääkä uutisten tai foorumeiden perusteella.
Kiinnittäkää lisäksi huomiota siihen, käyttääkö palvelin peilipalvelimia tai sisäisiä pakettilähteitä. Monissa yrityksissä palvelimet eivät hae päivityksiä suoraan valmistajalta vaan sisäisen peilin tai hallintatyökalun kautta. Jos peili ei ole ajan tasalla, dnf ei löydä uusia paketteja, vaikka ne on julkaistu jo kauan sitten.
PHP-päivityksen tarkistaminen RHELillä ja jäljennöksillä
Seuraavat komennot vain lukevat. Pakettinimet koskevat jakelun PHP-paketteja; kolmannen osapuolen lähteiden, kuten Remin, paketit voivat olla nimetty osin eri tavalla.
# Mitkä PHP-streamit järjestelmä tuntee, mikä on aktiivinen? (RHEL 8 ja 9)
dnf module list php
# Asennetut PHP-paketit versioineen ja alkuperineen
rpm -qa 'php*' --qf '%{NAME}-%{VERSION}-%{RELEASE} %{VENDOR}\n' | sort
# Onko CVE-tunnisteille tietoturvailmoituksia tälle järjestelmälle?
dnf updateinfo list --cve CVE-2026-109618
dnf updateinfo list --cve CVE-2026-109619
# Onko korjaus asennetun paketin muutoslokissa?
rpm -q --changelog php-fpm | grep -E "CVE-2026-10961[89]"
dnf updateinfo näyttää vain ilmoitukset päivityksistä, joita ei ole vielä asennettu; valitsimella --installed näette myös jo asennetut. Tyhjä tulos voi siis tarkoittaa kahta asiaa: päivitys on jo asennettu tai sitä ei ole vielä julkaistu. Muutoslokin vertailu ratkaisee asian. Miten tuloksen kirjaatte todisteeksi, kuvaa artikkeli CVE-numeroiden todistaminen paketin muutoslokista.
Kuten muillakin yritysjakeluilla, paketti säilyttää yleensä alkuperäisen PHP-versionsa; vain release-tieto muuttuu. Vanhempi numero komennolla php -v ei siksi ole merkki puuttuvasta korjauksesta. Yleisiä ohjeita version tarkistamiseen löytyy kohdasta PHP-version ja korjaustilan tarkistaminen oikein.
Oikean ajotavan tunnistaminen
Red Hat mainitsee oletusajotavat: RHEL 8:sta alkaen PHP toimii PHP-FPM:n kautta, RHEL 7:llä mod_php:na Apache-palvelussa httpd. Monet palvelimet poikkeavat tästä, esimerkiksi paneelien, kolmansien lähteiden tai vanhojen konfiguraatioiden vuoksi.
| Järjestelmä | Oletus Red Hatin mukaan | Uudelleenkäynnistys päivityksen jälkeen |
|---|---|---|
| RHEL 8, 9, 10 ja jäljennökset | PHP-FPM | systemctl restart php-fpm |
| RHEL 7 | mod_php httpd:ssä | systemctl restart httpd |
| RHEL- tai UBI-pohjaiset kontit | kuvasta riippuen | Rakenna kuva uudelleen, korvaa kontti |
Konteille Red Hat suosittelee päivitettyjen peruskuvien jälkeen rakentamaan omat kuvat uudelleen ja korvaamaan käynnissä olevat kontit tai podit. Päivitys käynnissä olevassa kontissa ei ole kestävä tie.
Päivityksen jälkeen: uudelleenkäynnistys ja tarkistus
Red Hat korostaa, ettei uudelleenlataus riitä. Olemassa olevat workerit voivat säilyttää alttiin tilan. Käynnistäkää siksi jokainen PHP:n lataava palvelu uudelleen ja tarkistakaa tulos:
# Näytä palvelut, joilla on vanhentuneita kirjastoja (dnf-utils tai dnf-plugins-core)
needs-restarting -s
# Vertaa PHP-prosessien käynnistysaikaa päivityksen ajankohtaan
ps -eo pid,lstart,cmd | grep -E "[p]hp-fpm|[h]ttpd"
Konfiguraation osalta Red Hatilla on käytännöllinen vinkki: php -i näyttää komentorivin asetukset, ei verkkopalvelimen. Joka haluaa tarkistaa, tehoavatko väliaikaisarvot kuten session.upload_progress.enabled=0 verkkokontekstissa, käyttää lyhytaikaisesti suojattua phpinfo-sivua ja poistaa sen sen jälkeen. Mitä uudelleenkäynnistyksessä on muuten huomioitava, kerrotaan kohdassa PHP-FPM:n ja kaikkien workerien uudelleenkäynnistys.
Väliaikaistoimet: Red Hatin ohjeet
Missä päivitys vielä puuttuu, Red Hat viittaa samoihin väliaikaistoimiin kuin php.net ja lisää joitakin käytännön vinkkejä RHEL-järjestelmille. Ne eivät korvaa päivitystä.
- Lisätkää rivi todella: Red Hatin mukaan
session.upload_progress.enabled-rivi on toimitetussa konfiguraatiossa kommentoitu pois, joten toiminto on oletuksena aktiivinen. Arvo0on asetettava nimenomaisesti. - Asettakaa ylikirjoittamattomasti:
php_admin_value-direktiivillä PHP-FPM-poolissa, mod_php:n tapauksessa Apache-konfiguraatiossa. Eiini_set()-funktiolla eikä.user.ini-tiedostolla. - Etsikää vastavoimat: Red Hat suosittelee tarkistamaan
.htaccess-tiedostot, VirtualHostit ja.user.ini-tiedostot sen varalta, että ne kytkevät alttiit asetukset takaisin päälle. - Asettakaa rajat myös edeltä: PHP:n
post_max_size-asetuksen lisäksi Red Hat neuvoo harkitsemaan pyyntökoon rajoja myös verkkopalvelimessa tai välityspalvelimessa.
PHP-FPM-järjestelmissä poolit sijaitsevat yleensä hakemistossa /etc/php-fpm.d/. Jokaisen muutoksen jälkeen pätee sama kuin päivityksen jälkeen: käynnistäkää kaikki workerit kokonaan uudelleen.
Jos samalla palvelimella toimii lisäksi PHP Remi-repositoriosta, sille pätevät omat paketit ja palvelut. Lukekaa siitä artikkeli Remi-repositorio.
Miten PHP SOS auttaa konkreettisesti?
- Tarkistamme RHELillä, AlmaLinuxilla ja Rocky Linuxilla kaikki PHP-paketit, streamit ja kolmannen osapuolen lähteet ja vertaamme niitä tietoturvailmoituksiin.
- Asennamme päivitykset, käynnistämme kaikki workerit kokonaan uudelleen ja tarkistamme prosessien käynnistysajat.
- Konttiympäristöissä rakennamme kuvat uudelleen ja korvaamme käynnissä olevat instanssit hallitusti.
- Palvelinkohtaisen tilan kirjaamme PHP-päivityspalvelun todisteeseen.
Usein kysytyt kysymykset
Koskeeko PHP2Shell RHEL 7:ää?
Red Hatin mukaan RHEL 7:ää koskee vain CVE-2026-109619; CVE-2026-109618:n haavoittuvaa koodia siinä ei ole. RHEL 7:llä mod_php on oletusajotapa, jonka PHP-tiimi arvioi erityisen riskialttiiksi.
Miksi Red Hat arvioi aukon matalammaksi kuin php.net?
Red Hat käyttää omaa arviotaan CVSS v3.1:n mukaan ja luokittelee CVE-2026-109618:n tasolle Important, koska hyväksikäyttö vaatisi tarkan ajoituksen. php.net arvioi CVSS v4.0 -pisteillä 9,2. Molemmat pitävät koodin suoritusta ilman kirjautumista mahdollisena, päivitys on joka tapauksessa tarpeen.
Saavatko AlmaLinux ja Rocky Linux korjaukset automaattisesti?
Molemmat rakentavat pakettinsa uudelleen Red Hatin lähteistä ja julkaisevat omat tietoturvailmoituksensa. Ajankohta voi poiketa Red Hatin ajankohdasta. Tarkistakaa siksi tila omasta järjestelmästänne ja jakelunne ilmoituksista.
Riittääkö systemctl reload php-fpm päivityksen jälkeen?
Ei. Red Hat huomauttaa nimenomaisesti, ettei uudelleenlataus riitä, koska olemassa olevat workerit voivat säilyttää alttiin tilan. Käynnistäkää kaikki workerit uudelleen, mod_php:n tapauksessa Apache-palvelu httpd.