If you’re running an Apache Cassandra database and want to use user-defined functions (UDFs), you might be exposing yourself to a serious risk—even without realizing it. The vulnerability CVE-2021-44521 centers around allowing attackers with the right permissions to execute arbitrary code on the Cassandra machine by taking advantage of a specific configuration setup. In this post, we’ll break down what this vulnerability is, how it works, and what you should do about it. Let's keep things straightforward.

What is CVE-2021-44521?

CVE-2021-44521 is a security flaw in Apache Cassandra affecting configurations where UDFs (functions written by users to process data stored in Cassandra) are enabled in a particular unsafe way. When these settings are in place:

enable_user_defined_functions: true
enable_scripted_user_defined_functions: true
enable_user_defined_functions_threads: false

…the normal safety mechanisms are turned off, and any user with the right database permissions can run Java code on the Cassandra server. This could easily let an attacker take over your machine.

Cassandra's documentation itself warns that this is unsafe, and even after the discovery of this vulnerability, this mode is still considered dangerous.

Why Does This Happen?

Cassandra lets users create UDFs to run custom logic against stored data. Normally, these functions are sandboxed (isolated) with separate threads to keep them under control and restrict what they can do. That’s the job of enable_user_defined_functions_threads.

If enable_user_defined_functions_threads is set to false, Cassandra runs these functions on the same threads as everything else, dropping key protections. Combined with allowing scripted functions (enable_scripted_user_defined_functions: true), this means that the code inside UDFs can do *much more* than expected—including running system commands, reading files, making network connections, etc.

There's no exploit required other than creating a UDF with malicious code as long as an attacker can create UDFs.

Get Database Access:

The attacker needs permission to create user-defined functions. This usually means they need login credentials with that ability. By default, not everyone has it.

Create a Malicious UDF:

The attacker writes a Java UDF containing dangerous code—for example, Runtime.getRuntime().exec() to run system commands.

Real Exploit Example

Suppose an attacker gains the necessary database permissions. They could inject a UDF that starts a shell or downloads malware. Here’s how this might look in CQL (Cassandra Query Language):

Example: Creating a Dangerous UDF

CREATE OR REPLACE FUNCTION exploit()
  CALLED ON NULL INPUT
  RETURNS text
  LANGUAGE java AS '
    java.lang.Runtime.getRuntime().exec("touch /tmp/exploit_was_here");
    return "Hacked!";
  ';

This code will create a file /tmp/exploit_was_here on your server, marking it as compromised.

References

- Official Cassandra CVE Note
- Detailed Security Advisory - GitHub
- Apache Cassandra Documentation: UDF Security
- Exploit-DB Reference *(Similar exploits)*

enable_user_defined_functions_threads: false

and allowing potentially untrusted users to create UDFs.

How Can You Stay Safe?

- Never run with enable_user_defined_functions_threads: false in production, even inside a firewall.
- Review all user roles and permissions—*do not* let regular users create UDFs unless you are certain they are trusted.

Bottom Line

With the wrong Cassandra configuration, anyone with enough database permissions can take full control of your server—no need for fancy hacks. UDFs are powerful but dangerous if not sandboxed. Always double-check your cassandra.yaml and role permissions.

If you use Cassandra, review your settings today.

Stay secure! If you want to deep dive further, check the links above or watch for updates on Cassandra’s official announcements.


*This post is exclusive and written in simple language for easy risk awareness.*

Timeline

Published on: 02/11/2022 13:15:00 UTC
Last modified on: 08/09/2022 00:39:00 UTC