Blocking SessionReaper and PolyShell File Access with Fastly on Magento/Adobe Commerce

If you’ve been keeping an eye on the Magento security space recently, you’ll have seen the research from Sansec around SessionReaper exploitation and the more recent PolyShell - both of which use the media/custom_options/ directory as a vector for uploading and executing malicious PHP files.

The SessionReaper attack targets session data to extract customer and admin credentials, and the PolyShell technique builds on this by disguising executable PHP within files that appear to be valid image uploads.

Blocking access at the edge with Fastly

If you’re running Adobe Commerce Cloud or any Magento instance fronted by Fastly, you can block access to these paths before requests ever reach your origin server. This is a fairly simple custom VCL snippet that returns a 403 for any request targeting media/custom_options/:

if (req.url ~ "^/media/custom_options/") {
  error 403 "Forbidden";
}

Add this as a custom VCL snippet in your Fastly configuration with the type set to recv and priority 1. This will catch any direct access attempts to files within that directory - whether they’re SessionReaper scripts, PolyShell payloads or anything else that has no business being served publicly.

Edge-level blocking over application-level blocking

Blocking at Fastly rather than at the application level means the request never reaches nginx, Varnish or PHP. This is important for two reasons - it reduces the attack surface significantly and it means even if an attacker has managed to upload a malicious file, they can’t execute it by requesting it directly through the public URL.

You should still be auditing your media/custom_options/ directory for any suspicious files and ensuring your Magento instance is patched, but adding this edge-level block is a solid defensive layer that takes seconds to deploy.

Important Note

If your store actively uses custom options with file upload fields on products, you’ll need to be more careful with this approach. Blanket blocking the entire media/custom_options/ path could interfere with legitimate file uploads that customers need to access. In that case you may need to refine the VCL to target specific file extensions or patterns rather than the whole directory.

Further reading

Sansec’s research on both of these attack vectors is well worth a read if you haven’t already:

With a bit of luck this saves you from a headache down the line. If you’re not already monitoring your media directories for unexpected PHP files, now is a good time to start.