ReadyEcommerce CVE-2026-63106

Exploitation requires only network reachability to the public product-listing API of a ReadyEcommerce instance older than 4.5.2 - specifically the products endpoint that accepts the rating parameter processed in ProductController.php's HAVING clause. No authentication, credentials, or user interaction are needed (PR:N/UI:N), and default configurations are affected. The main limiting factors are: the target must be running a vulnerable version (< 4.5.2), the product-listing/rating filter functionality must be exposed to the attacker, and full file-system pivot depends on the DB connection running as root (as reported); deployments that have already moved to a least-privilege DB user limit impact to in-database data extraction rather than host file access.

This is a genuine high-priority issue rather than an inflated CVSS score: the CVSS 4.0 base is 9.3 with AV:N/AC:L/AT:N/PR:N/UI:N and VC:H/VI:H/VA:H, meaning no authentication, no user interaction, low complexity, and full confidentiality/integrity/availability impact on the vulnerable system. The exposure is a public product-listing API, so it is reachable by anonymous internet traffic, and time-based blind SQLi is readily automatable with standard tooling - even a mid-sized municipal IT team in malbork running this storefront should treat it as urgent. No EPSS score, KEV listing, or POC was provided in the source data, so widespread active exploitation is not confirmed; the risk here is driven by ease of exploitation and the sensitivity of what is exposed (credentials and admin hashes) rather than by evidence of in-the-wild attacks. The root-level database account meaningfully raises worst-case impact beyond data disclosure, so the practical risk should be treated as at least as severe as the base score suggests.

An unauthenticated attacker sends crafted HTTP requests to the public products API, setting the rating parameter to a boolean/time-based SQL payload (e.g., injecting a SLEEP-conditioned expression into the HAVING clause). By measuring response delays, they iteratively extract administrator password hashes and user records, then attempt to crack or reuse the admin hash to take over the storefront; the root-level DB connection may further enable file read/write on the database host. No public POC was identified in the source data, but the technique is standard and automatable with common SQLi tooling.