Īsi: Symfony drošība pēc PHP2Shell nozīmē: ielāpot PHP, pārstartēt visus procesus, ieskaitot Messenger worker, un pēc tam pārbaudīt Secrets, kešatmiņu un Profiler. Ievainojamība atrodas PHP, nevis Symfony; ar Symfony atjauninājumu vien to neaizver.
Kāpēc PHP2Shell skar katru Symfony projektu
Symfony ir daudzu uzņēmumu lietojumprogrammu, API un portālu pamats, un tas atrodas arī tādās sistēmās kā Shopware 6 un Contao. PHP ievainojamības CVE-2026-109618 un CVE-2026-109619 saskaņā ar PHP komandu ļauj izpildīt ļaunprātīgu kodu bez pieteikšanās. Vai lietojumprogramma ir tīri programmēta, tam nav nozīmes.
PHP komanda risku mod_php gadījumā vērtē kā augstāko, taču skarti ir arī PHP-FPM, php-cgi, FrankenPHP un LiteSpeed. Symfony projektiem, kas ar Symfony Runtime tiek darbināti uz FrankenPHP vai citiem pastāvīgi darbojošiem serveriem, pēc atjaunināšanas vajadzīga pilnīga pārstartēšana vai jauns attēls (image).
Symfony drošība: PHP versijas un procesu pārbaude
php bin/console about rāda Symfony versiju, vidi, atkļūdošanas režīmu un komandrindas PHP versiju. Tīmekļa pieprasījumi tomēr darbojas caur PHP-FPM vai lietojumprogrammu serveri, un tā var būt cita versija. Pārbaudiet abus ceļus vai likt tos apstiprināt operatoram.
Labotās upstream versijas ir 8.5.12, 8.4.27, 8.3.36 un 8.2.35; distributīvu backport labojumiem bieži ir vecāki numuri. Kuras PHP versijas atbalsta jūsu Symfony versija, pārbaudiet pēc sistēmas prasībām dokumentācijā vietnē symfony.com.
# Parādīt vidi, atkļūdošanas režīmu un PHP versiju
php bin/console about
# Likt Messenger worker pēc pašreizējā ziņojuma beigt darbu
php bin/console messenger:stop-workers
# Zināmas ievainojamības atkarībās
composer audit
Ja vairākas instances darbojas aiz slodzes balansētāja (load balancer) vai konteineros, katrai jābūt ielāpotai un pārstartētai. Aizmirsta instance turpina apkalpot daļu pieprasījumu ar veco PHP.
Messenger worker, cron komandas un citi fona procesi PHP ielādē vienreiz startēšanas brīdī. Līdz pārstartēšanai tie atmiņā darbojas ar veco PHP. Procesu pārvaldniekam tie pēc apturēšanas atkal jāpalaiž.
Kur Symfony lietojumprogrammas ir ievainojamas
| Vieta | Saturs | Pārbaudes punkts |
|---|---|---|
.env, .env.local, .env.local.php |
Vides mainīgie, bieži datubāze un API atslēgas | Nav izsaucami no webroot, aizdomu gadījumā vērtības mainīt |
config/secrets/prod/ |
Šifrēti Secrets | Privātā atšifrēšanas atslēga nepieder repozitorijā |
public/ |
Dokumentu sakne ar index.php |
Papildu PHP faili |
var/cache/prod/ |
Ģenerēts konteiners un veidnes kā PHP | Aizdomu gadījumā dzēst un ģenerēt no jauna |
var/log/ |
Žurnāli | Saglabāt |
config/packages/security.yaml |
Ugunsmūri (firewalls), lomas, piekļuves noteikumi | Negaidītas izmaiņas |
Kešatmiņa ir par zemu vērtēta slēptuve. Symfony tur ģenerē PHP failus, kas tiek ielādēti katrā pieprasījumā. Izmaiņa šajos failos repozitorijā nav pamanāma, jo kešatmiņa netiek versionēta.
Produkcijā jābūt APP_ENV=prod un APP_DEBUG=0, un WebProfilerBundle tur nedrīkst būt aktīvs. Publiski pieejams Profiler zem /_profiler atklāj konfigurāciju un pieprasījumu datus.
Admin apgabali, bundle un atkarības
Symfony projektiem atkarībā no uzbūves ir savi admin apgabali, bieži ar bundle, piemēram, EasyAdmin vai Sonata. Pārbaudiet security.yaml, kuri ceļi kādas lomas prasa, un datubāzē, kam šīs lomas ir. Admin ceļiem, kas vajadzīgi tikai iekšēji, jābūt ierobežotiem uz zināmiem tīkliem tīmekļa servera līmenī.
Bundle un Composer pakotnes ir svešs kods ar savām ievainojamībām. composer audit rāda zināmas problēmas; plašāk lasiet rakstā Composer atkarību pārbaude uz ievainojamībām. Novecojušas pakotnes turklāt ir biežākais iemesls, kāpēc PHP jauninājums Symfony projektos aizņem ilgāk nekā plānots.
Ko Symfony atjauninājums dod un ko ne
Symfony komponentu atjauninājums aizver kļūdas ietvarā. Tas neielāpo PHP, nepārstartē worker procesus, nemaina noplūdušus Secrets un nenoņem manipulētu kešatmiņu. Vai ir uzbrukuma pazīmes, apraksta Vai esmu jau kompromitēts?. Tā kā apstiprinātu kompromitācijas pazīmju (Indicators of Compromise) nav, palīdz galvenokārt neparastas uzvedības novērošana, piemēram, negaidīti procesi vai izejošie savienojumi.
Ja projekts tiek piegādāts kā konteiners, jaunajam PHP jābūt bāzes attēlā. Uzbūvējiet attēlu no jauna, arī ja kodā nekas nav mainījies, un izvietojiet to visās vidēs. Skatiens Dockerfile parāda, kāds bāzes attēls tiek izmantots; fiksēta veca birka (tag) citādi neļauj jaunbūvei vispār saņemt ielāpoto PHP. Sīkāk lasiet rakstā PHP ielāpošana Docker konteineros.
Kā PHP SOS palīdz konkrēti?
- Mēs nosakām, kuru PHP izmanto jūsu Symfony projekta tīmeklis, CLI un worker, un pavadām sakārtotu pārstartēšanu.
- Mēs saglabājam žurnālus no 20.10.2026 un salīdzinām kodu serverī ar jūsu repozitoriju.
- Mēs pārbaudām vides failus, Secrets, kešatmiņu, Profiler iestatījumus un admin lomas.
- Procesu un savienojumu pastāvīgai novērošanai mēs piedāvājam drošības monitoringu.
Biežāk uzdotie jautājumi
Vai Symfony ir skarts ar PHP2Shell?
Pašam Symfony jaunas ievainojamības nav. PHP2Shell atrodas PHP, tātad katras Symfony lietojumprogrammas izpildes vidē. Ievainojamību aizver PHP atjauninājums vai apstiprināts backport un visu PHP procesu pārstartēšana.
Kā apturēt Messenger worker pēc PHP atjauninājuma?
Ar php bin/console messenger:stop-workers darbojošiem worker procesiem tiek norādīts beigt darbu pēc pašreizējā ziņojuma. Procesu pārvaldnieks, piemēram, Supervisor vai systemd, tad tos pārstartē ar jauno PHP.
Kāpēc Symfony Profiler produkcijā ir bīstams?
Profiler rāda pieprasījumus, konfigurāciju un bieži vides mainīgos. Ja tas ir aktīvs publiskā serverī, šo informāciju var izsaukt ikviens. Tas pieder tikai izstrādes videi.
Kas notiek ar kešatmiņu pēc uzbrukuma?
Kešatmiņā zem var/cache ir ģenerēts PHP kods. Uzbrucējs tur var novietot kodu, kas darbojas katrā pieprasījumā. Aizdomu gadījumā kešatmiņa jāizdzēš un jāģenerē no jauna no pārbaudīta pirmkoda.