Magento Security Audit: A Practical Checklist

Most Magento security work is about prevention: applying patches, hardening access, keeping extensions current. A Magento security audit answers a different question: is this store clean right now, and would we notice if it were not?

That question matters most after a serious vulnerability. In September 2026, Adobe released an emergency fix for CVE-2026-75650 (bulletin APSB26-146), an unauthenticated remote code execution flaw that was already being exploited. Applying the patch closed the hole. It said nothing about whether anyone had used it first. “Patched” and “not compromised” are two separate claims, and only the first one comes with the patch.

This checklist is what we work through when auditing an Adobe Commerce or Magento Open Source store, whether after an incident, when taking over a store from another team, or as a periodic review.

1. Patch Level and Applied Patches

Start with facts, not assumptions.

• Record the exact version, such as 2.4.8-p5, and compare it with the latest Adobe security bulletins.
• List every patch the build applies: isolated security patches, Adobe Cloud patches, quality patches and any custom ones. Confirm in the build or deploy log that they actually applied, rather than trusting the directory listing.
• Check that patches pinned to specific releases still match the version you run. A patch constrained to an older patch release can silently stop applying after an upgrade.

If nobody can produce this list in a few minutes, that is the first finding. Our guide to applying Magento security patches describes how to keep it current.

2. Unexpected Files

Many Magento exploits end with a file on disk: a web shell, a backdoor or a modified core file. The APSB26-146 patch, for example, closed a path that could write executable PHP into error report files. So the audit has to look at the filesystem, not only the logs.

• Search writable directories, above all pub/media, pub/static and var, for PHP files or other executable content that has no business being there.
• Compare core and vendor code against a clean install of the same version, so that modified core files stand out.
• Confirm that the web server refuses to execute PHP from media and static directories, and that deny rules from Adobe’s sample server configuration are actually in your configuration.

3. Admin Users and Access

• Review every admin account. Remove anything unknown, shared or belonging to someone who has left.
• Make sure two-factor authentication is enforced for all admin users.
• Check that the admin URL is not the default, and that the admin is restricted by IP or sits behind an access layer where possible.
• Review roles. Most people who use the admin do not need full access.

4. Integrations, Tokens and Credentials

An attacker who could execute code could also read app/etc/env.php, which holds database credentials and the encryption key. That is why Adobe’s guidance after APSB26-146 asked merchants to rotate the encryption key and every credential the application could have exposed, including admin passwords, integration tokens, OAuth secrets, payment gateway credentials, and database, CDN and deploy keys. Adobe also points out that rotating the encryption key alone does not invalidate credentials that may already have leaked.

• List all integrations and API tokens. Remove those nobody can explain.
• Check which third parties hold credentials to the store, and whether those credentials are still needed.
• Decide on rotation based on evidence and exposure. If there is any sign of compromise, rotate everything listed above.

5. Injected Scripts

Payment skimmers rarely live in PHP files. They are usually injected into places the admin can edit, so they survive deployments and code reviews.

• Check the configuration fields that add scripts to every page, such as the miscellaneous HTML head and footer settings, for code nobody added deliberately.
• Search CMS blocks, CMS pages and widgets for inline scripts and unknown external domains.
• Review the scripts loaded on checkout. Every external domain should have an owner and a reason.

6. Cron Jobs and Scheduled Tasks

• Review server crontabs and the Magento cron schedule for jobs nobody recognises.
• Check for recently added or changed modules and extensions, especially ones that are not in version control.

7. Logs and Traffic: Read Them Carefully

Exploit attempts leave traces, and the traces are easy to misread in both directions.

• Look for the exploit’s footprint. Payloads often surface as odd application errors. After APSB26-146, for example, we saw PHP code arriving in GraphQL requests where a store code should be, logged as “store not found” errors.
• Look for follow-up probes. Scanners that attempt an exploit usually come back to check whether their dropped file exists. Requests for freshly named PHP files under /media/ tell you exactly what was attempted.
• A 200 is not an execution. Many Magento storefronts return a placeholder image with HTTP 200 for any unknown path under /media/. Before calling something an incident, check what the response actually contained, its type and size, and which code path served it. In the case above, every 200 was the same placeholder image, and a filesystem search found nothing.

8. Document What Normal Looks Like

Exploit scanners keep hitting patched stores for weeks or months. Their errors appear in every monitoring query and look alarming every time someone new finds them. Once you have verified that a pattern is harmless, write a short note: what it is, why it is safe, and what would turn it into a real alarm, such as a response that is not the placeholder, or a file that the search does find. That note saves the next person an evening.

9. Make the Audit Repeatable

An audit done once is a snapshot. The useful version is a short routine that runs on a schedule and after every critical bulletin:

• Run Adobe’s free Security Scan tool for an automated baseline, and treat it as a starting point rather than a verdict.
• Script the filesystem checks, so they can be rerun in minutes.
• Keep the list of admin users, integrations and external scripts in a place where changes are visible.

Magento Security Audit Checklist

• Exact version recorded and compared with the latest bulletins.
• All patches listed and confirmed as applied in the build log.
• No unexpected executable files in media, static or var directories.
• Core and vendor code match a clean install.
• PHP execution blocked in writable directories.
• Admin accounts reviewed, two-factor authentication enforced, admin access restricted.
• Integrations and tokens reviewed. Credentials rotated where exposure is possible.
• No unknown scripts in configuration, CMS content or checkout.
• No unknown cron jobs or modules.
• Logs reviewed for exploit footprints, with HTTP status codes verified against actual responses.
• Known background noise documented.

A clean audit is not permanent, but it gives you a baseline that makes the next anomaly obvious. If you are not sure whether your store is clean after the latest bulletin, or you are taking over a store with an unknown history, a security audit is a sensible first step with our Magento support team.