In short
- PrestaShop 1.7 has been unmaintained since 10 June 2025, the day PrestaShop 9.0 shipped. No fixes at all, security included. The information was published in the project’s technical channels, without causing the slightest visible change in any back office.
- The real hole is underneath. Official documentation caps PrestaShop 1.7.8 at PHP 7.4, whose end of life dates back to 28 November 2022. No module and no firewall patches a flaw in the interpreter itself.
- PrestaShop 8 does not fix that: the same documentation caps the whole 8 branch, 8.2 included, at PHP 8.1, end of life since 31 December 2025. The target of a migration is PrestaShop 9, not PrestaShop 8.
- Migrating is not only about security. The theme shipped by default with PrestaShop 9.1 is built around the European accessibility requirements that have applied to online shops since 28 June 2025. One migration therefore addresses two obligations.
- Since January and February 2026, the module ecosystem has been leaving 1.7: quality badge removed and updates rejected when a module is not compatible with the latest PrestaShop version.
- Vulnerability discovery is accelerating, and the gap is widening. On maintained software, a flaw found becomes a patch. On abandoned software, it becomes permanent exposure. The stock of known flaws in PrestaShop 1.7 can only grow.
- The inventory comes before the quote. The cost of a migration is not in your PrestaShop version, it is in your list of modules and overrides. It takes an hour, with no tools, from your back office.
Open your back office, look at the bottom of the home page, and read the version number. If it starts with 1.7, what follows concerns you directly. Nothing broke, no letter arrived, the shop takes orders exactly as it did yesterday. Three things stopped all the same, on three different dates, and the last one only just happened.
PrestaShop 1.7 end of support: what stopped, and when
1. The core, on 10 June 2025. In January 2023 the PrestaShop project published a sentence that committed the future: the maintenance period for 1.7 would end when PrestaShop 9.0 was released, and on that day 1.7 would no longer be maintained. PrestaShop 9.0 shipped on 10 June 2025. The sentence took effect without anyone having to republish it. Since that date, no fix has been issued for 1.7, including for a security flaw.
2. The language, on 28 November 2022. This one is older and runs deeper, and it is the point audits miss most often, because people read the shop version without reading the version of the language running it. The official compatibility table caps PrestaShop 1.7.8 at PHP 7.4. PHP 7.4 stopped being maintained on 28 November 2022. A shop on 1.7 therefore runs, at best, on an interpreter that has had no fixes for close to four years. That is a layer no module, no application firewall and no amount of hosting goodwill can make up for.
3. The module market, in January and February 2026. Since 1 January 2026, the official marketplace removes its quality badge from any module not compatible with the latest PrestaShop version. Since 1 February 2026, an update to a module not compatible with the latest version is rejected at validation. The expected baseline is now to work with the two latest major versions.
Why a module still compatible with 1.7 does not make you secure
There are still modules sold as compatible with 1.7, and that line reads spontaneously as a guarantee. It is the opposite.
A module still presented as compatible with 1.7 is, since the start of this year, either outside the official validation channel or maintained for a platform its own publisher no longer fixes. And even perfectly up to date, it does not protect a shop whose core and language are frozen. A module’s compatibility says nothing about the security of the shop hosting it, in the same way a site that is perfectly accessible on its home page can remain unusable in its checkout.
That is why the subject never surfaces: taken one at a time, every indicator you check is green.
Including the most misleading of them all. A vulnerable shop keeps showing its products, taking orders and collecting payment normally. Working properly is not a security indicator. The only one that is, is the date of the last fix available for your platform.
These tables hold a surprise that changes the target of a migration. Official documentation caps the entire PrestaShop 8 branch, version 8.2 included, at PHP 8.1, whose end of life came on 31 December 2025. Stopping at PrestaShop 8 does get you out of the unmaintained version, but it leaves the shop on a language that already receives no fixes. Only PrestaShop 9, which accepts PHP 8.1 to 8.5, puts the whole stack back on supported branches. The documentation says as much itself, noting that PHP versions past their end of support are compatible but not recommended.
Worth keeping in mind when arbitrating a budget: going from PrestaShop 1.7 to PrestaShop 8 is a technical step along the way, not a destination. The destination is PrestaShop 9.
Why the gap is widening: vulnerability discovery is accelerating
Since 2026 an argument has been circulating among providers: artificial intelligence will arm a generation of attackers and bring everything forward. The published figures say something else.
Artificial intelligence models are now able to hunt for flaws in existing code, at scale. On 7 April 2026 Anthropic announced a model called Mythos, which it chose not to release publicly for safety reasons, and reported more than 23,000 findings from the associated programme. Of those 23,000 findings, 126 led to a published vulnerability, and one has been confirmed exploited in the wild. More broadly, of the 1,061 vulnerabilities attributed to AI-assisted discovery in the first half of 2026, threat intelligence firm VulnCheck confirmed 14 as exploited, or 1.3 per cent.
The flood did not happen, then, and VulnCheck even concludes that these tools currently benefit defenders more than attackers. Anyone selling you a migration by waving that spectre is overstating it.
What is measured, on the other hand, is the compression of time. The median delay between the publication of a flaw and the moment its exploitation is observed fell from 120 days in 2025 to 80 days in the first half of 2026, across 495 newly exploited vulnerabilities.
The point that actually matters When discovery accelerates, maintained software turns every finding into a patch. Abandoned software turns every finding into permanent exposure. The gap between the two does not depend on the number of attackers; it widens mechanically with the pace of discovery.
That is why the subject is more pressing in 2026 than it was in 2023. Not because attackers have become more numerous, which the available data does not show, but because the stock of known flaws in a frozen version can only grow while the time available to react shrinks. On a maintained version, that stock empties with every patch. On PrestaShop 1.7, it will never empty.
PrestaShop 1.7, PCI DSS and regulation: what changed in 2025 and 2026
As long as staying on 1.7 was a technical trade-off, the decision could legitimately wait. Two texts moved the subject out of that register, and each carries a date.
The payment card industry data security standard, in version 4.0.1, applies to any shop handling card payments. Its so-called future requirements have been mandatory since 31 March 2025. One of them requires reviewing, at least once a year, all hardware and software technologies in use, to confirm that each still receives security fixes from its vendor. A shop running PrestaShop 1.7 immediately raises a problem in that review: one of the central technologies it uses no longer receives fixes from its publisher. The standard does not forbid using a technology past its end of support; it requires you to note it and to document a plan to address it. The platform carries plenty of other obligations besides that one, and not always the ones people expect, as our e-commerce platform compliance matrix shows. Another requirement asks for critical fixes to be applied within thirty days, which no longer has an object when none are issued.
The European cyber resilience regulation came into force on 10 December 2024, its reporting obligations have applied since 11 September 2026, and it applies in full on 11 December 2027. A point of honesty, because it is routinely glossed over in articles on the subject: those obligations fall on software publishers, not on the merchant, and how the text will classify an e-commerce module sold separately is not settled yet. So we will not tell you what your suppliers will have to do. What can be said safely is that the intent of the text is to make software maintenance enforceable against those who publish it, and that this pushes the ecosystem in the same direction as the marketplace rules described above.
Not theoretical: PrestaShop is an active target
PrestaShop is a known target, and the documented campaigns explicitly go after shops that are behind.
In July 2022, a campaign exploiting an unpatched flaw was used to steal payment data, and the project’s own warning named “shops using outdated versions of the software or vulnerable third-party modules”. In August 2024, a skimmer known as GTAG WebSocket was observed injected directly into core files, exfiltrating card data over a WebSocket to slip past conventional detection. The pkfacebook module served as an entry point for skimmer drops. In 2025, CVE-2025-51586 allowed administrator email addresses to be enumerated from the password reset form, across every version from 1.7 to 8.2.2. In February 2026, an unauthenticated SQL injection was published on the advancedpopupcreator module.
What these incidents have in common is not the sophistication of the attack. It is that the fix existed, or could have existed, on a maintained version.
Updating PrestaShop 1.7: the inventory to run before any quote
The question we always get is the budget. The budget of a migration is not in the PrestaShop version, which is the tooled and predictable part. It is in your modules and your overrides. Here is how to establish it yourself, in an hour, before asking anyone for a figure.
1. Record your exact version and your PHP version. The first is at the bottom of the back office home page, the second in the configuration information. Note both, they condition everything else.
2. List your installed and active modules. Active ones only. Modules disabled three years ago are not a migration subject, they are files to remove.
3. For each module, fill in three columns: the publisher, the installed version, and whether a version compatible with PrestaShop 9 exists. That third column is filled from the module’s page at its publisher, a few minutes per line.
4. Sort the result into three piles. A version 9 exists, that is a simple update line. It does not exist but the publisher is active, that is a question to ask right away, because their answer sets your schedule. It does not exist and the publisher has vanished, that is a replacement to plan, and this is the pile that blows budgets when nobody saw it coming.
This last point meets a blind spot we described about server-side tracking: a measurement or tracking chain breaks silently, without ever raising an error.
5. Record your overrides and your theme. A maintained and documented theme generally simplifies the migration without making it free: between PrestaShop 1.7 and 9, adaptations remain likely. A theme bought several years ago and edited directly in its files needs a specific audit, and it is better to raise that now than to discover it along the way.
The table to fill in has five columns, and looks like this.
| Module | Publisher, version | PrestaShop 9 version | Action |
|---|---|---|---|
| Carrier | Active publisher, 2.4 | Yes | Update |
| Loyalty | Active publisher, 1.8 | Not announced | Write to the publisher, their answer sets the schedule |
| Catalogue import | Publisher unreachable, 3.1 | No | Replacement to budget |
So you do not start from an empty spreadsheet, we publish this template freely in our resources: the PrestaShop 1.7 to 9 migration inventory. It returns a verdict per module, counts the three piles and exports the whole thing as CSV. Everything is computed in your browser; nothing is sent or stored.
At the end of this inventory you know what your situation is costing you. Not before. And you arrive at a provider with your list, which changes the nature of the conversation.
PrestaShop 8 or PrestaShop 9: four possible stances
| Stance | What it gives you | Who for |
|---|---|---|
| Do nothing | The risk does not show until it shows. But the annual review required by the card standard already fails today | Nobody, except the reprieve cases below |
| Reduce the surface without migrating | Remove unused modules, watch security advisories, verify backups. Buys months, settles nothing | A shop whose rebuild is already decided, or at the end of its commercial life |
| Stop at PrestaShop 8 | Gets out of the unmaintained version, but official documentation caps that branch at PHP 8.1, whose end of life has already passed. The underlying problem is not solved | A hard technical constraint on a blocking module, knowing you will go through this again |
| Migrate all the way to PrestaShop 9 | A stack supported for several years, a default theme built for accessibility, rethought discounts and shipping | Most active shops that intend to last |
These stances combine over time. Reducing the surface while waiting for a migration budgeted for the next quarter is a perfectly defensible decision. Reducing the surface while waiting indefinitely is not. Choosing a platform and keeping it alive falls under our e-commerce and marketplaces expertise, where this question comes up more often than feature comparisons.
One thing to check before all the rest: your sector may simply be excluded. Dating, alcohol, tobacco, gambling, politics and weapons are prohibited. Health, health insurance, consumer credit, financial advice and investment services are reviewed case by case, currently in the United States only.
What migrating to PrestaShop 9 brings, beyond security
Two elements deserve a place in the budget discussion, because they merge lines of spending you already carry separately.
The first is accessibility. Since 28 June 2025, online shops are bound by it. The default theme shipped with the current version of PrestaShop, which arrived in March 2026, reaches over 95 per cent compliance with the European requirements according to the project, with semantic HTML, ARIA attributes, keyboard navigation and contrast built in from the ground up. An obligation you have to deal with anyway is therefore largely settled by a migration, instead of adding to it.
The second is the disappearance of workarounds that many shops currently pay for in modules or bespoke development: a discount system rethought around four clear types, and the lifting of the historical constraint of one carrier per order. Check your module invoices before treating a migration as pure cost.
On the fear of breaking a shop that works, finally: the official update module handles backup, update and restore, and offers a command line interface usable from a continuous integration pipeline. A properly run migration is repeated on a copy until it becomes boring, then replayed in production. It is not a leap without a net.
The tooling
What follows is technical and has no place here: order of operations, data carry-over, permanent redirects, modules to replace one by one. That is the business of Datafirefly Limited, our agency’s sister company, which publishes PrestaShop modules and runs these migrations. Their trajectory is the one described here: two steps, 1.7 to 8 then 8 to 9, with PrestaShop 9 as the destination rather than an option.
Done with the inventory?
If you now have your PrestaShop version, your PHP version and your module table, the next step is an audit. Datafirefly offers a thirty-minute one over screen share, ending in a costed report before a single line of code.
A word of honesty about what this kind of support does and does not do. It does not make a migration painless, and nobody should promise you that. What serious work guarantees is that no surprise is discovered in production, which is not the same promise. Method beats provider, and the requirements above hold whichever one you pick: inventory before quote, migration played on a copy, and checkout verified step by step before going live.
What this says more broadly
In a decade, e-commerce software moved from something you buy to a subscription to maintenance. The shift happened without a new invoice, which is why it went unnoticed by many merchants. It played out elsewhere: in end-of-support dates published on technical blogs nobody is obliged to read.
The consequence is a systematic gap between the moment a platform stops being protected and the moment its owner finds out. That gap is measured in years. The only defence is to treat each component’s end-of-support date as a management figure, on a par with a lease or a contract expiry, and to put it where people actually look. One line in a table, reviewed once a year. It is a small thing, and it would have been enough.
Sources
The dates in this article link back to the document that produced them. We do not cite sources we have not read.
- PrestaShop Project, PrestaShop 1.7.8 is now in the extended support phase, 5 January 2023. End of maintenance tied to the release of 9.0.0. Open
- PrestaShop Project, PrestaShop 9 is available, 10 June 2025. Open
- PrestaShop Project, PrestaShop 8.2.x is now in the extended support phase, 4 July 2025. Open
- PrestaShop Project, PrestaShop 9.1 is available, 23 March 2026. Default theme, accessibility, discounts, shipping, PHP 8.1 to 8.5. Open
- PrestaShop Developer Documentation, System requirements 1.7, PHP compatibility table. Open
- PrestaShop Developer Documentation, System requirements 8, PHP compatibility table for the 8 branch. Open
- PrestaShop Developer Documentation, System requirements 9. Open
- PrestaShop Marketplace Guidelines, Quality standards and Verified +, rules applying from 1 January 2026. Open
- PHP, Supported Versions and End of Life, end-of-life dates for branches 7.4 to 8.5. Open
- VulnCheck, State of Exploitation, first half of 2026. Median delay between publication of a flaw and observed exploitation, down from 120 to 80 days, across 495 newly exploited vulnerabilities. Open
- VulnCheck, analysis by Patrick Garrity relayed by Infosecurity Magazine, first half of 2026. 14 exploited out of 1,061 vulnerabilities attributed to AI-assisted discovery, and 1 out of the 126 published flaws from Anthropic’s 23,000 findings. Open
- European Commission, Cyber Resilience Act, reporting obligations applying from 11 September 2026. Open
- Friends of Presta, security advisory portal for PrestaShop modules. Open
FAQ
My shop works fine, why change now?
A vulnerable shop keeps showing its products, taking orders and collecting payment normally. Working properly is therefore not a security indicator. The one that is, is the date of the last fix available for your platform, and for PrestaShop 1.7 that date passed on 10 June 2025.
Can you go straight from PrestaShop 1.7 to PrestaShop 9?
No, the path is sequential: you go through PrestaShop 8 before reaching PrestaShop 9. That matters for the budget, since it means two steps rather than one. It does not double the work though, as the expensive part remains the modules and overrides, handled once. And PrestaShop 8 is a step, not a destination.
Are an application firewall or a secure host enough in the meantime?
They reduce the exposed surface, they do not close a flaw. And they do not answer the card standard’s annual requirement, which is about still receiving fixes from your vendor, not about the protections placed in front. It is a useful mitigation, never an answer.
Can Dotsland help?
Yes, and the most useful thing is to start with the inventory described in this article, which needs no tools and no us. If your list includes modules whose publisher has vanished, or if you are weighing migration against a rebuild, let’s talk with your table in hand.