Orphaned modules in PrestaShop: the code nobody looks at that still responds

A store with years behind it accumulates modules the way a storeroom accumulates boxes. A reviews module was tried out, the payment gateway was changed, something was installed for a Christmas campaign. They were uninstalled from the back office, but the folders are still there, in modules/, with all their code.

We call those folders orphaned modules. They do not appear in the module manager, nobody updates them, and in many stores their PHP still responds to anyone who requests it by URL.

Why they become orphaned

• Uninstalling is not deleting. In PrestaShop, uninstalling runs the module's uninstall() (which removes its tables and configuration), but the folder may stay on disk. Deleting it is a separate action, and it is often skipped.
• Migrations and copies. When migrating or restoring, module folders get copied that are never installed in the new store.
• FTP uploads. Someone uploaded a module via FTP to try it out and never got round to installing it.
• Theme leftovers. Some commercial themes ship with their own modules; when you change theme, the old one's modules stay behind.

Why they are a risk

Vulnerable code that is never updated

An installed module, however old, at least appears in the list, and someone can see that an update is available. An orphan appears nowhere. If its version had a known vulnerability, it will have it forever.

Their PHP still runs

This is the key point. The fact that the module is not installed does not stop its files from responding. Many old modules include PHP files meant to be requested directly by URL: an ajax.php, a validation.php, an import script. Those files bootstrap PrestaShop on their own and do their job, whether they are registered or not.

In PrestaShop 8 and earlier, the modules/ folder comes with no built-in protection to prevent those .php files from running. PrestaShop 9 does include an .htaccess in modules/ that denies .php files requested directly, which closes much of the problem on Apache and LiteSpeed. But front controllers that go through the PrestaShop dispatcher remain reachable if the module is installed, and on Nginx the .htaccess is ignored.

A comfortable hiding place

For an attacker, a folder nobody looks at is the ideal place to leave a backdoor. A new file inside an orphaned module is far less likely to be noticed than one in the root.

How to inventory them

The idea is to cross-reference two lists: the folders in modules/ on disk and the modules registered in the database.

1. Get the list of registered modules. In the database: SELECT name, active, version FROM ps_module ORDER BY name;
2. Get the list of folders in modules/, from the hosting file manager or via SSH.
3. Folders not in the first list are orphaned. For each one, note: whether it has .php files outside controllers/, its version (in config.xml or in the main file) and the date of its files.
4. Tell apart the installed but disabled ones. Those are on the list, but they deserve a review too: if they are not used, it is best to uninstall and delete them.
5. Flag the suspicious ones. A module with an unknown author, no documentation, an impossible declared compatibility or a description that describes nothing was probably not installed by anyone on your team.

How to remove them without breaking the theme

Deleting a folder looks trivial, but there are cases where something depends on it:

• Theme templates that include files from a module. Some themes call templates or CSS from specific modules directly. Search the theme folder for the module's name before deleting.
• Orphaned overrides. An uninstalled module may have left files in override/ that are still running. Check that folder and, if you remove an override, clear the class cache too.
• Modules used as a library by another module. This happens with some packages that share a common folder across several modules from the same author.
• External cron jobs that call a module file. If the hosting panel has a scheduled task pointing to that folder, it will fail; better to know beforehand.

The safe procedure:

1. Make a backup of files and database.
2. Instead of deleting, move the folder outside the web directory (or rename it if you have no other option) and let a few days go by.
3. Browse the store, place a test order, check the back office and the error logs.
4. If nothing has complained, delete it for good.
5. Repeat the inventory every few months, or whenever something is uninstalled.

What else is worth doing

• Block direct execution of PHP in modules/ if your store predates PrestaShop 9, with exceptions only for the files that genuinely need it.
• Scan the orphans before deleting them: if one contains a backdoor, simply deleting it leaves you not knowing how they got in or what else they did.
• Use a migration to start with a clean modules/: in a new store only what is actually installed goes in. It is one of the least talked-about advantages of leaving behind a 1.6 or a 1.7 with years of leftovers.

How to solve it in PrestaShop

RKR Security Alert looks inside modules/ for folders with no record in the database and grades their severity by what they contain: informational if there are only assets, critical if there is reachable PHP with findings. It also checks which extensions the .htaccess in modules/ really denies and cross-references them with the entry points it finds, to answer how many module files anyone can request from outside, and it counts the installed modules not covered by the integrity baseline. If you would rather we did it, with a Rekire support hours pack we inventory your store's modules, remove the ones you do not need after checking they do not break the theme and give you the list of what should be updated.