The National Vulnerability Database (NVD) has published CVE-2026-128049, a critical-severity vulnerability with a CVSS score of 9.0, affecting OpenMage Magento LTS — a widely deployed open-source e-commerce platform. The flaw is a cross-site request forgery (CSRF) in the OAuth confirmation workflow, allowing remote attackers to hijack administrative or customer sessions and mint persistent REST API access tokens bound to the victim's identity.
This is not a theoretical risk. The vulnerability is remotely exploitable over the network with low attack complexity and requires only that the victim be lured to a crafted URL while authenticated. For organizations running affected versions of OpenMage Magento LTS — specifically versions before 20.18.2 and the 21.0.0-beta1 branch before 21.0.0-beta3 — this vulnerability represents a direct path to API-level compromise of your storefront backend, potentially exposing customer data, order records, and administrative functionality.
If your organization operates an OpenMage Magento LTS storefront, you need to patch immediately and review your OAuth token inventory for signs of unauthorized access.
Technical Analysis
Affected Products and Versions
| Product | Affected Versions | Fixed Version |
|---|---|---|
| OpenMage Magento LTS | All versions before 20.18.2 | 20.18.2 |
| OpenMage Magento LTS | 21.0.0-beta1 through versions before 21.0.0-beta3 | 21.0.0-beta3 |
OpenMage Magento LTS is the community-maintained long-term support fork of Magento 1.x, which reached end-of-life from Adobe in 2020. Despite its age, it remains in active production use across thousands of e-commerce storefronts globally, making it an attractive target for attackers seeking to compromise payment data and customer PII.
CVE Details
- CVE ID: CVE-2026-128049
- CVSS Score: 9.0 (CRITICAL)
- Attack Vector: Network
- Vulnerability Type: Cross-Site Request Forgery (CWE-352)
How the Vulnerability Works
The root cause of CVE-2026-128049 lies in the OAuth confirmation workflow within OpenMage Magento LTS. Specifically, the confirm and confirmSimple actions in both the admin panel and the storefront accept HTTP GET requests without validating a form key (the platform's standard CSRF token mechanism).
In a properly implemented OAuth 1.0a flow, the confirmation step — where a user authorizes a third-party application to access their account — should require a state-changing POST request protected by an anti-CSRF token. OpenMage's implementation fails on both counts.
The attack chain unfolds as follows:
- Prerequisite: The attacker already possesses a valid OAuth consumer key and consumer secret. This is a realistic scenario — consumer credentials are often embedded in mobile apps, browser extensions, third-party integrations, or may have been obtained through prior compromise or information disclosure.
- Token Request: The attacker initiates the OAuth flow by requesting a request token from the target OpenMage instance.
- Social Engineering: The attacker crafts a URL pointing to the vulnerable
confirmorconfirmSimpleaction, embedding their malicious request token. They then lure a logged-in administrator or customer to click this link — via phishing email, malvertising, or a compromised site. - CSRF Execution: Because the endpoint accepts GET requests without form-key validation, the victim's browser automatically submits the OAuth confirmation, authorizing the attacker's request token using the victim's authenticated session.
- Token Exchange: The attacker exchanges the now-authorized request token at
/oauth/tokenfor a persistent REST API access token bound to the victim's identity and permissions. - Post-Exploitation: With a valid API access token, the attacker can interact with the OpenMage REST API to exfiltrate customer data, modify product listings, create fraudulent orders, manipulate pricing, or — if the victim was an admin — perform full administrative operations through the API.
The criticality of this vulnerability is amplified by the fact that the resulting access token is persistent — it does not expire with the victim's session. This gives the attacker long-lived API access that survives password changes and session invalidation unless the token itself is explicitly revoked.
Exploitation Status
As of this writing, there is no confirmed public proof-of-concept exploit code, and CVE-2026-128049 has not been added to the CISA Known Exploited Vulnerabilities (KEV) catalog. However, the attack path is straightforward, requires no specialized tooling beyond a web browser and knowledge of the OAuth flow, and targets a platform with a large installed base of potentially unpatched instances. Defenders should assume that exploit code will emerge rapidly now that the vulnerability details are public.
Detection & Response
The following detection content is designed to help SOC teams identify exploitation attempts and post-exploitation activity related to CVE-2026-128049.
SIGMA Rules
---
title: OpenMage OAuth Confirm CSRF Exploitation Attempt
id: a1b2c3d4-1280-4e5f-a6b7-c8d9e0f1a2b3
status: experimental
description: Detects GET requests to the vulnerable OAuth confirm or confirmSimple endpoints in OpenMage Magento LTS, which may indicate a CSRF exploitation attempt per CVE-2026-128049. These endpoints should not normally receive GET requests from external sources without a valid form key.
references:
- https://nvd.nist.gov/vuln/detail/CVE-2026-128049
author: Security Arsenal
date: 2026/04/06
tags:
- attack.initial_access
- attack.t1190
logsource:
category: webserver
detection:
selection_uri:
cs-uri-stem|contains:
- '/oauth/confirm'
- '/oauth/confirmSimple'
selection_method:
cs-method: 'GET'
condition: selection_uri and selection_method
falsepositives:
- Legitimate OAuth confirmation flows that use GET requests in the vulnerable versions
- Health checks or monitoring tools hitting OAuth endpoints
level: high
---
title: OpenMage OAuth Token Exchange from External Source
id: b2c3d4e5-1280-4f6a-b7c8-d9e0f1a2b3c4
status: experimental
description: Detects POST requests to the OpenMage /oauth/token endpoint from external or non-whitelisted IP addresses. After a successful CSRF attack per CVE-2026-128049, the attacker exchanges the authorized request token for a persistent access token at this endpoint.
references:
- https://nvd.nist.gov/vuln/detail/CVE-2026-128049
author: Security Arsenal
date: 2026/04/06
tags:
- attack.credential_access
- attack.t1550
logsource:
category: webserver
detection:
selection_uri:
cs-uri-stem|contains: '/oauth/token'
selection_method:
cs-method: 'POST'
condition: selection_uri and selection_method
falsepositives:
- Legitimate OAuth token exchanges from authorized integrations and third-party applications
- Internal API consumers performing scheduled token refreshes
level: medium
---
title: Suspicious REST API Activity via Stolen OAuth Token
id: c3d4e5f6-1280-4a7b-c8d9-e0f1a2b3c4d5
status: experimental
description: Detects REST API requests to sensitive OpenMage endpoints (customers, orders, admin operations) that originate from IP addresses not associated with known OAuth consumers. This may indicate use of a stolen persistent access token obtained via CVE-2026-128049.
references:
- https://nvd.nist.gov/vuln/detail/CVE-2026-128049
author: Security Arsenal
date: 2026/04/06
tags:
- attack.collection
- attack.t1213
- attack.impact
logsource:
category: webserver
detection:
selection_api:
cs-uri-stem|contains:
- '/api/rest/customers'
- '/api/rest/orders'
- '/api/rest/products'
- '/api/rest/admin'
selection_auth:
cs-method:
- 'GET'
- 'POST'
- 'PUT'
- 'DELETE'
condition: selection_api and selection_auth
falsepositives:
- Legitimate API consumers including ERP integrations, inventory management, and reporting tools
- Mobile applications using REST API for storefront functionality
level: medium
KQL (Microsoft Sentinel / Defender)
The following KQL queries are designed for Microsoft Sentinel environments ingesting web server logs (IIS, Apache, or Nginx) via CommonSecurityLog (CEF/Syslog) or Azure Application Gateway WAF logs.
// Hunt 1: Identify GET requests to vulnerable OAuth confirm endpoints (CSRF delivery)
CommonSecurityLog
| where TimeGenerated > ago(30d)
| where RequestURL has_any ("/oauth/confirm", "/oauth/confirmSimple")
| where RequestMethod == "GET"
| project TimeGenerated, SourceIP, RequestURL, RequestMethod, RequestContext, DeviceAction
| sort by TimeGenerated desc
// Hunt 2: Correlate OAuth confirm GET requests with subsequent token exchanges from different IPs
let ConfirmEvents = CommonSecurityLog
| where TimeGenerated > ago(7d)
| where RequestURL has_any ("/oauth/confirm", "/oauth/confirmSimple")
| where RequestMethod == "GET"
| project ConfirmTime=TimeGenerated, VictimIP=SourceIP, RequestURL;
let TokenEvents = CommonSecurityLog
| where TimeGenerated > ago(7d)
| where RequestURL has "/oauth/token"
| where RequestMethod == "POST"
| project TokenTime=TimeGenerated, AttackerIP=SourceIP, TokenURL=RequestURL;
ConfirmEvents
| join kind=inner TokenEvents on $left.ConfirmTime < $right.TokenTime
| where TokenTime between (ConfirmTime .. ConfirmTime + 1h)
| where VictimIP != AttackerIP
| project ConfirmTime, VictimIP, TokenTime, AttackerIP, RequestURL, TokenURL
| sort by ConfirmTime desc
// Hunt 3: Detect anomalous REST API access patterns (potential stolen token usage)
CommonSecurityLog
| where TimeGenerated > ago(7d)
| where RequestURL has "/api/rest/"
| where RequestMethod in ("GET", "POST", "PUT", "DELETE")
| summarize APICallCount = count(), UniqueEndpoints = dcount(RequestURL), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated) by SourceIP, bin(TimeGenerated, 1h)
| where APICallCount > 100
| sort by APICallCount desc
Velociraptor VQL
While OpenMage Magento LTS is typically deployed on Linux web servers, Velociraptor can be deployed on the server endpoint to hunt for signs of OAuth token abuse and web log evidence.
-- Hunt for evidence of OAuth token abuse in web server access logs
-- Targets Apache and Nginx access logs for suspicious OAuth endpoint activity
SELECT FullPath, Line,
timestamp(string=parse_string_to_array(string=Line, regex="\\[(\\d+/\\w+/\\d+:\\d+:\\d+:\\d+)")[0], format="02/Jan/2006:15:04:05") AS LogTime
FROM glob(globs=["/var/log/apache2/access*.log", "/var/log/nginx/access*.log", "/var/log/httpd/access*.log"])
WHERE Line =~ "oauth/(confirm|confirmSimple|token)"
AND Line =~ "GET"
ORDER BY LogTime DESC
LIMIT 1000
Remediation Script (Bash)
The following Bash script helps identify your OpenMage Magento LTS version, check for OAuth tokens that may have been issued to unauthorized parties, and verify the patch has been applied.
#!/bin/bash
# CVE-2026-128049 Detection and Remediation Script for OpenMage Magento LTS
# Run on the web server hosting OpenMage
set -euo pipefail
OPENMAGE_ROOT="${1:-/var/www/html}"
echo "=============================================="
echo " CVE-2026-128049 OpenMage OAuth CSRF Checker"
echo "=============================================="
echo ""
# Step 1: Identify OpenMage version
echo "[STEP 1] Identifying OpenMage Magento LTS version..."
if [ -f "${OPENMAGE_ROOT}/app/Mage.php" ]; then
VERSION=$(grep -oP "getVersionInfo.*?'major'\\\s*=>\\\s*'\\K[^']+" "${OPENMAGE_ROOT}/app/Mage.php" 2>/dev/null || echo "unknown")
echo " Found app/Mage.php"
else
echo " WARNING: app/Mage.php not found at ${OPENMAGE_ROOT}"
echo " Checking composer.json for version info..."
if [ -f "${OPENMAGE_ROOT}/composer.json" ]; then
grep -i version "${OPENMAGE_ROOT}/composer.json" | head -5
fi
fi
# Check for version in composer.lock if available
if [ -f "${OPENMAGE_ROOT}/composer.lock" ]; then
echo " Checking composer.lock for openmage version..."
grep -A2 '"openmage' "${OPENMAGE_ROOT}/composer.lock" | head -10
fi
echo ""
echo "[STEP 2] Checking for OAuth tokens in database..."
echo " Connect to your MySQL/MariaDB database and run:"
echo ""
echo " SELECT token, secret, consumer_key, created_at, updated_at"
echo " FROM oauth_token"
echo " ORDER BY created_at DESC;"
echo ""
echo " Look for tokens with recent creation dates that you cannot attribute"
echo " to known integrations or user actions."
echo ""
# Step 3: Check web server access logs for exploitation attempts
echo "[STEP 3] Scanning web server access logs for OAuth confirm GET requests..."
LOG_DIRS=("/var/log/apache2" "/var/log/nginx" "/var/log/httpd")
FOUND_LOGS=false
for LOG_DIR in "${LOG_DIRS[@]}"; do
if [ -d "${LOG_DIR}" ]; then
echo " Scanning ${LOG_DIR}/access*.log* for OAuth endpoint access..."
MATCHES=$(zgrep -h "GET.*oauth/\(confirm\|confirmSimple\)" "${LOG_DIR}"/access*.log* 2>/dev/null || true)
if [ -n "${MATCHES}" ]; then
FOUND_LOGS=true
echo ""
echo " !!! POTENTIAL EXPLOITATION ATTEMPTS FOUND !!!"
echo ""
echo "${MATCHES}" | tail -20
echo ""
else
echo " No GET requests to oauth/confirm endpoints found in ${LOG_DIR}"
fi
fi
done
if [ "$FOUND_LOGS" = false ]; then
echo " No web server access logs found in standard locations."
echo " Manually check your access logs for: GET /oauth/confirm or GET /oauth/confirmSimple"
fi
echo ""
echo "[STEP 4] Checking for /oauth/token POST activity..."
for LOG_DIR in "${LOG_DIRS[@]}"; do
if [ -d "${LOG_DIR}" ]; then
TOKEN_MATCHES=$(zgrep -h "POST.*oauth/token" "${LOG_DIR}"/access*.log* 2>/dev/null || true)
if [ -n "${TOKEN_MATCHES}" ]; then
echo " POST requests to /oauth/token found:"
echo "${TOKEN_MATCHES}" | tail -10
echo ""
fi
fi
done
echo ""
echo "[STEP 5] Checking for vulnerable OAuth controller files..."
OAUTH_CONTROLLER=$(find "${OPENMAGE_ROOT}" -path "*/oauth*" -name "*.php" -path "*/controllers/*" 2>/dev/null | head -5)
if [ -n "${OAUTH_CONTROLLER}" ]; then
echo " Found OAuth controller files:"
echo "${OAUTH_CONTROLLER}"
echo ""
echo " Checking for form key validation in confirm actions..."
for FILE in ${OAUTH_CONTROLLER}; do
if grep -q "confirmAction\|confirmSimpleAction" "${FILE}" 2>/dev/null; then
echo " --- ${FILE} ---"
if grep -q "validateFormKey\|_validateFormKey\|form_key" "${FILE}" 2>/dev/null; then
echo " [OK] Form key validation appears to be present."
else
echo " [VULNERABLE] No form key validation found in confirm actions!"
fi
fi
done
else
echo " Could not locate OAuth controller files."
fi
echo ""
echo "=============================================="
echo " RECOMMENDED ACTIONS"
echo "=============================================="
echo " 1. Update OpenMage to version 20.18.2 or 21.0.0-beta3+"
echo " 2. Revoke ALL existing OAuth access tokens in the admin panel"
echo " 3. Force re-authorization for all legitimate OAuth consumers"
echo " 4. Review access logs for signs of exploitation (see Step 3)"
echo " 5. If exploitation is suspected, initiate incident response"
echo "=============================================="
Remediation
Immediate Actions
-
Apply the patch immediately. Update OpenMage Magento LTS to version 20.18.2 (for the 20.x branch) or 21.0.0-beta3 (for the 21.x beta branch). The patch adds form-key validation to the
confirmandconfirmSimpleactions and enforces POST-only requests for these state-changing OAuth operations. -
Revoke all existing OAuth access tokens. Because the vulnerability allows attackers to mint persistent tokens that survive session invalidation, you must assume that any existing tokens may be compromised. In the OpenMage admin panel, navigate to the OAuth consumer management section and revoke all access tokens. Legitimate integrations will need to re-authorize.
-
Audit OAuth consumer registrations. Review all registered OAuth consumers. Remove any that are no longer in use, and rotate consumer keys and secrets for all active integrations.
-
Review web server access logs. Search for GET requests to
/oauth/confirmand/oauth/confirmSimpleendpoints. Correlate with subsequent POST requests to/oauth/tokenfrom different source IP addresses. This pattern is a strong indicator of successful exploitation.
Configuration Hardening (Defense-in-Depth)
-
Restrict OAuth endpoint access at the WAF/reverse proxy level. If your OAuth integrations are only used by known third-party services, consider IP-allowlisting access to
/oauth/confirm,/oauth/confirmSimple, and/oauth/tokenendpoints at your WAF, reverse proxy, or load balancer. -
Implement Content Security Policy (CSP) headers. While CSP does not directly prevent CSRF, it can reduce the risk of malicious redirect chains used to deliver the crafted confirm URL.
-
Enforce SameSite cookie attributes. Set
SameSite=StrictorSameSite=Laxon session cookies to reduce the risk of cross-origin requests carrying authenticated session state. Note that this is a defense-in-depth measure and does not replace patching. -
Enable and monitor audit logging. Ensure that OAuth token issuance events are logged and forwarded to your SIEM. Alert on token issuance events that correlate with GET requests to confirm endpoints.
Vendor References
- NVD Entry: https://nvd.nist.gov/vuln/detail/CVE-2026-128049
- OpenMage GitHub Repository: Check the OpenMage/magento-lts repository for release notes and security advisories related to versions 20.18.2 and 21.0.0-beta3.
Incident Response Considerations
If you find evidence of exploitation — specifically, GET requests to the confirm endpoints followed by token issuance to an unrecognized source — treat this as a confirmed breach and initiate your incident response plan:
- Contain: Immediately revoke all OAuth tokens and take the affected instance offline if feasible.
- Investigate: Determine what API actions were performed using the stolen token. Focus on customer data access, order manipulation, and administrative operations.
- Notify: If customer PII or payment data was accessed, evaluate your notification obligations under applicable regulations (PCI-DSS, GDPR, CCPA, state breach notification laws).
- Recover: Patch to the fixed version, re-issue OAuth credentials to legitimate consumers only, and restore normal operations with enhanced monitoring.
Related Resources
Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.