A newly disclosed, high-severity vulnerability in Splunk for Windows lets local users escalate privileges due to misconfigured file permissions installed on the system. The flaw affects both Splunk Enterprise and Universal Forwarder, creating an avenue for attackers to overwrite sensitive files and gain elevated access to the host.
In Splunk’s advisory, the Enterprise issue is described as allowing non-administrator users on the machine to access the directory and all of its contents. The root cause lies in permission configurations applied by Splunk’s Windows installer during fresh installations and version upgrades.
Where the problem lives
The vulnerabilities, tracked as CVE-2025-20386 (affecting Splunk Enterprise) and CVE-2025-20387 (affecting Splunk Universal Forwarder), stem from overly permissive NTFS settings that the installer may apply to Splunk’s default installation directories. This means non-admin users could gain read and write access to files that should be protected.
These directories house critical components, including:
- Executable binaries that Splunk services load at startup
- Configuration files that govern indexing, forwarding, and authentication behavior
- PowerShell, Python, and batch scripts invoked by Splunk’s service processes
- Modular inputs and technology add-ons capable of running code with elevated privileges
With write access to these assets, an authenticated but low-privilege user could:
- Replace Splunk binaries (for example, swapping in a malicious trojan or backdoored executable)
- Alter important configuration files to enable attacker-controlled code or change service behavior
- Inject rogue startup scripts that execute under the privileged Splunk service account
- Hijack DLLs or supporting executables in the installation directory to achieve persistence at the system level
- Escalate from a standard user to NT AUTHORITY\SYSTEM by abusing the elevated permissions of Splunk’s service account
Because Splunk services typically run with LocalSystem rights, loading any malicious file would lead to immediate privilege escalation and a full compromise of the host.
Severity and practical risk
These flaws were given a CVSS score of 8.0, reflecting the potential for complete loss of confidentiality, integrity, and availability. While exploitation technically requires an authenticated user, many enterprise environments grant broad internal access, which can lower the practical barrier to exploitation in real-world deployments.
Key hardening steps for Splunk deployments
To reduce the risk of privilege escalation via misconfigured permissions, consider these protective measures:
- Apply the latest fixed versions of Splunk Enterprise and Universal Forwarder as soon as possible.
- Tighten NTFS permissions on Splunk directories so that only administrators can modify binaries, configurations, and scripts.
- Implement application allow-listing to block unauthorized executables from running inside Splunk directories.
- Run Splunk services under least-privilege accounts and restrict interactive logons on Splunk servers.
- Use endpoint detection and response (EDR) and file-integrity monitoring to detect unauthorized changes or suspicious child processes in Splunk paths.
- Regularly validate configuration integrity across all deployments, including directory permissions, apps, and forwarder settings.
- Segment the Splunk environment and monitor for lateral movement or privilege-escalation attempts originating from Splunk systems.
Adopting these controls helps minimize the risk of privilege escalation within Splunk’s Windows components and limits the potential impact of any breach.
Editor’s note: The original report first appeared on our sister publication, eSecurityPlanet.com.
