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.

Included because

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

Affected estate

Splunk Enterprise below 10.2.4 (10.2.x branch) or below 10.0.7 (10.0.x branch). Splunk Cloud Platform 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.

Action

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

Urgency

Patch immediately

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.

Included because

CVSS 7.8; extremely common embedded library; memory corruption class

Affected estate

Any system running SQLite before 3.53.2 with FTS5 enabled. Azure Linux 3.0 ships sqlite 3.44.0-3, which is vulnerable.

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%';`.

Action

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

Urgency

Patch this week

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.

Included because

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

Affected estate

Migration-planner deployments that process RVTools .xlsx uploads, particularly those running in Kubernetes or OpenShift environments with service account tokens on disk.

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.

Action

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

Urgency

Patch immediately

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.

Included because

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

Affected estate

Any Python environment with Dulwich >= 0.10.0 and < 1.2.5 installed, especially on Windows. Also relevant for POSIX systems that clone and re-publish repos consumed on Windows.

How to check

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

Action

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

Urgency

Patch within 24 hours

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