Un grup de skimming a compromis scriptul de analytics Plausible găzduit de Convertr și a injectat cod care fura datele cardurilor la checkout. Sansec a identificat campania pe 24 octombrie 2026 și suspectează o vulnerabilitate de execuție neautentificată în instalația Plausible veche. Convertr a curățat scriptul și a actualizat platforma, conform cercetătorilor citați de BleepingComputer.

Ce s-a întâmplat, pe scurt și fără ambalaj

Convertr este o platformă braziliană de ecommerce care deservește zeci de branduri mari de modă și procesează plăți de ordinul a 2 miliarde de reali. Compania rula o instanță proprie de Plausible, alternativă open source la Google Analytics. Atacatorii au modificat fișierul tracker de pe serverul self-hosted, iar acel fișier se încarcă pe paginile de checkout ale tuturor comercianților de pe platformă.

Sansec, firmă de securitate pentru ecommerce, a identificat campania pe 24 octombrie 2026 și o atribuie unui grup brazilian activ din cel puțin iulie 2024, specializat pe magazine Magento, OpenCart și WooCommerce. Cercetătorii suspectează că accesul inițial a venit prin CVE-2026-8467, o vulnerabilitate de execuție de comenzi fără autentificare care afecta instalația veche de Plausible Community Edition. Sursa precizează clar: ipoteza nu a fost confirmată.

Atacatorii au injectat cod malițios în trackerul legitim, nu au creat un fișier separat. Asta e diferența care contează. Un script care vine de pe infrastructura platformei și se încarcă pe fiecare pagină de plată este, practic, un punct unic de compromis pentru tot ecosistemul.

Skimmerul a evoluat. Versiunile timpurii foloseau patternuri generice pentru câmpurile de plată. Până pe 26 octombrie, atacatorii au împins o versiune rafinată care viza exact numele câmpurilor din API-ul de plăți Convertr. Ce colecta: numărul cardului, data expirării, CVV-ul, numele titularului și CPF-ul, adică identificatorul fiscal brazilian. Practic tot ce ai nevoie ca să faci o tranzacție frauduloasă sau să vinzi datele mai departe.

Convertr a eliminat skimmerul și a actualizat Plausible la o versiune patch-uită. Compania a anunțat că notifică comercianții afectați și procesatorii de plăți. BleepingComputer a cerut un punct de vedere oficial și nu primise răspuns la momentul publicării. Un detaliu operațional important: cache-ul browserului poate ține scriptul malițios activ până la 24 de ore după curățare. Sansec recomandă clienților să își golească cache-ul înainte de o comandă nouă.

De ce analytics-ul e un vector de atac, nu un raport

Aici e lecția care se aplică dincolo de Brazilia. Scripturile de analytics, tag manager, pixel și tracking trăiesc pe fiecare pagină, inclusiv pe checkout. Le încarci o dată, în header, și rulează la fiecare vizitator. Cine controlează acel fișier controlează, tehnic, tot ce se întâmplă în browserul clientului.

Majoritatea echipelor de marketing tratează zona asta ca pe un teren de joacă: adaugă un tag nou, un pixel, un script de A/B testing, un heatmap. Fiecare vine de la un domeniu terț, fiecare are permisiuni de execuție în pagina de plată. Suprafața de atac crește cu fiecare instrument adăugat, iar nimeni nu face inventarul.

Skimmerul din cazul Convertr nu era un fișier străin. Era trackerul legitim, modificat. Asta înseamnă că semnătura de încredere (domeniul platformei, scriptul cunoscut) a fost exact ce a făcut atacul dificil de detectat. Un scan rapid care caută domenii necunoscute nu prinde asta.

Mai e un strat: Magecart și familiile de skimmer se adaptează. Trei zile au trecut între identificare și versiunea care viza câmpurile exacte ale API-ului Convertr. Nu vorbim despre un atac static, scris o dată și uitat. Vorbim despre adaptare la țintă, în timp real.

Ce spune și ce nu spune sursa

Fapte confirmate sau raportate direct:

Ce rămâne ipoteză sau neconfirmat:

Nu transformăm suspiciunea într-o certitudine. Faptul că un CVE e suspectat nu înseamnă că a fost exploatat în acest incident, iar absența unei confirmări nu înseamnă nici că platforma era curată. E o verificare incompletă, iar o verificare incompletă nu dovedește nimic în niciuna dintre direcții.

Ce înseamnă pentru tine, dacă vinzi online din România

Ai un magazin pe Shopify, WooCommerce sau Magento. Ai un checkout, ai pixeli, ai un tag manager, ai analytics. Chiar dacă nu lucrezi cu Convertr și nu ai clienți în Brazilia, modelul de atac se aplică identic.

Primul reflex: inventarul scripturilor care rulează pe pagina de plată. Nu pe homepage, nu pe pagina de produs, pe checkout. Câte sunt, de pe ce domenii vin, cine le administrează, când au fost actualizate ultima dată. Dacă răspunsul e „nu știu exact" sau „le-a pus cineva acum doi ani", ai o problemă de guvernanță, nu neapărat un incident.

Al doilea reflex: separă instrumentele de marketing de pagina de plată. Un pixel de retargeting nu are ce căuta pe checkout dacă nu îți trebuiește acolo. Fiecare script eliminat de pe pagina de plată e un vector mai puțin. Dacă îți trebuiește pentru măsurare, izolează-l în sandbox, limitează permisiunile, monitorizează ce încarcă.

Al treilea reflex: tratează dependența de platformă ca pe o dependență de securitate. Când checkout-ul tău rulează pe infrastructura altcuiva, securitatea acelui furnizor e securitatea ta. Întreabă ce versiuni rulează, ce patch-uri au, cine răspunde la incidente și în cât timp. Dacă nu primești răspunsuri concrete, ai informația de care ai nevoie.

Al patrulea: cache-ul. Dacă vreodată primești o notificare de incident de la un furnizor, curățarea pe server nu înseamnă curățare în browserul clientului. Recomandarea Sansec de golire a cache-ului se traduce în comunicare activă către clienți, nu doar în tăcere operațională.

Pe partea de plăți, metoda cardurilor virtuale de unică folosință rămâne o măsură rezonabilă pentru cumpărători. Pentru comerciant, nu rezolvă problema, dar reduce impactul asupra clientului final.

Dacă lucrezi cu procesatori care oferă tokenizare și 3D Secure, ai straturi suplimentare. Nu elimină skimmingul, pentru că skimmerul citește datele înainte să ajungă la procesator, dar limitează ce se poate face cu ele. Un checkout care nu are niciodată datele cardului în DOM-ul propriu e mai greu de skimming decât unul care le are.

Pentru magazinele care se bazează pe integrări de tip analytics și CRM, merită citit și materialul despre cum colectezi emailuri într-un magazin online, fără spam, pentru că aceleași principii de minimizare a datelor se aplică și la formulare. Iar dacă lucrezi cu Shopify, mutarea payout-urilor în Dev Dashboard discutată aici ridică aceeași întrebare de guvernanță a accesului: cine are chei, cine are permisiuni, cine răspunde.

Un plan de verificare în șapte pași

Nu îți promit că rezolvi securitatea într-o după-amiază. Îți dau un cadru de lucru realist.

  1. Inventar complet al scripturilor de pe checkout, cu domeniu sursă, proprietar intern și data ultimei revizuiri.
  2. Elimină tot ce nu e strict necesar pe pagina de plată. Măsurarea se poate face și fără execuție în acel context.
  3. Verifică dacă furnizorii self-hosted (analytics, tag manager, CDN) rulează versiuni actualizate și au proces de patch documentat.
  4. Cere furnizorului de platformă un răspuns scris despre gestionarea incidentelor și notificarea clienților.
  5. Monitorizează integritatea scripturilor critice, cu alertă la modificare, nu doar cu scan periodic.
  6. Pregătește un plan de comunicare pentru clienți, pentru scenariul în care primești o notificare de incident.
  7. Documentează totul. Un inventar scris valorează mai mult decât o promisiune verbală de la un contractor.

Niciunul dintre pași nu garantează că nu vei fi lovit. Toți reduc timpul în care un atac trece nedetectat, iar timpul e variabila care contează cel mai mult în skimming.

FAQ

A fost confirmat CVE-2026-8467 ca vector de atac? Nu. Sansec îl suspectează ca punct de acces inițial în instalația veche de Plausible Community Edition a Convertr, dar materialul sursă spune explicit că ipoteza nu a fost confirmată. Tratează-l ca pe o pistă de investigație, nu ca pe o concluzie.

Dacă nu folosesc Convertr, sunt în siguranță? Nu există „în siguranță" ca stare permanentă. Modelul de atac vizează orice script terț care rulează pe checkout. Platforma diferă, principiul rămâne același: un fișier compromis pe infrastructura unui furnizor afectează toți comercianții care îl încarcă.

Cât timp rămâne scriptul activ după curățare? Sansec avertizează că cache-ul browserului poate păstra scriptul malițios până la 24 de ore după ce a fost eliminat de pe server. Clienții sunt sfătuiți să golească cache-ul înainte de o comandă nouă.

AI-ul te ajută să analizezi, dar decizia și execuția rămân umane

Un instrument AI îți poate face inventarul scripturilor în câteva minute, poate compara versiuni, poate semnala diferențe între ce rulează acum și ce rula acum o săptămână. Poate tria lista de furnizori după risc. Poate redacta un plan de comunicare pentru clienți. Aici AI-ul chiar ajută, fără hype.

Ce nu face AI-ul: să decidă dacă acel tag de pe checkout merită păstrat, dacă furnizorul self-hosted are un proces serios de patch, dacă notificarea primită e suficientă sau trebuie escaladată. Decizia de a elimina un script, de a schimba un furnizor sau de a comunica public un incident rămâne la media buyer, la omul care răspunde de operațiune. Execuția pe un magazin real cere context pe care un model nu îl are.

Pasul concret îl face ALLSoft Agency: inventar de scripturi pe checkout, verificare de configurare și un plan de acțiune scris, nu o promisiune. Fără cifre inventate, fără promisiuni de „zero risc". Cu verificare acolo unde probele sunt insuficiente.