CVE-2024-51127 Overview
CVE-2024-51127 affects the createTempFile method in Red Hat HornetQ version 2.4.9. The flaw enables local attackers to overwrite arbitrary files or read sensitive information through insecure temporary file handling. The vulnerability maps to [CWE-22] (Path Traversal) and the broader category of insecure temporary file creation [CWE-378].
Exploitation requires local access with low privileges and no user interaction. Successful attacks impact both confidentiality and integrity of files accessible to the HornetQ process. The issue is documented in a public GitHub advisory.
Critical Impact
Local attackers can overwrite arbitrary files or access sensitive data handled by HornetQ through predictable temporary file behavior.
Affected Products
- Red Hat HornetQ v2.4.9
- Applications embedding HornetQ messaging libraries
- Systems exposing HornetQ to multi-user local environments
Discovery Timeline
- 2024-11-04 - CVE-2024-51127 published to NVD
- 2024-11-21 - Last updated in NVD database
Technical Details for CVE-2024-51127
Vulnerability Analysis
The vulnerability resides in the createTempFile method within HornetQ v2.4.9. The method generates temporary files in a manner that does not adequately protect them against local actors. An attacker with local access to the host can predict, race, or symlink the resulting paths to influence file operations performed by HornetQ.
The issue falls under [CWE-22] Path Traversal and aligns with [CWE-378] Creation of Temporary File With Insecure Permissions. Both weakness classes allow attackers to redirect file operations outside intended directories or to access files belonging to other users on the same system.
Exploitation results in arbitrary file overwrite or disclosure of sensitive information processed by the HornetQ instance. The integrity and confidentiality of the host file system are at risk when HornetQ runs with elevated privileges.
Root Cause
The createTempFile implementation does not enforce safe directory selection, restrictive permissions, or atomic creation semantics. Temporary files inherit permissive defaults, and the file path may be guessable or modifiable by other local users. This combination enables symlink attacks and unauthorized reads of intermediate data.
Attack Vector
An attacker requires an authenticated local shell on the host running HornetQ. The attacker plants a symbolic link or predicts the temporary file name before HornetQ writes to it. When HornetQ invokes createTempFile, the write redirects to an attacker-chosen target, or the attacker reads data the service places in a world-readable location.
The vulnerability does not require network access, and no user interaction is needed. The attack succeeds when the attacker and HornetQ share access to the same temporary directory.
No public proof-of-concept exploit is available at the time of publication. Technical details are described in the GitHub advisory for CVE-2024-51127.
Detection Methods for CVE-2024-51127
Indicators of Compromise
- Unexpected symbolic links inside /tmp or the configured Java temporary directory pointing to sensitive paths such as /etc/passwd or HornetQ configuration files
- Temporary files created by the HornetQ process with world-readable or world-writable permissions
- File modification events on system files whose write timestamps correlate with HornetQ activity
Detection Strategies
- Audit HornetQ runtime directories for predictable temporary file names produced by createTempFile
- Enable Linux auditd rules to log open, creat, and symlink syscalls executed by the HornetQ JVM process
- Review application logs for messaging operations that coincide with file system anomalies in shared temporary directories
Monitoring Recommendations
- Forward file integrity monitoring events for /tmp, /var/tmp, and java.io.tmpdir paths to a central log platform
- Alert on symbolic link creations in temporary directories by non-HornetQ user accounts
- Track HornetQ process file descriptors for writes outside expected data and log directories
How to Mitigate CVE-2024-51127
Immediate Actions Required
- Inventory all systems running HornetQ v2.4.9 and identify dependent applications
- Restrict local shell access on hosts running HornetQ to trusted administrators only
- Set a dedicated, non-shared temporary directory for the HornetQ JVM with strict permissions
Patch Information
No vendor patch is currently referenced for HornetQ v2.4.9 in the published advisory. HornetQ has been largely superseded by Apache ActiveMQ Artemis. Organizations should evaluate migration to a supported messaging broker. Consult the HornetQ project site and the CVE-2024-51127 advisory for status updates.
Workarounds
- Configure java.io.tmpdir to a directory owned by the HornetQ service account with 0700 permissions
- Apply mandatory access controls such as SELinux or AppArmor profiles that confine HornetQ file writes to approved paths
- Run HornetQ under a dedicated low-privileged user account to limit the impact of arbitrary file overwrite
# Configuration example: harden the HornetQ temporary directory
sudo mkdir -p /var/lib/hornetq/tmp
sudo chown hornetq:hornetq /var/lib/hornetq/tmp
sudo chmod 0700 /var/lib/hornetq/tmp
# Pass the hardened directory to the JVM at startup
export JAVA_OPTS="${JAVA_OPTS} -Djava.io.tmpdir=/var/lib/hornetq/tmp"
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.


