CVE-2026-53787

CVE-2026-53787 is an unauthenticated arbitrary file upload in an Amasty Magento extension, and the severity rating alone undersells the actual risk. The upload endpoint accepts files and places them directly into the media directory—a location explicitly designed to be web-accessible and often CDN-backed. This transforms a single vulnerability into a distribution mechanism: uploading a PHP webshell gives you remote code execution on a server that actively serves files to thousands of daily visitors. The blast radius isn't the store; it's every customer who browses it. The path traversal component compounds this. The fact that arbitrary paths could be supplied in the upload request indicates the developer either assumed the framework would sanitize input or never considered path traversal a threat model. Neither assumption holds in production. The commit that introduced the fix likely added explicit path validation—but the critical question is whether it also added cart-session validation, moved to an authenticated endpoint, or simply blocked file extensions. These represent three fundamentally different security postures, and without the diff, you should treat the worst-case (extension-only) as your working assumption. What makes this exploitation particularly dangerous in the Magento ecosystem is the extension interconnection. An Amasty extension touching checkout, order management, and database persistence means a successful upload-RCE chain accesses customer PII, order history, and payment metadata. Once an attacker has code execution inside the shared Magento runtime, they can inspect the DI configuration, identify other extension classes, and use lower-severity vulnerabilities as persistence mechanisms—even after you patch this one. Your immediate actions: First, verify whether you're on a pre-4.0.0 Amasty version. Second, audit your media directory configuration—if PHP execution is allowed there, you have a remote code execution vector regardless of whether this specific endpoint is reachable. Third, treat any successful upload from an unauthenticated source as a confirmed compromise: audit your access logs for unusual file types in the media directory, check for newly created PHP files, and assume lateral movement is possible if you've been running vulnerable versions. Fourth, factor the upgrade cost into your risk calculation—the security fix arrived in a breaking 4.0.0 release, which means stores reluctant to accept regressions stayed exposed. Your exposure window isn't just time since disclosure; it's time between the fix shipping and your deployment completing. That gap is where attackers establish footholds.

Reviewed through automated stages and approved by a human before publication.