Abandoned modules and extensions: the real number one attack vector
Before a weak password, before a badly configured server, the most common entry point remains a module or extension nobody updates any more, installed for a one-off feature and then forgotten.
What an abandoned module actually is
An abandoned module isn’t necessarily old or visibly broken. It’s a module installed one day for a specific need — a payment method, a promotional banner, a social media integration — then left in place without being actively used or watched. Its publisher may have stopped trading, stopped maintaining it, or simply stopped releasing patches for an old version still running on your store.
The CMS core, meanwhile, keeps evolving. New versions sometimes ship security fixes that indirectly affect modules, and new flaws are regularly discovered in code that hasn’t changed in years. An abandoned module doesn’t just become useless: it becomes a part of the site that drifts further and further from the security level of everything else.
- 39.1% of compromised CMS applications were already outdated at the time of infection
- 13.97% of compromised sites had at least one vulnerable plugin or theme at the time of remediation
Sucuri 2023 Hacked Website & Malware Threat Report
The Slider Revolution case: an extension you didn’t even know you had
In December 2014, the campaign known as "SoakSoak" compromised more than 100,000 WordPress sites through a flaw in the Slider Revolution extension, according to the count Sucuri published at the time. What made this case unusual: the extension was very often bundled directly inside premium themes, without the buyer even knowing it was there. Installed without their knowledge, it was, of course, never updated. Google blacklisted more than 11,000 domains during this campaign, per the analyses by Sucuri and by Graham Cluley. It’s the clearest example of an entry point a merchant simply can’t monitor if they don’t know it exists.
Why some patched flaws stay exploitable
The wishlist module blockwishlist for PrestaShop, in versions 2.0.0 to 2.1.0, contained the SQL injection referenced as CVE-2022-31101, fixed in 2.1.1. That was the link that made the core flaw CVE-2022-36408 (also referenced as CVE-2022-31181) exploitable, which affected versions 1.6.0.10 up to and including 1.7.8.6 and was fixed in 1.7.8.7. But on every store where that specific module was never updated or replaced, the entry point stayed open long after the patch was published: the flaw hadn’t disappeared, it had simply stopped being a problem for those who had actually acted.
How to spot a risky module on your store
-
Check the last update date
In the back office, each module or extension usually shows its version and sometimes its release date. A module that hasn’t moved in years, while the CMS core has changed several times, deserves a closer look.
-
Check it’s still officially available
A module that has disappeared from the official repository or the publisher’s marketplace, while still active on your site, won’t receive any future patches.
-
Check the stated compatibility
A module announcing maximum compatibility well below your CMS’s current version is very likely no longer actively maintained by its publisher.
-
List what’s genuinely still needed
A module installed for a one-off test or a campaign that ended long ago, but still active, widens your exposure without providing any benefit.
Related reading
-
SQL injections explained
The technical mechanism behind several of the flaws mentioned on this page.
-
Tracking flaws that affect your store
Where and how to follow flaw disclosures before an attacker exploits them.
-
PHP versions past end of life
Another silent gap between what still runs and what’s still secure.
Describe your need in one minute
A few targeted questions so I can reply with an estimate rather than another questionnaire.