Two Flaws in Splunk: Files Destroyed Without a Login, CVE-2026-20253 and CVE-2026-20251, Update Now

A "log platform" that gathers a company's every activity record for monitoring can have its server files destroyed by someone who never logged in, and be hijacked from an ordinary employee account──two serious flaws like this have been disclosed in Splunk, the go-to enterprise monitoring platform. They are CVE-2026-20253 (CVSS 9.8, Critical) and CVE-2026-20251 (CVSS 8.8, High).

Splunk is software for collecting the large volumes of logs (activity records) produced by servers and applications into one place to search, monitor, and analyze them. As the core of security monitoring (SIEM) for spotting intrusions early, it is used by many large enterprises in finance, telecom, and manufacturing, in Japan as well. Splunk was acquired by Cisco for about $28 billion in 2024, and the vendor on NVD is now listed as Cisco Systems.

The more severe of the two is CVE-2026-20253: an attacker with no credentials at all can create or truncate (wipe the contents of) files on the server through an internal helper database. The other, CVE-2026-20251, lets a user holding only an ordinary, low-privilege account run arbitrary code (take over the server) by abusing how data saved by a mobile-integration feature is restored. Fixes are available, and Splunk Enterprise must be updated to 10.2.4 or 10.0.7 or later. Review Splunk's security advisories and act now.

What Splunk Is, and Why It Sits at the Heart of the Enterprise

Splunk ingests the logs emitted by a company's servers, network gear, and applications, then searches, visualizes, and alerts on them. Because the record of "who did what, where, and when" all lands in one place, it becomes the foundation for incident investigation and security monitoring. In security use especially, it is often placed at the center of the security operations of large Japanese enterprises, serving as a "watchtower" that overlooks the whole organization.

What matters here is that the watchtower itself is the place every company secret passes through. Logs contain passwords and API keys that slipped into error output, exchanges with customers, and the audit records of who accessed which system. From an attacker's view, seizing the Splunk where all of that is concentrated, in one strike, is far more efficient than attacking each server one by one. And if the monitoring server is taken over, the attacker can also erase the traces of their own intrusion.

These two flaws open the door to that watchtower from two directions: one is a file operation reachable over the network without authentication (CVE-2026-20253), the other is a takeover from an ordinary-privilege account (CVE-2026-20251). The former can be triggered from a position near the perimeter, the latter by someone who has already stepped one foot inside — and for defenders, neither can be overlooked.

Where You Are at Risk, by Situation

"Two flaws in Splunk" means different things depending on which product you run and how. Let's separate them first.

Companies running Splunk Enterprise on their own servers must raise the version themselves. For Splunk Cloud Platform, the fix is applied by Splunk in stages, but you should confirm whether your tenant has reached a fixed version. In particular, environments that enable Splunk Secure Gateway, which connects to the "Splunk Mobile" smartphone app, take a direct hit from CVE-2026-20251.

When the Watchtower Is Taken, What Disappears from the Company

Splunk is the "watchtower" that single-handedly gathers every record left by the company's servers and apps. Let's look at the story of those keys being left open from the attacker's side. The target is not an abstract "hacker." It is the ransomware operator who has wormed into the internal network, the soon-to-leave former admin plotting to exfiltrate data, the industrial spy posing as a business partner, the disgruntled insider who holds only a regular employee account. What they want are the passwords and API keys that slipped into the logs, the exchanges with customers, and the audit records of who accessed what and when. The moment these two flaws are triggered, the watchtower's contents are read out, rewritten, and the traces of their own intrusion alone are wiped clean.

There are two entry points. CVE-2026-20253 is a hole where even a party holding no credentials can create and truncate files through the internal helper database (the PostgreSQL sidecar); tamper with config files or startup scripts and the monitoring platform itself becomes a foothold for attack. CVE-2026-20251 lets anyone with just an ordinary-privilege account hijack the server by abusing the restore process of the mobile-integration feature. The former is triggered from near the perimeter, the latter by someone one step inside.

What makes it frightening is that Splunk is the side that watches for attacks. If an ordinary server goes down, someone notices; but if the watcher is seized from within, the attacker can erase only the logs they find inconvenient, silence the alerts, and sit there as if nothing happened.

The number CVSS 9.8 is just a label for the maximum technical severity. What a security operations team truly loses is the evidence of intrusion being erased by the attacker's own hand, until even what was stolen can never be known. When the watchtower changes hands, the very means of knowing where the walls were breached goes with it.

Looking at the Two CVEs Individually, What Happens Where

In order of severity. These are two flaws of completely different nature.

CVE-2026-20253: Creating and Destroying Server Files Without Logging In (Missing Authentication)

CVE-2026-20253 (CVSS 9.8) is a flaw where the endpoint of the helper database service Splunk uses internally (the PostgreSQL sidecar) has no authentication (CWE-306, Missing Authentication for a Critical Function). Anyone who can reach it over the network, holding no login at all, can create arbitrary files on the server or truncate existing files to wipe their contents. Destroying or tampering with config files, certificates, or startup scripts leads directly to taking Splunk down or building a foothold for further intrusion. Because it succeeds with no authentication (PR:N), no user interaction (UI:N), and over the network (AV:N), all four metrics lean toward the worst, pushing the CVSS up to 9.8.

CVE-2026-20251: Hijacking the Server from a Low-Privilege Account (Unsafe Data Restore)

CVE-2026-20251 (CVSS 8.8) is a flaw where the mobile-integration feature Splunk Secure Gateway used an unsafe method when restoring KV Store data (such as settings) with the Python library jsonpickle (CWE-502, Deserialization of Untrusted Data). jsonpickle is known to risk running arbitrary code when turning saved data back into the original object, so planting crafted data causes the attacker's program to run at restore time. The troubling part is that even an ordinary-privilege user, neither admin nor a higher role, can execute it — granting server takeover to someone who merely holds one normal account inside the company. This is a textbook example of a "deserialization" attack that abuses the data-restore process.

Impact and Response Cheat Sheet

As of publication, neither CVE is listed in CISA KEV (the catalog of vulnerabilities confirmed exploited in the wild), and no actual exploitation has been reported. Still, the unauthenticated CVE-2026-20253 has a low technical barrier, the kind that gets hammered the moment exploit code circulates. Cases where serious holes in enterprise products see exploitation accelerate after disclosure keep recurring, so it is safer to update without waiting for exploitation reports.

Which Version Fixes It

Fixes are out. Updating to the versions below (or later) resolves the relevant flaws. Fixes are available across several major-version branches, so pick the one matching the branch you run.

For self-hosted Splunk Enterprise, moving to the latest 10.2.4 or the long-term branch 10.0.7 clears both flaws. If you are still on an older 9.x branch, CVE-2026-20251 is fixed in 9.4.12 / 9.3.13. Splunk Secure Gateway can also be updated on its own, so in environments where updating the core is hard right away, raising Secure Gateway to 3.10.6 or later first closes off the more severe takeover path. Check the current fixed versions in Splunk's advisory archive.

The Same Hole Opened Again — jsonpickle Returns

There is a sense of déjà vu with CVE-2026-20251. In Splunk Secure Gateway, arbitrary code execution from the very same unsafe jsonpickle restore process was already fixed in December 2024 (CVE-2024-53247, CVSS 8.8). This time, a flaw of the same product, same library, same attack class, and same severity has surfaced again via a different path.

jsonpickle is a convenient library for saving Python objects as JSON and restoring them later, but the danger of arbitrary code running when restoring untrusted data has long been pointed out. Even after one spot is fixed, if a similar save-and-restore process remains elsewhere in the product, the same kind of hole opens again. The lesson that "the process of restoring saved data becomes a takeover entry point the moment input is trusted" keeps reappearing across products. In environments not using Secure Gateway for business, disabling the app outright is also an effective defense.

What Administrators Should Do Now

In priority order. This is for organizations running Splunk.

1. Update Splunk Enterprise to a fixed version. If you run it on your own servers, moving to 10.2.4 or 10.0.7 or later clears both flaws. This is the main fix.

2. If you can't update right away, address Secure Gateway first. When updating the core takes time, raise Splunk Secure Gateway to 3.10.6 or later, or — in environments not using Splunk Mobile, Spacebridge, or Mission Control — disable the Secure Gateway app to close off the CVE-2026-20251 takeover path.

3. Check the reach of the PostgreSQL sidecar. CVE-2026-20253 can be triggered by an unauthenticated party reaching it over the network. Inspect your firewall and network segmentation to ensure Splunk's management ports and internal services are not reachable from a wider network than necessary.

4. Cloud users should confirm rollout status. Splunk Cloud Platform is updated by Splunk as a rule, but confirm whether your tenant has reached a fixed version via Splunk's security advisories and your support contact.

Timeline

In Summary: The Watchtower That Watches for Attacks Was Itself Targeted

What these two flaws lay bare is that Splunk, where all the company's logs converge, is both the linchpin of defense and the highest-value target for attackers. CVE-2026-20253, which can destroy files without authentication, and CVE-2026-20251, which can be taken over from low privilege, differ in nature, yet both serve as an entry point that "turns the monitoring server into a foothold for attack." Lose the watcher, and you lose the very means of knowing the full extent of the damage.

What to do is clear: update Splunk Enterprise to 10.2.4 or 10.0.7 or later; if that's not immediately possible, close off the takeover path first by updating or disabling Secure Gateway; and inspect the reach of internal services. That a jsonpickle takeover has resurfaced after two years shows you can't let your guard down even for a class of hole you fixed once. Act now, before exploitation reports arrive.

References

• ▸NVD - CVE-2026-20253 (missing auth on PostgreSQL sidecar, unauthenticated file ops)
• ▸NVD - CVE-2026-20251 (unsafe jsonpickle restore, RCE from low privilege)
• ▸Splunk Vulnerability Disclosure (official security advisories)
• ▸Splunk Security Advisories Archive
• ▸Splunk - SVD-2024-1205 (the 2024 jsonpickle RCE, CVE-2024-53247)
• ▸jsonpickle - security discussion on restoring untrusted data (Issue #335)
• ▸CWE-306 - Missing Authentication for Critical Function
• ▸CWE-502 - Deserialization of Untrusted Data
• ▸Cisco - completion of the Splunk acquisition (March 2024)
• ▸CISA KEV Catalog