Using and Interpreting the Magento Security Scan Tool Correctly

1. What the Magento Security Scan Tool is and how registration works

The Magento Security Scan Tool is a free service operated by Adobe that automatically checks publicly reachable Magento stores from the outside, without needing access to the server or the source code. The scan runs strictly against the publicly visible surface of the store, much like an external visitor or a bot would see the site. A store is registered at security.magento.com through the "Add Site" menu item, where only the domain is entered at first.

Before the first scan, the tool requires proof of domain ownership, either through an HTML verification file placed in the webroot or a meta tag on the homepage. Only after successful verification is the domain enabled for recurring scans. This hurdle prevents third parties from scanning stores they do not own and potentially seeing sensitive vulnerability information before the actual operator finds out.

#!/usr/bin/env bash
# Verify the domain-ownership file is publicly reachable before
# registering the site at https://security.magento.com/
set -euo pipefail

DOMAIN="shop.example.com"
VERIFICATION_FILE="magento-security-scan-verification.html"

# The verification file must be placed in the webroot so the
# scan tool can confirm domain ownership before the first scan
status=$(curl -s -o /dev/null -w "%{http_code}" "https://${DOMAIN}/${VERIFICATION_FILE}")

if [[ "$status" == "200" ]]; then
  echo "[OK] Verification file is reachable, ready to register at security.magento.com"
else
  echo "[ERROR] Verification file returned HTTP ${status}, check webroot deployment" >&2
  exit 1
fi

2. What the tool actually checks: CVEs, file permissions, exposed files

The core of the scan is comparing the detected Magento version and installed patches against the public database of known vulnerabilities. The tool usually detects the version through characteristic response headers, static asset paths, or fingerprints in the HTML, then compares it against the list of published security patches and CVEs. If a critical patch is missing, the corresponding CVE shows up in the report with its severity.

In addition, the tool checks for typical configuration mistakes: insecure file permissions that are detectable from the outside, and publicly reachable paths that should be protected, such as .git directories, .env files, composer lock files, or backup archives in the webroot. Such exposed files often leak database credentials, internal paths, or the exact package version, and are a popular first target for automated attacker bots that systematically scan the internet for exactly these patterns.

{
  "scan_id": "b41f9e7a-2026-07-12",
  "target": "https://shop.example.com",
  "scanned_at": "2026-07-12T03:00:00Z",
  "summary": { "critical": 1, "high": 2, "medium": 3, "low": 1 },
  "findings": [
    {
      "id": "PATCH-2024-0007",
      "category": "patch_status",
      "severity": "critical",
      "title": "Missing security patch for remote code execution",
      "description": "Installed version is missing a patch that fixes an unauthenticated remote code execution issue.",
      "recommendation": "Apply the corresponding composer security patch and redeploy."
    },
    {
      "id": "EXPOSED-FILE-002",
      "category": "sensitive_file",
      "severity": "high",
      "title": "Exposed .git directory",
      "description": "The .git directory is reachable from the public webroot and can leak source code and history.",
      "recommendation": "Block access via webserver rule or move the repository outside the webroot."
    }
  ]
}

3. Setting up recurring scans and configuring notifications

After verification, a scan interval can be set for each registered domain, in practice usually weekly. A single one-time scan only provides a snapshot, while recurring scans catch regressions, for example when a deployment accidentally copies an .env file into the public directory, or a patch gets reverted by a later update.

For every registered domain, an email address can be configured to receive a summary after each scan. This notification should go to a group address read by the whole responsible team, not to a single person who may later leave the company. It is also worth forwarding these emails into a ticketing system or a Slack channel, so new findings do not disappear in an overflowing inbox.

4. Reading the report and prioritizing findings by severity

The report typically groups findings into categories such as patch status, malware, file system, and configuration, each with a severity rating like critical, high, medium, and low. This rating is usually based on the CVSS score of the underlying vulnerability and its exploitability without authentication. Critical and high findings, especially missing patches for remote code execution issues, always belong at the top of the priority list.

A simple matrix of severity combined with actual attack surface helps with prioritization: a critical finding on a publicly reachable checkout page weighs heavier than the same finding on an internally used admin endpoint behind an IP restriction. It is important not to view the report in isolation, but to map it against your own system landscape before allocating resources for remediation.

5. Common findings and how to remediate them

The most common findings in practice are missing security patches, which are simply fixed by applying the corresponding composer update or quality patch, followed by exposed .git directories, which can be blocked with a webserver rule or, better, avoided entirely by deploying outside the webroot. Publicly reachable phpinfo files or debug endpoints that were useful during development but forgotten before go-live also show up regularly.

For file permission findings, the basic rule is that directories with 750 and files with 640 permissions are sufficient for most Magento installations, while world-writable permissions (777) are almost never necessary and make it considerably easier for attackers to load further malicious code once they gain an initial foothold. After every fix, it is worth triggering a manual rescan through the dashboard instead of waiting for the next scheduled run.

#!/usr/bin/env bash
# Internal check mirroring the Security Scan Tool's file permission checks
set -euo pipefail

MAGENTO_ROOT="/var/www/html"

echo "Checking for world-writable files..."
find "$MAGENTO_ROOT" -type f -perm -o+w -not -path "*/var/*" -not -path "*/generated/*"

echo "Checking for world-writable directories..."
find "$MAGENTO_ROOT" -type d -perm -o+w -not -path "*/var/*" -not -path "*/generated/*"

echo "Checking for publicly exposed sensitive files..."
for path in ".git/config" ".env" "app/etc/env.php" "var/log/exception.log"; do
  code=$(curl -s -o /dev/null -w "%{http_code}" "https://shop.example.com/${path}")
  if [[ "$code" == "200" ]]; then
    echo "[EXPOSED] ${path} is publicly reachable (HTTP ${code})" >&2
  fi
done

6. Spotting false positives and verifying findings manually

Like any automated scan tool, the Magento Security Scan Tool occasionally produces false positives, for example when a CDN or reverse proxy masks the actual backend version and the tool assumes an older, already patched version. Custom response headers set for debugging purposes can also mislead version detection and trigger a patch finding that does not actually apply.

Before escalating anything to the team, it is worth doing a manual verification: check the actually installed patch level via bin/magento --version and the composer lock file, fetch affected paths by hand with curl, and compare the result against the report. Only confirmed findings should feed into prioritization; unconfirmed findings should still be documented and re-checked at the next scan instead of being silently ignored.

7. Limitations of the tool: not a full penetration test

The Magento Security Scan Tool is deliberately built to be broad rather than deep: it checks known patterns against a database, but does not actively exploit vulnerabilities and does not interact with forms, checkout flows, or authenticated areas. Vulnerabilities in custom-developed code, such as a self-written module or a customized checkout flow, are fundamentally not detected because they do not exist in any public signature database.

Business logic flaws are also out of scope, such as whether a discount code can be redeemed multiple times, whether prices can be manipulated client-side, or whether one customer can access another customer's order data. Such vulnerabilities require human understanding of the business logic and cannot be uncovered through signature matching alone. The tool is a good starting point, but not a substitute for structured security reviews backed by human expertise.

8. Complementary tools and processes for full coverage

Static code analysis with tools like PHPStan or dedicated SAST scanners uncovers vulnerabilities in custom code before it is even deployed, such as unsafe SQL composition, missing escaping calls, or unsafe deserialization. composer audit adds an ongoing check of all third-party dependencies against known advisories, right in the local development environment or the CI pipeline, long before an external scan would even notice the outdated library.

A web application firewall (WAF) blocks attack attempts in real time regardless of whether the underlying vulnerability has already been patched, and additionally provides valuable logs of actual attack patterns. Finally, an annual penetration test performed by certified testers uncovers business logic flaws and gaps in custom code that neither the scan tool nor automated tooling can find. These four building blocks complement each other rather than replacing one another.

#!/usr/bin/env bash
# composer audit as a complement to the external scan, run in CI
set -euo pipefail

cd /var/www/html

# Fail the pipeline on any advisory of severity high or critical
composer audit --format=json > composer-audit-report.json

critical_count=$(jq '[.advisories[][] | select(.severity == "critical" or .severity == "high")] | length' composer-audit-report.json)

if [[ "$critical_count" -gt 0 ]]; then
  echo "[FAIL] ${critical_count} high or critical severity advisories found" >&2
  exit 1
fi

echo "[OK] No high or critical severity advisories"

9. Integrating scans into a regular security review cadence

The biggest benefit comes from not treating the Security Scan Tool in isolation, but as part of a recurring cadence: a weekly external scan, a monthly composer audit run in the CI pipeline, a quarterly internal review of file permissions and access rights, and an annual external penetration test. Each layer covers a different attack surface, and the combination substantially reduces the time a vulnerability stays undetected.

It is important to clearly assign responsibilities: who receives the scan emails, who prioritizes findings, who applies the patches, and who confirms the fix at the next rescan. Without a defined process, even good scan results get lost in unread inboxes. A simple ticket per critical or high finding, tied to a deadline, makes the entire process traceable and auditable.

# /etc/cron.d/security-internal-checks
# Runs weekly internal checks that complement the external
# Magento Security Scan Tool, offset from the external scan window

# min  hour  day  month  weekday  user    command
0      3     *    *      1        deploy  /usr/local/bin/check-file-permissions.sh >> /var/log/security/permissions.log 2>&1
30     3     *    *      1        deploy  /usr/local/bin/composer-audit-ci.sh >> /var/log/security/composer-audit.log 2>&1
0      4     *    *      1        deploy  mail -s "Weekly internal security check" security-team@example.com < /var/log/security/permissions.log

The scan covers an important but limited slice of the attack surface. The table below shows where the tool is reliable and where a deliberate complement is still needed.

In practice, the rows of this table complement each other: the scan provides broad, free baseline coverage against known patterns, while every gap in the middle column points to an area that stays untested without an additional measure. Looking at both columns together makes it easy to see which budget should go into which tool.

10. Summary

The Magento Security Scan Tool is a free, easy-to-set-up first building block of store security: register the domain, verify ownership, enable recurring scans with email notifications, and regularly prioritize the report by severity and actual attack surface. The most common findings, missing patches, exposed .git or .env files, and insecure file permissions, can usually be fixed within a few hours and should be confirmed with a manual rescan after the fix.

At the same time, the tool is explicitly not a full penetration test: business logic flaws, vulnerabilities in custom code, and complex attack chains stay undetected. Combining the scan tool with static code analysis, composer audit, a web application firewall, and annual manual pentests, all embedded in a fixed review cadence, achieves a significantly more robust security posture than any single building block on its own.

11. FAQ: Magento Security Scan Tool