# Ranljivost Magento PHP2Shell: zaščita Magento in Adobe Commerce

> Zaščitite Magento in Adobe Commerce po PHP2Shell: razjasnite stanje PHP, zavarujte env.php, poiščite skimmerje v podatkovni zbirki in pub/, preverite skrbnike.

Vir: https://phpsos.de/sl/plattformen/magento-adobe-commerce/  
Stanje: 25.10.2026  
Ponudnik: PHP SOS, Nujna pomoč za PHP in varnost strežnikov. Takojšnja pomoč po WhatsAppu: https://wa.me/491736494914?text=Pozdravljeni%2C%20PHP%20SOS%2C%20potrebujemo%20pomo%C4%8D%20z%20na%C5%A1im%20stre%C5%BEnikom%20PHP.%20Podjetje%3A%20%E2%80%A6%20Spletna%20stran%3A%20%E2%80%A6

**Na kratko:** Aktualna ranljivost Magento se imenuje PHP2Shell in ni v Magentu, ampak v PHP. Popravek Magento je ne zapre. Po posodobitvi PHP s ponovnim zagonom preglejte `app/etc/env.php`, podatkovno zbirko glede skimmerjev in seznam skrbniških računov.

## Kaj PHP2Shell pomeni za trgovine Magento

Magento Open Source in Adobe Commerce sta veliki aplikaciji PHP, ki večinoma tečeta s PHP-FPM. Ranljivosti CVE-2026-109618 in CVE-2026-109619 po navedbah ekipe PHP omogočata izvajanje škodljive kode brez prijave. Ali je trgovina sama aktualna, pri tem ni pomembno.

Trgovine Magento so že leta priljubljena tarča skimminga kreditnih kartic, pri katerem se vnosi v blagajni sproti berejo. PHP2Shell za to odpira še eno pot. Palo Alto Networks je naštel več kot 22,6 milijona izpostavljenih, potencialno ranljivih primerkov PHP; katere trgovine so med njimi, ni znano.

## Ranljivost Magento: pravilno ugotovite stanje PHP

Magento različice PHP v skrbniškem delu ne prikaže vidno. Stanje zato preverite v upravljalnem panelu gostovanja za domeno ali ga dajte potrditi ponudniku gostovanja. `php -v` v ukazni vrstici prikaže samo PHP CLI, s katerim tečeta `bin/magento` in cron opravila. PHP za splet prek FPM je lahko druga različica, popravljeni pa morata biti obe.

Odpravljene različice izvorne kode so 8.5.12, 8.4.27, 8.3.36 in 8.2.35, backporti distribucij lahko nosijo starejše številke. Katere različice PHP podpira vaša različica Magento, preverite v sistemskih zahtevah v dokumentaciji Adobe (experienceleague.adobe.com). Pri Adobe Commerce na infrastrukturi Adobe se o stanju pozanimajte pri Adobeju ali svojem upravljavcu. Navodila po korakih nudi prispevek [Pravilno preverjanje različice PHP in stanja popravkov](https://phpsos.de/sl/php2shell/php-version-pruefen/).

## Kje je škodljiva koda v Magentu

| Mesto | Vsebina | Točka preverjanja |
|---|---|---|
| `app/etc/env.php` | Podatkovna zbirka, ključ za šifriranje, pot do skrbniškega dela | Datum spremembe, ob sumu obnoviti vrednosti |
| `pub/` | Korenska mapa dokumentov, `pub/media`, `pub/static` | Datoteke PHP v mapah za medije in static |
| `app/code/` | Lastni moduli | Neznani moduli, spremenjene datoteke |
| `vendor/` | Paketi Composer, tudi razširitve | Odstopanja od datoteke lock |
| `generated/`, `var/` | Ustvarjena koda, predpomnilnik, dnevniki | Zavarovati dnevnike, kodo ustvariti znova |
| Podatkovna zbirka | Konfiguracija, bloki CMS, skrbniški uporabniki | Tuji skripti, novi skrbniki |

Skimmerji v Magentu pogosto ležijo v podatkovni zbirki, na primer v nastavitvah za dodatne skripte v glavi ali nogi strani in v blokih CMS. Samo skeniranje datotek jih spregleda. Neškodljivi bralni dostopi pomagajo pri prvem pogledu (predpona tabel je odvisna od namestitve):

```bash
bin/magento info:adminuri
bin/magento module:status
```

```sql
SELECT username, email, created FROM admin_user;
SELECT path, value FROM core_config_data WHERE path LIKE 'design/%' AND value LIKE '%<script%';
```

> **Pomembno:**
> Očiščena blagajna ne pomeni, da podatki niso iztekli. Pred odstranjevanjem skriptov zavarujte dnevnike od 20. 10. 2026 in izvoze podatkovne zbirke. Samo tako je pozneje mogoče ugotoviti, od kdaj in katera naročila so bila prizadeta.

## Skrbniški del in razširitve

Pot do skrbniškega dela je v Magentu prosto izbirna in zapisana v `env.php`. Težko uganljiva pot je smiselna, vendar ne nadomešča dvofaktorske prijave in omejitve na znana omrežja. Skrbniške uporabnike in njihove vloge redno preverjajte, prav tako integracije in žetone API.

Razširitev tretjih ponudnikov je pri Magentu veliko: načini plačila, povezave z ERP, moduli za iskanje in trženje. Vsaka prinaša kodo, ki jo je treba preveriti ob nadgradnjah PHP. Redno uporabljajte `composer audit` in izklopljene module popolnoma odstranite.

Pomislite tudi na procese v ozadju. Magento dela s cron opravili in pogosto z consumerji čakalnih vrst, ki tečejo kot lastni procesi PHP prek ukazne vrstice. Po posodobitvi PHP se morajo ti znova zagnati prav tako kot PHP-FPM. Po zamenjavi glavne različice PHP naj se poleg tega znova zgradita ustvarjena koda v `generated/` in statične datoteke, trgovino pa je treba v testnem okolju preizkusiti, preden se spet začne delovanje v živo. Kako se ponovni zagon opravi čisto, opisuje prispevek [Ponovni zagon PHP-FPM in vseh workerjev](https://phpsos.de/sl/php2shell/php-fpm-neustart/).

## Kaj posodobitev Magento zmore in česa ne

Izdaja Magento ali varnostni popravek Adobe zapre napake v kodi trgovine. PHP ne popravi, ne zažene znova procesov FPM, ne odstrani skriptov iz podatkovne zbirke in ne izbriše tujih skrbniških računov. Če se je koda že izvedla, je potrebna preiskava. Kako prepoznate stranska vrata, razlaga prispevek [Prepoznavanje in odstranjevanje webshellov](https://phpsos.de/sl/ratgeber/webshell-erkennen/).

Za trgovce s plačili s karticami velja še: preglejte pravila svojega ponudnika plačil za varnostne incidente in se pred obnovo ključev z njim uskladite. Ali je potrebna prijava nadzornemu organu za varstvo podatkov, razjasnite s pooblaščencem za varstvo podatkov ali odvetnikom.

## Kako PHP SOS pomaga konkretno?

- Razjasnimo PHP za splet in CLI na vašem strežniku Magento ter dosežemo potrditev popravka in ponovnega zagona.
- Dnevnike, datoteke in podatkovno zbirko zavarujemo sledljivo, po potrebi prek naše [IT-forenzike](https://phpsos.de/sl/leistungen/it-forensik/).
- Preverimo `env.php`, `pub/`, module, konfiguracijske tabele, bloke CMS in skrbniške račune.
- Očistimo, obnovimo ključe in dostope ter dokumentiramo obdobje možne prizadetosti za varstvo podatkov in ponudnike plačil.


## Pogosta vprašanja

**Ali varnostni popravek Magento zapre tudi PHP2Shell?**  
Ne. Popravki Magento odpravljajo napake v kodi trgovine. PHP2Shell je v interpreterju PHP na strežniku in se zapre samo s posodobitvijo PHP ali potrjenim backportom s ponovnim zagonom vseh procesov.

**Kje napadalci v Magentu skrivajo skimmerje kreditnih kartic?**  
Pogosto ne v datotekah, ampak v podatkovni zbirki, na primer v nastavitvah za dodatne skripte v glavi strani ali v blokih CMS. Zato ob sumu vedno sodi zraven tudi pregled podatkovne zbirke.

**Kdo popravlja PHP pri Adobe Commerce v oblaku?**  
To je odvisno od vaše pogodbe in okolja. Pri Adobeju ali svojem upravljavcu pisno povprašajte o stanju PHP in ponovnem zagonu. Lastne razširitve in vsebina podatkovne zbirke ostanejo v vaši odgovornosti.

**Zakaj je app/etc/env.php tako pomembna?**  
Datoteka vsebuje dostop do podatkovne zbirke, ključ za šifriranje in pot do skrbniškega dela. Kdor jo je lahko prebral, lahko dešifrira šifrirane vrednosti in najde skrbniški del. Ob sumu je treba te vrednosti obnoviti.

## Viri

- [php.net: varnostna obvestila](https://www.php.net/)
- [Adobe Commerce](https://business.adobe.com/)
- [OWASP Cheat Sheets](https://cheatsheetseries.owasp.org/)
- [Palo Alto/TechTarget: izpostavljeni primerki](https://www.techtarget.com/cybersecurity/news/366652444/PHP2Shell-22M-exposed-servers-at-risk-as-emergency-patches-released)