JFrog Finds RCE Issue in Apache Cassandra – InApps Technology 2025

It’s always something when it comes to security. This time around the JFrog’s Security Research team has found a remote code execution (RCE) issue in Apache Cassandra, the popular open source NoSQL database. And, oh joy, of course with this RCE, you can stop Cassandra in its tracks. Since companies such as Netflix, Twitter, Reddit, and hundreds of others rely on Cassandra to be running every moment of the day, this is not good news.

The good news is that default Cassandra isn’t vulnerable to this assault. The bad news is that with these perfectly reasonable Cassandra options in the cassandra.yaml configuration file:

enable_user_defined_functions: true

enable_scripted_user_defined_functions: true

enable_user_defined_functions_threads: false

Your system is open to attack.

How Bad Is It?

So how bad is the Cassandra CVE-2021-44521 vulnerability? Try a Common Vulnerability Scoring System (CVSS) 8.4 level of bad. For those of you playing at home, that’s high, which is another way of saying really bad. It would be all too easy to pop this security crack open.

It works by abusing Cassandra’s Nashorn engine in the Java Runtime Environment (JRE) which is a JavaScript engine that runs on top of the Java Virtual Machine (JVM). Usually, you can’t do anything by attacking Nashorn because it works inside a sandbox. A successful attack, however, can break a hacker out of the sandbox and let them run an RCE.

The most obnoxious of these is to get a user-defined function (UDF) to run more than it allotted time. Then, the entire Cassandra daemon will shut down, not just the UDF’s thread. Then you can knock out the entire database by creating a function that loops forever with a simple while(true) loop.

True, to do this the attacker would need to have enough permissions to create UDF in the first place to be able to exploit this. But, under the above settings, all users — I repeat all users — are allowed to create and execute arbitrary UDFs. Oh, and did I mention all users mean anonymous logins are enabled by default too? So, yes even an anonymous user could be used to make a successful assault. There’s a reason why this has such a high CVSS score.

What Can You Do?

So, what can you do about it? Fortunately, a lot.

First, you can mitigate the issue If UDFs are not actively used by being completely disabled by setting enable_user_defined_functions to false, which is the default value. If you must have UDFs you can set enable_user_defined_functions_threads to true. This is again the default value. Finally, you can–and should–remove the permissions of creating, altering, and executing functions for untrusted users by removing the following permissions: ALL FUNCTIONS, ALL FUNCTIONS IN KEYSPACE, and FUNCTION for CREATE, ALTER, and EXECUTE queries. I highly recommend you do this last one. Allowing untrusted users to do anything requiring trust is, by its very nature, a stupid idea.

And, of course, you should upgrade your Cassandra software to one of the following versions, which resolves CVE-2021-44521:

3.0.x users should upgrade to 3.0.26

3.11.x users should upgrade to 3.11.12

4.0.x users should upgrade to 4.0.2

That done, you can relax and get back to work. But, first, patch your Cassandra software. The potential for disaster here is too high to put this fix off until tomorrow.

InApps Technology is a wholly owned subsidiary of Insight Partners, an investor in the following companies mentioned in this article: JFrog.