Another RCE vulnerability disrupts Java applications community

Print Friendly, PDF & Email

Yet another zero-day vulnerability involving remote code execution (RCE) is roiling the Java application community in the wake of the disclosure of a flaw in the widely employed Spring framework for building these applications.

Known as Spring4Shell, the vulnerability allows an attacker to remotely execute arbitrary code on the target server. It allows attacks to abuse a RequestMapping annotation that maps incoming HTTP requests into their appropriate handler functions. The vulnerable condition occurs when RequestMapping is used in conjunction with traditional Java objects as the handler parameter.

Such an attack might allow access to all website internal data, including any database. It might also allow access to additional internal resources to gain more permissions or to pivot to other parts of the internal network. The Java applications impacted employ versions 5.3.17 or 5.2.19 of the Spring framework and version 9 or higher of the Java Development Kit (JDK).

The disclosure of Spring4Shell vulnerability comes on the heels of the RCE exploit found in open source Log4j software known as Log4Shell that many organizations rely on to manage the logs created by a Java application. In the wake of the discovery of that vulnerability, it appears security researchers have increased their efforts to discover other RCE vulnerabilities within Java applications.

Shifting left to address vulnerabilities

No one can say for certain if there are more vulnerabilities like this, but cybersecurity teams would be well advised to prepare for the worst. In addition to modernizing incident management processes, many organizations have more aggressively embraced DevSecOps best practices that shift more responsibility for application security left toward developers. Developers, after all, are not only the ones who have to fix these vulnerabilities, they also usually have a better appreciation for which applications running where might be affected.

There is, of course, a lot of debate over just how far left to shift responsibility for application security. In theory, many developers are now being held responsible for managing the entire lifecycle of an application, including all security updates. The trouble is that most developers don’t have a lot of security expertise. A case is being made to instead embed various types of code analysis tools within the continuous integration/continuous delivery (CI/CD) platforms that many organizations now employ to manage application development. Rather than shifting completely left, the operations teams that support developers are in effect leaning further left in a way that doesn’t require developers to become security experts.

Regardless of approach, scrutiny of software supply chains has already increased in the wake of a series of high-profile breaches that led to the Biden administration issuing an executive order requiring more stringent practices. The real issue now will be to determine which legacy applications to keep despite the potential for more zero-day vulnerabilities being discovered versus replacing them with newer applications that are developed in a programming language that might be inherently more secure.

The trouble is the number of zero-day vulnerabilities being disclosed continues to steadily increase. Unfortunately, cybercriminals are paying a lot more attention to these disclosures than many of the organizations affected. In many cases, no one is tracking zero-day vulnerabilities at all. After all, the percentage of their applications that have been impacted by a zero-day vulnerability may be relatively small.

Scroll to top