Security Announcement: Releases 3.3.22, 4.0.22 and 4.1.7

The PayPal IPN listener's signature check (_validateIPN()) accepted UNVERIFIED and any non-INVALID response as valid, made its verification request with CURLOPT_SSL_VERIFYPEER disabled, and stored its verdict in a field nothing downstream ever checked — so processing continued regardless of the outcome. Separately, the paid-amount comparison only ran when mc_gross was a positive number; omitting the field from the POST body (floatval(null) == 0) skipped the check entirely. 

Impact: Unauthenticated financial fraud (free order confirmation) and denial of legitimate orders, verified against a live test installation.

The product-tags listing echoed filter_tag unescaped into a hidden <input>'s value attribute, via J2Html::input()'s hidden branch, in every shipped template family (tag_default, tag_bootstrap3, tag_bootstrap4, each with default.php, default_filters.php, and default_sortfilter.php). pricefrom and priceto behave the same wherever the price-filter UI is enabled. A value containing " closes the attribute early and injects an event handler.

Impact: Arbitrary JavaScript execution in a victim's browser after opening a crafted link, e.g. filter_tag=" autofocus onfocus=alert(1) x=" — no click beyond the initial navigation is required.

fof.xml grants the carts view's tasks a wildcard true ACL, and FOF only enforces CSRF tokens on back-end HTML requests, not on front-end format=raw requests. J2StoreControllerCarts already scoped remove() to the caller's own session, but never overrode the generic FOF save task, so it remained reachable to insert new cart rows with an attacker-chosen user_id/session_id, or overwrite an existing row by id.

Impact: Anonymous cart poisoning and cross-account/session interference, verified against a live test installation (row created and then overwritten via a reused id).

editAddress() redirected non-owners away only when the loaded address row had a non-empty user_id belonging to someone else. Guest-checkout address rows have an empty user_id, so that check never triggered for them — any logged-in account guessing a small, sequential address_id got a guest customer's full name, street address, and phone number rendered prefilled into the edit form.

Impact: Personal data disclosure (PII leak) to any registered site user, requiring only ordinary login and address-id enumeration.

J2StoreControllerApps's appTask delegation path instantiates app-plugin controllers with no com_j2store-specific ACL check anywhere in the code. fof.xml's <backend> node — the only node FOF loads for this admin-side controller — has no <view> ACL entries at all, so the framework's default for an unmatched task is allow, not deny. The only reason anonymous visitors can't reach this today is Joomla core's own administrator-login wall, which is unrelated to J2Store; it blocks guests before any component code runs, but does nothing to check com_j2store permissions for a user who is already logged into the backend for any reason.

Impact: Exploitable today, in production, by any authenticated Joomla backend user, regardless of whether they hold any com_j2store permission — e.g. an account that only manages an unrelated component. That user can trigger arbitrary #__j2store_* table truncation and traversal-based SQL file execution. This is a privilege-escalation issue: a low-value backend login (any) becomes a path to data destruction and potential code execution. It is not exploitable by unauthenticated visitors, which is why PR:L rather than PR:N.