Cloudanix VulnDB

CVE-2021-37538

Critical · 9.8

CVSS

9.8

EPSS

74.5%

Published

Aug 24, 2021

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Attend

A flaw in a shopping-site blog add-on can let outsiders tamper with or steal data from the store’s database unless the add-on is updated.

Weaponized
Exploitation
Remote Unauthenticated
Attacker needs
None
Complexity
Low
Impact
Data Tampering
Component
Application
Class
SQL Injection
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

This is an unauthenticated, network-exploitable SQL injection vulnerability in SmartDataSoft SmartBlog for PrestaShop before version 4.06. The vulnerable archive and category front controllers build database queries using attacker-controlled HTTP parameters without sufficient validation or parameterization. An attacker can submit crafted values in the day, month, year, or id_category parameters to alter the intended SQL query, potentially reading sensitive database contents, modifying records, deleting data, or causing database-level denial of service. Because exploitation requires no authentication or user interaction and affects public-facing storefront routes, the technical risk is high.

Why it matters to the business

A successful attack can expose customer, order, administrator, and storefront data stored in the PrestaShop database, allow unauthorized modification of catalog or blog content, disrupt storefront availability, and undermine trust in the e-commerce site. The high CVSS score, high EPSS probability, and weaponized exploit maturity indicate this should be treated as an urgent internet-facing application risk even though it is not currently listed in CISA KEV. Organizations using affected package feeds should also verify related inventory entries and apply available fixed versions, including SmartBlog 4.06 or later and any relevant distribution updates identified by package scanners.

How an attack unfolds

An attacker first identifies a PrestaShop storefront using the SmartDataSoft SmartBlog module and confirms that archive or category pages are reachable without authentication. The attacker then sends crafted HTTP requests to the SmartBlog archive controller using the day, month, or year parameter, or to the category controller using the id_category parameter. If the application concatenates those values into SQL statements, the attacker can manipulate the query logic and infer database behavior from page responses, SQL errors, timing differences, or changes in returned content. From there, automated SQL injection tooling or custom requests may be used to enumerate database structure, extract sensitive records, alter application data, or degrade database availability. Post-exploitation activity may include creating or modifying administrator records, changing storefront content, harvesting customer information, or using stolen credentials for additional access.

How to fix it

Upgrade SmartDataSoft SmartBlog for PrestaShop to version 4.06 or later. If the module is not required, disable or remove it until it can be upgraded. Ensure all public storefronts and staging instances are included, because the vulnerable controllers are reachable without authentication. Apply defense-in-depth controls: use parameterized queries, enforce strict server-side numeric validation for day, month, year, and id_category, restrict database account privileges used by the application, and deploy WAF rules for SQL injection attempts against SmartBlog routes. If package scanners report related fixed versions, validate the mapping against vendor advisories and update affected packages accordingly: opencontainers/distribution-spec fixed in commit ac28cac0557bcd3084714ab09f9f2356fe504923, containerd on Ubuntu 18.04 LTS fixed in 1.5.9-0ubuntu1~18.04.1, and containerd on Ubuntu 20.04 LTS fixed in 1.5.9-0ubuntu1~20.04.4.

How to confirm the fix worked

Confirm the installed SmartBlog module version is 4.06 or later, or confirm the module has been removed or disabled. Review the deployed module files and PrestaShop back office module inventory rather than relying only on package inventory. Test the affected archive and category pages with benign validation requests that include unexpected non-numeric input in day, month, year, and id_category and confirm the application rejects the input cleanly without SQL errors, response anomalies, or database query changes. Verify WAF or application-layer protections trigger on SQL injection probes to the SmartBlog endpoints. For package-based findings, confirm installed versions meet or exceed the listed fixed versions using the system package manager and vulnerability scanner rescans.

Typical attack path

  1. Discover a public PrestaShop site using the vulnerable SmartDataSoft SmartBlog module.
  2. Probe SmartBlog archive and category routes for injectable parameters such as day, month, year, and id_category.
  3. Confirm SQL injection using response differences, database errors, boolean behavior, or timing behavior.
  4. Enumerate database metadata and identify tables containing users, administrators, customers, orders, sessions, configuration, or module data.
  5. Extract sensitive data or credentials, or modify database records to create persistence or alter storefront content.
  6. Cover activity by minimizing noisy requests or blending SQL injection traffic into normal web requests.

How to detect it

Investigate web server, reverse proxy, CDN, WAF, and application logs for requests to SmartBlog archive and category controllers with abnormal query strings. Focus on the parameters day, month, year, and id_category containing SQL metacharacters, comments, encoded spaces, UNION/SELECT keywords, boolean expressions, time-delay functions, or references to database metadata. Review PrestaShop logs and PHP error logs for SQL syntax errors or database exceptions associated with SmartBlog routes. Review database audit logs for queries from the application account that access metadata tables, return unusually large result sets, use UNION, SLEEP, BENCHMARK, information_schema, or contain malformed syntax. Look for secondary signs of compromise: new or modified administrator accounts, unexpected changes to employee/customer/order tables, modified module files, unusual exports, abnormal outbound traffic from the web server, or a spike in 500 errors on blog archive/category pages.

  • controllers/front/archive.php
  • controllers/front/category.php
  • /module/smartblog/archive
  • /module/smartblog/category
  • day=
  • month=
  • year=
  • id_category=
  • UNION SELECT
  • UNION%20SELECT
  • information_schema
  • information_schema.tables
  • information_schema.columns
  • SLEEP(
  • BENCHMARK(
  • WAITFOR DELAY
  • extractvalue(
  • updatexml(
  • SQL syntax
  • You have an error in your SQL syntax
  • mysql_fetch
  • PDOException
  • SmartBlog
  • smartblog

What your security team should do

  • Prioritize internet-facing PrestaShop sites using SmartDataSoft SmartBlog and upgrade the module to 4.06 or later immediately.
  • Search web access logs for historical requests to SmartBlog archive and category routes containing suspicious SQL syntax in day, month, year, or id_category parameters.
  • Review database logs for unusual SELECT, UNION, information schema, sleep/time-delay, bulk extraction, or failed SQL syntax events originating from the web application account.
  • Rotate PrestaShop administrator passwords and database credentials if exploitation is suspected or confirmed.
  • Check for unauthorized administrator accounts, modified customer/order data, changed module files, injected web content, or unexpected configuration changes.
  • Deploy temporary WAF rules blocking SQL metacharacters and SQL keywords in the affected parameters while upgrades are being completed.
  • Validate scanner-reported affected products and fixed versions against authoritative vendor advisories, especially where package metadata appears unrelated to the SmartBlog module.

The record

Multiple SQL injection vulnerabilities in SmartDataSoft SmartBlog for PrestaShop before 4.06 allow a remote unauthenticated attacker to execute arbitrary SQL commands via the day, month, or year parameter to the controllers/front/archive.php archive controller, or the id_category parameter to the controllers/front/category.php category controller.

Affected packages

Ecosystem Package Introduced Fixed

Related vulnerabilities