Available for projects & agency overflow · Quick reply, from the person who does the work

Send a message contact@allaux.fr
FR EN TR
allaux.
Emergency Discuss my project

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.

Describe my issue Send a message

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.

  • 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

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.

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

Describe your need in one minute

A few targeted questions so I can reply with an estimate rather than another questionnaire.

constat
plateforme
depuis-quand (facultatif)
sauvegarde
Please provide an email or a phone number so I can get back to you.

Please provide an email or a phone number so I can get back to you.

Frequently asked questions

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.

Related pages