Alior „raty” w PrestaShop. Dwa SQL Injection z CERT Polska
Nie będzie tu payloadów ani checklisty „jak wyciągnąć bazę cudzego sklepu”. CERT Polska opisał dwie podatności w module bankowym i podał poprawione wersje. Interesuje mnie coś bliższego polskiej niszy: jak często zaufanie do wtyczki „od banku” kończy się SQL Injection w panelu PrestaShop, czyli w miejscu, gdzie leżą zamówienia, klienci i czasem dane do rat.
14 września 2026 CERT ogłosił koordynację ujawnienia CVE-2026-7848 i CVE-2026-15600 w module raty Alior Banku dla partnerów handlowych na PrestaShop. Obie to klasyczne SQLi: wartości z POST idą prosto do UPDATE bez sanityzacji. Poprawki są. Kto został na starej gałęzi, trzyma dziurę w backoffice.
Co dokładnie ujawniono
CVE-2026-7848 siedzi w hookach przy aktualizacji produktu i kategorii (hookActionObjectProductUpdateBefore, hookActionObjectCategoryUpdateBefore, hookActionObjectCategoryAddAfter). Parametry POST alior_product_promotion, alior_category_promotion i alior_category_enabled trafiają do zapytań SQL bez walidacji. Według CERT problem domknięto w 8.1.11 i 9.0.7.
CVE-2026-15600 dotyczy metody toggleCategoryPromotionAction: parametr POST status też ląduje w UPDATE na surowo. Tu łatka to 8.1.12 i 9.0.8. Rekord CVE podaje CVSS 4.0 na poziomie 8.6 (wysoki), z wymogiem wysokich uprawnień w panelu.
Praktyczna konkluzja wersji: na linii 8.x celuj w co najmniej 8.1.12, na 9.x w 9.0.8. Niższe „naprawione” buildy z pierwszego CVE nie zamykają drugiego.
Zgłoszenie poszło do CERT od Krzysztofa Winiarskiego. Alior publikuje materiały dla partnerów handlowych przy kredytach ratalnych; stamtąd bierze się też ścieżka dystrybucji samego modułu.
Wymaga panelu. I tak boli
Obie luki wymagają dostępu do funkcji dodawania lub edycji produktów i kategorii w panelu administracyjnym PrestaShop. Nie ma tu historii o skanowaniu portu 80 z Shodana i natychmiastowym roocie. Jest historia o kimś, kto już siedzi w backoffice: skompromitowane konto pracownika, wyciek hasła z infostealera, zbyt szerokie uprawnienia dla agencji SEO, stary login freelancera.
Z takiego miejsca SQLi w module ratalnym nie kończy się na popsutej promocji Aliora. Kończy się na odczycie i zmianie bazy sklepu: klienci, adresy, historie zamówień, tokeny, co akurat leży w MySQL. W e-commerce to często wystarczy, żeby incydent przestał być problemem z wtyczką, a zaczął być RODO, bankiem i reputacją naraz.
Moduł od banku daje fałszywe poczucie, że to warstwa finansowa „już sprawdzona”. W praktyce to nadal kod PHP na Twoim serwerze, wpięty w hooki katalogu. Marka na stronie partnera nie sanityzuje parametrów POST.
Polska półka, nie abstrakcyjny CVE
PrestaShop w Polsce nadal ciągnie sporo sklepów średnich i mniejszych. Raty Aliora to konkretny produkt sprzedażowy, nie egzotyczny plugin z marketplace’u bez nazwy. Google lubi zapytania z marką i technologią naraz: „alior prestashop”, „raty podatność”, „sql injection prestashop”. CERT dał polski komunikat, numery CVE i wersje. To wystarczy, żeby temat żył dłużej niż jeden newsday.
Wzorzec z września jest znajomy. MikroTrick uderzał w edge z otwartym zarządzaniem. Cisco FMC w panel nad firewallami. Tu panel jest sklepowy, a „zarządzanie” to katalog i promocje ratalne. Inna skala, ten sam błąd zaufania: ktoś zostawił uprzywilejowaną powierzchnię i założył, że skoro wtyczka jest „oficjalna”, to baza jest bezpieczna.
CERT nie pisze o aktywnym wykorzystaniu w sieci. Nie ma też PoC w komunikacie. Sensowna linia: admin dostaje wersje, nie tutorial. Trzymam się jej.
Co zrobić, jeśli masz ten moduł
Sprawdź wersję wtyczki raty w PrestaShop. Jeśli jesteś poniżej 8.1.12 (gałąź 8) albo poniżej 9.0.8 (gałąź 9), aktualizuj z kanału Aliora dla partnerów, nie z losowego ZIP-a z forum. Po update: przegląd kont backoffice, logów logowań, nietypowych zmian w katalogu i bazie. Hasła paneli i dostępów do bazy warto wymienić, jeśli konto mogło być współdzielone.
Backoffice nie wystawiaj „na chwilę” do internetu bez MFA i bez ograniczenia IP, jeśli da się inaczej. Uprawnienia do edycji katalogu dawaj tylko tym, którzy naprawdę muszą. Moduł ratalny nie jest jedyną wtyczką w sklepie; ta akurat dostała CVE z CERT, więc wypada ją potraktować jak łatę bezpieczeństwa, nie jak opcjonalny changelog marketingowy.
Dwa SQLi w module ratalnym Aliora to sprawa sklepu, nie włamania do banku centralnego. Wtyczka siedzi na Twoim serwerze, wpięta w katalog i bazę, z której korzystasz na co dzień. CERT podał numery i wersje. Reszta należy do tego, kto ten sklep utrzymuje.