Lyhyesti: Remi PHP-repositorio toimittaa ajantasaisia PHP-versioita Fedoralle ja RHEL-perheelle, joko moduulistreamina, joka korvaa järjestelmän PHP:n, tai Software Collectionina, joka asentaa useita versioita rinnakkain. PHP2Shell-korjaukset 8.2.35, 8.3.36, 8.4.27 ja 8.5.12 ilmoitettiin siellä 22. lokakuuta 2026. Tarkistakaa jokainen asennettu versio erikseen ja käynnistäkää jokainen siihen kuuluva palvelu uudelleen.
Miksi niin monet RHEL-palvelimet hankkivat PHP:n Remiltä
Yritysjakelut, kuten RHEL, AlmaLinux ja Rocky Linux, panostavat pitkään vakauteen. Ne toimittavat vain vähän PHP-haaroja ja pitävät ne vuosia. Monet sovellukset vaativat kuitenkin uudempia versioita kuin jakelu tarjoaa. Tähän astuu Remi Colletin repositorio, jonka ylläpitäjä on pitkäaikainen PHP-pakettien huoltaja Fedora- ja RHEL-ympäristössä.
Remi rakentaa PHP-versiot lyhyellä viiveellä virallisten julkaisujen jälkeen. PHP2Shellistä repositorion blogissa ilmestyi 22. lokakuuta 2026 artikkeli versioista 8.2.35, 8.3.36, 8.4.27 ja 8.5.12. Siinä mainitaan kaksi kriittistä aukkoa, CVE-2026-109618 ja CVE-2026-109619, ja päivitystä suositellaan kiireellisesti. Red Hatin tietoturvailmoitukset eivät koske näitä paketteja; mitä Red Hat ilmoittaa omista paketeistaan, kerrotaan artikkelissa RHEL, AlmaLinux ja Rocky Linux: PHP-päivityksen tarkistaminen.
Kaksi tietä: moduulistream tai Software Collection
Remin blogin mukaan buildit Enterprise Linuxille versiosta 8 alkaen ovat saatavilla kahta tietä. Se, kumpaa palvelimellanne käytetään, määrää, miten tarkistatte ja käynnistätte uudelleen.
| Tie | Repositorio | Vaikutus | Tyypillinen palvelu |
|---|---|---|---|
Moduulistream, esimerkiksi php:remi-8.3 |
remi-modular | korvaa järjestelmän PHP:n, yksi oletusversio | php-fpm |
Software Collection, esimerkiksi php83 |
remi-safe | lisäversio rinnakkain omassa polussa | oma palvelu versiota kohti, esimerkiksi php83-php-fpm |
| Testipaketit ja release-ehdokkaat | remi-modular-test, remi-test | esiversiot | ei tuotantoon |
Software Collectionit sijaitsevat tyypillisesti hakemistossa /opt/remi/phpXY, niiden konfiguraatio hakemistossa /etc/opt/remi/phpXY. Se on käytännöllistä vanhojen ja uusien sovellusten ajamiseksi samalla palvelimella. Se on myös yleisin syy siihen, että versio jää huomaamatta päivityksessä.
Huomio komentoriviin: Software Collectionit eivät ole automaattisesti käytettävissä komennolla php. Asetuksesta riippuen cron-työt ja skriptit kutsuvat niitä omalla komennolla tai täydellä polulla. Tarkistakaa siksi myös crontabit ja käyttöönottoskriptit, jos haluatte tietää, mitä collectionia käytetään mihinkin.
Remi PHP-repositorion tarkistus PHP2Shellin jälkeen
Seuraavat komennot vain lukevat ja näyttävät, mitkä Remi-paketit on asennettu ja missä tilassa ne ovat.
# Aktiiviset pakettilähteet: onko remi-modular tai remi-safe käytössä?
dnf repolist
# PHP:n aktiivinen moduulistream
dnf module list --enabled php
# Peruspaketit ja rinnakkain asennetut Software Collectionit
rpm -qa 'php-*' 'php[0-9][0-9]-php-*' --qf '%{NAME}-%{VERSION}-%{RELEASE}\n' | sort
# Jokaisen asennetun collectionin versio
for b in /opt/remi/php*/root/usr/bin/php; do echo "$b"; "$b" -v | head -1; done
Tuetuilla haaroilla tilanne on yksiselitteinen: jos siinä lukee 8.5.12, 8.4.27, 8.3.36 tai 8.2.35 tai uudempi, korjaus on mukana. Remillä versionumero vastaa yleensä upstream-versiota, toisin kuin jakelupaketeissa, jotka usein säilyttävät vanhan numeronsa.
Vanhemmille collectioneille, kuten php81, php80 tai php74, virallista tavoiteversiota ei ole. Remi luettelee PHP 8.1:n End-of-Life-tilassa. Sisältääkö asennettu paketti korjauksen PHP2Shelliä vastaan, selvitätte muutoslokista, esimerkiksi komennolla rpm -q --changelog php81-php-fpm | grep -E "CVE-2026-10961[89]". Ilman osumaa kohdelkaa pakettia selvittämättömänä. Miten tällaiset osumat todistetaan siististi, kuvaa artikkeli CVE-numeroiden todistaminen paketin muutoslokista.
Älkää aktivoiko testirepositorioita, kuten remi-test tai remi-modular-test, pysyvästi tuotantopalvelimilla. Ne toimittavat release-ehdokkaita, jotka on tarkoitettu testeihin.
Jokaisen version päivitys ja uudelleenkäynnistys
Päivitys itsessään on Remillä yleensä vaatimaton: dnf upgrade hakee uudet paketit streamille ja collectioneille. Kriittinen osa tulee sen jälkeen. Jokaisella collectionilla on oma FPM-palvelunsa, ja jokainen on käynnistettävä uudelleen.
# Luettele kaikki PHP-FPM-palvelut, myös collectionien
systemctl list-units --type=service --all | grep -E "php.*fpm"
# Tarkista kaikkien PHP-prosessien käynnistysajat
ps -eo pid,lstart,cmd | grep -E "[p]hp-fpm|[h]ttpd"
Päivitystä edeltävät käynnistysajat tarkoittavat: tämä palvelu toimii yhä vanhalla koodilla. Miksi uudelleenlataus ei riitä, selittää sivu PHP-FPM:n ja kaikkien workerien uudelleenkäynnistys.
Remi ja jakelu: kuka vastaa?
Joka siirtyy moduulistreamilla Remiin, vaihtaa PHP:n toimittajaa. Red Hatin, AlmaLinuxin tai Rocky Linuxin tietoturvailmoitukset eivät silloin enää koske asennettuja PHP-paketteja. Toisaalta Remi ei ilmoita ongelmista järjestelmän muissa paketeissa. Molempia lähteitä on siis seurattava.
Mistä asennettu paketti on peräisin, näyttää pakettitietokanta, esimerkiksi komennolla rpm -qi php-fpm valmistajan ja paketoijan kentissä. Koska Remin paketeille ei ole errataa Red Hatin tapaan, repositorion blogi sopii ilmoituskanavaksi; sen voi tilata RSS-syötteellä. PHP2Shellin kohdalla ilmoitus ilmestyi sinne päivää virallisten julkaisujen jälkeen.
Yrityksille tämä jako ei ole este, mutta se on dokumentoitava. Kirjatkaa ylös, mitkä palvelimet hankkivat PHP:n Remiltä, kuka lukee ilmoitukset ja kuka käynnistää palvelut uudelleen päivityksen jälkeen. Muuten jokainen luottaa toiseen.
Pitäkää järjestys: vähemmän versioita, vähemmän riskiä
Software Collectionit houkuttelevat jättämään vanhat versiot lojumaan. PHP2Shellin jälkeen on hyvä hetki siivota:
- Selvittäkää jokaisen collectionin osalta, mikä verkkosivusto tai cron-työ sitä käyttää.
- Poistakaa käyttämättömät collectionit käytöstä ja poistakaa ne seurantajakson jälkeen.
- Nostakaa vanhoilla collectioneilla toimivat sovellukset tuettuun haaraan.
- Dokumentoikaa jäljelle jäävät versiot käyttötarkoituksineen ja vastuuhenkilöineen.
Miten yleiskuva säilyy monesta rinnakkaisesta versiosta, kuvaa artikkeli Useita PHP-versioita yhdellä palvelimella.
Miten PHP SOS auttaa konkreettisesti?
- Kartoitamme kaikki palvelimillanne olevat Remi-streamit ja -collectionit ja yhdistämme ne verkkosivustoihin ja cron-töihin.
- Tarkistamme PHP2Shell-tilan versiokohtaisesti paketin version ja muutoslokin avulla.
- Asennamme päivitykset, käynnistämme jokaisen palvelun uudelleen ja todistamme sen prosessien käynnistysajoilla PHP-päivityspalvelun puitteissa.
- Tarpeettomat collectionit poistamme sovitusti ja hallitusti.
Usein kysytyt kysymykset
Onko Remi toimittanut PHP2Shell-versiot?
Kyllä. Repositorion blogissa ilmoitettiin 22. lokakuuta 2026 versiot 8.2.35, 8.3.36, 8.4.27 ja 8.5.12 viitaten kahteen kriittiseen aukkoon, CVE-2026-109618:aan ja CVE-2026-109619:ään, ja suositeltiin päivitystä kiireellisesti.
Mikä ero on moduulistreamilla ja SCL:llä Remillä?
Moduulistreamilla korvaatte järjestelmän PHP:n Remin versiolla, jolloin oletuksena on yksi PHP-versio. Software Collectionit asentavat lisäversioita rinnakkain omiin polkuihinsa, jokaisella oma palvelunsa.
Saako PHP 8.1 Remiltä vielä päivityksiä?
Remi luettelee PHP 8.1:n End-of-Life-tilassa, PHP-projekti ei enää ylläpidä haaraa. Sisältääkö tietty 8.1-paketti korjauksen PHP2Shelliä vastaan, tarkistatte asennetun paketin muutoslokista. Ilman merkintää tilaa pidetään selvittämättömänä.
Pitääkö minun käynnistää jokainen PHP-versio uudelleen Remi-päivityksen jälkeen?
Kyllä. Jokaisella rinnakkain asennetulla versiolla on oma FPM-palvelunsa. Jos uudelleenkäynnistetään vain pääversion palvelu, muut jatkavat vanhalla koodilla.