Lyhyesti: Symfonyn tietoturva PHP2Shellin jälkeen tarkoittaa: korjatkaa PHP, käynnistäkää kaikki prosessit, myös Messenger-workerit, uudelleen ja tarkistakaa sen jälkeen secretit, välimuisti ja profiler. Aukko on PHP:ssä, ei Symfonyssä; pelkkä Symfony-päivitys ei sulje sitä.
Miksi PHP2Shell koskee jokaista Symfony-projektia
Symfony on monen yrityssovelluksen, rajapinnan ja portaalin perusta, ja se on lisäksi mukana järjestelmissä kuten Shopware 6 ja Contao. PHP-tiimin mukaan PHP-haavoittuvuudet CVE-2026-109618 ja CVE-2026-109619 sallivat haittakoodin suorittamisen ilman kirjautumista. Sillä, onko sovellus ohjelmoitu siististi, ei ole tässä merkitystä.
PHP-tiimi arvioi riskin suurimmaksi mod_php:ssä, mutta haavoittuvia ovat myös PHP-FPM, php-cgi, FrankenPHP ja LiteSpeed. Symfony-projektit, joita ajetaan Symfony Runtimen kautta FrankenPHP:llä tai muilla jatkuvasti käynnissä olevilla palvelimilla, tarvitsevat päivityksen jälkeen täydellisen uudelleenkäynnistyksen tai uuden kuvan.
Symfonyn tietoturva: PHP-version ja prosessien tarkistus
php bin/console about näyttää Symfony-version, ympäristön, debug-tilan ja komentorivin PHP-version. Verkkopyynnöt kulkevat kuitenkin PHP-FPM:n tai sovelluspalvelimen kautta, ja se voi olla eri versio. Tarkistakaa molemmat reitit tai pyytäkää ylläpitäjää vahvistamaan ne.
Korjatut upstream-versiot ovat 8.5.12, 8.4.27, 8.3.36 ja 8.2.35; jakelujen backportit kantavat usein vanhempia numeroita. Mitä PHP-versioita teidän Symfony-versionne tukee, tarkistatte järjestelmävaatimuksista symfony.comin dokumentaatiosta.
# Näytetään ympäristö, debug-tila ja PHP-versio
php bin/console about
# Käsketään Messenger-workerit päättymään nykyisen viestin jälkeen
php bin/console messenger:stop-workers
# Riippuvuuksien tunnetut aukot
composer audit
Jos kuormantasaajan takana tai konteissa toimii useita instansseja, jokainen yksittäinen on korjattava ja käynnistettävä uudelleen. Unohdettu instanssi palvelee edelleen osaa pyynnöistä vanhalla PHP:llä.
Messenger-workerit, cron-komennot ja muut taustaprosessit lataavat PHP:n kerran käynnistyessään. Kunnes ne käynnistetään uudelleen, ne toimivat vanhalla PHP:llä muistissa. Prosessinhallinnan on käynnistettävä ne pysäytyksen jälkeen uudelleen.
Missä Symfony-sovellukset ovat haavoittuvia
| Paikka | Sisältö | Tarkistuskohde |
|---|---|---|
.env, .env.local, .env.local.php |
Ympäristömuuttujat, usein tietokanta ja API-avaimet | ei avattavissa web-juuresta, arvot uusittava epäilyn jälkeen |
config/secrets/prod/ |
salatut secretit | yksityinen salauksen purkuavain ei kuulu repositorioon |
public/ |
dokumenttijuuri: index.php |
ylimääräiset PHP-tiedostot |
var/cache/prod/ |
generoitu kontti ja mallipohjat PHP:nä | poistettava epäilyn jälkeen ja luotava uudelleen |
var/log/ |
lokit | talteen |
config/packages/security.yaml |
palomuurit, roolit, pääsysäännöt | odottamattomat muutokset |
Välimuisti on aliarvioitu piilopaikka. Symfony luo sinne PHP-tiedostoja, jotka ladataan jokaisella pyynnöllä. Näiden tiedostojen muutos ei näy repositoriossa, koska välimuistia ei versioida.
Tuotannossa kuuluvat asetukset APP_ENV=prod ja APP_DEBUG=0, eikä WebProfilerBundle saa olla siellä aktiivinen. Julkisesti saavutettava profiler osoitteessa /_profiler paljastaa asetukset ja pyyntötiedot.
Hallinta-alueet, bundlet ja riippuvuudet
Symfony-projekteissa on rakenteesta riippuen omia hallinta-alueita, usein bundleilla kuten EasyAdmin tai Sonata. Tarkistakaa security.yaml-tiedostosta, mitkä polut vaativat mitäkin rooleja, ja tietokannasta, kenellä nämä roolit ovat. Hallintapolut, joita tarvitaan vain sisäisesti, pitäisi rajata verkkopalvelimen tasolla tunnettuihin verkkoihin.
Bundlet ja Composer-paketit ovat vierasta koodia omine aukkoineen. composer audit näyttää tunnetut ongelmat; yksityiskohtaisemmin asiaa käsittelee sivu Composer-riippuvuuksien aukkojen tarkistus. Vanhentuneet paketit ovat lisäksi yleisin syy siihen, että PHP-päivitys kestää Symfony-projekteissa suunniteltua kauemmin.
Mihin Symfony-päivitys pystyy ja mihin ei
Symfony-komponenttien päivitys sulkee kehyksen virheitä. Se ei korjaa PHP:tä, ei käynnistä workereita uudelleen, ei uusi vuotaneita secrettejä eikä poista muokattua välimuistia. Onko hyökkäyksestä merkkejä, kuvaa sivu Olenko jo vaarantunut?. Koska vahvistettuja Indicators of Compromise -tunnisteita ei ole, auttaa ennen kaikkea epätavallisen käyttäytymisen, kuten odottamattomien prosessien tai lähtevien yhteyksien, tarkkailu.
Jos projekti toimitetaan konttina, uusi PHP kuuluu peruskuvaan. Rakentakaa kuva uudelleen, vaikka koodiin ei olisi tullut muutoksia, ja ottakaa se käyttöön kaikissa ympäristöissä. Dockerfile näyttää, mitä peruskuvaa käytetään; kiinteästi asetettu vanha tunniste estää muuten uudelleenrakennusta saamasta korjattua PHP:tä lainkaan. Yksityiskohdat ovat sivulla PHP:n korjaus Docker-konteissa.
Miten PHP SOS auttaa konkreettisesti?
- Selvitämme, mitä PHP:tä Symfony-projektinne web, CLI ja workerit käyttävät, ja tuemme hallittua uudelleenkäynnistystä.
- Varmuuskopioimme lokit 20.10.2026 alkaen ja vertaamme palvelimen koodia repositorioonne.
- Tarkistamme ympäristötiedostot, secretit, välimuistin, profilerin asetukset ja hallinnan roolit.
- Prosessien ja yhteyksien jatkuvaan tarkkailuun tarjoamme tietoturvamonitoroinnin.
Usein kysytyt kysymykset
Koskeeko PHP2Shell Symfonyä?
Symfonyssä itsessään ei ole uutta aukkoa. PHP2Shell on PHP:ssä, siis jokaisen Symfony-sovelluksen ajoympäristössä. Aukko suljetaan PHP-päivityksellä tai vahvistetulla backportilla ja kaikkien PHP-prosessien uudelleenkäynnistyksellä.
Miten pysäytän Messenger-workerit PHP-päivityksen jälkeen?
Komennolla php bin/console messenger:stop-workers käynnissä olevat workerit käsketään päättymään nykyisen viestin jälkeen. Prosessinhallinta, kuten Supervisor tai systemd, käynnistää ne sitten uudelleen uudella PHP:llä.
Miksi Symfony-profiler on tuotannossa vaarallinen?
Profiler näyttää pyyntöjä, asetuksia ja usein ympäristömuuttujia. Jos se on aktiivinen julkisella palvelimella, kuka tahansa voi hakea nämä tiedot. Se kuuluu vain kehitysympäristöön.
Mitä välimuistille tapahtuu hyökkäyksen jälkeen?
Hakemiston var/cache välimuisti sisältää generoitua PHP-koodia. Hyökkääjä voi tallentaa sinne koodia, joka suoritetaan jokaisella pyynnöllä. Epäilyn jälkeen välimuisti kannattaa poistaa ja luoda uudelleen tarkistetusta lähdekoodista.