This particular vulnerability exists because on unix-like systems (not including MacOS) the system temporary directory is shared between all users.
As such, failure to correctly set file permissions and/or verify exclusive creation of directories can lead to either local information disclosure, or local file hijacking by another user.
 
In the worse case scenario, this can lead to a local privilege escalation vulnerability.

An attacker can create these directories before the java process creates them, but with wider user permissions. Since these directory names are not in any way random, the attacker can simply create these directories ahead of Keycloak. When this happens, the java process doesn't complain that the directories already exist, `mkdir` and `mkdirs` simply return false.

However, assuming that the java process is the first thing to create these directories, `mkdir` and `mkdirs` will only set the directory following the default umask (I believe); by default that means that these directories are created with the permissions `drwxr-xr-x`.
Thus allowing a malicious local user to read the contents of this temporary directory.
 
The safest protections are to switch to the `Files` API that allow you to exclusively set the file permissions when creating the directories. Or use the `Files` API's for creating temporary directories.

https://issues.redhat.com/browse/KEYCLOAK-17000