Remote Code Execution Vulnerabilities in Apache Struts
CVE-2024-53677 and CVE-2023-50164 are vulnerabilities in Apache Struts that could pave the way for remote code execution, or RCE. Learn how to figure out if you’re affected, and if so what to do about it
CVE-2024-53677 and CVE-2023-50164 are vulnerabilities in Apache Struts that could pave the way for remote code execution, or RCE. Learn how to figure out if you’re affected, and if so what to do about it
CVE-2024-53677 and CVE-2023-50164 are vulnerabilities in Apache Struts that could pave the way for remote code execution, or RCE. Learn how to figure out if you’re affected, and if so what to do about it
CVE-2024-53677 and CVE-2023-50164 are vulnerabilities in Apache Struts that could pave the way for remote code execution, or RCE. Learn how to figure out if you’re affected, and if so what to do about it
CVE-2024-53677 and CVE-2023-50164 are vulnerabilities in Apache Struts that could pave the way for remote code execution, or RCE. Learn how to figure out if you’re affected, and if so what to do about it
How worried should you be about the recent CVEs in Apache Struts?
In December 2024, the Apache Software Foundation disclosed a new security flaw impacting Apache Struts that could pave the way for remote code execution, or RCE. CVE-2024-53677 (and CVE-2023-50164) is a critical path-traversal bug in the FileUploadInterceptor class of Struts prior to 6.4.0. Path traversal in uploads can potentially lead to RCEs — there’s no doubt the potential impact is high. And with 50164 having an EPSS above 50% (meaning it has a strong probability of being exploited), it’s definitely urgent to determine whether you’re safe.
What is Apache Struts?
Apache Struts is a popular open source framework used for building Java web applications. It's been around for a long time and is used by many large organizations. Essentially, Struts provides a set of tools and components that make it easier to create complex web applications, handling things like user input, data processing, and displaying information in a web browser. Think of it as a scaffolding that helps developers build web apps more efficiently.
Why are RCEs dangerous?
Remote code execution (RCE) vulnerabilities are among the most serious security flaws a web application can have. Why? Because they allow attackers to take complete control of the affected system. Imagine someone breaking into your house and having the ability to do whatever they want – that's essentially what an RCE allows an attacker to do to your server. They can steal data, install malware, delete files, or even use your server to launch attacks on other targets.
Which Struts users are at risk?
Fortunately, not all Struts users will be impacted. Many of those who are potentially affected are also likely to have strong mitigations already in place. The attack path relies on your web app accepting file uploads using Struts’ FileUploadInterceptor. No file upload capability? No attack path. Using some other facility? No attack path. (This kind of analysis is why we at Endor Labs invested so much into function-level reachability: we can tell you if you’re using the part of Struts that’s vulnerable.)
If you're potentially vulnerable, that doesn’t guarantee an adversary can successfully exploit your application. They must be able to successfully manipulate the request data when uploading. Many Java application servers in enterprises are configured to filter out or encode this class of malicious parameter, either directly or via some third-party security plugin. And if not that, anti-path-traversal web application firewall (WAF) rules in front of affected endpoints are good mitigators. And, for the upload to succeed, the application server user (or whatever user your Struts application runs as) has to have write access to the targeted path.
Beyond that, if you’ve done a good job with least privilege and decent filesystem permissions as part of your server or container hardening, then even if exploitation is successful, the attacker is unlikely to be able to write files anywhere important. That means the risk of RCE goes down significantly.
If you have these things in place, you’re at a much lower risk of successful attack. Maybe that means you can plan your upgrade in a way that doesn’t make your dev teams work nights and weekends.
So in short, ask the following to figure out how risky these Struts vulns are for you:
- Do you have the affected versions of Struts anywhere in your stack?
- Are you using the vulnerable feature (FileUploadInterceptor)?
- Do you lack effective mitigations, such as server hardening/config management or request filtering rules?
If you need to address these CVEs, make sure you can track your remediation activities across the org, and hit your riskiest things first (exposed to the internet without auth is at the top of your list!).
The challenges of upgrading Apache Struts
Let’s assume at this point you’re impacted by these CVEs, and you need to get safe. As we talked about in Breaking Changes, Breaking Trust, this is easier said than done.
Scenario 1: Major upgrades
You might be on a really old version that won’t get patched by the maintainers. If you are still on the 2.x series of Apache Struts, we’re talking to you! Upgrading to a safe version (6.4 or later) is going to be a major version change that has breaking changes. As the Apache Struts Wiki puts it “This change isn't backward compatible as you must rewrite your actions to start using the new Action File Upload mechanism and related interceptor. Keep using the old File Upload mechanism keeps you vulnerable to this attack.”
This could take your developers months to untangle and it can be especially difficult to justify the developer time if you’re managing an application that is scheduled to sunset.
Scenario 2: Minor upgrades
Or maybe you’re on the 6.x series! Lucky for you, the effort of this upgrade might not be as great. Even then, we’ve found that minor upgrades risk client breaks 94% of the time. But we know how it sometimes goes with security upgrades: if you don’t have a pressing business reason to fix it now (e.g. FedRAMP compliance), then that upgrade might linger somewhere in the backlog. And again, you’re still at risk.
Patching Apache Struts with Endor Patches
It can be a pain to fix security issues, especially when it involves breaking changes. This is a great use case for Endor Patches, where we do the hard work so you don’t have to. If you have lingering RCE risks in Apache Struts series 6.x and 2.x, you can use an Endor Patch to remove all high and critical severity CVEs without having to upgrade. And because the only changes are those security fixes, you can be confident it won’t break your app. This lets you stay on older versions of Apache Struts until your engineering team is ready for the upgrade (or you sunset those apps).
Here’s how we created the patches:
- For each CVE, we found the corresponding fix created by the struts community within the open source code for 6.4
- We identified the changes between 6.4 and the earlier versions with the CVEs.
- We then backported those changes to create security patches for 6.3.0.2 and 2.5.33 to start, with other versions available on request.
- Upon identification of a backwards incompatible fix for the vulnerability, the team developed a localized fix so you don’t have to rewrite your file uploads to fix your known vulnerabilities
To validate our approach, we also submitted our fix to the open source maintainers of the Apache Struts project. They approved and accepted the changes to the code, although no new release will be cut since 2.3.x has officially reached end of life (EOL).
You could try rebuilding and testing 2.3.x yourself with our backported security patch included – or you can apply an Endor Patch to get safe now. We provide all build and test logs, as well as the fully built artifact, so you don’t have to do the work of building and testing the release yourself.
Read the whitepaper to learn more about Endor Patches and contact us to learn how we can help you fix risks faster.
