Security Announcement: Releases 3.3.23, 4.0.23 and 4.1.8

A previous release added JSession::checkToken() to the cart controller's state-changing actions. This release completes that hardening across the rest of the storefront: none of the checkout controller's flow-advancing actions (guest/registered login and registration during checkout, billing and shipping address submission, shipping/payment method selection, order confirm()) or the my-profile controller's saveAddress() validated an anti-CSRF token, and the matching templates generated their forms with no token attached. As with the earlier cart-only finding, the token check is opt-in per controller action, so every affected task was reachable by a forged cross-site request as long as the victim's browser held a valid session for the store.

Impact: A forged request riding a victim's active checkout session could silently overwrite the billing or shipping address before order confirmation — the most consequential sub-case, since it opens the door to redirecting a paid order's goods to an attacker-controlled address — or tamper with a saved profile address via saveAddress(). As before, each forged request executes with only the victim's own session privileges, so there is no cross-account data access.

The storefront product listing and product-tags listing both accept a product_types array filter that F0F auto-populates straight from the request into model state. Both models built the product_type IN (...) SQL fragment by wrapping each supplied value in literal quotes and implode()-ing them together, with no escaping and no check that the values were even valid product-type keys. A value containing a ' closed the string early, letting an unauthenticated visitor append arbitrary SQL — e.g. a boolean- or time-based condition — to extract data from the database blind, with no authentication and no user interaction beyond the crafted request.

Impact: Unauthenticated, blind extraction of arbitrary database content (e.g. customer records, order data, stored credentials/tokens) via boolean- or time-based inference, reachable on any public storefront that exposes the standard product listing or product-tags filter.

J2StoreModelOrderdownloads::getFilePath() built the on-disk path to a purchased digital download by concatenating the configured attachment folder with the product file's stored product_file_save_name, using only JPath::clean() (which normalises separators but does not resolve or reject .. segments) and a plain JFile::exists() check — never confirming the resolved path stayed inside the configured attachment folder. If a product file's product_file_save_name ever contained a ../ traversal segment — most plausibly via the CSRF-forgeable admin product-file save actions described in Issue 1, but equally by any future integration or bug that writes that field — any customer holding a valid download token/pid pair for that product file could have the traversal resolve to a path outside the attachment folder and download any file readable by the web server (e.g. configuration.php).

Impact: Unauthenticated-adjacent (token-gated) arbitrary file read, including files containing database credentials and other secrets, chainable with Issue 1's admin CSRF gap to poison a target file entry without ever compromising an admin account directly.

A previous release stopped the PayPal IPN listener from letting an unverified callback confirm an order for free, but a failed IPN signature check was still passed down into _processSale() as an ordinary entry in its $errors array rather than stopping processing — and whenever any error was present, _processSale() unconditionally called $order->update_status(3) (Failed) on whatever order_id the request's custom field named, with no check on the order's current status. Since checkStatusOfPaypal() trivially returns false for any POST that isn't a real PayPal transaction, an anonymous attacker only needed to guess or enumerate a numeric order id and POST a forged IPN body to flip that order — pending, already confirmed, already shipped, any of them — straight to FAILED.

Impact: Unauthenticated denial-of-service against the order pipeline: mass-failing pending orders to disrupt revenue and force manual reprocessing, or flipping already-fulfilled orders back to FAILED to cause operational confusion (unwarranted refunds/cancellations, customer-support load). Unlike the earlier confirmation-fraud issue, this required no correct payment amount or transaction data at all.

The token stored on each order — the bearer credential used for guest order lookup and digital-download authorization — was generated from the single site-wide Joomla secret from configuration.php (the same value Joomla reuses for its anti-CSRF form tokens). The token is generated once at order creation and is never regenerated afterward.

Impact: Anyone who obtains the site's Joomla secret — for example via the configuration.php disclosure in Issue 3 above, or any other config-leak vector on the site — can compute a valid access token for any order on the site without ever having placed one, gaining guest access to that order's details and any purchased digital downloads. Because the token is never rotated, this exposure persists indefinitely even after the underlying secret-disclosure vector is patched, unless the Joomla secret itself is also rotated. The attack complexity (AC:H) is high because it depends on the secret already being known through a separate vector; it is not directly exploitable by an anonymous visitor with no other foothold.

notify.php is a standalone PayPal IPN entry point that bypasses Joomla's normal component dispatch, so it is reachable by anyone, not only PayPal's servers. It took every key/value pair from $_REQUEST (GET, POST, and COOKIE) and concatenated them directly into the query string of a redirect it issues to the com_j2store checkout controller, with no encoding at all.

Because the values are not confined to their intended query-string position, a &, =, or # in an attacker-supplied field is interpreted as new query syntax rather than literal data.

Impact: A crafted link to this endpoint, if followed by a victim's browser (or an automated system that fetches it), causes the resulting redirect to com_j2store's checkout controller to carry attacker-chosen query parameters instead of only the intended view=checkout&task=confirmPayment&orderpayment_type=...&paction=process set — parameter injection/smuggling into that follow-up request. This requires a victim to load the crafted link; it does not by itself grant an unauthenticated attacker anything they could not already obtain by requesting the target com_j2store URL directly with their own parameters.