# El. parduotuvė nulaužta? IT sauga prekiautojams

> El. parduotuvė nulaužta ar jai kelia pavojų PHP2Shell? Kaip prekiautojai apsaugo klientų paskyras, atsiskaitymą ir apyvartą bei tvarko pirmąsias valandas.

Šaltinis: https://phpsos.de/lt/branchen/onlineshops/  
Būsena: 2026-10-25  
Teikėjas: PHP SOS, PHP avarinė pagalba ir serverio sauga. Skubi pagalba per „WhatsApp“: https://wa.me/491736494914?text=Sveiki%2C%20PHP%20SOS%2C%20mums%20reikia%20pagalbos%20su%20m%C5%ABs%C5%B3%20PHP%20serveriu.%20%C4%AEmon%C4%97%3A%20%E2%80%A6%20Svetain%C4%97%3A%20%E2%80%A6

**Trumpai:** Jei jūsų el. parduotuvė nulaužta arba veikia su nepataisyta PHP versija, vienu metu kyla trys klausimai: klientų duomenys, atsiskaitymas ir jūsų apyvarta. Perjunkite parduotuvę į kontroliuojamą techninės priežiūros režimą, išsaugokite žurnalus nuo 2026-10-20 ir išsiaiškinkite, kas jūsų serveryje atnaujina ir paleidžia iš naujo PHP.

## Kas el. parduotuvėje pastatyta ant kortos

Parduotuvė yra daugiau nei svetainė. Ji tvarko klientų paskyras su slaptažodžių maišomis (hash), pristatymo ir sąskaitų adresus, užsakymų istoriją, nuolaidų kuponus ir dažnai taip pat sąsajas su prekių apskaita, pristatymo paslaugų teikėjais ir prekyvietėmis. Kas gali vykdyti kodą serveryje, paprastai prieina prie duomenų bazės ir joje saugomų API raktų.

Kortelių duomenys dažniausiai saugomi ne pas jus, o pas mokėjimo paslaugų teikėją. Tai nuramina tik iš dalies: užpuolikas gali į užsakymo procesą įterpti JavaScript, kuris naršyklėje skaito įvestis. Tokie skimming skriptai parduotuvės veikloje beveik nepastebimi, nes užsakymai praeina visiškai įprastai.

Prisideda sąsajos. Parduotuvė, kuri perduoda užsakymus prekių apskaitai, pristatymo paslaugų teikėjams ir prekyvietėms, prieigos raktus joms dažniausiai saugo serverio konfigūracijos failuose. Kas juos nukopijuoja, gali prekiautojo vardu kurti siuntų etiketes, keisti likučius ar piktnaudžiauti prekyviečių paskyromis.

## Tipinės parduotuvių sistemos ir kodėl jas veikia PHP2Shell

Plačiai paplitusios parduotuvių sistemos Europos vidutinio dydžio įmonėse veikia ant PHP: [Shopware 6](https://phpsos.de/lt/plattformen/shopware-6/), [WooCommerce](https://phpsos.de/lt/plattformen/woocommerce/), Magento, OXID, PrestaShop ir daug senesnių Shopware 5 diegimų. PHP2Shell (CVE-2026-109618 ir CVE-2026-109619, po CVSS 9,2) slypi pačiame PHP. Užpuolikams nereikia nei kliento paskyros, nei administratoriaus prieigos.

Prekiautojams tai reiškia: naujausias parduotuvės atnaujinimas neapsaugo. Lemia tai, ar serverio PHP yra 8.5.12, 8.4.27, 8.3.36 ar 8.2.35 arba hostingo teikėjas įdiegė backport, ir ar po to visi PHP procesai buvo paleisti iš naujo. Senoms parduotuvėms su PHP 8.1 ar senesne versija PHP projektas oficialių atnaujinimų nebeteikia. Tuomet greta avarinės situacijos laukia migracija, kurios nenorėtumėte atlikti skubėdami sezono piko metu.

## El. parduotuvė nulaužta: ką incidentas reiškia konkrečiai

Pažeista parduotuvė daro žalą keliais lygiais, kurie vienas kitą stiprina:

- **Apyvarta:** Kiekviena techninės priežiūros režimo valanda kainuoja užsakymus. Tačiau parduotuvė, kuri nepastebimai veikia toliau, gali kainuoti gerokai brangiau.
- **Klientų duomenys:** Nutekėję adresai ir užsakymai naudojami tikslingiems sukčiavimo (phishing) laiškams, kurie atrodo tikri, nes mini tikrus užsakymus.
- **Matomumas:** Jei Google aptinka kenkėjišką kodą, paieškos rezultatuose pasirodo įspėjimas. Kaip jo atsikratyti, aprašyta vadove [Google įspėjimo pašalinimas](https://phpsos.de/lt/ratgeber/google-warnung-entfernen/).
- **Partneriai:** Mokėjimo paslaugų teikėjai ir prekyvietės turi savo reikalavimus saugumo incidentams. Kas praneša per vėlai, rizikuoja problemomis atsiskaitant.

## Kas atsakingas: agentūra, hostingo teikėjas ar prekiautojas?

Daugelyje parduotuvių klausimas dėl PHP nukrinta tarp kėdžių. Agentūra parduotuvę sukūrė ir prižiūri įskiepius, hostingo teikėjas eksploatuoja serverį, o prekiautojas mano, kad vienas iš jų pasirūpins. Valdomame hostinge pataisas paprastai diegia hostingo teikėjas, nuosavame vServer niekas automatiškai.

| Užduotis | Paprastai atsakingas | Ką patikrinti |
|---|---|---|
| Atnaujinti PHP paketą | Hostingo teikėjas arba serverio prižiūrėtojas | Raštiškas patvirtinimas su paketo būsena |
| Paleisti iš naujo PHP procesus | Tas, kas valdo serverį | Paleidimo iš naujo laikas |
| Parduotuvė ir įskiepiai | Agentūra | Priežiūros sutartis ir prieigos |
| Informuoti mokėjimo paslaugų teikėją | Prekiautojas | Sutartinės pranešimo pareigos |

> **Svarbu:**
> PHP pataisa neįrodo, kad anksčiau nieko neįvyko. Jei parduotuvė buvo užpulta tarp spalio 17 d. ir pataisos įdiegimo momento, įterptas kodas gali veikti toliau. Leiskite tai patikrinti, kol paskelbsite, kad pavojus praėjo.

## Pirmosios valandos: seka prekiautojams

1. Perjunkite parduotuvę į techninės priežiūros režimą arba, jei to padaryti negalima, laikinai atjunkite nuo tinklo.
2. Išsaugokite žiniatinklio serverio, PHP ir parduotuvės žurnalus nuo 2026-10-20, kol rotacija jų neištrynė.
3. Paprašykite hostingo teikėjo raštu patvirtinti PHP paketo būseną ir paleidimą iš naujo.
4. Atnaujinkite administratorių slaptažodžius, mokėjimų, pristatymo ir prekyviečių API raktus bei duomenų bazės prieigas, ir tai darykite tik po išvalymo.
5. Patikrinkite atsiskaitymą, mokėjimo įskiepius ir įtrauktus skriptus dėl pakeitimų.

Jei yra duomenų nutekėjimo požymių, galioja [BDAR 72 valandų terminas](https://phpsos.de/lt/compliance/dsgvo-meldepflicht-72-stunden/). Teisinį vertinimą atliekate su savo duomenų apsaugos pareigūnu ir, jei reikia, su advokatu.

## Kaip konkrečiai padeda PHP SOS?

- Nuotoliu tikriname tikrąją PHP paketo būseną, veikimo režimą (pavyzdžiui, mod_php ar PHP-FPM) ir ar visi darbiniai procesai (worker) buvo paleisti iš naujo.
- Tiriame parduotuvės failus, duomenų bazę ir atsiskaitymą dėl webshell, skimming kodo ir naujų administratorių paskyrų ir [pašaliname rastą kenkėjišką programinę įrangą](https://phpsos.de/lt/leistungen/malware-entfernung/).
- Derinamės su jūsų agentūra ir hostingo teikėju, kad parduotuvės priežiūra ir serverio eksploatavimas nesikirstų.
- Radinius ir priemones dokumentuojame taip, kad galėtumėte pateikti mokėjimo paslaugų teikėjui, draudikui ir duomenų apsaugos pareigūnui.
- Po to sutvirtiname serverį ir pageidaujant perimame nuolatinę stebėseną.


## Dažni klausimai

**Ar dėl PHP2Shell turiu atjungti parduotuvę nuo tinklo?**  
BSI (Vokietijos federalinė informacijos saugumo tarnyba) rekomenduoja laikinai atjungti žiniatinklio serverius nuo tinklo, jei PHP atnaujinimas iš karto neįmanomas. Parduotuvei techninės priežiūros režimas su informaciniu puslapiu dažnai yra geresnis kelias nei klaidos pranešimas. Kai tik PHP pataisytas ir visi procesai paleisti iš naujo, parduotuvę galima vėl atidaryti.

**Ar mano parduotuvėje kyla pavojus kredito kortelių duomenims?**  
Daugumoje parduotuvių kortelių duomenys saugomi ne jūsų serveryje, o pas mokėjimo paslaugų teikėją. Pavojingas yra manipuliuotas atsiskaitymo kodas, kuris perima įvestis dar prieš joms pasiekiant teikėją. Todėl po atakos atsiskaitymas įtraukiamas į kiekvieną patikrą.

**Ar pakanka atnaujinti Shopware ar WooCommerce?**  
Ne. PHP2Shell veikia patį PHP, o ne parduotuvės sistemą. Parduotuvės atnaujinimas pažeidžiamumo neuždaro, o PHP pataisa nepašalina jau įterpto kenkėjiško kodo.

**Ką turiu informuoti po duomenų nutekėjimo?**  
Esant asmens duomenims, per 72 valandas gali tekti pranešti duomenų apsaugos priežiūros institucijai, o pagal riziką ir informuoti susijusius asmenis. Prisideda sutartinės pareigos mokėjimo paslaugų teikėjui ir draudikui. Vertinimą kiekvienu atveju atliekate kartu su duomenų apsaugos pareigūnu ir advokatu.

## Šaltiniai

- [php.net: saugumo pranešimai](https://www.php.net/)
- [BSI (Vokietijos federalinė informacijos saugumo tarnyba): įspėjimai ir rekomendacijos](https://www.bsi.bund.de/)
- [BDAR 33 straipsnis: pranešimas priežiūros institucijai](https://dsgvo-gesetz.de/art-33-dsgvo/)
- [OWASP Top 10](https://owasp.org/www-project-top-ten/)