Adobe Commerce APSB26-92 is being actively exploited: How to detect if your store is already compromised

Adobe Commerce APSB26-92, including CVE-2026-71362, an unauthenticated customer account takeover, is being actively exploited against live stores as of August 2026. Apply the patch immediately, then audit customer account records modified since August 11 for unauthorised changes, review access logs for exploitation signatures, and run a malware scan. Patching stops future attacks but does not undo damage already done.

The APSB26-92 vulnerability disclosed on August 11, 2026, is being actively exploited against Adobe Commerce and Magento Open Source stores. The most severe flaw, CVE-2026-71362 an unauthenticated customer account takeover, allows attackers to compromise customer accounts without any credentials. If your store has not been patched, you need to check for signs of compromise immediately, not just apply the update.

What makes this vulnerability different

CVE-2026-71362 requires no authentication. An attacker does not need admin access, stolen credentials, or any prior interaction with your store. They can bypass security checks and gain unauthorised write access to customer accounts remotely. This is not a theoretical risk requiring sophisticated tooling; it is a straightforward exploit being used against live stores right now.

• Security firm Sansec confirmed it is actively blocking exploitation attempts.
• Belgium's Centre for Cybersecurity (CCB) issued a formal warning confirming active exploitation in the wild and advising immediate patching.
• Hosting provider Hypernode deployed emergency server-level blocks across all hosted Magento merchants to contain the threat.

The broader context is alarming: account takeover attempts increased by over 300% year over year across ecommerce according to WiserReview's 2026 data, and the average confirmed account takeover incident costs ecommerce brands $12,000 in direct fraud loss before chargeback fees and customer recovery costs according to MojoAuth's 2026 analysis.

Recognisable symptoms of a compromised store

The challenge with account takeover exploits is that they produce no visible storefront error. Your store continues to load, checkout continues to function, and your admin dashboard shows no alerts. The symptoms appear in places most merchants are not monitoring:

• Unexpected customer account changes: Email addresses, shipping addresses, or saved payment methods modified without the customer initiating the change.
• Unfamiliar customer service requests: Legitimate customers reporting they cannot log in, that their order history shows unfamiliar purchases, or that their password no longer works.
• Unusual order patterns: Orders placed from previously dormant customer accounts, orders shipped to new addresses, or orders placed in rapid succession from accounts that typically order infrequently.
• Password reset spikes: An abnormal increase in password reset requests may indicate attackers are locking legitimate customers out of compromised accounts.
• Suspicious admin user activity: If attackers escalate privileges, new admin users or modified admin permissions may appear.

Likely error or alert variants

You may encounter these in logs, customer communications, or support tickets:

• "I didn't place this order", from a legitimate customer whose account was taken over
• "My account email was changed, and I didn't do it"
• "I can't log in to my account anymore"
• Unusual customer_save_after or customer_address_save_after event log entries
• Unexpected REST API or GraphQL mutations against customer accounts in your access logs

Immediate containment steps

If you suspect exploitation has already occurred, take these steps in order:

1. Apply the APSB26-92 isolated security patch immediately. Adobe provides patches for versions 2.4.4 through 2.4.9. For Cloud merchants, use the Quality Patches Tool to verify deployment. For on-premises installations, download from the Adobe Commerce Help Center.

2. Audit customer account modifications. Query your customer_entity table for records modified between August 11 and your patch date. Focus on changes to email, password hash, and address fields that customers did not initiate.

3. Review access logs for exploitation signatures. Check web server access logs for unusual POST requests to customer account endpoints. Security researchers have published specific indicators of compromise for this vulnerability.

4. Force password resets for affected accounts. If you identify compromised customer accounts, force a password reset and notify the affected customers directly. Do not wait for customers to discover the problem.

5. Check for privilege escalation. Review your admin user list for accounts created after August 11 that you do not recognise. Check for modified file permissions or new files in your webroot.

6. Scan for injected code. Attackers who gain code execution access frequently inject payment skimmers, redirect scripts, or backdoor files. Run a file integrity check against a known-clean baseline. Pay particular attention to checkout templates, payment processing files, and configuration files.

How to verify your store is clean

Patching stops future exploitation but does not undo damage already done. After applying APSB26-92:

• Confirm the patch is active by checking your composer.lock for the updated package version.
• Run a malware scanner such as Sansec eComscan against your codebase.
• Compare current customer account data against your most recent pre-August-11 backup to identify unauthorised modifications.
• Monitor your customer service queue for the next 7–14 days for account-related complaints.
• Verify checkout integrity by completing test transactions through every payment method and confirming no unexpected scripts load during the payment step.

Prevention and continuous monitoring

The window between vulnerability disclosure and patch application is where the real damage happens. Sansec, Hypernode, and others responded within days, but many merchants will take weeks to patch, and attackers know this.

Continuous storefront monitoring bridges this gap by detecting the symptoms of compromise at the customer-facing level: unexpected script injections on checkout pages, modified form actions, new external resource requests, and page behaviour changes that indicate tampering. These are the signals that appear even when your server logs look clean, and your admin dashboard shows no alerts.

AuditIQ is an eCommerce monitoring tool that watches your live storefront from the outside; the same perspective an attacker's injected code operates from. Rather than relying on server logs or admin alerts that compromise leaves untouched, AuditIQ monitors what actually happens on your pages when real sessions occur.

For Adobe Commerce and Magento merchants managing the APSB26-92 exposure, AuditIQ provides:

• Checkout script monitoring: detects unexpected third-party scripts loading on payment pages, including skimmers injected via compromised extensions or file modifications
• Page behaviour anomaly detection: flags when form actions, external resource requests, or DOM structure change in ways that indicate tampering
• Real-user session tracking: captures what customers actually experience during checkout, catching silent failures and injected interference that synthetic tests miss
• Continuous baseline comparison: compares your live storefront against a known-clean state after every deployment or suspicious event
• Revenue impact correlation: connects technical anomalies to conversion and order data, so you can quantify the business impact of a compromise, not just the technical footprint

So instead of discovering a compromise weeks later through chargebacks or customer fraud reports, you see the anomaly within hours, while there is still time to contain it.

Book a free AuditIQ demo to see how continuous storefront monitoring detects the signs of compromise that your security patches and server logs can't show you.

Frequently asked questions

1. How do I know if my Adobe Commerce store was attacked before I applied the APSB26-92 patch?

Audit customer account records modified between August 11 and your patch date. Look for email, address, or password changes that customers did not initiate. Review access logs for unusual POST requests to customer account API endpoints.

2. Does applying the APSB26-92 patch remove any malware already on my store?

No. The patch prevents future exploitation of these specific vulnerabilities. It does not detect or remove code already injected by an attacker. A separate malware scan and file integrity check are required.

3. Which Adobe Commerce and Magento versions are affected?

APSB26-92 affects Adobe Commerce, Adobe Commerce B2B, and Magento Open Source across supported version lines. Adobe provides isolated security patches for each.

4. My hosting provider says they applied a server-level block. Do I still need to patch?

Yes. Server-level blocks protect against known exploitation patterns but do not address the underlying vulnerability. New exploit variants may bypass server-level protections. The patch is the only definitive fix.