Validate frontend input type for file uploads

[SkyMulley]

Description (*)

The customer address file upload endpoint (Customer/Controller/Address/File/Upload.php) did not validate whether the requested attribute's frontend_input type was file or image before proceeding with the upload.

This allowed an attacker to supply any custom address attribute code (e.g. a text type attribute) as the upload target. Since non-file attributes have no file_extensions validation rules configured, getAllowedExtensions() returns an empty array, causing the framework uploader to permit all file types — including executable files such as .php.

The fix adds a check immediately after fetching the attribute metadata, throwing a LocalizedException if the frontend_input is not file or image.

Manual testing scenarios (*)

1. Create a custom customer address attribute with frontend_input type of text (e.g. my_text_attribute)
2. Log in as a customer and send a POST request to /customer/address/file/upload with custom_attributes[my_text_attribute] as the file field, uploading a .php file
3. Without fix: file is accepted and saved to pub/media/customer_address/tmp/
4. With fix: request returns an error — Attribute "my_text_attribute" does not support file uploads. — and no file is written to disk
5. Verify that uploading via a legitimate file or image type attribute still works as expected

Questions or comments

This vulnerability requires an authenticated customer session to exploit. However, customer registration is typically open on Magento storefronts, making the attack surface effectively unauthenticated. The exploitability of the resulting upload also depends on whether PHP execution is blocked in the media directory, but defence in depth requires rejecting the upload regardless.

[m2-assistant]

Hi @SkyMulley. Thank you for your contribution!
Here are some useful tips on how you can test your changes using Magento test environment.
❗ Automated tests can be triggered manually with an appropriate comment:

• @magento run all tests - run or re-run all required tests against the PR changes
• @magento run <test-build(s)> - run or re-run specific test build(s)
  For example: @magento run Unit Tests

<test-build(s)> is a comma-separated list of build names.

Allowed build names are:

1. Database Compare
2. Functional Tests CE
3. Functional Tests EE
4. Functional Tests B2B
5. Integration Tests
6. Magento Health Index
7. Sample Data Tests CE
8. Sample Data Tests EE
9. Sample Data Tests B2B
10. Static Tests
11. Unit Tests
12. WebAPI Tests
13. Semantic Version Checker

You can find more information about the builds here
ℹ️ Run only required test builds during development. Run all test builds before sending your pull request for review.

---

For more details, review the Code Contributions documentation.
Join Magento Community Engineering Slack and ask your questions in #github channel.

[ct-prd-pr-scan]

The security team has been informed about this pull request due to the presence of risky security keywords. For security vulnerability reports, please visit Adobe's vulnerability disclosure program on HackerOne or email psirt@adobe.com.