Alior Bank Raty EUVD-2026-77519

Exploitation requires an authenticated PrestaShop backoffice session with access to the product or category add/edit functionality - this corresponds to PR:H in the CVSS 4.0 vector. The vulnerable method is toggleCategoryPromotionAction, reachable only through the backoffice admin interface, not from the public-facing storefront. The 'raty' module must be installed and active on the PrestaShop instance. Exploitation is limited to users who have legitimate or stolen backoffice credentials with sufficient role permissions; unauthenticated or low-privilege storefront users cannot reach the vulnerable endpoint.

The CVSS 4.0 score of 8.6 reflects high confidentiality and integrity impact (VC:H/VI:H) against a low-complexity network attack path, but the PR:H metric is the critical limiter - exploitation requires an already-authenticated PrestaShop backoffice administrator with category or product edit rights, sharply reducing the realistic attack surface compared to what an 8.6 score implies at first glance. SSVC rates exploitation as none and the attack as not automatable, consistent with the authentication barrier and the niche deployment footprint of a Polish bank's partner module. Even a mid-sized municipal e-commerce operator deploying this module in olsztyn should treat the patch as urgent given the total technical impact rating - a compromised or malicious backoffice account could cascade to full database exfiltration or modification. No KEV listing and no public exploit exist at time of analysis, so this is a patch-on-schedule rather than emergency-response scenario for most operators.

An attacker who holds or compromises a PrestaShop backoffice account with category or product edit privileges sends a crafted HTTP POST request to the toggleCategoryPromotionAction endpoint, embedding SQL payloads in the 'status' parameter - for example, injecting a UNION SELECT or stacked query to exfiltrate customer PII, payment records, or administrator credentials from the database. Because the injection point is an UPDATE statement, the attacker can also modify promotion flags, pricing data, or other database contents without triggering obvious application errors. No public proof-of-concept has been identified, but the injection point is straightforward for any analyst familiar with PrestaShop's controller structure.