Lühidalt: Symfony turvalisus pärast PHP2Shelli tähendab: PHP paigata, kõik protsessid, sealhulgas Messengeri töötajad, taaskäivitada ning seejärel kontrollida secrets'e, vahemälu ja profilerit. Turvaauk asub PHP-s, mitte Symfonys; ainuüksi Symfony uuendus seda ei sulge.
Miks PHP2Shell puudutab iga Symfony projekti
Symfony on paljude ettevõterakenduste, API-de ja portaalide alus ning peitub lisaks süsteemides nagu Shopware 6 ja Contao. PHP turvaaugud CVE-2026-109618 ja CVE-2026-109619 võimaldavad PHP meeskonna andmetel kahjuliku koodi käivitamist ilma sisselogimiseta. Kas rakendus on puhtalt programmeeritud, sealjuures rolli ei mängi.
PHP meeskond hindab riski mod_php puhul kõige suuremaks, kuid mõjutatud on ka PHP-FPM, php-cgi, FrankenPHP ja LiteSpeed. Symfony projektid, mida käitatakse Symfony Runtime'i kaudu FrankenPHP-ga või muude pidevalt töötavate serveritega, vajavad pärast uuendust täielikku taaskäivitust või uut tõmmist.
Symfony turvalisus: PHP versiooni ja protsesside kontrollimine
php bin/console about näitab Symfony versiooni, keskkonda, silumisrežiimi ja käsurea PHP versiooni. Veebipäringud töötavad aga PHP-FPM-i või rakendusserveri kaudu ja see võib olla teine versioon. Kontrollige mõlemat teed või laske need haldajal kinnitada.
Upstream'i parandatud versioonid on 8.5.12, 8.4.27, 8.3.36 ja 8.2.35; distributsioonide tagasiportimised (backport) kannavad sageli vanemaid numbreid. Milliseid PHP versioone teie Symfony versioon toetab, kontrollige süsteeminõuete järgi dokumentatsioonis lehel symfony.com.
# Keskkonna, silumisrežiimi ja PHP versiooni kuvamine
php bin/console about
# Messengeri töötajate lõpetamine pärast praegust sõnumit
php bin/console messenger:stop-workers
# Sõltuvuste teadaolevad turvaaugud
composer audit
Kui mitu instantsi töötab koormusjaguri taga või konteinerites, peab iga üksik olema paigatud ja taaskäivitatud. Ununenud instants teenindab edasi osa päringuid vana PHP-ga.
Messengeri töötajad, cron-käsud ja muud taustaprotsessid laadivad PHP ühe korra käivitamisel. Kuni neid ei taaskäivitata, töötavad nad mälus oleva vana PHP-ga. Protsessihaldur peab need pärast peatamist uuesti käivitama.
Kus Symfony rakendused on ründamisele avatud
| Koht | Sisu | Kontrollpunkt |
|---|---|---|
.env, .env.local, .env.local.php |
Keskkonnamuutujad, sageli andmebaas ja API võtmed | Ei ole veebijuurest kättesaadav, väärtused kahtluse korral uuendada |
config/secrets/prod/ |
Krüpteeritud secrets | Privaatne dekrüpteerimisvõti ei kuulu hoidlasse |
public/ |
Dokumendijuur koos index.php |
Lisa-PHP failid |
var/cache/prod/ |
Genereeritud konteiner ja mallid PHP-na | Kahtluse korral kustutada ja uuesti genereerida |
var/log/ |
Logid | Varundada |
config/packages/security.yaml |
Tulemüürid, rollid, ligipääsureeglid | Ootamatud muudatused |
Vahemälu on alahinnatud peidukoht. Symfony genereerib sinna PHP faile, mida laaditakse igal päringul. Nende failide muudatus ei jää hoidlas silma, sest vahemälu ei versioonita.
Tootmises kuuluvad APP_ENV=prod ja APP_DEBUG=0 ning WebProfilerBundle ei tohi seal aktiivne olla. Avalikult kättesaadav profiler aadressil /_profiler annab konfiguratsiooni ja päringuandmed ära.
Admin-piirkonnad, bundle'id ja sõltuvused
Symfony projektidel on ülesehitusest olenevalt oma admin-piirkonnad, sageli bundle'itega nagu EasyAdmin või Sonata. Kontrollige failis security.yaml, millised rajad nõuavad milliseid rolle, ja andmebaasis, kellel need rollid on. Admin-rajad, mida vajatakse ainult sisemiselt, peaksid olema veebiserveri tasemel piiratud teadaolevate võrkudega.
Bundle'id ja Composeri paketid on võõras kood oma turvaaukudega. composer audit näitab teadaolevaid probleeme; põhjalikumalt leht Composeri sõltuvuste kontroll turvaaukude suhtes. Aegunud paketid on lisaks sagedaseim põhjus, miks PHP-upgrade Symfony projektides kestab kauem kui planeeritud.
Mida Symfony uuendus annab ja mida mitte
Symfony komponentide uuendus sulgeb raamistiku vead. See ei paiga PHP-d, ei taaskäivita töötajaid, ei uuenda lekkinud secrets'e ega eemalda manipuleeritud vahemälu. Kas on rünnaku märke, kirjeldab leht Kas olen juba kompromiteeritud?. Kuna kinnitatud kompromiteerimise indikaatoreid (Indicators of Compromise) ei ole, aitab eelkõige ebatavalise käitumise, näiteks ootamatute protsesside või väljaminevate ühenduste jälgimine.
Kui projekt tarnitakse konteinerina, kuulub uus PHP baastõmmisesse. Ehitage tõmmis uuesti, ka kui koodis midagi ei muutunud, ja rullige see välja kõigis keskkondades. Pilk Dockerfile'i näitab, millist baastõmmist kasutatakse; kindlaks määratud vana silt (tag) takistab muidu, et uusehitus paigatud PHP-d üldse saab. Üksikasjad leiate lehelt PHP paikamine Dockeri konteinerites.
Kuidas PHP SOS konkreetselt aitab?
- Teeme kindlaks, millist PHP-d teie Symfony projekti veeb, CLI ja töötajad kasutavad, ning toetame korrapärast taaskäivitust.
- Varundame logid alates 20.10.2026 ja võrdleme serveri koodi teie hoidlaga.
- Kontrollime keskkonnafaile, secrets'e, vahemälu, profileri sätteid ja admin-rolle.
- Protsesside ja ühenduste jooksvaks jälgimiseks pakume turvamonitooringut.
Korduma kippuvad küsimused
Kas Symfony on PHP2Shellist mõjutatud?
Symfonyl endal uut turvaauku ei ole. PHP2Shell asub PHP-s, ehk iga Symfony rakenduse käitusaegses keskkonnas. Turvaauk suletakse PHP uuenduse või kinnitatud tagasiportimisega (backport) ja kõigi PHP protsesside taaskäivitusega.
Kuidas ma Messengeri töötajad pärast PHP uuendust peatan?
Käsuga php bin/console messenger:stop-workers antakse töötavatele töötajatele korraldus pärast praegust sõnumit lõpetada. Protsessihaldur, nagu Supervisor või systemd, käivitab need seejärel uue PHP-ga uuesti.
Miks on Symfony profiler tootmises ohtlik?
Profiler näitab päringuid, konfiguratsiooni ja sageli keskkonnamuutujaid. Kui see on avalikul serveril aktiivne, saab igaüks need andmed kätte. See kuulub ainult arenduskeskkonda.
Mis juhtub vahemäluga pärast rünnakut?
Vahemälu kaustas var/cache sisaldab genereeritud PHP koodi. Ründaja võib sinna jätta koodi, mis töötab igal päringul kaasa. Kahtluse korral tuleks vahemälu kustutada ja kontrollitud lähtekoodist uuesti genereerida.