Splunk's 9.8 file-write bug steals the show, plus SQL injection via spreadsheet

An unauthenticated attacker who can reach the Splunk PostgreSQL sidecar service endpoint can create or truncate arbitrary files on the Splunk server. No credentials needed, no user interaction. A CVSS 9.8 means this is about as bad as it gets: think data destruction, config tampering, or chaining file writes into code execution.

Affected estate

Splunk Enterprise operators running versions below 10.2.4 or 10.0.7, and Splunk Cloud Platform users on versions below 10.4.2604.3 or 10.2.2510.14

How to check

In Splunk Web, go to Settings > About or run `splunk version` on the CLI. Check whether the PostgreSQL sidecar service port is network-reachable from untrusted hosts.

Included because

unauthenticated; network-reachable; CVSS 9.8; arbitrary file write; common enterprise product

Action

Upgrade Splunk Enterprise to 10.2.4 or 10.0.7. For Splunk Cloud, verify the patched version with Splunk support.

Why it matters

Unauthenticated arbitrary file creation and truncation can destroy indexes, corrupt configs, or chain into full system compromise.

Source

Splunk advisory

A memory corruption bug in SQLite's FTS5 (full-text search) extension can be triggered by crafted database content. Exploitation typically requires an attacker to feed a malicious database file or query to an application using FTS5, so the risk depends heavily on whether your apps accept untrusted SQLite databases. CVSS 7.8 reflects local exploitation with potential code execution.

Affected estate

Anyone running applications that use SQLite's FTS5 extension, especially on Azure Linux 3.0 with sqlite 3.44.0-3 or earlier

How to check

Run `sqlite3 --version` on the host. Check if FTS5 is compiled in by running `SELECT * FROM pragma_compile_options WHERE compile_options LIKE '%FTS5%';`.

Included because

CVSS 7.8; extremely common embedded library; memory corruption class

Action

Update the sqlite package to 3.53.2 or later via your package manager.

Why it matters

Memory corruption in SQLite can affect any application that processes untrusted database files, potentially leading to code execution.

Source

SQLite advisory

An authenticated attacker can upload a crafted RVTools .xlsx spreadsheet to the migration-planner tool, and malicious SQL embedded in cell values gets executed when cluster names are processed. That's SQL injection via spreadsheet import, and it lets the attacker read arbitrary files on the server, including Kubernetes service account tokens. At CVSS 9.6, a successful exploit can lead to full compromise of the SaaS environment.

Affected estate

Teams running Red Hat migration-planner that accept RVTools .xlsx uploads, especially in OpenShift or Kubernetes-backed SaaS environments

How to check

Confirm whether migration-planner is deployed in your environment and whether the RVTools upload endpoint is exposed. Review recent .xlsx uploads for unusual cell content in cluster name fields.

Included because

authenticated but low-complexity; CVSS 9.6; SQL injection; credential exposure; cloud/SaaS impact

Action

Apply the vendor patch for migration-planner. If no patch is available yet, disable or restrict the RVTools upload endpoint.

Why it matters

SQL injection through spreadsheet import can expose Kubernetes tokens and credentials, leading to full environment compromise.

Source

Red Hat advisory

Cloning or checking out a malicious Git repository using Dulwich on Windows lets an attacker write arbitrary files, which chains into remote code execution. The bug exists because Dulwich accepted filenames containing bytes that Windows treats as path separators, and the safety settings (core.protectNTFS, core.protectHFS) were silently ignored due to a config lookup bug. POSIX systems aren't directly exploitable, but they can unknowingly relay a poisoned repo to Windows users.

Affected estate

Anyone using Dulwich 0.10.0 through 1.2.4 on Windows, or anyone whose CI/CD pipelines or tools use Dulwich to clone untrusted repos. POSIX users who push repos consumed by Windows clients should also upgrade.

How to check

Run `pip show dulwich` to check the installed version. Any version from 0.10.0 to 1.2.4 is vulnerable.

Included because

CVSS 8.8; arbitrary file write to RCE; no workaround; safety bypass; affects untrusted repo clones

Action

Run `pip install --upgrade dulwich>=1.2.5` on all affected systems.

Why it matters

Arbitrary file write on clone leads directly to remote code execution on Windows, and the intended safety config was broken, so no workaround exists.

Source

Dulwich GitHub advisory