Magecart-angripere gjør Stripe om til en perfekt kamuflert kommandosentral

En kampanje avslørt av Sansec og BleepingComputer i juni 2026 viser hvordan Magecart-angripere tar i bruk Stripes egen infrastruktur som en engangs kommandosentral og eksfiltreringskanal . Angrepet laster aldri kode fra et ondsinnet domene. I stedet går alt – skriptet, skimming-nyttelasten og de stjålne betalingsdataene – gjennom googletagmanager.com og api.stripe.com. Dette er to domener som er så avgjørende for moderne netthandel at nesten ingen butikker blokkerer eller inspiserer dem nøye .

Samtidig ser vi en separat, kritisk sårbarhet i WordPress-pluginen Everest Forms Pro (CVE-2026-3300) som utnyttes aktivt. Denne lar uautoriserte angripere kjøre vilkårlig PHP-kode og overta sårbare nettsteder .

Slik fungerer det tretrinns Stripe Magecart-angrepet

Kampanjen består av tre ledd som hver for seg misbruker legitime tjenester for å unngå oppdagelse .

Trinn 1: Last inn skriptet via Google Tag Manager

Først får angriperne tilgang til en Google Tag Manager (GTM)-beholder på den aktuelle nettbutikken. De setter inn en ondsinnet tag som lastes på hver side. Fordi skriptet kommer fra googletagmanager.com, et pålitelig analysdomene, omgår det typiske innholdsbegrensninger (Content Security Policies) og annonseblokkere uten å vekke mistanke . GTM blir dermed en usperrbar leveringsmekanisme.

Trinn 2: Hent skimmeren fra Stripes API

I stedet for å kontakte en lyssky tredjepartsserver, ber GTM-taggen om skimming-nyttelasten fra api.stripe.com. Angriperne lagrer hele JavaScript-skimmeren i et kundemetadatafelt på sin egen Stripe-konto, og bruker en hemmelig testnøkkel (sk_test_...) for å skrive og hente den . Skimmeren kommer altså fra et domene butikkoperatører stoler helt på som del av sin betalingsløsning, og verken nettverksovervåking eller CSP-regler reagerer på kallet.

Trinn 3: Send stjålne data tilbake til den samme Stripe-kontoen

Når en kunde skriver inn kortdetaljer, personlig informasjon og fakturaadresse i kassen, fanger den injiserte skimmeren opp dataene og sender dem tilbake til angripernes Stripe-konto. Informasjonen skrives som falske kundeposter eller metadataoppføringer via det samme Stripe API-et . Siden eksfiltreringstrafikken går rett til api.stripe.com, glir den sømløst inn blant legitime API-kall – tyveriet blir nærmest usynlig i brannmurlogger og verktøy for avviksdeteksjon .

Hele operasjonen har pågått siden minst 24. desember 2025, ifølge indikatorene forskerne har sett .

Derfor er hemmelige testnøkler så farlige her

Stripes hemmelige testnøkler (sk_test_...) gir full lese- og skrivetilgang i sandkassemiljøet, og tillater ubegrenset opprettelse av falske kunder og metadatafelt uten kostnad . Fordi testnøkler aldri utløser ekte transaksjoner, er misbruk lett å overse. Angriperne baserer seg på at mange organiasjoner anser testnøkler som lavrisiko og ikke reviderer sandkasseaktiviteten med samme grundighet som produksjonsmiljøet.

En relatert, men separat, trussel er eksponering av hemmelige produksjonsnøkler (sk_live_...), som vil gi en angriper direkte tilgang til reelle transaksjonsdata og muligheten til å utstede refusjoner eller overføre penger . Selv om denne kampanjen bruker testnøkler for å holde seg skjult, er det underliggende prinsippet det samme: Stripe API-nøkler, uansett modus, er kraftige fullmakter som aldri bør vises i klientside-kode eller GTM-beholdere .

CVE-2026-3300: Kritisk RCE i Everest Forms Pro

Mens Stripe-kampanjen retter seg mot kasseflyten i nettbutikker, står WordPress-eiere overfor en like akutt trussel fra en plugin-sårbarhet som har vært aktivt utnyttet siden 13. april 2026 .

CVE-2026-3300 er en uautorisert ekstern kodekjøring (RCE) i Everest Forms Pro-pluginen, som har omtrent 4000 aktive installasjoner . Sårbarheten har en CVSS-score på 9,8 og påvirker alle versjoner opp til og med 1.9.12 .

Feilen ligger i process_filter()-funksjonen i utvidelsen "Calculation". Når funksjonen for "Kompleks beregning" er aktivert, tar pluginen brukerleverte verdier fra tekstfelter, limer dem direkte inn i en PHP-kodestreng og sender resultatet til eval() uten forsvarlig sikkerhetshåndtering . Funksjonen sanitize_text_field() som brukes på inndataene, nøytraliserer ikke enkle anførselstegn eller andre tegn med spesiell betydning i PHP-kodesammenheng, noe som lar en angriper bryte ut av den tiltenkte strengen og injisere vilkårlige kommandoer .

Wordfence har blokkert over 29 300 utnyttelsesforsøk og rapporterer at angripere oppretter uautoriserte administratorkontoer som del av angrepet . Nettstedeiere bør se etter tegn på kompromiss, som nye admin-brukere med uventede navn, uvanlige filer på serveren eller mistenkelige utgående tilkoblinger .

Forsvarstiltak mot begge trusler

Stopp Stripe Magecart-angrepskjeden

• Lås ned Google Tag Manager. Begrens GTM-beholdere til kun godkjente, reviderte tagger og innfør strenge godkjenningsrutiner før publisering .
• Stram inn Content Security Policy (CSP). Ikke oppgi api.stripe.com som script-src med mindre det er strengt nødvendig. Må du ha den med, håndhev subresource integrity (SRI)-hasher. Å blokkere innebygde skript gir et ekstra forsvarslag .
• Revidér Stripe-sandkasseaktiviteten. Overvåk Stripe-dashbordet for uvanlig mange opprettelser av kundeobjekter eller metadatasettinger under testnøkler. Behandle avvik i sandkassen med samme alvor som i produksjon.
• Roter og beskytt API-nøkler. Legg aldri ut hemmelige Stripe-nøkler – verken test eller live – i klientside-JavaScript, GTM-variabler eller offentlige kodelagre . Roter alle nøkler som kan ha blitt eksponert .
• Ta i bruk klientsideovervåking. Bruk integritetssjekker i nettleseren som oppdager uautorisert DOM-manipulasjon på kassesidene .

Tett sårbarheten i Everest Forms Pro

• Oppdater umiddelbart. Oppgrader til Everest Forms Pro versjon 1.9.13 eller nyere, som inneholder rettelsen .
• Deaktiver den risikable funksjonen hvis oppdatering må utsettes. Som en midlertidig løsning kan du skru av "Kompleks beregning"-funksjonen i plugin-innstillingene for å hindre utnyttelse via den ubeskyttede eval()-inngangen .
• Søk etter tegn på kompromiss. Se etter ukjente admin-kontoer, uventede filer, mistenkelige eval()-kall og utgående nettverksforbindelser til ukjente IP-adresser. En fullstendig integritetssjekk av WordPress-kjerne, temaer og plugin-filer er avgjørende etter opprydding .