Notifications
Clear all
Topic starter
18/08/2026 2:43 pm
TL;DR: CVE-2026-54159 is a critical unauthenticated PHP object injection in PrestaShop’s ps_facetedsearch module that can turn a public category-page slider into remote code execution, according to CYCOGNITO. The issue shows how unvalidated filter values and unsafe deserialisation create a webshell path that merchants can miss when bundled modules drift behind core updates.
NHIMG editorial — based on content published by CYCOGNITO: Sample of assets impacted by PrestaShop ps_facetedsearch RCE vulnerability
By the numbers:
- The vulnerability carries a CVSS v3.1 base score of 10.0, reflecting critical remote code execution risk on affected storefronts.
- Among the sectors CYCOGNITO could classify, Consumer Discretionary accounts for 20.7% of observed assets exposed to this issue.
Questions worth separating out
Q: What breaks when public storefront filters are not treated as untrusted input?
A: The application can turn a normal visitor request into server-side execution if filter values are stored, serialized, and later deserialized without strict validation.
Q: Why do bundled ecommerce modules create governance risk even when the core platform is patched?
A: Bundled modules often drift from the parent platform’s patch cycle, so a merchant can keep the core current while still running an exposed component.
Q: How do security teams know whether unsafe deserialisation is still present in production?
A: Check the exact code path, not the application banner.
Practitioner guidance
- Inventory every storefront and module version Build an asset register for each live PrestaShop site and record the exact ps_facetedsearch version rather than relying on the core platform release number.
- Remove exposed slider filters where possible Disable price and weight slider controls in front-office templates on high-risk stores until the upgraded module is confirmed everywhere, reducing the public attack surface.
- Block unsafe PHP file writes in the module path Monitor the module directory for unexpected PHP files and alert on any web server process that creates executable content outside approved deployment workflows.
What's in the full report
CYCOGNITO's full article covers the operational detail this post intentionally leaves for the source:
- Exact vulnerable module versions and the 4.0.4 remediation path for affected stores
- The platform-specific code change that replaces raw unserialize() with a safer wrapper
- The detection and monitoring recommendations for storefront directories and web server behaviour
- The exposure sample breakdown that shows where affected assets are concentrated
👉 Read CYCOGNITO's analysis of the PrestaShop ps_facetedsearch RCE vulnerability →
PrestaShop filter injection: are your storefront controls enough?
Explore further
18/08/2026 3:27 pm
Public storefront functionality is now a code-execution boundary: This case shows that ecommerce filters, search refinements, and cache-backed UI state are not benign presentation logic. When those controls accept untrusted input and later rehydrate it server-side, the application becomes a trust engine for attackers. The practical conclusion is that public interaction points must be governed like sensitive execution paths, not treated as cosmetic features.
A few things that frame the scale:
- 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time, according to Ultimate Guide to NHIs , Key Challenges and Risks.
- Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs , Key Challenges and Risks.
A question worth separating out:
Q: Who is accountable when a public ecommerce module enables remote code execution?
A: Accountability usually spans application owners, platform operators, and change managers, because the issue often persists through version drift and incomplete patch validation. The right governance response is to treat module verification as a formal control, with evidence for every live store and every deployed extension. That is especially important when the vulnerable path is public-facing and unauthenticated.
👉 Read our full editorial: PrestaShop ps_facetedsearch RCE shows how storefront filters become code execution
