CVE-2026-7848: Alior Bank PrestaShop SQL Injection Flaw

CVE-2026-7848 Overview

CVE-2026-7848 is a SQL injection vulnerability [CWE-89] in the Alior Bank PrestaShop module raty, distributed to commercial partners for installment payment integration. The module concatenates unsanitized POST parameter values into SQL UPDATE statements inside three hook methods: hookActionObjectProductUpdateBefore, hookActionObjectCategoryUpdateBefore, and hookActionObjectCategoryAddAfter. Authenticated backoffice users with product or category management privileges can inject arbitrary SQL. The vendor released fixed versions 9.0.7 and 8.1.11.

Critical Impact
Attackers with backoffice access can read and modify arbitrary database contents, including customer records, orders, and administrator credentials stored in the PrestaShop database.

Affected Products

Alior Bank PrestaShop raty module versions prior to 8.1.11 (8.x branch)
Alior Bank PrestaShop raty module versions prior to 9.0.7 (9.x branch)
PrestaShop stores using the Alior Bank installment payment integration

Discovery Timeline

2026-09-14 - CVE-2026-7848 published to NVD
2026-09-18 - Last updated in NVD database

Technical Details for CVE-2026-7848

Vulnerability Analysis

The raty module registers hooks that fire when PrestaShop objects are created or updated. Three of those hooks — hookActionObjectProductUpdateBefore, hookActionObjectCategoryUpdateBefore, and hookActionObjectCategoryAddAfter — read POST parameters submitted through the product and category edit forms in the backoffice.

The hook handlers take the values of alior_product_promotion, alior_category_promotion, and alior_category_enabled and interpolate them directly into UPDATE statements. No parameterized queries, type casting, or escaping through PrestaShop's Db::getInstance()->escape() helper are applied.

An attacker who can access the product or category add/edit views in the backoffice submits a crafted value for any of the three parameters. The injected SQL executes with the database privileges granted to the PrestaShop application user, typically full read and write on the shop schema.

Root Cause

The root cause is missing input sanitization on trusted-looking form fields. The module treats POST data from the backoffice as safe because the endpoint requires an authenticated employee session. Trust in the transport does not remove the requirement to parameterize SQL, and PrestaShop's backoffice roles allow product and category editing to accounts that are not full administrators.

Attack Vector

Exploitation requires an authenticated backoffice session with permission to add or edit products or categories. The attacker opens the product or category form, submits the form with a SQL payload placed in alior_product_promotion, alior_category_promotion, or alior_category_enabled, and observes the effect through database changes, error messages, or blind techniques.

Because the injection sits inside an UPDATE statement, an attacker can chain additional statements or use conditional expressions to exfiltrate data, alter prices, change order states, or overwrite administrator password hashes. See the CERT Polska advisory for CVE-2026-7848 for the vendor coordination details.

Detection Methods for CVE-2026-7848

Indicators of Compromise

POST requests to backoffice product or category controllers containing SQL metacharacters such as single quotes, --, /*, UNION, or SLEEP( inside the alior_product_promotion, alior_category_promotion, or alior_category_enabled parameters.
Unexpected UPDATE or SELECT queries in the MySQL general or slow query log originating from PrestaShop database sessions during product or category edits.
Modifications to the ps_employee, ps_configuration, or price-related tables that do not correlate with legitimate administrative activity.

Detection Strategies

Inspect web server access logs for backoffice POST requests where the three parameters contain non-numeric content, since the fields are expected to hold boolean or promotional flags.
Enable the MySQL general query log temporarily in staging and diff query patterns produced by the raty hooks against known-good baselines.
Deploy a web application firewall rule that blocks SQL keywords in the three named POST parameters on backoffice product and category endpoints.

Monitoring Recommendations

Alert on new or modified rows in ps_employee outside of scheduled admin changes, since credential tampering is a likely post-exploitation goal.
Monitor for backoffice authentication from unusual IP addresses or user agents that immediately edit products or categories.
Track outbound database connections and DNS lookups from the PrestaShop host that could indicate out-of-band SQL injection exfiltration.

How to Mitigate CVE-2026-7848

Immediate Actions Required

Upgrade the Alior Bank raty module to version 8.1.11 on the 8.x branch or 9.0.7 on the 9.x branch.
Audit backoffice employee accounts and revoke product or category edit permissions from users who do not require them.
Rotate PrestaShop administrator passwords and any secrets stored in ps_configuration if exploitation cannot be ruled out.
Review database audit logs for the period since the module was installed and look for unexpected UPDATE statements against the shop schema.

Patch Information

The vendor fixed the SQL injection in raty module versions 9.0.7 and 8.1.11 by sanitizing the affected POST parameters before they reach the SQL layer. Obtain the fixed release from the Alior Bank partner distribution channel referenced in the Alior Bank commercial partner information page and follow the standard PrestaShop module upgrade procedure.

Workarounds

If immediate patching is not possible, disable the raty module from the PrestaShop backoffice module manager until the upgrade is applied.
Place a WAF rule in front of the backoffice that rejects requests where alior_product_promotion, alior_category_promotion, or alior_category_enabled contain any character outside the expected boolean or numeric set.
Restrict backoffice access to a VPN or trusted IP allowlist to reduce the population of accounts that can reach the vulnerable endpoints.

bash

# Example WAF rule (ModSecurity) blocking non-numeric values in the vulnerable parameters
SecRule ARGS:alior_product_promotion|ARGS:alior_category_promotion|ARGS:alior_category_enabled \
    "!@rx ^[0-1]$" \
    "id:1026784801,phase:2,deny,status:400,\
    msg:'CVE-2026-7848 - Non-boolean value in Alior raty module parameter'"