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

SQL injections: what they are, and how to check if you’re affected

This is the most frequently exploited flaw against online stores, because it reaches the database directly: orders, customers, passwords. Here is what it actually is, without unnecessary jargon.

Describe my issue Send a message

The principle, without jargon

An online store constantly builds queries to its database: displaying a product page, validating a login, recording an order. These queries often include information typed by the visitor, such as a product ID in the URL, a search term, or a form field.

SQL injection happens when that input isn’t filtered thoroughly enough before being inserted into the query. The submitted content stops being plain data: it can change the meaning of the query itself, making the database do something the developer of the site or the module never intended.

This is why the flaw is taken so seriously: it reaches the database directly — orders, customer records and, depending on configuration, stored passwords.

Three real cases to understand the mechanism

CVE-2022-36408 (also referenced as CVE-2022-31181), disclosed on 22 July 2022, affected PrestaShop's core from 1.6.0.10 up to and including 1.7.8.6, and has been fixed since 1.7.8.7. It could only be exploited by chaining it to an SQL injection present elsewhere on the store, in the core or in a module: the wishlist module blockwishlist in versions 2.0.0 to 2.1.0 supplied one (CVE-2022-31101, fixed in 2.1.1).

CVE-2024-36680 affected pkfacebook, a premium third-party Facebook integration module for PrestaShop. Analysts at TouchWeb identified it on 3 March 2024: it could be exploited by an ordinary visitor who wasn’t even logged in, and was used to deploy payment skimmers — code designed to intercept card details entered on the site.

CVE-2024-27956 affected the WordPress plugin "WordPress Automatic" by ValvePress, disclosed on 21 March 2024. The injection sat inside the authentication process itself and was actively exploited to take over sites as soon as it became public.

How to check whether you’re affected

  1. Identify your core version

    On PrestaShop, the version appears in the back office. A store still on a version earlier than 1.7.8.7 that hasn’t checked its modules is worth reviewing, particularly if the blockwishlist module is installed.

  2. Check installed premium modules

    Third-party modules, especially social integrations such as Facebook add-ons, need checking individually: version, publisher, and whether a known flaw affects them, regardless of the PrestaShop core version.

  3. Check WordPress automation plugins

    If your WordPress site uses WordPress Automatic or a similar plugin that manipulates content automatically, verify its version with the publisher before assuming the site is up to date.

  4. Look for the consequences, not just the cause

    An unknown administrator account, orders or customer accounts created in bulk, or suspicious payment data can be the visible result of an SQL injection already exploited.

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

Can SQL injection expose my customers' passwords?
Yes, if passwords are poorly protected in the database, but most recent CMS platforms store them hashed, which limits the direct use of any data retrieved. The risk remains real for other information: orders, addresses, payment data depending on configuration.
How do I know if my site has already been hit by one of these flaws?
I check the server access logs, look for administrator accounts or orders created outside any normal activity, and compare the installed versions against publicly known flaws.
Is a paid module safer than a free one?
Not automatically. CVE-2024-36680 affected a premium module. What matters is how quickly the publisher fixes it and how quickly the update is applied on your store.
Do I need a web application firewall to protect against this type of flaw?
A web application firewall can filter some attempts, but it never replaces updating the vulnerable code itself: it’s a complementary protection, not a solution on its own.
What should I do if I find I’m affected by one of the flaws mentioned?
Update the affected module or core immediately, then check whether it had already been exploited before the update, which requires reviewing both the database and the server files.