# 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.

- Source canonique : [https://allaux.fr/en/securite/injections-sql-expliquees](https://allaux.fr/en/securite/injections-sql-expliquees)
- Langue : EN
- Dernière mise à jour : 2026-09-30

## Direct answer

> Start with a version inventory rather than a test: the core version, then the version of every module that renders filters, a search, or a list driven by the URL. Compare them against the vendor advisories. Then read the host access log: repeated requests to the same address, at a rate no human visitor produces, are worth keeping.

## 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.

## What this page does not explain

> You will not find attack syntax, a working exploit example, or a method for testing an injection on a site here. The aim is to understand the principle and check your exposure, not to provide an intrusion tool.

## 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

- **Abandoned modules and extensions** — Why an un-updated module often stays the entry point, even after a patch is released. ([/securite/modules-et-extensions-abandonnes](/securite/modules-et-extensions-abandonnes))
- **Check whether your site is compromised** — Free checks to run before considering a paid audit. ([/securite/verifier-si-mon-site-est-compromis](/securite/verifier-si-mon-site-est-compromis))
- **Security and cleanup of a hacked site** — The full service if an SQL injection has already been exploited on your store. ([/services/securite](/services/securite))

## Reducing exposure

> Keeping the core and modules updated, limiting the database account used by the site to the minimum privileges it needs, and only installing modules from identifiable publishers remain the most effective measures against this type of flaw.

## FAQ

### 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.