Splunk patched a critical bug that lets an unauthenticated, network-reachable attacker pull off remote code execution. The root cause is that Splunk Enterprise's PostgreSQL sidecar service endpoint lacks authentication controls, so any network-reachable user can invoke file operations without credentials.

How the attack works

Per watchTowr Labs, who published technical details, the attacker abuses the /backup and /restore Postgres recovery endpoints:

  1. Connect to an attacker-controlled database, dump it to a file via /backup.
  2. Restore that malicious dump into the local Postgres instance via /restore — using a passfile argument pointing at Splunk's .pgpass file to authenticate as the postgres_admin user.
  3. The malicious SQL in the dump executes, yielding an arbitrary file write.
  4. Escalate to RCE by overwriting a Python script that Splunk runs regularly.

What's affected

VersionStatus
Splunk Enterprise 10.0.0–10.0.6Fixed in 10.0.7
Splunk Enterprise 10.2.0–10.2.3Fixed in 10.2.4
Splunk Enterprise 10.4Not affected
Splunk CloudNot impacted (no Postgres sidecars)

Bottom line

No evidence of exploitation in the wild yet, but with the exploit details now public, opportunistic attacks are likely, so patch quickly.