In this feature, we answer questions from our GraphDB users. Today's question is about the Log4j vulnerability for different versions of GraphDB.
A zero-day vulnerability is one of the most stressful situations for any operations team, especially when dealing with a vulnerability with the highest severity remote code execution (RCE). The situation is much worse if the vulnerable library (in this case Spring) is in widespread use in thousands of applications.
This is exactly what happened at the end of last week with the announced CVE-2022-22965, also known as Spring4Shell or SpringShell. The vulnerability exposes the class object when binding the parameters in certain types of requests. A public PoC exploit demonstrated RCE using the exposed class loader to modify the Tomcat log configuration and upload a JSP web shell.
The full extent of the vulnerability is still under revision. From what we know so far, the attacker can exploit it if all of these are met:
GraphDB uses the Spring framework extensively. In GraphDB 9.9.x, 9.10.x and 9.11.0 the Spring framework is v5.2.15 and as such will be reported as vulnerable by a blind scan that just checks for the existence of certain versions of specific libraries.
We analyzed the vulnerability carefully and we concluded GraphDB is not vulnerable due to several independent reasons:
Since the nature of the vulnerability is more general, and there may be other ways to exploit it, we decided to immediately release GraphDB 9.11.1 with security patches, including two library version upgrades that both address CVE-2022-22965: