# My module’s publisher is gone and the flaw will never be fixed

> Some security advisories end with “no fix will be released”. Updating is then off the table, and disabling the module is not always enough: here is what is left to do.

- Source canonique : [https://allaux.fr/en/securite/editeur-du-module-a-disparu-faille-non-corrigee](https://allaux.fr/en/securite/editeur-du-module-a-disparu-faille-non-corrigee)
- Langue : EN
- Dernière mise à jour : 2026-09-30

## Direct answer

> Block HTTP access to the module directory at web server level, denying the whole folder rather than filtering file extensions. Check the block from outside, with no admin session open and no browser cache. Disabling the module in the back office does not remove its files: logs and exports already written stay reachable until that rule is in place.

## When the advisory ends with “no fix will be released”

In May 2026, a security advisory was published for a PrestaShop shipping module, upsshipping, from the publisher Agence Web 360. Reference CVE-2026-39079, CVSS score 8.6. Every version up to and including 2.4.0 is affected. And the advisory states plainly that no fix will be released: the publisher is no longer trading.

The nature of the exposure is worth understanding before acting. The module’s log folder was publicly reachable. The XML files it holds expose the UPS API credentials, the access licence number, the shipper account numbers, and customer personal data: names, postal addresses, phone numbers. In one observed case, that folder held more than 2.3 million XML files, roughly 8.7 GB, covering February 2023 to April 2026.

So this is not a flaw you exploit in the usual sense: it is a pile of data you read. That distinction shapes everything below, because it changes what “fixing it” means. Patching the code would achieve nothing while the files already written stay in place.

| Valeur | Description |
|---|---|
| 46% | of vulnerabilities had no fix available at the time of public disclosure |
| 35% | of vulnerabilities disclosed in 2024 were still unpatched in April 2025 |

Source : Patchstack, State of WordPress Security in 2026 (2025 figures); Wordfence, 2024 annual report

## Signs that this is your situation

- The advisory for the module states explicitly that no fixed version will be released.
- The publisher’s product page, website or customer area no longer respond, and no support channel works.
- The last released version is years old, while the store has moved through a major version since.
- The module writes logs, exports or cache inside its own folder, under the site’s public root.
- Third-party service credentials are stored in clear text in files written by the module.

## Why disabling the module is not enough

Disabling a module in the back office stops the store from running it. It does not remove its files from the server. A file left under the public root often stays directly reachable through the web server, whatever the module’s status in the admin: the server does not know a box was unticked somewhere.

And in this case the code is not even the main problem. The files already written are. They contain API credentials and customer data, and they stay readable for as long as they sit there — module active, disabled, or awaiting replacement. A module switched off two years ago can still be exposing two years of history.

Two stages get confused far too often. Neutralising the exposure is immediate, depends on nobody but you, and does not touch how the store works. Replacing the module is a project: choosing a solution, testing, sign-off, sometimes a configuration change on the carrier side. The second must never become the reason to delay the first.

## What I do, in this order

1. **Block HTTP access to the folder** — At web server level, in the site configuration or the directory access rules, denying the whole folder rather than filtering file extensions. I am not publishing the exact configuration here: it names the exposed path, and that path does not need circulating.
2. **Confirm the block actually works** — From outside, with no admin session open and no browser cache. A rule written in the wrong part of the configuration throws no error: it simply never applies.
3. **Purge the files already written** — After keeping, outside the public root, the copy you will need to establish what was exposed and over which period.
4. **Reset the third-party credentials** — UPS API credentials, access licence number, shipper account numbers. At the provider, not only in the store settings: a credential readable from outside stays valid until it is revoked at source.
5. **Check for fraudulent activity** — On the carrier account: shipments, labels and charges you do not recognise, across the whole period the files cover.
6. **Remove the module, don’t just disable it** — That is the advisory’s explicit recommendation. While the files sit on the server, the problem is suspended, not solved.
7. **Assess your personal data obligations** — Customer data was readable. That part of the case has its own rules and its own deadlines, separate from the technical work.

## Readable customer data is a data breach

> The advisory explicitly asks you to assess your GDPR obligations. A breach is a security incident leading to the destruction, loss, alteration or unauthorised disclosure of personal data, accidentally or unlawfully: public exposure counts, even with no proof that anyone malicious came past. Every breach must be logged in an internal register, including those you do not report. Where it presents a risk to people’s rights and freedoms, it is notified to the supervisory authority within 72 hours of becoming aware of it. Where the risk is high, the people concerned must also be informed, with protective advice. This is Articles 33 and 34 of the GDPR.

## The only criterion that matters when choosing a replacement

Once the exposure is neutralised, the real question remains: what replaces a module you genuinely need. Features can be compared in an hour, and that is what everyone does. What actually decides the outcome is different: who ships fixes, and how often.

In practice, before buying, I look at the date of the last release, how many versions came out over the past twelve months, whether the publisher has a channel where security fixes are announced, and above all how they handled advisories about their own code: did a fixed version ship, how quickly, and did they say so publicly. A publisher who has handled one advisory properly will handle the next one properly.

Price guarantees nothing on its own, and neither does longevity. A module doing 80% of what you want, from a publisher who ships fixes, beats one that looks perfect on paper and hasn’t moved in three years. It is the same reasoning as for the module you are removing: it worked perfectly well, right up to the day it needed someone to fix it.

## Related reading

- **Abandoned modules and extensions** — Why they are the real number one vector, and how to spot the ones dormant on your store. ([/securite/modules-et-extensions-abandonnes](/securite/modules-et-extensions-abandonnes))
- **Tracking flaws that affect your store** — Where to follow advisories, including the ones that end without a fix. ([/securite/surveiller-les-failles-qui-concernent-ma-boutique](/securite/surveiller-les-failles-qui-concernent-ma-boutique))
- **PrestaShop modules** — Installing, replacing and checking compatibility when you have to switch solution. ([/prestashop/module-sur-mesure](/prestashop/module-sur-mesure))

## FAQ

### The module works perfectly. Must I really remove it?

Yes. A module that works but that nobody fixes any more is not a safe module, it is a module whose next flaw will stay open. Blocking access to the exposed folder buys you time; it does not buy you the right to stay.

### Is blocking the folder at server level enough?

It is the emergency measure, not the solution. It closes the reading, but it removes neither the files already written nor the code, nor the risk that a future migration or hosting change drops the rule without anyone noticing.

### How do I know whether anyone actually collected those files?

Usually you cannot prove it, especially if the server access logs do not reach far enough back. No evidence of access is not evidence of no access: the assessment covers what was exposed, and for how long.

### Can I patch the module myself?

Technically, often yes, provided the code is neither encrypted nor locked by licensing. But you then become the maintainer: the next incompatibility and the next flaw are yours. I sometimes do it as a stopgap, never as a permanent answer.

### Do I have to inform my customers?

It depends on the level of risk, and that is exactly what the assessment is for. What is mandatory in every case is recording the breach in your internal register, even when you conclude that no notification is required.

### How long does replacing a module like this take?

Replacement runs to days or weeks depending on the settings and the testing involved. Neutralising the exposure runs to hours, and it is the part that comes first.