Abhishek Nandkumar Bhaskar — Abhi HackZ, abhi_hackz on HackerOne — is credited as Finder and Reporter on four published GitHub Security Advisories in OpenMage (Magento LTS), the community-maintained fork of Magento 1 that still powers thousands of e-commerce stores. The findings span four core application-security areas — session & request forgery, token entropy, abuse throttling and file-path handling — and were all fixed in OpenMage 20.18.2 / 20.19.0 / 21.0.0-beta3, published on Oct 26, 2026.
The OAuth 1.0a authorization step could be completed with a plain GET request and no CSRF token — for store administrators and storefront customers alike. An attacker holding OAuth consumer credentials only has to get a logged-in victim to load a crafted URL: the victim's session silently authorizes the attacker's request token, which the attacker then exchanges for a persistent REST API access token tied to the victim.
The resulting token stays valid until it — or the consumer — is explicitly revoked. An administrator token grants whatever REST role that admin holds, which can mean reading and changing customer, order, product and stock data long after the one forged click.
Remediation
Upgrade to 20.18.2 / 20.19.0 / 21.0.0-beta3 — the authorization confirm actions now require a POST with a valid form key. Until then: remove or disable OAuth consumers you don't use, review issued tokens, and don't assign REST roles to admins who don't need API access.
GHSA-grrq-9gq2-vm55 as published on github.com/OpenMage/magento-lts — Abhi-Hackz in the credits.
Several account-security tokens were generated with time-based, non-cryptographic constructions instead of a CSPRNG. The most serious: the customer email-confirmation key was built from md5(uniqid()). An unauthenticated attacker who can reconstruct the generator state can compute the key and log in to a newly registered, unconfirmed customer account without the password — and email confirmation is enabled by default, so this sits on the default registration path. Customer and administrator password-reset tokens relied on the same weak generator; for an admin, a predicted reset token can mean full store compromise.
Remediation
Upgrade to 20.18.2 / 20.19.0 / 21.0.0-beta3 — tokens now come from random_bytes(16) and are compared with hash_equals(). Existing unconfirmed accounts keep their old predictable keys, so purge stale unconfirmed accounts after upgrading. Until then, rate-limit /customer/account/confirm/ at the WAF.
GHSA-7j66-6mw7-rgfx as published on github.com/OpenMage/magento-lts — Abhi-Hackz in the credits.
The per-IP rate limiter guarding the guest Orders & Returns lookup — itself added as a security fix for CVE-2023-41879 — never actually throttled a request, for two compounding reasons: the limit check ran only after the order had already been loaded, and failed form lookups never recorded a hit against the counter. An unauthenticated attacker could therefore brute-force order number + billing last name + email or postcode without limit; a correct guess exposes the order's contents and the customer's billing and shipping addresses.
A good reminder that a rate limiter is a control worth testing like any other feature — presence is not enforcement.
Remediation
Upgrade to 20.18.2 / 20.19.0 / 21.0.0-beta3 — the limiter now runs on entry and counts failed lookups. Behind a proxy or CDN, configure global/remote_addr_headers so real client IPs are used, or one failed lookup can block all guests. Until upgraded, rate-limit POSTs to /sales/guest/view/ at the edge.
GHSA-rqc2-p2h7-6hw9 as published on github.com/OpenMage/magento-lts — Abhi-Hackz in the credits.
Custom-option file downloads built file paths from values stored with an order or quote item without confining them to the custom-option media directory. On a store selling recurring (nominal) products, a logged-in customer could store crafted paths and download any file the web server user can read — most damagingly app/etc/local.xml, which holds the database credentials and the store's encryption key. Restricting file permissions doesn't help, because the web server user is the one doing the read.
Remediation
Upgrade to 20.18.2 / 20.19.0 / 21.0.0-beta3 — stored paths are now normalised, confined to the custom-option directories, symlink-resolved, and the file's content hash must match its download key. Until then, disable recurring-profile payment methods or stop selling nominal products.
GHSA-2p72-3v6m-9p2h as published on github.com/OpenMage/magento-lts — Abhi-Hackz in the credits.
All four issues were reported responsibly through OpenMage's vulnerability disclosure process on HackerOne and published as coordinated GitHub Security Advisories, crediting Abhishek Nandkumar Bhaskar (Abhi HackZ, abhi_hackz on HackerOne, @Abhi-Hackz on GitHub). He is credited as Finder on the OAuth authorization CSRF advisory and as Reporter on the other three — the sole reporter on the guest order lookup finding, and alongside researchers who reported independently on the rest; each advisory’s credits section lists everyone. Proof-of-concept details are withheld; the facts on this page are taken from the public advisories. CVE IDs have been requested and this page will be updated when they are assigned. For how coordinated disclosure works end to end, read From a Bugcrowd VDP Report to a Published CVE; published CVE records are on the CVEs page.
