The first step is to inventory every application using Struts file upload functionality and confirm whether it relies on FileUploadInterceptor or the older upload path. If the old mechanism is still in use, teams should rewrite those actions to the new Action File Upload mechanism and related interceptor. Simply upgrading Struts without changing the code path can leave the application exposed to remote code execution.
Confirm the upload path before you assume the upgrade fixed it
Struts upgrades can remove the obvious version gap while leaving the dangerous execution path intact. The practical issue is not the presence of a newer release by itself, but whether any action still routes file handling through the older upload mechanism. Teams that stop at version checking often miss the code-level dependency that actually determines exposure. Guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it reinforces the need to validate control implementation, not just policy intent. In practice, many teams discover the lingering upload path only after a review of affected actions, rather than through the upgrade process itself.
What changes when you move from the old mechanism to the Action File Upload path
The old Struts upload mechanism and the newer Action File Upload approach are not interchangeable implementation details. The change matters because the safer path is tied to a different interceptor flow and a different expectation for how uploads are processed at the action layer. If an application still depends on FileUploadInterceptor or any older upload path, the upgrade does not automatically change how user-supplied files are handled.
That is why the first operational task is inventory, not patching in the abstract. Teams should identify every action that accepts uploads, confirm the interceptor stack in use, and map each entry point to the actual code path. Once that mapping is complete, rewrite any affected actions to use the newer mechanism and verify that the configuration and action classes are aligned. A partial migration is usually worse than a clean one, because it creates a false sense of remediation while preserving the risky path.
- Find every Struts action that accepts file input.
- Check whether it still depends on the older upload path or FileUploadInterceptor.
- Move affected actions to the Action File Upload mechanism and its related interceptor.
- Test the revised upload flow in the same environment and deployment pattern used in production.
This guidance breaks down when teams cannot prove which upload path each action actually uses, because then the upgrade status is only a guess.
Where upgrade-only fixes fail in mixed or legacy Struts estates
Tighter upload handling often increases refactoring effort, requiring organisations to balance remediation speed against application churn. That tradeoff becomes sharper in mixed estates where some actions were modernised and others were left on legacy wiring. The main edge case is not technical novelty; it is incomplete coverage. Applications can look upgraded at the framework level while retaining legacy upload handling in a subset of actions, modules, or inherited configurations.
Another common variation is where teams change the Struts version but leave related action code untouched because upload functionality seems unrelated to the exploit. That is a governance mistake as much as a technical one, since security ownership shifts from package management to application behaviour. In this situation, the correct interpretation is that the framework upgrade reduced exposure but did not complete remediation. If teams cannot confidently identify the upload mechanism in use, they should treat the application as not yet remediated rather than assume the newer version is sufficient.
Practitioner takeaway: Treat the upload mechanism as the remediation boundary, not the Struts version number, because that is what determines whether the risky code path is still live.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.IP-1 — Baseline Configuration and Change Management | Upload-path migration is a controlled code change, not a version check. |
| PR.AC-4 — Access Permissions and Authorizations are Managed | The upload mechanism governs how input is accepted and processed by the app. | |
| Recommendation — Verify the implemented upload path and change it through controlled remediation. Confirm only the intended upload flow is authorised in each affected action. | ||
| CIS Controls v8 | 4.1 — Establish and Maintain an Inventory of Enterprise Assets | Teams must inventory affected applications before deciding remediation scope. |
| 16.10 — Perform Root Cause Analysis on Security Incidents | Persistent exposure usually reflects an unchanged vulnerable code path. | |
| Recommendation — Inventory all Struts applications that accept file uploads before assuming they are safe. Trace why the legacy upload path remains and remove the underlying dependency. | ||
| MITRE ATT&CK | T1190 — Exploit Public-Facing Application | Old Struts upload handling can remain an externally reachable exploitation path. |
| Recommendation — Hunt public-facing actions that still expose legacy upload processing. | ||
Related resources from NHI Mgmt Group
- How should teams use entitlements to control what an AI agent can do after a user authenticates?
- What should security teams do first when password resets are still used as a primary control?
- What should organisations do first when they discover a contractor may still have access after termination?
- How should security teams use IAST and RASP in NHI governance?
