CVE-2026-78065 in J2Store Extension
Summary
by MITRE • 09/03/2026
Joomla Extension - j2commerce.com - Guest checkout address disclosure to any authenticated user (IDOR) in J2Store 1.0.0-3.3.21, 4.0.0-4.0.21, 4.1.0-4.1.6 - `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.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/03/2026
The vulnerability identified in J2Store versions 1.0.0 through 3.3.21 and 4.0.0 through 4.1.6 represents a critical instance of an Insecure Direct Object Reference, commonly categorized under CWE-639. This flaw exists within the `editAddress()` function, which is responsible for handling address modifications during both registered user checkouts and guest checkout processes. The core technical deficiency lies in the authorization logic employed by the application when validating access to specific address records stored in the database. Specifically, the code checks whether the currently authenticated user's identifier matches the `user_id` associated with the requested address row. However, this validation mechanism contains a logical gap that fails to account for addresses created during guest checkout sessions.
During a standard registered user transaction, an address is linked to a specific customer account via a non-null `user_id`. The vulnerability logic correctly redirects or denies access if the authenticated user attempts to edit an address belonging to another user by verifying this identifier. In contrast, when a purchase is made as a guest without creating a permanent account, the resulting address record is stored with a null or empty `user_id` field because no persistent identity exists at that moment. The flawed authorization check only triggers a denial of access if the loaded address row possesses a non-empty `user_id` belonging to someone else. Consequently, when an attacker targets a guest checkout address where the `user_id` is empty, this specific conditional check evaluates as false or bypassed entirely, allowing the request to proceed without proper ownership verification.
The operational impact of this vulnerability allows any authenticated user on the Joomla site to access sensitive personally identifiable information belonging to guests who have previously made purchases. By exploiting a predictable pattern in database identifiers, an attacker can iterate through sequential `address_id` values using automated tools or simple scripts. Upon finding a valid address ID associated with a guest checkout, the application renders the full name, physical street address, and phone number into the edit form interface. This exposure occurs without any additional authentication barriers because the system assumes that empty user identifiers imply public accessibility or lack of strict ownership constraints. The disclosure is significant as it compromises customer privacy and can facilitate further social engineering attacks or targeted fraud against individuals who trusted the platform with their contact details during anonymous transactions.
This vulnerability aligns closely with MITRE ATT&CK technique T1078, specifically regarding valid accounts being used to access unauthorized resources, although in this case, the resource is data rather than a system function. It also reflects CWE-269, Improper Privilege Management, as the application fails to enforce appropriate security privileges for different types of user sessions. To mitigate this issue, developers must implement robust object-level authorization checks that do not rely solely on the presence or absence of a `user_id`. The fix should involve verifying ownership through session context, such as checking if the address was created within the current guest session token or ensuring that only the creator of an order can view its associated details. Additionally, implementing randomization for database identifiers rather than relying on sequential integers would significantly increase the difficulty of enumeration attacks. Administrators running affected versions should apply vendor-provided patches immediately and review server logs for signs of automated scanning activity targeting address endpoints to assess potential data exposure scope.