JoomShaper EasyStore CVE-2026-90904

Requires an existing authenticated Joomla backend (administrator-area) user account of any privilege level; the flaw lets that account edit EasyStore records even without the specific EasyStore ACL edit grant, because allowEdit() ignores the permission check entirely. It affects EasyStore extension versions 1.0.0 through 3.0.0. Limiting factors: exploitation is impossible for fully unauthenticated / front-end-only visitors (backend login is mandatory), and impact is confined to sites running the EasyStore extension in the affected version range.

This is a broken-access-control / ACL bypass (CWE-284) in the JoomShaper EasyStore Joomla extension where allowEdit() in ApiController.php was hardcoded to return true;, defeating Joomla's component- and asset-level permission model. The only CVSS provided is a vendor (Joomla) 4.0 vector scoring 8.6 (AV:N/AC:L/PR:H/UI:N/VC:H/VI:H/VA:H). Two of those metrics look overstated: PR:H does not match the description, which says 'any authenticated backend user' regardless of ACL grants - that is a low-privilege prerequisite (PR:L), not high. VC:H/VA:H are also aggressive: the flaw grants unauthorized *editing* of arbitrary EasyStore records, so integrity (VI:H) is the real impact, while confidentiality is incidental (edit views may leak record contents, ~VC:L/C:L) and availability impact is unclear (VA:N). There is no EPSS score, no CISA KEV listing, and no public exploit referenced, so exploitation status is 'no public exploit identified at time of analysis.' Net: a genuine authorization flaw that any backend account can trigger, but real-world risk is bounded by the requirement for an existing authenticated backend session and by the extension's modest deployment footprint - a real-but-not-urgent priority rather than a high-CVSS emergency. The single reference is only the vendor product page, so version boundaries and fix details cannot be independently corroborated.

An attacker who already holds any authenticated Joomla backend account (e.g. a low-tier staff or manager role never granted EasyStore edit rights) sends a crafted request to the EasyStore ApiController record-edit endpoint. Because allowEdit() unconditionally returns true, the ACL check is skipped and the attacker modifies arbitrary EasyStore records - products, orders, or store data - outside their permission scope. No public proof-of-concept is referenced.