This is an open redirect vulnerability in J2Store's redirect handlers, but framing it as 'just another open redirect' obscures the real danger. The CVSS 5.1 rating reflects a technical scoring model that doesn't account for where this flaw lives: a payment checkout flow. Users mid-transaction, credit card in hand, bouncing from a trusted checkout domain to an attacker-controlled destination through what appears to be a normal J2Store redirect. That's not a medium-severity issue by any measure that accounts for human behavior under cognitive load — it's a trust-transfer mechanism that gives attackers your domain, your SSL certificate, and your browser trust indicators automatically, without requiring the victim to ignore warning signs.
Four separate task handlers implement the same flawed pattern: base64-encoded redirect URLs that get decoded and followed without any destination validation. The repetition is the diagnostic signal. Either the codebase lacked a secure redirect utility (forcing developers to invent ad-hoc solutions), that utility existed but wasn't discoverable, or time pressure pushed developers toward the first working approach rather than the correct one. The base64 encoding itself is likely a red herring — whether it was intended as security or merely as transport encoding for URLs with special characters, the failure is identical: attacker-controlled input enters the system, gets processed, and exits as a redirect destination without any host allowlist or relative-URL check.
The version archaeology adds a troubling dimension. This pattern survived across three separate release branches (3.x, 4.0.x, and 4.1.x), meaning either the flawed code was copy-pasted into each branch at creation, or someone fixed it in one branch and never propagated the fix to the others. Either scenario indicates a gap in cross-branch security patch coordination. For sites running older branches, particularly if those branches have reached end-of-life, the calculus is simple: no patch is coming, and the remediation path is migration.
The immediate action is to verify whether your J2Store installation exposes any of these four handlers in its task routing, then apply any available patch. But the systemic fix requires two things: first, audit your codebase for other instances of 'encode and trust' patterns where input is transformed and then treated as safe without post-decode validation. Second, establish a host allowlist for all redirects in payment-adjacent code — relative-URL-only policies work where the application context permits. The payment flow context means these redirects fire at the moment users are most primed to trust the domain, which is precisely what makes this class of vulnerability historically dangerous and why the CVSS rating badly understates the actual risk.