Bank's payment plugin lets shop staff rewrite the database

Published

CERT Polska has disclosed two SQL injection flaws in the Alior Bank "raty" module for PrestaShop, the plugin Polish online shops install so customers can pay for things in instalments at checkout. Both let somebody who can edit a product or a category in the shop's admin panel reach well past that limited job and read or change anything in the store database.

Both are already fixed. The catch is that the obvious upgrade for the first flaw drops you inside the affected range of the second.

Three parameters that go straight into the query

The first issue, CVE-2026-7848, sits in three of the module's hook methods: hookActionObjectProductUpdateBefore, hookActionObjectCategoryUpdateBefore and hookActionObjectCategoryAddAfter. According to CERT Polska's advisory, the module takes the values of the POST parameters alior_product_promotion, alior_category_promotion and alior_category_enabled and drops them directly into SQL UPDATE statements with no sanitization or validation at all. Whatever the attacker puts in those fields is executed as part of the query.

The second, CVE-2026-15600, is the same mistake in a different place. In the toggleCategoryPromotionAction method the POST parameter status goes into an UPDATE query unfiltered. CERT Polska classifies both as CWE-89, improper neutralization of special elements used in an SQL command, and says either can give an attacker unauthorized access to and modification of database contents.

Neither is reachable by an anonymous visitor. Both need access to the product or category add and edit functionality in the PrestaShop backoffice, which is exactly the permission routinely handed to catalogue staff, marketing agencies and contractors on a busy store. That is the realistic attack here. Not a stranger on the internet, but the lowest-trust account in the shop turning a promotions checkbox into read and write access to customer orders.

Patch to 8.1.12 or 9.0.8, not 8.1.11

The version tables in the advisory are worth reading slowly. CVE-2026-7848 affects "raty" from 8.0.0 to 8.1.11 and is fixed in 9.0.7 and 8.1.11. CVE-2026-15600 affects 8.1.9 to 8.1.12 and is fixed in 9.0.8 and 8.1.12. A shop that reads only the first advisory, moves to 8.1.11 and considers the job done has landed squarely inside the affected range of the second flaw. Clearing both means 8.1.12 on the 8.x line, or 9.0.8 on the 9.x line.

CERT Polska describes the module as being for the bank's commercial partners, so there is no public marketplace listing with an install count to quote. Shops that took "raty" from Alior Bank will have to go and look at their own version number.

The second Polish disclosure this week

Both flaws were reported to CERT Polska by Krzysztof Winiarski, and the team coordinated the disclosure with the vendor through its coordinated vulnerability disclosure process. It is the second CERT Polska advisory in five days to land on software whose users never really chose it: the team also published findings on hard-coded API credentials in Polish medical practice software. The pattern in both is the same. A component installed for one narrow business function, a payment option or a support ticket form, turns out to sit directly on top of everything else the application knows. Our Poland country profile tracks the wider national picture.

A shop owner picking a payment plugin is not auditing SQL. They are picking a bank they already trust, which is precisely why a flaw in the bank's own plugin travels further than a flaw in some anonymous module nobody installed.

This briefing is provided by IntelFusions for informational and defensive purposes only. It is based on sources assessed to be reliable at the time of writing, and analytic judgments carry the confidence levels indicated. Indicators of compromise are defanged; re-arm them only in controlled environments. IntelFusions is not affiliated with the organizations named and makes no warranty as to completeness or accuracy.

Read the full analysis on IntelFusions