under 1 h to respond
A PrestaShop developer — not an automated acknowledgement, not a salesperson — replies in under an hour and can start work straight after.
The clock starts at your message or your paymentMalware, a skimmer on your checkout, redirects to somebody else's site, a back office you can't get into, a "dangerous site" warning in Google. You buy one hour of emergency work for €50 and a PrestaShop developer starts on your store straight after.
Two response times, depending on the day. Whichever applies right now is highlighted, based on the clock on your own device.
A PrestaShop developer — not an automated acknowledgement, not a salesperson — replies in under an hour and can start work straight after.
The clock starts at your message or your paymentWe don't work weekends as standard. We do still check what comes in and reply within two to three hours. If it's burning — a live skimmer, a suspended merchant account — we can usually get someone on it the same day.
No surcharge: the hour is still €50These are response times, not repair times. Nobody can promise to repair a compromised store in an hour without knowing what is inside it. What we do promise is that within an hour on a weekday — 2–3 hours at a weekend — somebody actually looks at your store, tells you what they see, and stops the bleeding.
Each symptom maps to a different family of attack, with its own priorities inside the first hour. Pick the one closest to what you can see: you will get what it means and what we do first.
All three start before you have repaired anything.
GDPR Article 33 gives you 72 hours from the moment you become aware of a personal data breach to notify your supervisory authority. The clock started when you found out, not when you are repaired.
A skimmer on the checkout page is a card incident. Providers and acquirers suspend the merchant account while they investigate — and a suspended account does not reopen in an afternoon, even once the store is clean.
Once Safe Browsing flags the domain, the store stops being visited: Chrome, Firefox and Safari show a full-screen warning before your homepage. Paid traffic keeps being billed and stops reaching the catalogue.
We have split the emergency into two decisions instead of one. The first costs €50 and takes thirty seconds. You make the second once you know exactly what is inside your store — and how many hours it takes to get it out.
You pay, you send us the access, we go in. No meeting to schedule, no brief to write.
After payment you immediately get the link to send us your access credentials securely.
Why €50 and not a free audit? A free audit gets you a report. €50 gets you an hour of someone actually working on the store. It is also what lets us put you ahead of the queue on a Sunday evening.
The order matters. We don't clean before there is evidence, and we don't restore a backup before knowing how long the intrusion has been running — last night's may already contain the backdoor.
A developer replies, not a form. We collect FTP/SSH, database and back-office access. If the attacker changed your passwords, we go through the host — it is common and it is workable.
A full copy of files and database in their compromised state. That is what lets you prove what happened — to your insurer, your payment provider, your supervisory authority — and stops the clean-up destroying the only evidence there is.
Skimmer on the checkout: neutralised first, before anything else. Admin accounts created by the attacker: removed. Cron jobs and web shells that reinstall the infection: disarmed. Outbound redirects: cut.
Dating the intrusion from file timestamps, server logs and PrestaShop logs. Identifying the entry point: vulnerable module, reused password, end-of-life branch, compromised FTP credentials. Without that answer, any clean-up is temporary.
You get it in writing: what was found, what was done during the hour, what is still open, and whether personal data was exposed — the information your GDPR notification needs. Alongside it, the number of hours the full fix takes.
Exhaustive clean-up of files and database, entry point closed, credentials and keys rotated, a Google review request filed once the store is genuinely clean, then monitoring. The real test of a clean-up is not the same day: it is the following week.
These are the indicators of compromise PrestaShop published in its 17 February 2026 alert. They are what we look for in the first ten minutes.
_partials/head.tpl
The theme file modified to inject code into every page of the site. That is where a skimmer sits so it can watch the payment forms go past.
mloader
A malicious loader dropped to fetch and run the next payload. It survives most "visual" clean-ups and quietly reinstalls the rest.
simplefilemanager
A fake module acting as a remote file manager. While it is there, the attacker keeps a key to your server even after you change every password.
atob(...)
A base64-encoded payload decoded at runtime so it reads as noise. A plain grep will not find it: you have to know where to look.
Source: PrestaShop security alert, 17 February 2026. If you recognise even one of these on your store, the infection is not superficial — and restoring a backup will not be enough.
ps_facetedsearch, published June 2026. It exposes every store on 1.7.1.0 or above. The maximum score means: exploitable remotely, without an account, without you doing anything.
True — and sometimes it is even enough. Here is where the line actually falls, so you can decide on the facts rather than on the sticker price.
| What has to be dealt with | A €99 clean | Restoring a backup | PrestaChamps€50 emergency hour, then a quote |
|---|---|---|---|
| Removing the visible malicious code | Yes, that is the job | Yes, on the surface | Yes — but that is the easy part |
| Finding the backdoor that reinstalls everything | Rarely — this is why it comes back | No — often already in the backup | Systematic sweep for known IOCs, database included |
| Dating the start of the intrusion | Out of scope | Impossible once restored | File timestamps plus server and PrestaShop logs |
| Closing the entry point | Varies | No — the flaw comes back with it | Module, version or credential identified and fixed |
| Preserving usable evidence | The clean-up destroys it | The restore overwrites it | Snapshot of the compromised state before anything is touched |
| What your GDPR notification needs | Not provided | Not provided | What was affected, since when, and what left the server |
| Google blacklist recovery | Often filed too early, so rejected | Only if the backup is clean | Filed once the store is verified clean |
| What you know before paying for the rest | A flat price with no written scope | Nothing: you find out as you go | A quote in hours, line by line, after the diagnosis |
| If it comes back in six weeks | You pay the €99 again | You restore again | Post-incident monitoring: the real test of the clean-up |
If your store is a shop window with no online payment, no customer accounts and no personal data, a €99 clean can be enough and we will say so. The maths changes the moment there are cards, customer accounts or a merchant account to protect: there, a clean-up that leaves a backdoor behind did not cost you less — it cost you six more weeks.
It comes down to one thing: does the person opening your store know PrestaShop, or are they running a clean-up procedure that would apply to any CMS? We only do PrestaShop. No WordPress, no Shopify.
Three fields, because this is an emergency and not a tender. If you would rather start straight away, buy the emergency hour — we come back to you for the access right after.
We reply in under an hour (Monday to Friday).
Already sure this is an emergency?
Buy the emergency hour — €50