Over the past few weeks, I’ve been reviewing a number of Magento stores and have noticed a recurring pattern across multiple environments. This includes sites that are up to date, patched and generally well maintained.
In several cases, I’ve seen unexpected directories appear within pub/media, most commonly:
customer_addresscustomer_options
These are not typically present in a standard Magento setup and are often linked to exploit attempts targeting the customer address file upload functionality.
This post is based on what I’ve observed across live projects, along with the practical steps I recommend to secure Magento stores against this type of attack.
What is the Magento customer_address folder issue?
If you’re seeing a customer_address folder or customer_options directory in Magento, it’s usually the result of an attempted interaction with the customer address file upload endpoint.
The pattern tends to look like this.
A new directory appears:
pub/media/customer_address/or:
pub/media/customer_options/Inside, there may be uploaded files such as:
.pharfiles.datfiles- Session-like files with encoded or obfuscated content
Access logs may include requests such as:
POST /customer/address_file/upload
GET /media/customer_address/...pharThis isn’t part of normal Magento behaviour. If these directories appear, it’s a strong signal that your site has been targeted by automated probing or exploit attempts.
The link to CVE-2025-54236 (SessionReaper)
This behaviour is associated with CVE-2025-54236, often referred to as SessionReaper.
This vulnerability combines two attack vectors:
- Nested deserialization, allowing manipulation of PHP session storage paths
- Unauthenticated file upload via the customer address endpoint
When combined, these can potentially lead to remote code execution, particularly on Magento installations using file-based session storage.
Why this can affect fully patched Magento sites
One of the more surprising aspects of this issue is that it’s not limited to outdated installations.
Even on sites that are:
- Fully patched
- Running recent Magento versions
- Actively maintained
…the Magento customer_address folder or customer_options directory can still appear.
In most cases, this comes down to factors outside Magento core.
1. Extension behaviour
Third-party modules that interact with customer attributes, file uploads or APIs can introduce unintended exposure.
2. Publicly accessible endpoints
The following endpoint is often still available, even if unused:
/customer/address_file/uploadThis provides a target for automated requests.
3. Lack of server-level restrictions
If access to /media/customer_address and related paths isn’t restricted, uploaded files can be accessed directly.
Quick checklist if you find a Magento customer_address folder
If you’ve identified a customer_address or customer_options directory on your site, here’s a practical checklist:
- Remove the directory and any unexpected files
- Review access logs for upload attempts
- Block
/customer/address_file/uploadat server level - Block direct access to
/media/customer_address - Apply the latest Magento security patches
- Disable unused upload functionality
- Review installed extensions for anything interacting with file uploads
Recommended steps to secure your Magento site
Based on what I’ve seen across multiple projects, here’s the approach I recommend.
1. Apply the latest Magento security updates
Ensure your store is fully patched, including updates related to CVE-2025-54236.
While patches may not cover every edge case, they significantly reduce exposure.
2. Remove unexpected directories and files
Check for and remove:
pub/media/customer_address/
pub/media/customer_options/Also review:
.pharfiles.datfiles- Any recently modified or unfamiliar files
3. Block vulnerable endpoints
At server or WAF level, restrict access to:
/media/customer_address
/customer/address_file/uploadThese should not be publicly accessible unless explicitly required.
4. Disable the customer address upload controller
If your store doesn’t require customer file uploads, it’s best to disable this functionality entirely.
This can be done by overriding:
vendor/magento/module-customer/Controller/Address/File/Upload.phpand preventing execution of the upload logic.
5. Use a dedicated security module
A more maintainable approach is to use a module designed for this purpose:
magento2-disable-customer-upload-controller
This disables the unauthenticated upload endpoint and provides protection against SessionReaper-style exploits and similar file upload vulnerabilities.
6. Check for additional uploaded payloads
Once these directories appear, it’s worth confirming that no additional files have been written.
For example:
find pub/media -type f -name "*.phar" -o -name "*.dat"Also review:
- Recently modified files in
pub/media - Any unfamiliar filenames or encoded content
What to monitor going forward
To stay ahead of this type of issue, I’d recommend:
- Monitoring for new directories within
pub/media - Tracking file changes across the application
- Reviewing access logs for unusual POST requests
- Auditing extensions that interact with customer data or file uploads
This appears to be part of a broader automated pattern, so ongoing visibility is key.
Final thoughts
This is a good example of how security in Magento often sits beyond just applying patches.
The interaction between core functionality, extensions and server configuration creates potential exposure points, particularly around publicly accessible endpoints.
From what I’ve seen, the most effective approach is to:
- Disable functionality that isn’t required
- Restrict access at server level
- Regularly review file changes and logs
If you’re seeing a Magento customer_address folder or customer_options directory, it’s worth investigating promptly and tightening controls around file uploads and public endpoints.
If you’d like help reviewing or securing your Magento setup, feel free to get in touch.