What happened
OpenMage Magento LTS is the community-maintained continuation of the Magento 1 e-commerce platform, which its original vendor stopped supporting in 2020. On October 26, 2026, the OpenMage team published security advisory GHSA-grrq-9gq2-vm55 and rated the flaw critical. VulnCheck described it on November 12, 2026, and it has been listed in the NVD since November 13, 2026 as CVE-2026-128049.
The bug sits in the step where an administrator or customer approves an external application’s access to the store through the REST API (OAuth authorization). The approval could be completed simply by opening a link, with no check that the person actually meant to approve anything. An attacker holding the credentials of a registered application can therefore lure a logged-in administrator to a prepared link and obtain persistent API access in that person’s name.
Several researchers reported the issue privately and independently through HackerOne. OpenMage does not say in its advisory that the flaw has been exploited. It is not in the CISA KEV catalog, and the EU vulnerability database EUVD does not record any exploitation either.
Why it is dangerous
This is a CSRF flaw (cross-site request forgery). Every time you visit the store, your browser automatically sends your login along. If the store does not check that an action really came from a person using its own form, the victim only has to open a link in an email or on another website, and the store carries out the action as if the victim had confirmed it. Think of someone slipping you a power of attorney that counts as signed the moment you glance at it.
The result is a REST API access token tied to the victim, whether an administrator or a customer. It works independently of their browser session and stays valid until someone revokes it. According to OpenMage, an administrator’s token is only useful if that administrator has a REST role assigned. The attacker then gets whatever that role allows, which on stores using the API typically means reading and changing customer, order, product and stock data.
The attack works over the internet, but not just anyone can pull it off. The attacker needs valid OAuth application credentials, meaning integrator-level access rather than an administrator account. The victim must be logged in and must open the link.
Both OpenMage and VulnCheck rate the flaw 9.0 out of 10 under CVSS 3.1, which is critical. VulnCheck also gives a score of 9.4 under the newer CVSS 4.0. CVSS measures severity, not whether anyone is exploiting the bug. That is what the CISA KEV catalog of confirmed exploited flaws is for, and this one is not in it. The EPSS score, which estimates the likelihood of exploitation within the next 30 days, is about 0.23%, which is low.
Who is affected
This affects stores running OpenMage Magento LTS in any version before 20.18.2. The 21.x pre-release line from 21.0.0-beta1 up to but not including 21.0.0-beta3 is affected too. The flaw exists both in the admin panel and in the customer-facing storefront.
OpenMage usually runs on shared web hosting or a company server with PHP, often in stores that started on Magento 1 and never moved to Magento 2. The highest risk is for stores that use the REST API to connect an ERP, warehouse, accounting system or marketplaces and have administrators with a REST role assigned.
- If you do not use the REST API and have no OAuth applications registered, the attacker has nothing to start with. You should still update.
- Magento 2 and Adobe Commerce are separate products and the OpenMage advisory does not cover them.
- OpenMage does not say whether the original Magento 1 is affected. Such a store has not received security fixes since 2020 and is risky in its own right.
How to check if you are affected
Check the version in the directory where the store is installed. If you installed it with Composer, look for the versions line in the output:
composer show openmage/magento-ltsWithout Composer, you can print the version through PHP. The command only loads the store core and changes nothing:
php -r 'require "app/Mage.php"; echo Mage::getOpenMageVersion(), PHP_EOL;'Then, in the admin panel, check System › Web Services › REST OAuth Consumers for registered OAuth applications, and System › Web Services › REST Roles to see whether any administrators have a REST role. If they do and your version is vulnerable, updating is urgent.
How to fix it
The fixed versions are 20.18.2 and 20.19.0, and 21.0.0-beta3 for the 21.x pre-release line. After the fix, confirming OAuth access requires submitting a form with a security key. Simply opening the approval link now returns a 404 error.
- 1. If you cannot update right away, put the temporary measures below in place today.
- 2. Back up the store files and database.
- 3. Test the update on a staging copy first. If your theme overrides the
oauth/authorize/button.phtmlorbutton-simple.phtmltemplates, align them with the new version, otherwise approving integrations will stop working. - 4. Update to 20.19.0 or 20.18.2, for example via Composer, and clear the cache.
- 5. Confirm the version and test that your integrations still work.
- 6. Review issued tokens and OAuth applications as described in the last section.
Temporary measures recommended by OpenMage:
- If you do not use the REST API, remove or disable all OAuth applications under System › Web Services › REST OAuth Consumers.
- Revoke applications you do not fully trust and review issued tokens.
- Do not assign REST roles to administrators who do not need API access.
- Restrict access to the admin panel, for example to selected IP addresses or via VPN.
What if you may already be compromised
A stolen token stays valid until you revoke it, and updating alone does not remove it. After patching, check:
- System › Web Services › REST OAuth Authorized Tokens: revoke any tokens you do not recognize.
- REST My Apps for administrator accounts and My Applications in customer accounts.
- OAuth applications you do not recognize and REST roles with overly broad permissions.
- Unexpected changes to prices, products, stock, orders or customer data.
You can search web server logs for requests to the OAuth approval addresses. Logs usually live in /var/log/apache2/, /var/log/httpd/ or /var/log/nginx/, and on shared hosting you will find them in the hosting control panel. Before the fix, legitimate integrations left these entries too, so compare them with the times you actually connected an application.
zgrep -E "oauth(_authorize|/authorize)/confirm" /var/log/apache2/*access* /var/log/httpd/*access* /var/log/nginx/*access* 2>/dev/nullIf you find a token nobody can explain, revoke it along with its application, rotate integration keys and bring in a security professional. If personal data was breached, GDPR generally requires notifying your data protection authority within 72 hours of becoming aware of it.