Splunk Release Notes

What's new in 10.4

Splunk Enterprise 10.4 was released on May 18, 2026.

If you are new to Splunk Enterprise, read the Splunk Enterprise Overview.

For system requirements information, see the Installation Manual.

Before proceeding, review the Known issues for this release.

Planning to upgrade from an earlier version?

If you plan to upgrade to this version from an earlier version of Splunk Enterprise, read How to upgrade Splunk Enterprise in the Installation Manual for information you need to know before you upgrade.

See About upgrading: READ THIS FIRST for specific migration tips and information that might affect you when you upgrade.

The Deprecated and removed features topic lists computing platforms, browsers, and features for which Splunk has deprecated or removed support in this release.

• Index-based Search Targeting

Index-Based Search Targeting is a new enhancement for Federated Search in transparent mode. This feature allows administrators to route search requests directly to specific providers based on index-to-host mappings, providing you with greater control over your search environment. Index-based search targeting provides the following key benefits:

• Enhanced Security: By restricting searches to specific hosts, you minimize the exposure of sensitive information and ensure that query logs are only accessible where necessary.
• Optimized Performance: Reduce system overhead and improve search speeds by eliminating unnecessary requests, which allows your infrastructure to focus resources only on relevant search providers.

This update ensures a more secure, streamlined, and efficient search experience across Federated Search for Splunk environments.

Administrators can now use the following new REST endpoint arguments to configure index-based provider selection for Federated Search for Splunk by specifying which indexes federated search heads can access from federated providers when operating in transparent mode:

• The data/federated/settings/general endpoint: The allowIndexBasedProviderFiltering argument enables index-based filtering for federated providers.
• The data/federated/provider/{federated_provider_name} endpoint: The fedSrchIndexesAllowed argument specifies the indexes that are accessible from each federated provider.

See Federated search endpoint descriptions in the REST API Reference.

• Improvements to Edge Processor pipeline previews and updated SPL2 support

The Edge Processor service has been upgraded to improve the accuracy of pipeline previews, allowing full support for additional SPL2 commands such as decrypt and ocsf. For information about the SPL2 commands and functions that are supported in this release, see Edge Processor pipeline syntax in the Use Edge Processors for Splunk Enterprise manual.

• Custom pipeline templates for Edge Processors

You can now create and use custom pipeline templates that are provided through SPL2-based apps. If an app that contains templates is installed on Splunk Enterprise, those templates become available on the Pipelines page and during the pipeline creation workflow. See Create custom pipeline templates in the Splunk Developer Guide for information on creating a template and including it in an app. See Use templates to create pipelines for Edge Processors in the Use Edge Processors for Splunk Enterprise manual for information on creating a pipeline by using a template as a starting point.

• Support for running Edge Processor in Federal Information Processing Standards (FIPS)-compliant mode.

Edge Processor now supports running with FIPS-compliance enabled, which is required in order to work within FedRAMP Moderate environments. This update lets government agencies and organizations with strict regulatory requirements leverage Edge Processor while maintaining compliance with federal security standards. See Set up an Edge Processor for more information.

• Edge Processors on Splunk Enterprise can successfully reconnect to the control plane after an extended disconnect

The Edge Processor service has been upgraded to automatic reconnection to the control plane after an extended disconnection period. For information about how to upgrade existing Edge Processors to automatically reconnect, see Upgrade Edge Processor to automatically reconnect in the Use Edge Processors for Splunk Enterprise manual.

• Additional match types and configuration options in the lookup command for Edge Processor pipelines

You can now configure lookups that use CIDR matching and wildcard matching. You can also optionally configure lookup matches to be case-sensitive, or require a minimum or maximum number of matches to be returned in the output. To specify these new configurations, you must manually enter the corresponding command arguments in the pipeline editor. For information about the supported syntax for the lookup command, see lookup command: Overview, syntax, and usage in the SPL2 Search Reference.

• Apply custom command function action for Edge Processor pipelines

To process the incoming data before sending it to a destination, you can now discover, select, and apply custom command functions, which are user-defined SPL2 functions. This is particularly helpful for customers with less experience using SPL2. See Create and apply a custom command function for the Edge Processor solution in the Use Edge Processors for Splunk Enterprise manual for more information.

• Additional new Dashboard Studio features

This release adds various new features for Dashboard Studio, including the following:

• Token Manager UI to view all tokens in a dashboard. See Token manager.

• New network graph visualization to visualize entities and the relationships between them. See Network graph.

• Accelerated render option for line charts with improved performance and responsiveness. See Accelerated render line chart example.

• Dashboards resource management

Running auto-refresh searches when viewing dashboards now requires the new auto_refresh_dashboards capability, which Splunk admins can choose to grant to user roles. Admins can also deactivate dashboards as needed. See Manage dashboard resource consumption.

Note: This is a change in default behavior. In earlier Splunk versions, all users could run auto-refresh searches. After upgrade to 10.4, only the admin and sc_admin roles have the auto_refresh_dashboards capability by default. Users with the admin and sc_admin roles will need to assign the capability to other user roles.

• New Dashboard Studio custom visualizations framework

Dashboard Studio supports custom visualizations built using the new custom dashboard extension framework for Dashboard Studio, which offers increased flexibility, simplicity, and performance. With the new framework, you can leverage modern libraries compared to the old custom visualizations framework for simple XML dashboards. See Custom visualizations for Dashboard Studio.

• Cisco One Look & Feel - Modern Navigation Adoption (GA)

Modern Navigation shifts the traditional top navigation bar to a sleek, side navigation panel complemented by an updated header. Designed to deliver a consistent, accessible experience, Modern Navigation is a part of our overall vision of a cohesive look and feel across Splunk and Cisco products. See Modern navigation UI changes.

• Bulk Data Move - support for CLI and SmartStore

You can now perform bulk data moves between SmartStore-backed indexers. Additionally, the Bulk Data Move toolset is now accessible through the Splunk CLI on the Cluster Manager, offering a command-line alternative to the existing REST API for automation and troubleshooting. See Bulk Data Move for indexer clusters in the Manage indexers and indexer clusters manual.

• Splunk topology API

Using the Topology REST API, admins and applications gain programmatic access to deployment topology and infrastructure introspection data through a unified interface. The endpoints retrieve information using the Splunk Topology sidecar.

The Splunk Topology API provides administrators with an automated, authoritative source for deployment and infrastructure data, streamlines complex workflows like app installations and release upgrades, and eliminates the need for manual input. See Topology endpoint descriptions in the REST API Reference manual.

• HTTP/2 support for Splunk Web UI

Splunk Web now supports the HTTP/2 protocol, which uses multiplexed communication to handle browsing activity in parallel. This significantly improves performance for complex dashboards, simultaneous searches, and multi-tab browsing compared to the sequential processing of HTTP/1.1.

HTTP/2 is supported on Linux and macOS environments.

HTTP/2 is deactivated by default and requires activation. See Activate HTTP/2 to enhance Splunk Web performance in the Admin manual.

• SHA-1 Certificate Support Removed

As of Splunk platform 10, SHA-1 certificates are no longer supported. Customers will need to apply new certificates not using this standard. The Splunk Cloud Monitoring Console and Splunk Enterprise Monitoring Console have previously been updated to report on SHA-1 related warnings and errors raised by the Splunk platform, and customers can continue to use these tools to navigate the change.

• App context for Federated Search for Splunk in standard mode

The new update for the app context for Federated Search for Splunk in standard mode introduces a more flexible approach to managing application contexts that gives users a more intuitive experience and simplifies how search contexts are handled. This update allows the federated provider to align with the application context of the search performed on the local federated search head; by default, Splunk platform on standard mode federated providers reflects the context of the user's local search environment.

This update includes a new useAppContextFromSearch parameter for the Splunk REST API {{data/federated/provider/{federated_provider_name}}} endpoint. For more information about this new parameter, see "Federated search endpoint descriptions" in the REST API Reference.

• New flag for disabling Splunk Web's Custom REST Endpoints and Custom Mako Templates.

Two new flags have been added to the [feature:appserver_security] stanza of web-features.conf that admins can use to disable the following Splunk Web features:

1. Custom REST Endpoints on the Splunk Web (not Splunk Core) platform can be disabled by setting disable_custom_cherrypy_controllers to true (default: false).
2. Custom Mako Templates shipped by apps (not default templates shipped with Splunk Web) can be disabled by setting disable_custom_mako_templates to true (default: false).

While the behavior does not change in Splunk platform 10.4, this flag has been added to support a future deprecation effort for both of the above features.

• Modernize Field administration pages

Splunk field administration pages will update to the latest UI components and libraries, providing a modernized and consistent look and feel with the Splunk platform.

• Agent management

Application matching cache

Agent management caches the results of application-to-server-class matching, which reduces the processing time required when agents check in for deployment updates. In large-scale environments with many agents and server classes, this cache improves the performance of the agent management.

Server class configuration viewer

You can view the full configuration details of a server class directly in the agent management interface. You can use this view to verify server class configurations before making changes or to troubleshoot unexpected deployment behavior across your fleet of agents.

Application content previewer

You can preview the contents of a deployment application before distributing it to agents directly in the agent management interface. Use the content previewer to verify that an application contains the expected files and settings, which helps you identify configuration issues before deployment reaches your agents.

Removed parameters from serverclass.conf

The following parameters are removed from the serverclass.conf configuration file in version 10.4: packageTypesFilter, updaterRunningFilter.

• Data Management

The new Data Management app now serves as a hub to relevant experiences with a consistent look and feel. Whether you are configuring inputs, monitoring ingestion health, or managing federated connections or datasets, you can now do it all from one location.

• Independent client-side Transport Layer Security (TLS) certificate configuration for App Key Value Store (KV Store)

In response to public CA policy changes that drop the Client Authentication EKU from default TLS certificates, Splunk now supports independent KV Store client-side TLS configuration through a new [kvstoreSslClientConfig] stanza, allowing separate client and server certificates for KV Store mutual TLS.

Available in Splunk Enterprise 10.4 and applicable for Splunk Enterprise 9.4.10, 10.0.5, and 10.2.2, and Splunk Cloud 10.2.2510.8 and 10.0.2503.13

In 10.4 only: [kvstore] SSL settings are now evaluated per field; partial configurations previously ignored may now apply and should be reviewed before upgrade.

• Deprecating and removing default support for versions 1.0 and 1.1 of the TLS protocol for network connections between Splunk platform components

The Splunk platform is now turning off support by default for TLS 1.0 and TLS 1.1. These protocols remain available should customers require them for migration purposes, but will be completely removed in a future release. TLS 1.2 support remains unchanged and enabled by default alongside the newly-introduced TLS 1.3 support.

• Upgrade Splunk Python version from 3.9 to 3.13

Python 3.13 will become the default Python interpreter, with Py3.9 as fallback.

• Federated Search for Splunk Transparent Mode Support for IPv6 in Search Head Clusters

Federated Search for Splunk in transparent mode now supports bundle replication to any remote peer within a search head cluster, eliminating the need for direct network access to the remote search head captain. This enhancement enables support for IPv6 environments, such as Microsoft Azure, and configurations where a load balancer serves as the remote gateway.

• Role-based Access for Federated Search for Splunk REST APIs

Enhanced security controls are now available for Federated Search for Splunk REST API endpoints, introducing granular, role-based access control (RBAC). Previously, authenticated users could view all federated providers, indexes, and settings. This update shifts access logic to the handler level, ensuring that users only see the resources they are explicitly authorized to access.

Administrators can now enforce precise permissions for individual users, preventing unauthorized information disclosure and ensuring that sensitive infrastructure details remain protected. New specific capabilities have been introduced to manage these permissions effectively, replacing the need for broad, global access. These changes strengthen your security posture and support stricter internal governance, providing a more secure and compliant environment for your Federated Search operations.

The following new capabilities for Federated Search for Splunk are now available in this release:

• edit_federated_indexes
• edit_federated_providers
• list_federated_providers

For more information, see the Table of Splunk Enterprise capabilities in Securing the Splunk Platform.

• Indexing/Replication Separation

Introduces a new SmartStore-based architecture for Splunk Enterprise indexer clusters that decouples indexing from peer-to-peer replication. Instead of replicating buckets directly between indexers, data and metadata are stored in SmartStore as the system of record, allowing indexers to operate independently.

By removing peer-to-peer replication dependencies, this approach simplifies multisite deployments, improves operational resilience, and enables more flexible scaling of indexers.

• Upgrading the backend database for KV Store and KV Service to MongoDB 8.0

Splunk 10.4 release will not include old unsupported MongoDB versions from 4 to 6. If you’re running Splunk 9.x and below, please upgrade to Splunk 10.0 or Splunk 10.2 first as a direct update from MongoDB 4.x / Mongo 6.x to Mongo 8 is unsupported. If you’re on Splunk 10.x, no action is needed as the upgrade to MongoDB 8 will happen automatically with the Splunk upgrade.

• Run Splunk Enterprise without root or administrator privileges

Splunk Enterprise 10.4 enforces non-privileged execution across supported operating systems.

Linux: Running Splunk Enterprise as root is no longer supported. The --run-as-root option is honored only with splunk start, splunk stop, and splunk restart.

Windows — new installations: Splunk Enterprise must be configured to run as either a Local Service Account (LSA) or a Domain User Account (DUA) that is not a member of the local Administrators group. The Local System User (LSU) option is no longer available, and installation halts if a selected DUA belongs to the local Administrators group.

Windows — upgrades to 10.4: LSU configurations are migrated to an LSA with ACLs reset appropriately; LSA configurations are retained as-is; DUA configurations are retained provided the account is not in the local Administrators group, and the upgrade is halted otherwise until the DUA is removed from that group.

• Workload Management support for Kubernetes

Splunk Enterprise now supports workload management on Kubernetes-based deployments. A new workload management Basic mode lets you apply admission rules on systems such as Kubernetes where cgroups are not available.

You can use admission rules to prevent rogue or resource-intensive searches from interfering with critical workloads. See Use Workload Management on Kubernetes.

• Support for post-quantum cryptographic algorithms.

Splunk is releasing support for a set of algorithms based on Kyber, Dilithium, and SPHINCS+ to meet the requirements laid out in FIPS 203, 204, and 205 and protect customers from these future quantum threats to cryptography.

• TLS 1.3 support

The Splunk platform now supports version 1.3 of the TLS protocol, alongside TLS 1.2, for all public-facing connections, enhancing security with stronger encryption, eliminating outdated cipher suites, and delivering better performance and efficiency. TLS 1.3 will be enabled by default alongside TLS 1.2. For more information, see Introduction to securing the Splunk platform with TLS.

• Provider-based Search Targeting with Role-Based Access Control (RBAC) for Federated Search for Splunk

Enhanced Provider Control for Federated Search for Splunk

The new enhancements for Federated Search for Splunk in transparent mode provide administrators and end users with unprecedented control over how data is searched across distributed Splunk environments. These updates ensure that your search operations are more efficient, secure, and tailored to your specific organizational needs.

Federated Search for Splunk allows you to run searches across multiple remote Splunk deployments as if the data were local. In transparent mode, the federated search head acts as a seamless proxy and simplifies the user experience by abstracting the complexity of the underlying remote infrastructure.

1. Targeted provider routing

You can now direct federated searches to specific providers with greater precision:

• User-directed targeting: End users can now explicitly define which federated or remote providers they want to include in their searches, which means that resources are only utilized as necessary.
• Default provider lists: Administrators can configure a default list of providers. If a user does not specify a provider in their search string, the system automatically routes the search to these pre-defined, relevant providers, which maintains a streamlined workflow.

1. Role-Based Access Control (RBAC) for providers

Control over security and governance is now more granular. With the introduction of a new UI-based configuration, administrators can define access controls for individual providers. Now you can specify a default list of providers in the new Providers tab on a role to restrict which roles have the authority to search specific providers, so sensitive data remains accessible only to authorized users.

Benefits

• Optimized performance: By allowing users to target specific providers or defaulting to a curated list, you eliminate unnecessary broadcast traffic. This reduces system overhead and significantly improves search response times across your federated environment.
• Enhanced security and compliance: With new RBAC capabilities, you can enforce strict data governance. By limiting provider access based on user roles, you minimize the risk of unauthorized data exposure and ensure compliance with internal security policies.
• Improved user experience: These features simplify the search process by reducing complexity for end users, while providing administrators with the tools needed to manage a large-scale, multi-deployment environment effectively.

For more information, see:

• “Configure role-based access and search targeting for transparent mode federated providers” in the Federated Search manual.
• The srchFederatedProvidersAllowed and the srchFederatedProvidersDefault arguments for the authorization/roles/{name} endpoint, in “Federated search endpoint descriptions” in the REST API Reference.

Original source

What's new in 8.5.x

What's new in Splunk Enterprise Security version 8.5.1

Splunk Enterprise Security version 8.5.1 is a maintenance release and was released on April 16, 2026 and includes several bug fixes. For more information on the issues fixed in this version, see Fixed issues in Splunk Enterprise Security version 8.5.1.

Note:

Detection versioning is turned off in this version of the release.

What's new in Splunk Enterprise Security version 8.5.0

Splunk Enterprise Security version 8.5.0 was released on April 8, 2026 and includes the following new enhancements:

Configuration and settings: Manage specific configuration settings in the ES UI

Ability to manage configuration files using a new system configurations page in Splunk Enterprise Security. For more information, see Modify configuration files using Splunk ES UI.

Configuration and settings: Configure workload pool to run search jobs

Configure settings in the ES UI to manage resources and optimize system performance when running search jobs from the analyst queue. For more information, see Manage resources by assigning search jobs to a workload pool.

Detections: Detection tuning

Adjust your detection SPL in real time to reduce false positives and improve the accuracy of alerts. For more information, see Tune detections in Splunk Enterprise Security.

Detections: Test detections in production

Test detections on production data using Splunk Enterprise Security to evaluate their behavior and validate search results without impacting SOC analyst workflows. For more information, see Test detections on production data using Splunk Enterprise Security.

Detections: Test panel in the detection editor to validate detection search results

Enhancements to the test panel in the detection editor to improve the accuracy of calculating alert volume during detection testing. You can select findings mode with a timeout option to calculate the number of findings based on the configuration settings of a detection and limit the duration of the test. You can select Events mode with a lookback option to show raw event counts within a specified time frame to spot duplicates or mis-configurations. For more information, see Estimate the volume of alerts from detection outputs in Splunk Enterprise Security.

Detections: Improvements in the detection editor for creating finding-based detections

SPL templates are provided in the detection editor that you can modify to create finding-based detections. For more information, see Edit detection SPL templates and macros for finding-based detections.

Detection: Improvements to Detection editor and default templates for detections

Tested SPL templates provided in the Detection editor to modify or create a finding-based detection. For more information, see Detection templates.

Analyst queue: Team-based queue enhancements

Assign queue permissions at a granular level for different roles. Determine whether a role can create, read, update, delete, or execute actions. See Permissions for team-based queues and Role-based access control lockdown.

Exposure analytics

Set up exposure analytics to automatically discover assets and users across your environment, enrich findings with context, and allow for precise attribution and a reduced attack surface. To set up exposure analytics, see Exposure analytics set up guide for admins in Splunk Enterprise Security. If you're an existing ARI user, see Using Splunk Asset and Risk Intelligence after upgrading to Splunk Enterprise Security 8.5.

Investigations: Workflow enhancements

Improved field groupings and collapsible panels introduced in the investigation side panel. For more information, see Pre-defined fields in the side panel of the investigation.

Investigations: Improved guidance on managing KVStore collections

KVStore optimization for detection performance. For more information, see Manage KV Store collections in Splunk Enterprise Security.

Splunk Attack Analyzer integration: Threat analysis for phishing incidents

Powered by Splunk Attack Analyzer, threat analysis allows you to perform static analysis on email bodies and metadata to identify malicious activity, review resource trees and system verdicts to assess the nature of the threat, and examine email screenshots to confirm visual indicators of phishing. See Phishing investigation and threat analysis in Splunk Enterprise Security.

Configure SOAR apps in Splunk Enterprise Security

Configure third-party apps in Enterprise Security to use Enterprise Security data. Microsoft (MS) Graph Office 365, IMAP, and Gmail apps can create findings in the Analyst Queue, so analysts can easily access full email content. See Configure Splunk SOAR apps in Splunk Enterprise Security.

Automation rules update

Automation rules can now trigger based on ingestions by apps configured in Splunk Enterprise Security. See Configure automation rules to run playbooks based on findings in Splunk Enterprise Security and Configure Splunk SOAR apps in Splunk Enterprise Security.

System insights dashboards

Splunk App for SOAR has new, intuitive dashboards – including more comprehensive metrics, direct links to run logs, and flexible alerting options – providing you with more precision and agility. For details, see System insights in the Splunk App for SOAR documentation.

Splunk Cloud Connect for Splunk Enterprise Security

Access Cloud extensions from Splunk Enterprise Security (On-premises). For more information, see Access Splunk Cloud Connect in Splunk Enterprise Security to access Cloud extensions. For some troubleshooting tips on common connection or user interface issues when using Splunk Cloud Connect, see Troubleshoot common issues when using Splunk Cloud Connect.

Support for CIM entity zones for entity risk scoring

Support for CIM entity zones for entity risk scoring. For more information, see Entity risk scoring in Splunk Enterprise Security.

UEBA enhancements

New UEBA detections and expanded regional availability. See UEBA regional availability and UEBA detection reference for UEBA on-premises.

Detection Studio

Ability to identify optimal detections using Detection Studio in Splunk Enterprise Security is GA. For more information, see Identify optimal detections using Detection Studio in Splunk Enterprise Security.

SOP Agent created response plans

Use the new SOP agent to import your existing SOP documents and create response plans from them. For details, see Create response plans with the SOP agent.

Ready-to-use Splunk response plans

New built-in, ready-to-use Splunk response plans available with recommended Splunk SOAR automation. See Included response plans in Splunk Enterprise Security.

Expanded regional availability for Threat Intelligence Management

New supported regions added for Threat Intelligence Management. See Threat Intelligence Management regional availability.

For Enhancements in Splunk SOAR, see the following articles:

Welcome to Splunk SOAR (Cloud)

Welcome to Splunk SOAR (On-premises)

Upgrade notice for 8.x

Upgrading Splunk Enterprise Security to version 8.x is a one-way operation. The upgrade process doesn't automatically back up the app, its content, or its data. Perform a full backup of the search head, including the KV Store, before initiating the Splunk Enterprise Security upgrade process.

When you upgrade to Splunk Enterprise Security version 8.x, you can no longer access any investigations created prior to the upgrade. To save archives of your investigation data, back up and restore your existing Splunk Enterprise Security instance.

If you need to revert back to the version that previously existed on your search head, you must restore the previous version of Splunk Enterprise Security from a backup.

See Upgrade Splunk Enterprise Security.

Note:

Upgrades to Splunk Enterprise Security version 8.x from versions 6.x and earlier are not supported. If you are using on-premises version 6.x or earlier, you must first upgrade to version 7.3.2 before upgrading to version 8.x.

Other important notes for upgrading include the following:

• You cannot upload Splunk Enterprise Security 8.x on an on-premises deployment of Splunk Enterprise 10.x using the UI. You must install Splunk Enterprise Security 8.x using the command line. See Install Splunk Enterprise Security from the command line.
• Splunk Enterprise Security in a search head cluster environment uses an installer that creates tokens and turns on token authorization if it is not available. Post-installation, the installer deletes the tokens. If an error occurs, contact Splunk Support to delete any residual tokens.
• The Splunk Enterprise Security Health app is installed but is turned off for all Splunk Cloud customers. This app is turned on by the Splunk Cloud Platform only during upgrades to ensure that the stacks get upgraded faster. Do not turn on the Splunk Enterprise Security Health app.

Share threat data in Splunk Enterprise Security

Sharing telemetry usage data is different from sharing threat data. Sharing of threat data in Splunk Enterprise Security is only introduced for Splunk Enterprise Security Hosted Service Offering (cloud) customers with a standard terms contract renewed or created after January 10, 2025. For more information, see Share threat data in Splunk Enterprise Security.

Compatibility and support

• Splunk Enterprise Security version 8.x is compatible only with specific versions of the Splunk platform. See Splunk products version compatibility matrix for details.
• Current versions of Splunk Enterprise Security only support TAXII version 1.0 and TAXII version 1.1.

Deprecated or removed features

The following features have been deprecated from Splunk Enterprise Security 8.x:

• Configuring the investigation type macro is no longer available.
• Incident Review row expansion is no longer available.
• Enhanced workflows are no longer available.
• Sequence templates are no longer available.
• The Investigation bar, Investigation Workbench, and Investigation dashboard from the Splunk Enterprise Security user interface (UI) are replaced by the Mission Control UI.
• Service level agreements (SLAs) and role-based incident type filtering are not available.
• The Content management page was updated to remove the following types of content: Workbench Profile, Workbench Panel, and Workbench Tab.
• Workbench and workbench related views such as ess_investigation_list, ess_investigation_overview, and ess_investigation have been removed.
• Capabilities such as edit_timeline and manage_all_investigations have been removed.
• The Comments feature is replaced by an enhanced capability to add notes.
• In Splunk Enterprise Security version 7.3, admins can turn on a setting to require analysts to leave a comment with a minimum character length after updating a notable event. In Splunk Enterprise Security version 8.x, you can no longer require a note when an analyst updates a finding in the analyst queue.

Add-ons

Technology-specific add-ons are supported differently than the add-ons that make up the Splunk Enterprise Security framework. For more information on the support provided for add-ons, see Support for Splunk Enterprise Security and provided add-ons in the Release Notes manual.

Note:

Some new features might not work for on-prem Splunk Enterprise Security deployments 8.x and higher, unless you upgrade the Splunk_TA_ForIndexers add-on for every release.

Note:

Do not uninstall the Mission Control app since the app is part of Splunk Enterprise Security.

To ensure that the Splunk Enterprise Security app works correctly, turn on the following add-ons. If any of the following add-ons aren't turned on, Splunk Support gets automatically notified and ensures that all the required add-ons are turned on automatically.

• DA-ESS-AccessProtection
• DA-ESS-EndpointProtection
• DA-ESS-IdentityManagement
• DA-ESS-NetworkProtection
• DA-ESS-ThreatIntelligence
• SA-AccessProtection
• SA-AuditAndDataProtection
• SA-EndpointProtection
• SA-IdentityManagement
• SA-NetworkProtection
• SA-ThreatIntelligence
• Splunk_SA_CIM
• Splunk_SA_Scientific_Python_linux_x86_64
• SplunkEnterpriseSecuritySuite
• Splunk_ML_Toolkit

Deprecated or removed add-ons

Splunk Enterprise Security no longer includes many of the technology add-ons in the Splunk Enterprise Security package. Instead, you can download the technology add-ons that you need directly from Splunkbase. This change improves the performance of Splunk ES by reducing the number of unnecessary enabled add-ons, and allows you to install the most appropriate and updated versions of add-ons when you install Splunk ES.

The following technology add-ons are removed from the installer, but still supported:

• Splunk Add-on for Blue Coat ProxySG
• Splunk Add-on for McAfee
• Splunk Add-on for Juniper
• Splunk Add-on for Microsoft Windows
• Splunk Add-on for Oracle Database
• Splunk Add-on for OSSEC
• Splunk Add-on for RSA SecurID
• Splunk Add-on for Sophos
• Splunk Add-on for FireSIGHT
• Splunk Add-on for Symantec Endpoint Protection
• Splunk Add-on for Unix and Linux
• Splunk Add-on for Websense Content Gateway

The following technology add-ons are removed from the installer, supported for the next year, but are deprecated and will reach end of support one year from the release date of this Enterprise Security version:

• TA-airdefense
• TA-alcatel
• TA-cef
• TA-fortinet
• TA-ftp
• TA-nmap
• TA-tippingpoint
• TA-trendmicro

Updated add-ons

The Common Information Model Add-on is updated to version 8.5.0 and was released on April 2, 2026. The version number for the Common Information Model is synchronized with the version number of Splunk Enterprise Security from this release.

Libraries

The following libraries are included in this release:

• Splunk_ML_Toolkit-5.3.0-1631633293630.tgz
• Splunk_SA_Scientific_Python_linux_x86_64-3.0.2-0
• Splunk_SA_Scientific_Python_windows_x86_64-3.0.0

Original source

This page contains information about new features, known issues, and resolved issues for the Ingest Processor solution, grouped by the release date. The Ingest Processor solution is a service within Splunk Cloud Platform designed to help you manage your data processing configurations and monitor your ingest traffic through a centralized Splunk Cloud service. Use the Ingest Processor solution to filter, mask, and transform your data before routing the processed data to external environments. For more information, see About Ingest Processor.

Note: The release date indicates when updates to the Ingest Processor solution were made available to Splunk Cloud Platform customers. For more information, contact your Splunk account representative.

Use the links to navigate to a specific section:

• New features, enhancements, and fixed issues
• Known issues

New features, enhancements, and fixed issues

Splunk Inc. releases frequent updates to the Ingest Processor solution. This list is periodically updated with the latest functionality and changes to the product.

February 18, 2026

The Ingest Processor solution now includes the following new features or enhancements.

• Support for Automated Field Extraction (AFE): The Ingest Processor solution now allows you to use Generative AI to suggest regular expressions (regex) for extracting multiple fields at ingest-processing time. See Extract fields from event data using Ingest Processor for more information.

January 27, 2026

The Ingest Processor solution now includes the following new features or enhancements.

• Support for the stats function: The Ingest Processor solution now allows you to aggregate your event data in batches and reduce the volume of logs sent to your destination. See Aggregate event data using Ingest Processor for more information.

December 19, 2025

The Ingest Processor solution now includes the following new features or enhancements.

• Additional pipeline templates: The Ingest Processor solution has been updated with pipeline templates that process AWS CloudTrail logs, CrowdStrike FDR logs, and Microsoft Office 365 Management Activity events, as well as templates that demonstrate common data processing workflows using generic sample data. You can use these templates as starting points for your own pipelines, or as references to learn how to write SPL2 to fulfill various use cases. See Use templates to create pipelines for Ingest Processor for more information.

October 20, 2025

The Ingest Processor solution now includes the following new features or enhancements.

• Decryption: The Ingest Processor solution now allows you to send encrypted data through your pipelines, and decrypt it before it reaches its destination. That way, you do not have to decrypt your data before processing it in Ingest Processor pipelines. To decrypt your data, apply the Decrypt command to your pipelines. See Use the Decrypt command to decrypt data in the Ingest Processor solution for more information.

October 8, 2025

The Ingest Processor solution now includes the following new features or enhancements.

• xml_to_object and object_to_xml functions: The Ingest Processor solution and the Edge Processor solution now support two new functions to modify pipeline data: xml_to_object and object_to_xml. Use the xml_to_object function to convert an XML string into a JSON object. The JSON format makes your data easier to manipulate and modify, and increases the efficiency to store and query from Splunk indexes. You can also set the xml_to_object function to infer the data types within your XML string. It can infer booleans, integers, floats, and recognizes the value null. Use the object_to_xml function to convert a JSON object into an XML string. You can use this function to return your data to its original format after modifying it to JSON. These functions are not available for searches. See Apply the xml_to_object and object_to_xml functions to pipelines for more information.

July 31, 2025

The Ingest Processor solution now includes the following new features or enhancements.

• Index partitioning for Ingest Processor pipelines: You can now add index partitioning to your Ingest Processor pipelines. This feature, available in Splunk Cloud Platform versions 10.0.2503 and higher, allows you to create an index predicate for your pipelines, in addition to the host, source, and source type partition options. See Create pipelines for Ingest Processor for more information.

June 18, 2025

The Ingest Processor solution now includes the following new features or enhancements.

• Conversion to OCSF format: You can now use the Ingest Processor to convert incoming event data to the Open Cybersecurity Schema Framework (OCSF) format, ensuring that the data can be used effectively in security applications. Conversions are supported for specific source types and event types. See Convert data to OCSF format using Ingest Processor for more information.

June 11, 2025

The Ingest Processor solution now includes the following new features or enhancements.

• Configurable timestamp rounding for metrics: By default, when you use the logs_to_metrics SPL2 command in a pipeline to generate metrics, the Ingest Processor rounds the timestamps of these metrics to the nearest 10 seconds. Rounding the timestamps prevents Splunk Observability Cloud from dropping data that arrives out of order. You can now choose to round metric timestamps to a different interval of seconds or turn off timestamp rounding by setting the round_timestamp parameter in the logs_to_metrics SPL2 command. See Generate logs into metrics using Ingest Processor for more information.

June 5, 2025

The Ingest Processor solution now includes the following new features or enhancements.

• Expanded support for Perl-compatible Regular Expressions 2 (PCRE2): To improve consistency and alignment with the Splunk platform new and existing pipelines will use PCRE2 syntax instead of RE2 syntax for regular expressions. All existing and new pipelines have been updated to use PCRE2 syntax. For more information about PCRE2 regular expressions in your existing pipelines, see Convert RE2 regular expressions to PCRE2 regular expressions.

April 30, 2025

The Ingest Processor solution now includes the following new features or enhancements.

• Apply custom command function: To process the incoming data before sending it to a destination, you can now discover, select, and apply custom command functions, which are user-defined SPL2 functions. This is particularly helpful for customers with less experience using SPL2.

March 5, 2025

The Ingest Processor solution now includes the following new features or enhancements.

• Support for Perl-compatible Regular Expressions 2 (PCRE2): To improve consistency and alignment with the Splunk platform, starting on March 5, 2025, new pipelines will use PCRE2 syntax instead of RE2 syntax for regular expressions. On June 5, 2025, all existing and new pipelines will be updated to use PCRE2 syntax. For information about converting and validating the regular expressions in your existing pipelines, see Convert RE2 regular expressions to PCRE2 regular expressions.

March 4, 2025

The Ingest Processor solution now includes the following new features or enhancements.

• Support for lookups: You can now use lookups in your pipelines to enrich incoming event data with additional information from CSV or KV collection lookup tables. See Enrich data with lookups using Ingest Processor for more information.

February 10, 2025

The Ingest Processor solution now includes the following new features or enhancements.

• Support for persistent queues (PQ) alongside in-memory queues to prevent data loss during system congestion: Ingest Processor supports persistent queues (PQ) alongside in-memory queues to prevent data loss during system congestion. When congestion occurs, Ingest Processor temporarily stores data by writing it to disk. Once the system returns to normal operation, Ingest Processor automatically forwards the stored data from these persistent queues. See the Resiliency and queueing in Ingest Processor topic in the Use Ingest Processors manual for more information.
• Support for previewing up to a chosen action in pipeline statements: You can now preview your pipeline statement at different actions in the SPL2 editor to analyze your data at different points of processing. For more information about how to preview up to an action, see Create pipelines for Ingest Processor.

November 19, 2024

The Ingest Processor solution now includes the following new features or enhancements.

• Support for gzip compression on data being sent to Amazon S3: When sending data from the Ingest Processor to Amazon S3, you can now compress that data using gzip. See Send data from Ingest Processor to Amazon S3 in the Use Ingest Processors manual for more information.

October 28, 2024

The Ingest Processor solution now includes the following new features or enhancements.

• Cloud region availability: Ingest Processor is now available in the following cloud regions: eu-south-1, eu-west-3. See About Ingest Processor for all cloud region availability.

September 10, 2024

The Ingest Processor solution now includes the following new features or enhancements.

• Support for sending your data from Ingest Processor to a Splunk platform metrics index destination: You can now send metrics data from Ingest Processor to a Splunk platform metrics index. Selecting a Splunk platform metrics index as a destination involves selecting a metrics destination and a corresponding metrics index. For information about how to configure sending metrics data to a Splunk Platform index, see Send metrics data from Ingest Processor to a Splunk platform metrics index. For information about how to send metrics to multiple destinations, see Send metrics to multiple destinations.

August 7, 2024

The Ingest Processor solution now includes the following new features or enhancements.

• Improved user interface for configuring index routing: The user interface for configuring index routing has been updated to present the configuration options more clearly. For information about how to configure index routing, see Create pipelines for Ingest Processor. For information about how the destination index for your data is determined by a precedence order of configurations, see How does Ingest Processor know which index to send data to?

July 19, 2024

The Ingest Processor solution now includes the following new features or enhancements.

• Updates to custom function support in SPL2: When defining a custom SPL2 function in a pipeline, you must now declare mandatory parameters before optional parameters. See Custom eval functions in the SPL2 Search Manual for more information.

July 17, 2024

The Ingest Processor solution now includes the following new features or enhancements.

• Ingest Processor General Availability: The Ingest Processor solution is now publicly available to all Splunk Cloud Platform users. See Get started with the Ingest Processor solution.
• Support for Premier and Essentials tier subscriptions: The Ingest Processor Essentials tier is included with a Splunk Cloud Platform subscription, and accommodates a maximum Daily Processing Volume of 500 GB/day. The Premier tier is a priced SKU for Daily Processing Volumes over 500 GB/day. For more information, contact your Splunk Sales representative. For more information about licensing in Splunk Cloud Platform, see the Use the License Usage dashboards topic in the Splunk Cloud Platform Admin Manual. For more information about Splunk Cloud Platform subscriptions, see the Subscription types section of the Splunk Cloud Platform Service Details topic in the Splunk Cloud Platform manual.
• Cloud region availability: Ingest Processor is available in the following cloud regions: us-east-1, us-west-2, ap-northeast-1, ap-southeast-1, ap-southeast-2, ca-central-1, eu-central-1, eu-west-1, eu-west-2.

May 14, 2024

The Ingest Processor solution now includes the following new features or enhancements.

• Support for the branch SPL2 command: You can now use the branch command to process and route copies of the incoming data in different ways. See Routing data in the same Ingest Processor pipeline to different actions and destinations for more information.

April 17, 2024

The Ingest Processor solution now includes the following new features or enhancements.

• Availability on HIPAA, IRAP, and PCI DSS compliant cloud environments: Splunk Cloud Platform has attained a number of compliance attestations and certifications from industry-leading auditors as part of Splunk's commitment to adhere to industry standards worldwide and Splunk's efforts to safeguard customer data. Generally Available products and features that are currently in scope of Splunk's compliance program may not be a part of the third-party audit report until the next assessment cycle. The Ingest Processor solution is in scope of the following compliance programs and will be audited at the next assessment cycle. Information Security Registered Assessors Program (IRAP): IRAP is an initiative of the Australian Signals Directorate (ASD) through the Australian Cyber Security Center (ACSC), designed to provide cyber security assessments on Information and Communications Technology (ICT) services to government organizations. IRAP is also a recognised standard with robust security controls for cloud services in the private sector across Australia.

April 15, 2024

The Ingest Processor solution now includes the following new features or enhancements.

• Cloud region availability: Ingest Processor is now available in the following cloud regions: ap-southeast-2, eu-central-1, eu-west-1. See Get started with the Ingest Processor solution.

April 4, 2024

The Ingest Processor solution now includes the following new features or enhancements.

• Support for the mvappend and mvdedup SPL2 functions: You can now use the following evaluation functions in pipelines for the Ingest Processor: mvappend, mvdedup. See SPL2 evaluation functions for Ingest Processor pipelines for more information.

March 26, 2024

The Ingest Processor solution now includes the following new features or enhancements.

• Updated workflow for configuring hashing functions: You can now use the Compute hash of action in the pipeline builder to add and configure hashing functions in your pipelines. See See Hash fields using Ingest Processor for more information for more information.

February 20, 2024

This is the first publicly available preview of the Ingest Processor solution. The following functionalities are available within this public preview to capture feedback from early adopters of Ingest Processor:

• Set up the Ingest Processor solution. See First-time setup instructions for the Ingest Processor solution.
• Process data using pipelines. See Create pipelines for Ingest Processors.
• Write metrics to Splunk Observability Cloud using pipelines. See Generate logs into metrics using Ingest Processor.
• Route data using pipelines. See Process a subset of data using Ingest Processor.
• View and configure destinations to route data to, including Splunk platform deployments, Splunk Observability Cloud environments, and Amazon S3 buckets. See Add or manage destinations.
• View the health status and data flow metrics of an Edge Processor. See View data flow information about Ingest Processor.

Known issues

The Ingest Processor solution is subject to the following limitations.

Browsers

• Multiple browser sessions are not supported since it is possible for users to try to edit the same pipeline in more than one browser session and make conflicting edits.

Ingest Processors

The following limitations exist for Ingest Processors:
CAUTION: Ingest Processors provide no data delivery guarantees. Data loss can occur if an Ingest Processor experiences high back pressure on connections to destinations, or when a data destination has a prolonged outage.

• Only Splunk Cloud tenant administrators can create and view Ingest Processor pipelines.

Forwarders

• The following limitations exist for forwarders:
• The useACK property in outputs.conf must be disabled in forwarders that are sending data to Ingest Processor pipelines.

HTTP Event Collector (HEC)

• When you receive data through HEC, the Enable indexer acknowlIngestment setting on the HEC token must be turned off.

Lookups

• CIDR matching is not supported. When configuring your lookup definition, make sure that the Match type advanced option is not set to CIDR.

Metrics

• Historical metrics presented in the detailed view of an Ingest Processor pipeline does not include metrics for deleted pipelines.

Pipelines

• The following limitations exist for pipelines:
• Only tenant administrators can create, edit, delete, apply, or remove pipelines.
• Some SPL2 functions work differently in Ingest Processor pipelines than they do in searches. For example, regular expressions in functions are interpreted differently because Ingest Processor pipelines support Regular Expression 2 (RE2) syntax while Splunk searches support Perl Compatible Regular Expressions (PCRE) syntax. See Ingest Processor pipeline syntax for more information.

Splunk Cloud Experience tenants

When you go through the first-time setup process for the Ingest Processor solution, you create a connection between your Splunk Cloud Experience tenant and your Splunk Cloud Platform deployment. This connection enables the tenant to surface specific indexes from that deployment as pipeline destinations.
The following limitations exist for this initial connection between your Splunk Cloud Experience tenant and your Splunk Cloud Platform deployment:

• You cannot connect your tenant to more than one Splunk Cloud Platform deployment using this method. To send data from a pipeline to an index that belongs to a different Splunk Cloud Platform deployment, you must configure a destination that corresponds to the indexer tier of that deployment and then include an eval expression that specifies the target index in your pipeline.
• If you create additional indexes in your Splunk Cloud Platform deployment after completing the first-time setup process, you must refresh the connection in order to make those indexes available in the tenant.

Original source

Note:
The Edge Processor solution is being gradually rolled out to Splunk Cloud Platform and may not be available immediately. If you have an urgent need for this capability and do not see it yet in your Splunk Cloud Platform environment, then please contact your Splunk Cloud Platform sales representative.

This page contains information about new features, known issues, and resolved issues for the Edge Processor solution, grouped by the generally available release date.

The Edge Processor solution is a service within Splunk Cloud Platform designed to help you manage data ingestion within your network boundaries. Use the Edge Processor solution to filter, mask, and transform your data close to its source before routing the processed data to external environments. For more information, see About the Edge Processor solution.

The Edge Processor solution is available on Splunk Cloud Platform version 9.0.2209 or higher. Updates are released frequently, and become available across all the supported Splunk Cloud Platform versions at the same time.

Note:
The release date indicates when updates to the Edge Processor solution were made available to Splunk Cloud Platform customers. For more information, contact your Splunk account representative.

Use these links to navigate to a specific section:

• New features, enhancements, and fixed issues
• Known issues

New features, enhancements, and fixed issues

Splunk releases frequent updates to the Edge Processor solution. This list is periodically updated with the latest functionality and changes to the product.

February 12, 2026

• The Edge Processor solution now includes the following new features or enhancements.
  • Improvements to source type syncing: The maximum number of source types that the Edge Processor service can sync from Splunk Cloud Platform has increased from 1000 to 4000. See Using source types to break and merge data in Edge Processors for more information.

January 27, 2026

• The Edge Processor solution now allows you to aggregate your event data in batches and reduce the volume of logs sent to your destination. See Aggregate event data using Edge Processor for more information.

January 26, 2026

• Bulk configuration of indexers for Splunk platform S2S destinations: When configuring a Splunk platform S2S destination, you can now enter a list of indexers or upload a list from a .txt or .csv file instead of specifying each indexer manually. See Send data from Edge Processors to non-connected Splunk platform deployments using S2S for more information.

December 19, 2025

• Additional pipeline templates: The Edge Processor solution has been updated with pipeline templates that process AWS CloudTrail logs, CrowdStrike FDR logs, and Microsoft Office 365 Management Activity events, as well as templates that demonstrate common data processing workflows using generic sample data. You can use these templates as starting points for your own pipelines, or as references to learn how to write SPL2 to fulfill various use cases. See Use templates to create pipelines for Edge Processors and SPL2 pipeline templates reference for more information.

December 4, 2025

• Incoming HTTP Event Collector (HEC) data size limit increased to 800 MB.
• Improved communication with Splunk indexer during unhealthy status with indefinite retry and exponential backoff.
• Edge Processor support for JSON array format as input. See Get data into an Edge Processor using HTTP Event Collector for more information.

November 6, 2025
Agnostic dot prefixes for datasets: The Edge Processor solution is now agnostic to dot prefixes for datasets, ensuring consistent handling.

October 15, 2025

• Decryption: The Edge Processor solution now allows you to send encrypted data through your pipelines and decrypt it before it reaches its destination. Apply the Decrypt command to your pipelines. See Use the Decrypt command to decrypt data in the Edge Processor solution for more information.

October 8, 2025

• xml_to_object and object_to_xml functions: Convert XML strings to JSON objects and vice versa to facilitate data manipulation and storage efficiency. These functions are not available for searches.
• Large lookups: Edge Processor now supports large lookup datasets up to 3 GB, enabling scalable data enrichment. Contact your Splunk sales representative to enable.

September 16, 2025

• Updated systemd configuration instructions to ensure more graceful shutdown procedures by specifying KillMode=mixed in the systemd unit file. See Install an instance and configure systemd section in Set up an Edge Processor for more information.

July 23, 2025

• Source type syncing from Splunk Cloud Platform to the Edge Processor service: Manage source types centrally in Splunk Cloud Platform, eliminating manual updates in Edge Processor service. See Using source types to break and merge data in Edge Processors for more information.

June 18, 2025

• Conversion to OCSF format: Use Edge Processors to convert incoming event data to the Open Cybersecurity Schema Framework (OCSF) format for effective use in security applications. See Convert data to OCSF format using an Edge Processor for more information.

June 11, 2025

• Edge Processor monitoring dashboards: Updated UI to visualize metrics and health of Edge Processors, including data volume, logs, CPU, memory, disk I/O, and disk space. Use dashboards to understand health and data flow.

June 5, 2025

• Expanded support for Perl-compatible Regular Expressions 2 (PCRE2): New and existing pipelines use PCRE2 syntax instead of RE2 syntax for regular expressions. See Convert RE2 regular expressions to PCRE2 regular expressions for more information.

May 27, 2025

• Common Vulnerabilities and Exposures (CVE) fixes: Fixes for CVE-2023-44487, CVE-2024-45339, CVE-2025-29786, CVE-2025-30204.
  • Fixed issues include TLS cipher suite mismatches and supervisor log parsing errors.

May 6, 2025

• Parquet format for data sent to Amazon S3: Option to store data as .parquet files when sending from Edge Processor to Amazon S3. See Send data from Edge Processors to Amazon S3 for more information.

April 30, 2025

• Apply custom command function: Discover, select, and apply user-defined SPL2 functions to process incoming data before sending to destination.

April 18, 2025

• Data compression option in Splunk platform S2S destinations: Compress data to reduce bandwidth when sending from Edge Processor to Splunk platform using S2S protocol. Option is on by default for new destinations.

March 20, 2025

• Common Vulnerabilities and Exposures (CVE) fix: Fix for CVE-2025-22869.

March 6, 2025

• Improvements to pipeline previews: Upgrade to improve accuracy of pipeline previews, rolled out in phases starting March 6, 2025.

March 5, 2025

• Support for PCRE2 syntax in new pipelines starting March 5, 2025; all pipelines updated by June 5, 2025. Support for exporter_error_count health metric. Fix for CVE-2024-45337.
  • Fixed issues include optimized retry behavior for Amazon S3 data sending and reduced noisy error logs.

February 10, 2025

• Support for previewing up to a chosen action in pipeline statements: Preview pipeline statements at different actions in SPL2 editor.

November 19, 2024

• Support for gzip compression on data sent to Amazon S3.

September 26, 2024

• Edge Processor acknowledgement for HTTP Event Collector (HEC) data: Verify receipt of data sent through HEC.
• Support for Amazon Data Firehose events.

September 25, 2024

• Edge Processor queue resiliency: Back pressure batches of data to upstream clients until ready to send to destination, fixing vCPU usage limitation.

September 16, 2024

• Fix for Time zone assignment option for syslog data not working as expected; specified time zone is now respected.

August 31, 2024

• Updated Warning status for Edge Processor instances to include cases with incomplete status information.

August 22, 2024

• Improved error handling and Edge Processor restart behavior; action required for existing users to set recommended limits on service account role.

August 7, 2024

• Improved user interface for configuring index routing.

July 30, 2024

• Time zone assignment for syslog data using RFC 3164 protocol.

July 19, 2024

• Updates to custom function support in SPL2: Mandatory parameters must be declared before optional parameters.

May 28, 2024

• Support for Amazon Linux 2 installation and running of Edge Processors.

May 14, 2024

• Support for thru and branch SPL2 commands to process and route copies of incoming data.

April 24, 2024

• Additional SPL2 functions supported: abs, exp, ln, log, pi, pow, sqrt, hypot.

April 18, 2024

• Renamed Global settings to Shared settings and updated side navigation.

April 4, 2024

• Support for json_valid, mvappend, mvdedup, and tojson SPL2 functions.

April 2, 2024

• HTTP Event Collector (HEC) token authentication support.

March 26, 2024

• Updated workflow for configuring hashing functions using Compute hash of action.

March 12, 2024

• Updated workflow for configuring lookups using Enrich events with lookup action.

February 27, 2024

• Updated configuration settings for TLS and mTLS; renamed configuration option for Splunk platform HEC destinations to HEC URI.

February 12, 2024

• Updated UI component for selecting data destinations in pipeline builder; renamed Append data to destination action to Send data to destination.

January 31, 2024

• Support for mvcount, mvrange, and mv_to_json_array SPL2 functions.

January 24, 2024

• Updated workflow for adding data processing actions to pipelines using plus icon in Actions section.

January 23, 2024

• Pipeline previews for multiple destinations; select specific destination to preview data.

January 22, 2024

• Updates to interpretation of where commands in pipelines; now consistently interpreted as filters, with data not matching dropped.

January 8, 2024

• Support for route SPL2 command to send subset of incoming data to different destination.

December 7, 2023

• Support for lookup SPL2 command to enrich incoming event data with CSV or KV Store lookup tables.
  • Raw data ingestion using HTTP Event Collector (HEC) services/collector/raw endpoint.

November 17, 2023

• Updated workflow for configuring system connections through new System connections page.
• Additional pipeline partitioning options.

November 8, 2023

• Updated workflows for sending data to specific Splunk indexes using Target index action.

October 30, 2023

• Additional SPL2 functions including cryptographic, trigonometric, hyperbolic, and statistical eval functions.

October 27, 2023

• Updated diagnostic tool edge_diagnostic to fix omission of compressed log files; checksum value changed.

September 18, 2023

• Syslog data transmission support; configure Edge Processor to receive syslog data.

August 22, 2023

• Support for split SPL2 function.

August 9, 2023

• Additional SPL2 functions: json_delete, filter, map, reduce.

August 4, 2023

• Availability on HIPAA, IRAP, and PCI DSS compliant cloud environments; Edge Processor solution in scope of these compliance programs.

July 27, 2023

• New pipeline builder for streamlined pipeline creation.

June 1, 2023

• Data transmission using HTTP Event Collector (HEC) services/collector endpoint.

May 19, 2023

• Pipeline previews using parsed sample data in CSV format.

April 27, 2023

• Default Destination assignment for Edge Processor to route unprocessed data.

March 25, 2023

• Time extraction and normalization in pipeline editor.

March 16, 2023

• Search results as sample data using Copy field values option.

March 15, 2023

• Field extraction support with dedicated UI in pipeline editor.

February 13, 2023

• First generally available release of the Edge Processor solution with functionalities for setup, pipeline creation, source type configuration, data forwarding, destination management, and health monitoring.

Known issues

The Edge Processor solution is subject to Tested and recommended service limits (Soft limits) in the Splunk Cloud Platform Service Details, as well as the following known issues.

Browsers

• Multiple browser sessions are not supported due to potential conflicting edits.

Edge Processors

• No data delivery guarantees; data loss can occur under high back pressure or prolonged destination outage.
• Uninstalling Edge Processor instances improperly causes Disconnected status in Manage instances panel.
• Only tenant administrators can create and view Edge Processors.

Forwarders

• useACK property in outputs.conf must be disabled in forwarders sending data to Edge Processors.
• props.conf configurations in forwarders and destination indexers can override or conflict with Edge Processor pipeline logic.

HTTP Event Collector (HEC)

• Enable indexer acknowledgement setting on HEC token must be turned off.
• Edge Processor may parse JSON-formatted event data sent to services/collector/raw endpoint as HEC event instead of raw string data.

Lookups

• CIDR matching is not supported; Match type advanced option must not be set to CIDR.

Metrics

• Historical metrics in detailed view do not include metrics for deleted pipelines.

Pipelines

• Only tenant administrators can manage pipelines.
• Some SPL2 functions behave differently in Edge Processor pipelines compared to searches.

Splunk Cloud Experience tenants

• Tenant can connect to only one Splunk Cloud Platform deployment via first-time setup.
• Additional indexes created after setup require connection refresh to be available in tenant.

Original source

10.2.2510.X Fixed Issues

This section includes information on fixed issues in 10.2.2510.X

10.2.2510.7

Publication Date:
February 12, 2026

Fixed Issues:
Uncategorized issues

Issue Number | Description
SPL-294995 | Make go binary splunk-spotlight portable
SPL-295105 | Ingest Actions File System Memory deadlock issue
SPL-295364 | WLM is not logging placement rules triggers
SPL-295511 | Upgrade to Python 3.13.11
SPL-295600 | Restore full backtracing capability to Splunk (crashlogs, etc).
SPL-295649 | Skip KV Store invalidation for search‑session tokens to reduce logout‑invalidation load
SPL-295685 | Respect minFreeSpace for Bulk Data Move split operations
SPL-295856 | Contention on WLM can cause search head to hang
SPL-295973 | Remove AssertionConsumerServiceURL from unsigned SAML AuthnRequests
SPL-296086 | Create a migration tool that can help Splunk app authors update their apps to use Python 3.13 version
SPL-296094 | Debug Sync issues in GCP w/ ES ITSI

10.2.2510.6

Publication Date:
February 02, 2026

Fixed Issues:
Admin and CLI issues

Issue Number | Description
SPL-293952 | Splunk calls systemctl with LD_LIBRARY_PATH pointed to $SPLUNK_HOME/lib

Distributed search and search head clustering issues

Issue Number | Description
SPL-294629 | Indexer cluster peer crashes at startup on Windows right after logging that it's downloaded its cluster bundle and it's about to restart.

Uncategorized issues

Issue Number | Description
SPL-292190 | SF/RF values shown wrong on the Monitoring console and Indexers
SPL-295087 | Fixed incorrect app update notifications caused by version comparison errors

... [The release notes continue with detailed fixed issues for multiple patch versions including 10.1.2507.X, 10.0.2503.X, 9.3.2411.X, and others, listing publication dates, security fixes, and detailed issue numbers with descriptions.]

Original source

Ingest and Workload dashboards

On the Ingest and Workload dashboards, users can view Promote: Amazon S3 ingestion metrics or SVC usage metrics alongside the Federated Analytics: AWS Security Lake and standard data ingestion scenarios. Ingest users can view Promote metrics on the Ingest dashboard. The Total ingestion volume card shows the total data ingestion from the last 7 days and the usage by Federated Analytics: AWS Security Lake, Promote: Amazon S3, and Standard ingestion. An Ingestion scenarios filter has been added to the license usage bar chart. Workload users can view Promote metrics on the Workload dashboard on the Indexing workload panel under the Workload metrics tab.

Fixes

Fixed an error that could cause incorrect Replication Factor values to appear in the Monitoring console and Indexers. False positive triggers for MC Alert - New Data in Index Specified as "lastchanceindex" have been removed. On the Health dashboard, Splunk 10.2 forwarders are now correctly shown as supported.

Original source

What's new

Splunk Enterprise Security version 8.4.0 was released on February 4, 2026 and includes the following new enhancements:

Identify and leverage the most powerful detections using Detection Studio

Ability to identify the most effective and powerful detections based on your data and security environment to improve search accuracy and reduce alert volume. For more information, see Identify the most optimal detections using Splunk Enterprise Security.

Improvements in the detection editor for creating event-based detections

Ability to edit event-based detections is enhanced significantly and includes the following features:

• Ability to specify findings and intermediate findings in separate sections of the detection editor along with their specific required fields.
• Information on threat objects, drill-down searches, drill-down dashboards, annotations, and so on, which are​ common to both findings and intermediate findings can be specified in the Analyst Queue section of the detection editor in collapsible panels.
• Risk scores are optional for findings and can be empty.
• Entities are not required for a finding and risk messages are not required for entities of a finding.
• If an intermediate finding output type is selected, at least one entity is required​.
  For more information, see Create event-based detections in Splunk Enterprise Security.

Improvements in the detection editor for creating finding-based detections

Ability to edit finding-based detections is enhanced significantly and includes the following features:

• Content from ESCU and other simpler, easy to use content templates are included.
• Fewer required fields and a streamlined design aligned with risk-based alerting best practices.
• Default information type such as entity, kill-chain are removed.​
• Panels to group findings based on entity type is deprecated
  For more information, see Create finding-based detections in Splunk Enterprise Security.

New macros introduced to simplify the composition of the searches for finding-based detections

Using these macros helps to standardize the aggregation of findings and group them based on entities. Macros also help to ensure consistency and maintainability of the search structure for finding-based detections. Following is a list of the new macros:

• generate_findings_summary
• calculate_findings_fields
• generate_findings_summary_on_entity

Detection versioning is a default feature

Turning on detection versioning is no longer optional but available by default when you install or upgrade to Splunk Enterprise Security version 8.4.

Allow skew detection

Ability to offset the time to run detections based on scheduler load can automatically distribute search loads across time and improve performance. For more information, see Skew the scheduled time to run detections.

Simplify the ability to create findings and investigations

Create investigations from scratch or add findings to investigations while creating the finding. Additionally, the number of required fields for creating findings has been reduced. This helps to instantly track emerging threats and reduces the number of required steps to open a case immediately and populate details as they become known. For more information, see Create a simple finding or investigation in Splunk Enterprise Security.

Add events to an investigation

Ability to provide context for robust security use cases using the ability to add events to investigations and bridge the gap between detection and evidence. Adding events to investigations lets you pull relevant raw events directly into their active investigations. For more information, see Add events to an investigation in Splunk Enterprise Security.

GCP pairing with Splunk SOAR

You can now pair Splunk Enterprise Security on GCP with Splunk SOAR on GCP. For more information, see Splunk SOAR Compatibility.

Unified data source configuration for Threat Intelligence Management

Activate and deactivate data sources for native threat intelligence or Threat Intelligence Management (Cloud) in a unified interface. See Configure threat intelligence sources in Splunk Enterprise Security.

Team-based work queues

Team-based queues organize findings and investigations into focused work-spaces that reflect each team's responsibilities. This can help teams stay focused, reduce noise, and respond to threats faster. See Analyst and team-based queues in Splunk Enterprise Security.

Turning the AI Assistant on or off

The AI Assistant in Splunk Enterprise Security helps you work through investigations by summarizing findings, explaining activity in clear language, and suggesting next steps. You can turn the AI Assistant on or off at any time in the configuration settings. See Turn the AI Assistant on or off in Splunk Enterprise Security.

Import and export response plans

Import your own response plans as JSON files into Splunk Enterprise Security, or export existing response plans. See Import response plans and Manage response plans.

Cisco Talos integration

Cisco Talos data is now available in the Intelligence tab of investigations. Access premium threat intelligence to enrich your findings for easier triage and detecting threats. Cisco Talos Intelligence helps to examine URLs, IP addresses, domain names and so on for security threat classifications and related threat intelligence. See Overview of threat intelligence in Splunk Enterprise Security.

Create a UEBA finding exclusion rule using an entity list

Create finding exclusion rules to suppress known safe or irrelevant activity that might otherwise inflate entity risk scores or create alert fatigue. You can now reuse existing entity lists to apply exclusions more effectively and consistently across key users and entities. See Create a finding exclusion rule using UEBA configuration page.

Upgrade notice for 8.x

Upgrading Splunk Enterprise Security to version 8.x is a one-way operation. The upgrade process doesn't automatically back up the app, its content, or its data. Perform a full backup of the search head, including the KV Store, before initiating the Splunk Enterprise Security upgrade process.
When you upgrade to Splunk Enterprise Security version 8.x, you can no longer access any investigations created prior to the upgrade. To save archives of your investigation data, back up and restore your existing Splunk Enterprise Security instance.
If you need to revert back to the version that previously existed on your search head, you must restore the previous version of Splunk Enterprise Security from a backup.
See Upgrade Splunk Enterprise Security.
Note:
Upgrades to Splunk Enterprise Security version 8.x from versions 6.x and earlier are not supported. If you are using on-premises version 6.x or earlier, you must first upgrade to version 7.3.2 before upgrading to version 8.x.
Other important notes for upgrading include the following:

• You cannot upload Splunk Enterprise Security 8.x on an on-premises deployment of Splunk Enterprise 10.x using the UI. You must install Splunk Enterprise Security 8.x using the command line. See Install Splunk Enterprise Security from the command line.
• Splunk Enterprise Security in a search head cluster environment uses an installer that creates tokens and turns on token authorization if it is not available. Post-installation, the installer deletes the tokens. If an error occurs, contact Splunk Support to delete any residual tokens.
• The Splunk Enterprise Security Health app is installed but is turned off for all Splunk Cloud customers. This app is turned on by the Splunk Cloud Platform only during upgrades to ensure that the stacks get upgraded faster. Do not turn on the Splunk Enterprise Security Health app.

Share threat data in Splunk Enterprise Security

Sharing telemetry usage data is different from sharing threat data. Sharing of threat data in Splunk Enterprise Security is only introduced for Splunk Enterprise Security Hosted Service Offering (cloud) customers with a standard terms contract renewed or created after January 10, 2025. For more information, see Share threat data in Splunk Enterprise Security.

Compatibility and support

• Splunk Enterprise Security version 8.x is compatible only with specific versions of the Splunk platform. See Splunk products version compatibility matrix for details.
• Current versions of Splunk Enterprise Security only support TAXII version 1.0 and TAXII version 1.1.

Deprecated or removed features

The following features have been deprecated from Splunk Enterprise Security 8.x:

• Configuring the investigation type macro is no longer available.
• Incident Review row expansion is no longer available.
• Enhanced workflows are no longer available.
• Sequence templates are no longer available.
• The Investigation bar, Investigation Workbench, and Investigation dashboard from the Splunk Enterprise Security user interface (UI) are replaced by the Mission Control UI.
• Service level agreements (SLAs) and role-based incident type filtering are not available.
• The Content management page was updated to remove the following types of content: Workbench Profile, Workbench Panel, and Workbench Tab.
• Workbench and workbench related views such as ess_investigation_list, ess_investigation_overview, and ess_investigation have been removed.
• Capabilities such as edit_timeline and manage_all_investigations have been removed.
• The Comments feature is replaced by an enhanced capability to add notes.
• In Splunk Enterprise Security version 7.3, admins can turn on a setting to require analysts to leave a comment with a minimum character length after updating a notable event. In Splunk Enterprise Security version 8.x, you can no longer require a note when an analyst updates a finding in the analyst queue.

Add-ons

Technology-specific add-ons are supported differently than the add-ons that make up the Splunk Enterprise Security framework. For more information on the support provided for add-ons, see Support for Splunk Enterprise Security and provided add-ons in the Release Notes manual.
Note:
Some new features might not work for on-prem Splunk Enterprise Security deployments 8.x and higher, unless you upgrade the Splunk_TA_ForIndexers add-on for every release.
Note:
Do not uninstall the Mission Control app since the app is part of Splunk Enterprise Security.
To ensure that the Splunk Enterprise Security app works correctly, turn on the following add-ons. If any of the following add-ons aren't turned on, Splunk Support gets automatically notified and ensures that all the required add-ons are turned on automatically.

• DA-ESS-AccessProtection
• DA-ESS-EndpointProtection
• DA-ESS-IdentityManagement
• DA-ESS-NetworkProtection
• DA-ESS-ThreatIntelligence
• SA-AccessProtection
• SA-AuditAndDataProtection
• SA-EndpointProtection
• SA-IdentityManagement
• SA-NetworkProtection
• SA-ThreatIntelligence
• Splunk_SA_CIM
• Splunk_SA_Scientific_Python_linux_x86_64
• SplunkEnterpriseSecuritySuite
• Splunk_ML_Toolkit

Deprecated or removed add-ons

Splunk Enterprise Security no longer includes many of the technology add-ons in the Splunk Enterprise Security package. Instead, you can download the technology add-ons that you need directly from Splunkbase. This change improves the performance of Splunk ES by reducing the number of unnecessary enabled add-ons, and allows you to install the most appropriate and updated versions of add-ons when you install Splunk ES.
The following technology add-ons are removed from the installer, but still supported:

• Splunk Add-on for Blue Coat ProxySG
• Splunk Add-on for McAfee
• Splunk Add-on for Juniper
• Splunk Add-on for Microsoft Windows
• Splunk Add-on for Oracle Database
• Splunk Add-on for OSSEC
• Splunk Add-on for RSA SecurID
• Splunk Add-on for Sophos
• Splunk Add-on for FireSIGHT
• Splunk Add-on for Symantec Endpoint Protection
• Splunk Add-on for Unix and Linux
• Splunk Add-on for Websense Content Gateway
  The following technology add-ons are removed from the installer, supported for the next year, but are deprecated and will reach end of support one year from the release date of this Enterprise Security version:
• TA-airdefense
• TA-alcatel
• TA-cef
• TA-fortinet
• TA-ftp
• TA-nmap
• TA-tippingpoint
• TA-trendmicro

Updated add-ons

The Common Information Model Add-on is updated to version 6.4.0.

Libraries

The following libraries are included in this release:

• Splunk_ML_Toolkit-5.3.0-1631633293630.tgz
• Splunk_SA_Scientific_Python_linux_x86_64-3.0.2-0
• Splunk_SA_Scientific_Python_windows_x86_64-3.0.0

Original source

Splunk Enterprise 10.2 was released on January 15, 2026.

If you are new to Splunk Enterprise, read the Splunk Enterprise Overview.

For system requirements information, see the Installation Manual.

Before proceeding, review the Known Issues for this release.

Planning to upgrade from an earlier version?

If you plan to upgrade to this version from an earlier version of Splunk Enterprise, read How to upgrade Splunk Enterprise in the Installation Manual for information you need to know before you upgrade.

See About upgrading: READ THIS FIRST for specific migration tips and information that might affect you when you upgrade.

The Deprecated and removed features topic lists computing platforms, browsers, and features for which Splunk has deprecated or removed support in this release.

What's New in 10.2

• Preview Update 2 feature: Field filters are now available by default (as of Splunk Enterprise version 10.2.2), and protect sensitive fields in searches that use the tstats command. Field filters let you limit access to confidential information by redacting or obfuscating fields in events within searches, with optional role-based exemptions. As of 10.2.2, field filters are visible for customer use by default, eliminating the need for manual configuration. Field filters now provide native support for the tstats command.

• Parquet format for data sent to Amazon S3 from Edge Processor: You can now choose to store data as parquet files when sending data from an Edge Processor to Amazon S3.

• Edge Processor on Splunk Enterprise operating system version support: Several OS versions are no longer supported (Amazon Linux 2, Centos 7, Debian 10 and 11, RHEL 8.0, SUSE Linux Enterprise 15.0, Ubuntu 20.04 LTS). New supported versions include Debian 12+, RHEL 9+, RockyLinux 9+, SUSE Linux Enterprise 15.0 SP6+, Ubuntu 24.04 LTS.

• Edge Processor on Splunk Enterprise supports JSON array format as input.

• Edge Processor monitoring dashboards: Updated UI to visualize metrics and health of Edge Processors.

• Updated systemd configuration instructions for graceful shutdown of Edge Processor instances.

• Support for OAuth2.0 for 3rd party and external applications.

• Improvements to Observability Metrics & Charts in Splunk Dashboard Studio.

• Splunk AI Assistant for SPL in the Search app is now available in Splunk Enterprise, providing natural language query generation, explanation, and translation.

• Removal of Node.js: Customers must update apps dependent on Node.js to bundle their own version.

• SPL2 language enhancements: Unified search and streaming language supporting SPL and SQL syntax, compatible with SPL.

• Federated provider names are now case-insensitive.

• SPL2 support for Dashboard Studio.

• Other Dashboard Studio enhancements.

• Ingest-Tier Scaling for high-throughput, scalable data ingestion.

• Bulk Data Movement between Indexes for efficient data reorganization.

• Enhanced visibility and management of OpenTelemetry Collector configurations.

• Agents lookup feature for improved performance in agent management UI.

• Agent management UI/UX enhancements.

• Destination configuration on agent management for S3 and file system destinations.

• Queued ad hoc search quotas to prevent unbounded queuing.

• TLS verification for inter-sidecar communication.

• Nascent sidecar ensures correct configuration on search head clusters.

• Audit Trail Log v2: structured audit log format compliant with CIM using JSON.

• Python 3.13 available on opt-in basis.

• KV store server version 8.0 available.

• Splunk Enterprise no longer runs as root by default.

• Monitoring Console Overview Dashboard (beta) redesign for improved user experience and efficiency.

Original source

Splunk Enterprise 10.2 was released on January 15, 2026.

If you are new to Splunk Enterprise, read the Splunk Enterprise Overview.

For system requirements information, see the Installation Manual.

Before proceeding, review the Known Issues for this release.

What's New in 10.2

• Preview Update 2 feature: Field filters are now available by default (as of Splunk Enterprise version 10.2.2), and protect sensitive fields in searches that use the tstats command.

  To protect your personal identifiable information (PII) and protected health information (PHI) data, and meet data privacy requirements such as GDPR or other privacy regulations, you can use field filters in the Splunk Platform to limit access to your sensitive data. Field filters let you limit access to confidential information by redacting or obfuscating fields in events within searches, with optional role-based exemptions. For more information about field filters, see Protect PII, PHI, and other sensitive data with field filters and Plan for field filters in your organization.

  With the Preview Update 2 release:

  • As of Splunk Enterprise version 10.2.2, field filters are visible for customer use by default, which eliminates the requirement for administrators to turn on the feature by configuring the limits.conf and web-features.conf files. Note: Not available in Splunk Enterprise versions 10.2.0 and 10.2.1.
  • Field filters now provide native support for the tstats command and the tstats command can now be used without restrictions on indexes protected by field filters.

  READ THIS FIRST: Should you deploy field filters in your organization? Field filters are a powerful tool that can help many organizations protect their sensitive fields from prying eyes, but it might not be a good fit for everyone.

  If your organization uses downstream configurations, such as accelerated data models, Splunk Enterprise Security (ES) detections using those data models, and user-level search-time field extractions, make sure that you plan around the implications of field filters on those configurations before deploying field filters in your environment. See READ THIS: Downstream impact of field filters.

  If your organization runs Splunk Enterprise Security or if your users rely heavily on commands that field filters restricts by default (mpreview and mstats), do not use field filters in production until you have thoroughly planned how you will work around these restricted commands. See READ THIS: Restricted commands do not work in searches on indexes that have field filters.

• Parquet format for data sent to Amazon S3 from Edge Processor:

  When sending data from an Edge Processor to Amazon S3, you can now choose to store the data as parquet files. See Send data from Edge Processors to Amazon S3 for more information.

• Edge Processor on Splunk Enterprise operating system version support:

  The Splunk 10.2 Enterprise release contains an update to remediate several CVEs. In the binary build process older versions of the Golang and Go libraries were inadvertently included resulting in a breaking change which caused the following changes in the supported operating systems:

  • Amazon Linux 2 is no longer supported.
  • Centos 7 is no longer supported.
  • Debian 10 and 11 are no longer supported. Debian 12 and higher are now supported.
  • Red Hat Enterprise Linux (RHEL) 8.0 is no longer supported. RHEL 9.0 and higher is now supported.
  • RockyLinux 9 and higher is now supported.
  • SUSE Linux Enterprise 15.0 is no longer supported. SUSE Linux Enterprise 15.0 SP6 and higher is now supported.
  • Ubuntu 20.04 LTS is no longer supported. Ubuntu 24.04 LTS is now supported.

  Users running their data management control plane and edge processors on any non-supported operating systems must upgrade to a supported version of that operating system before upgrading their data management control plane to Splunk Enterprise 10.2 to avoid any data loss from their edge processors. Other Splunk Enterprise deployment components outside of your data management control plane are not impacted by this change. See Installation requirements in the Use Edge Processors for Splunk Enterprise manual for a list of supported operating systems.

• Edge Processor on Splunk Enterprise support for JSON array format as input:

  Edge Processor on Splunk Enterprise now supports JSON array format as input. This enhancement allows input to contain square brackets and objects to be separated by commas. For more information, see Get data into an Edge Processor using HTTP Event Collector.

• Edge Processor on Splunk Enterprise monitoring dashboards:

  The Edge Processor on Splunk Enterprise solution now includes an updated user-interface that allows you to quickly visualize the metrics and health of your Edge Processors. View the inbound and outbound data volume of each pipeline, and the logs of your Edge Processors, for different lengths of time. Use Edge Processor monitoring dashboards to understand the health of your Edge Processors. Visualize the flow of data into destination queues and check pipeline connections.

• Updated systemd configuration instructions:

  The instructions for configuring systemd to manage the underlying process of your Edge Processor instance has been updated to ensure more graceful shutdown procedures. Previously, when you ran the restart or stop commands from systemctl, the Edge Processor supervisor and systemd both sent terminating signals to the Edge Processor instance, causing the instance to terminate abruptly. You can now prevent this issue by specifying the KillMode=mixed setting in the systemd unit file. See the Install an instance and configure systemd section in Set up an Edge Processor for more information.

• Support for OAuth2.0 for 3rd party and external applications:

  Customers can easily and securely authenticate their 3rd party applications using the standardized processes and workflows offered through version 2 of the Open Authorization (OAuth 2.0) protocol. Administrators can now configure OAuth 2.0 for use with products like Data Analytics and User Behavior Analysis (UBA) tools to connect to Splunk platform through REST APIs, so end users can get data and insights, make decisions faster, and turn data into doing. See Configure an external Open Authorization 2.0 authorization server.

• Improvements to O11y Metrics & Charts in Splunk Dashboard Studio:

  Users can leverage observability application service map views in both published and exported dashboards, and incremental improvements and bug fixing to feature Splunk Observability Cloud metrics and charts in Splunk Dashboard Studio. See Add a Splunk Observability Cloud service map to Dashboard Studio dashboards.

• Splunk AI Assistant for SPL in the Search app is now available in Splunk Enterprise:

  Splunk AI Assistant for SPL is now available in the Search app for hybrid on-premises Splunk platform deployments. The Splunk AI Assistant helps users generate, explain, and translate SPL using natural language. This generative AI-powered experience is designed to support both new and advanced users by providing query suggestions, detailed explanations, and direct access to Splunk platform documentation. The AI assistant enables faster onboarding, improved productivity, and more effective investigations. The Splunk AI Assistant for SPL app version 1.3.2 or higher must be installed before you can use the AI Assistant in searches in Splunk Web. To learn more, see Use Splunk AI Assistant for SPL in the Search app.

• Remove Node.JS:

  Splunk previously announced deprecation of Node.js and is now removing it. Customers using apps dependent on Node.js will need to update their apps to bundle their own version of Node.js. Failure to do so may result in App/TA functionality degradation and unexpected behavior.

• SPL2:

  SPL2 extends the existing SPL language by incorporating several powerful features. These features simplify data access and analysis while also providing support for complex investigations and data management workflows. With SPL2, you can write searches using either SPL or SQL syntax. This simplifies learning and using the language, and adds consistency to the language. SPL2 is a unified search and streaming language, offering a single syntax for searching data in Splunk indexes, accessing federated data stores, and preparing data in-stream across various Splunk products. SPL2 is fully compatible, and can operate in parallel, with SPL. For information about what's new, known issues, and fixed issues, see SPL2 release notes in the SPL2 Overview manual. Note: Some versions of Linux are not supported by SPL2 in 10.2. See the SPL2 Known Issues.

• Federated provider names are now case-insensitive:

  As of this release, federated provider names are case-insensitive for Federated Search for Splunk. For example, say you have a provider named MyProvider and you try to create a new provider with a Provider name of myprovider. In this instance, Splunk software prevents you from creating the new provider until you choose a Provider name that is unique, regardless of alphabetical character case. Note: If you are upgrading from a previous version of the Splunk platform, this might be a breaking change. If you have two or more federated providers in your Splunk platform deployment with names that differ only by case (such as one named MyProvider and another named myprovider), you must change the duplicate provider names to unique strings. There are two ways to accomplish this: You can delete and recreate the federated providers with duplicate names. If you have access to the .conf files for your Splunk platform deployment, you can edit the duplicate federated provider names directly in federated.conf. You cannot edit federated provider names in Splunk Web. If you choose to not delete or replace duplicate provider names, Splunk software uses the first name that appears in federated.conf. For example, if the MyProvider stanza appears before the myprovider stanza in federated.conf, Splunk software references only the MyProvider stanza when it receives any version of the string "myprovider".

• SPL2 support for Dashboard Studio:

  In Dashboard Studio, you can use SPL2 data sources in dashboards by doing one of the following:

  • Create an SPL2 query from within a dashboard
  • Reference an existing view from an SPL2 module

  See Create search-based visualizations with SPL2.

• Other Dashboard Studio enhancements:

  See What's new in Dashboard Studio.

• Ingest-Tier Scaling:

  Ingest-Tier Scaling delivers high-throughput, scalable data ingestion for self-managed Splunk deployments, enabling customers to handle larger data volumes with improved resilience, operational efficiency, and clearer separation of ingest and indexing tiers. See Ingest-Tier Scaling.

• Bulk Data Movement between Indexes: Clustering:

  Bulk Data Move allows Splunk Enterprise users to efficiently reorganize indexes and move data between them using specific search criteria. Reclaim storage and manage sensitive information without requiring full index removal. Available only non-SmartStore clustered environments. See Bulk Data Move for indexer clusters.

• Effective configuration of OTel Collectors:

  We have enhanced the visibility and management of OpenTelemetry (OTel) Collector agent configurations within the Splunk platform. Now you can view the complete, active configuration for each OTel Collector agent that communicates using OpAMP (Open Agent Management Protocol). For more information, see Effective configuration of OTel Collectors.

• Agents lookup:

  To improve performance when managing a large number of agents, we have introduced the agents lookup feature for the agent management user interface. When enabled, this feature significantly reduces UI load times by retrieving agent data from a cached CSV lookup file generated by a saved search, instead of querying the index directly for every interaction. For more information, see Agents lookup.

• Agent management UI/UX enhancements:

  To improve the admin experience, we have enhanced the agent management user interface and user experience. Forwarders and OpenTelemetry management are now unified into a single-stop console, and an automated wizard has been introduced for simplified server class creation.

• Destination configuration on agent management:

  You can now configure S3 and file system destinations directly from agent management, and these changes will automatically be propagated to your connected agents. To maintain consistency, always configure destinations from agent management. This feature requires agent management version 10.2 or higher, while there is no version restriction for compatible agents. You can enable or disable this feature using the enableS3ConfigOnDs flag in the limits.conf file. For more information, see Create an S3 destination.

• Queued ad hoc search quotas:

  This feature introduces configurable limits on the number of ad hoc searches that Splunk software can queue at both the system level and the role level. These limits are designed to prevent unbounded queuing of ad hoc searches, which can negatively impact system performance and resource utilization. For more information, see Create and manage roles in Splunk Enterprise using authorize.conf.

• TLS verification for inter-sidecar communication:

  To enhance security, each sidecar uses a server data plane certificate when communicating with other sidecars through the direct port of the destination sidecar. Over a Transport Layer Security (TLS) connection on the direct port, the connecting sidecar verifies the certificate of the destination sidecar to ensure a trusted connection. For more information, see Inter-sidecar communication.

• Using Nascent to ensure correct configuration on search head clusters:

  The Nascent sidecar ensures that the etcd service runs with the correct configuration on each search head in the cluster. By managing the etcd cluster, it provides consistent configuration and service discovery throughout the cluster. This sidecar is necessary for the proper functioning of the Storage sidecar due to its dependency on etcd. For more information, see About the Nascent sidecar.

• Audit Trail Log v2: structured audit log format:

  The structured format of audit trail logs, also known as Audit Trail Log v2, complies with the Common Information Model (CIM). It uses JSON, which makes logs easier to parse and interpret. Audit Trail Log v2 includes comprehensive metadata, making it suitable for compliance purposes. This is the first phase in delivering Splunk Idea E-I-49. To learn about this format, see About structured audit trail logs.

• Python 3.13 is available on an opt-in basis:

  You can opt in to use Python 3.13 instead of Python 3.9. Splunk platform still uses Python 3.9 by default, but Splunk Web uses Python 3.13 only. To learn how to switch between Python versions, see Python compatibility in Splunk apps.

• KV store server version 8.0 is available:

  Upgrade to KV store server version 8.0. Splunk Enterprise 10.2 still supports KV store server version 7.0, but this server version will be removed in future versions of Splunk Enterprise. To learn how to upgrade your KV store server version, see Upgrade the KV store server version.

• Run Splunk Enterprise without the root option:

  Splunk Enterprise no longer runs as root by default. To start, stop, or restart Splunk Enterprise as root, append --run-as-root to the command.

• Monitoring Console Overview Dashboard (beta) redesign:

  The Overview (beta) dashboard has been updated for improved user experience and efficiency. The dashboard provides a summary of your deployment's most important metrics:

  • View a summary of your deployment's license entitlements and understand your resource usage with status indicators for each license entitlement metric.
  • Personalize your dashboard and choose the metrics that are most important to your users.
  • Access action items such as Refresh and Open in search in each metric's ellipses menu.
  • Provide feedback to the Splunk MC team using the Feedback button.
  • Monitor forwarders and get alerts when forwarders are missing.

  To learn more about the Overview (beta) dashboard, see Overview Dashboard.

Original source

SPL2 overview

SPL2 extends the existing SPL language by incorporating several powerful features. These features simplify data access and analysis while also providing support for complex investigations and data management workflows. With SPL2, you can write searches using either SPL or SQL syntax. This simplifies learning and using the language, and adds consistency to the language.

SPL2 is a unified search and streaming language, offering a single syntax for searching data in Splunk indexes, accessing federated data stores, and preparing data in-stream across various Splunk products. SPL2 is fully compatible, and can operate in parallel, with SPL.

SPL2 release notes

For information about what's new, known issues, and fixed issues, see SPL2 release notes in the SPL2 Overview manual.

Original source

Product

Splunk Cloud Platform

Version(s)

9.2.2403.102 to 9.2.2403.104

Component

Authentication, Security Assertion Markup Language (SAML) protocol

Problem Class

Authentication failure, incorrect authorization

Problem

When you attempt to log into a Splunk Cloud Platform instance that uses the SAML protocol as an authentication scheme, you might receive an error message "No valid Splunk role found in local mapping." You might also log in successfully, but your account might not receive the roles you expect.

Cause

Splunk implemented a change on some Splunk Cloud Platform deployments where the Splunk platform no longer auto-maps SAML groups to Splunk roles by default. For more information on why Splunk made this change, see the "Background" section of this topic.

Prior to the change, the Splunk platform performed auto-mapping of groups that it retrieved from a SAML identity provider to Splunk roles with the same name. For example, if there is an "admin" group on the SAML IdP, the Splunk platform maps that group to the "admin" Splunk role, and any SAML user who is a member of the "admin" SAML group receives administrator-equivalent privileges on the Splunk platform instance through its "admin" role by virtue of the automatic role mapping.

If you used SAML for authentication previously in your Splunk Cloud Platform deployment, and Splunk subsequently upgraded the deployment to versions 9.2.2403.102 to 9.2.2403.104, auto-mapping of groups to roles no longer occurs, which can result in authentication failures for SAML users in the deployment, as described in the "Problem" section of this topic.

This change only affects Splunk Cloud Platform instances that use SAML as an authentication scheme. It does not affect native Splunk users on the platform. Those users can continue to log in and have access to all Splunk roles you have assigned to them.

Splunk is reversing this change in Splunk Cloud Platform version 9.2.2403.105 and higher based on customer feedback. If you are currently experiencing the login problems that this topic describes, and Splunk has not yet reversed the change on your deployment, you can reverse it yourself by following the procedure in the "Solutions" section of the topic.

Background

In version 9.1.2312 of Splunk Cloud Platform, Splunk changed which SAML groups that the Splunk platform automatically mapped to Splunk roles by default. It eliminated auto-mapping of the "admin" and "power" Splunk roles and advised customers to either create unique alternative role maps or turn auto-mapping back on if it was necessary. It also provided an option in Splunk Web to turn auto-mapping on or off.

In version 9.2.2403 of Splunk Cloud Platform, Splunk eliminated auto-mapping of SAML groups to Splunk roles by default entirely. Splunk is reversing this change on Splunk Cloud Platform due to customer feedback.

Splunk implemented both of these changes to address concerns that multiple parties raised as a result of routine security assessments.

Solution

To restore the auto-mapping of SAML groups to Splunk roles, you can turn on auto-mapping of SAML groups to Splunk roles in Splunk Web.

• Log into the Splunk Cloud Platform instance as sc_admin.
• From the system bar, select Settings > Authentication Methods.
• In the Authentication Methods page, under External, select SAML.
• Select the Configure Splunk to use SAML link.
• In the SAML Configuration dialog box that appears, under General settings, select Enable Auto Mapped Roles.
• Select Save.
• Reload the authentication configuration. From the system bar, select Settings > Authentication Methods, and in the Authentication Methods page that appears, select Reload authentication configuration.

Original source

When you upgrade to version 7.2.4+ of Splunk Cloud Platform, the behavior of certain field alias configurations changes.

A field alias is a way of setting up an alternate name for a field. You can then use that alternate name to search for events that contain that field. Ideally, you should be able to define multiple aliases for a single field, but each alias you define should apply only to one source field. Additionally, when you apply a field alias configuration to a search, the expectation is that the source field is in the events, but the alias field is not in the events.

This issue involves events that already include the alias field, but which are missing the source field or have no value for the source field.

Before the 7.2.4 field alias fix:

In versions of Splunk Cloud Platform previous to 7.2.4, when you applied a field alias configuration to events that had the alias field but not the source field, no changes were made to those events. The alias fields were allowed to stay.

This behavior is an erroneous application of the field alias concept. It allows users to have alias field values that do not correspond to source fields.

Example of the old field alias behavior:

Here are four events of sample log data. This is what they look like before we apply field alias processing to them. Each of these events has a sourcetype of st1 and a source of example.log.

[Sample events shown]

Now, say you want to apply this pair of props.conf field alias configurations to that set of events.

[FIELDALIAS-class1 = uid AS user]
[FIELDALIAS-class2 = id AS user]

With this pair of configurations, events that share a sourcetype of st1 and a source of example.log have the user field aliased to two different source fields: uid and id. These colliding configurations are problematic because field aliases are supposed to reference only one source field at a time.

In addition, you know that user, the alias field, already exists in the events. If your field alias configurations say that the value of user should match a value of either uid or id but the user field in the event already has a value of jessica, how does the search head resolve this? It replaces the user field value with one of the alias field values, according to lexicographical sort order logic.

But the real issue here is with the fourth event, where the alias field exists, but no source field exists. The pre-7.2.4 rules allowed the alias field to stay in an event when there were no source fields in the event.

Here is what the sample events look like after field alias processing with the pre-7.2.4 rules.

[Sample processed events shown]

This results in the overwriting of user values in the first two events. The search head resolves the conflict between id and uid in the first event by selecting id.

Note: The search head resolves collisions between two or more AS configurations by applying each of the FIELDALIAS class names in lexicographical sort order. It uses the last class that it applies. So in the first event of this example, it first applies class1 and then applies class2. Because class2 is the last class applied, the user field takes on the value of the id field.

The third event gets a new field. Before processing, it had a source field, but no alias field. After processing it has an alias field with the value of the source field. This is how field aliases are supposed to work.

But the fourth event has an alias field without a source field. After the field alias configuration is applied, the alias field should not appear in events that do not have the corresponding source fields. The logic set by the configuration is not consistent.

After the 7.2.4 field alias fix:

In Splunk Cloud Platform 7.2.4, this bug was fixed. The fix changed the behavior when you apply a field alias configuration to an event where the alias field is already present but no source fields exist. This table explains how the behavior has changed and why.

[Table describing behavior changes]

Example of the 7.2.4 fix:

This example shows you how the 7.2.4 fix changed the results of some searches. Say you start with the same two field alias configurations:

[FIELDALIAS-class1 = uid AS user]
[FIELDALIAS-class2 = id AS user]

You apply those configurations to the same four events as the preceding examples. Here are the results:

[Sample events after fix shown]

As you can see, the difference in this set of events is that the user field is removed from the fourth event. It is removed because it is an alias field and there is no source field in the event.

The introduction of ASNEW in 7.2.4:

Version 7.2.4 of the Splunk Cloud Platform introduced the ASNEW field alias configuration.

ASNEW allows you to combine field aliases without overriding or removing values.

For example, say you have a search that runs over events that include the dst field, and you want to apply the following props.conf field alias configuration to it:

[FIELDALIAS-classx src AS dst]

In the case of events that already have dst, you want the field and its values to be undisturbed by the field alias processing. You do not want dst to be removed, and you do not want the value of dst to be altered. In this case you must change the configuration from AS to ASNEW:

[FIELDALIAS-classx src ASNEW dst]

When you apply this configuration, the search head passes over instances of dst that are already present in your events. It does not remove them or overwrite them.

Configure settings on Splunk Web:

You can use the Overwrite field values setting to determine how alias fields are treated when they are already present in events at the time that field alias processing takes place.

Select Overwrite field values for a field alias that uses the corrected field alias behavior. This means that it does what it takes during processing to ensure that the alias fields in the event share the values of their corresponding source fields.

When Overwrite field values is not selected, the field alias uses the uncorrected behavior, which means that the alias field is not changed or removed if it exists in an event without a source field when field alias processing takes place.

When you create a new field alias, Overwrite field values is not selected by default.

Using calculated fields to apply an alias field to multiple source fields:

Calculated fields provide a more versatile method for applying an alias field to multiple source fields. Use eval functions such as coalesce to determine the order in which colliding source fields are applied to your alias fields.

Calculated fields that use functions like mvappend and mvdedup also enable you to deal with situations where your field alias configuration collides with a field extraction. For example, say you have this combination of a field alias configuration and a field extraction configuration:

[FIELDALIAS-class1 = uid AS user]
[EXTRACT-class2 = 123(?<user>[0-9]+)789]

During a search, the EXTRACT-class2 configuration extracts user field values for events with a source of example.log. Later in the search pipeline, the FIELDALIAS-class1 configuration applies a field alias to events with a source type of st1. FIELDALIAS-class1 gives the user field the same value as uid even when uid is null. As a result, events with a source of example.log and a source type of st1 have the extracted value of the user field overwritten by the contents of the uid field.

This configuration is fine if you intend for the extracted value of user to be overwritten. But if that is not the case, one of the following three calculated field configurations would be a better choice than the FIELDALIAS-class1 configuration, depending on the effect you are trying to achieve:

• EVAL-user = coalesce(user, uid): Retains only one field value. Prioritizes the extracted value over the aliased value.
• EVAL-user = mvappend(user, uid): Maintains both the extracted and aliased values. Could lead to duplicated values.
• EVAL-user = mvdedup(mvappend(user, uid)): Maintains both the extracted and aliased values. No duplicates.

Original source

This page lists features for which Splunk Inc. has deprecated or removed support in this version of the Splunk Platform.

What are "deprecated" and "removed" features?

• Deprecated features continue to work and Splunk supports them until support is removed. However, customers need to begin planning now for the future removal of support.
• Removed features are features that Splunk no longer supports and no longer work with the Splunk platform. Customers must find alternatives to removed features.

Deprecated features

The following table summarizes the features that are deprecated. These features continue to be supported, but Splunk reminds customers that deprecated features might be removed in a future release.

Newly disabled in this version What do I need to know? First deprecated Deprecated feature What do I need to know? First deprecated Deprecated version 1.0 endpoints for the Search API are now disabled by default Select version 1.0 endpoints for the Search API have been deprecated and disabled, and will be removed in a future release. Customers and app developers should upgrade usage of these disabled endpoints to the new API version, Search API version 2.0. These new Semantic Versioned Rest API endpoints for search improve platform contracts and resiliency to platform updates. If your organization has business-critical apps that still need to use the disabled endpoints, you can turn them on for a limited time as a temporary fix. See Semantic API versioning in the Splunk Cloud Platform REST API Reference Manual. Version 9.0.2208 Node.js support Node.js support is deprecated and will be removed in a future release of Splunk Cloud Platform. As soon as possible, update any private apps that depend on Node.js. For more information about the Node.js deprecation and updating your apps, see Node.js deprecation FAQ in Splunk Lantern. Version 10.0.2503 Hybrid search is deprecated. Hybrid search reached end-of-life on October 30, 2024 and is no longer a supported feature. Customers who currently use hybrid search must migrate to Federated Search for Splunk. See Migrate from hybrid search to Federated Search for Splunk in Federated Search. Version 10.0.2503 Deprecation of exporting PDFs, scheduling PDF delivery, and printing PDFs with Classic Simple XML dashboards. Exporting dashboard PDFs, scheduling PDF delivery, and printing PDFs with Classic Simple XML dashboards is deprecated and will be removed in a future release. Version 9.3.2408 The Splunk platform REST API spawn_process parameter is deprecated. Do not use the spawn_process parameter. It is deprecated and will be removed in a future release. Version 9.2.2403 The /services/search/commands REST API endpoint is deprecated. The undocumented /services/search/commands REST API endpoint is deprecated and will be removed in a future release. If you have been inadvertently using this endpoint, stop using it. Version 9.1.2312 Deprecated Splunk platform search execution methods The phased_execution_mode setting is deprecated. Contact Splunk Support to remove this setting from the limits.conf file for your Splunk Cloud Platform deployment if your users get the following warning message: Contact your administrator to remove the 'phased_execution_mode' setting in limits.conf, so this message is not displayed again. Version 9.0.2305 jQuery 3.5 by default Splunk Cloud Platform now uses jQuery 3.5 by default. The self-service toggle in the UI to re-enable the old jQuery libraries has been removed. Splunk Cloud administrators can no longer choose to enable lower versions in the Internal Library Settings. Users must use the version 3.5 jQuery libraries that are packaged with the Splunk platform by default. Splunk will remove support for all older versions of jQuery in a future release. Version 9.0.2305 Deprecated use of the _reload action with the rest search command Use of the _reload action with the rest command is deprecated. Do not use the _reload action with the rest command. Version 9.0.2208 Disabled audit search command The previously deprecated audit search command is now disabled for all customers as of 8.2.2203. Version 8.2.2203 Disabled createrss command The previously deprecated createrss command is now disabled for all customers as of 8.2.2203. Version 8.2.2203 HTML Dashboards Deprecation As of Splunk Cloud Platform 8.2.2105 and Splunk Enterprise 8.2, Splunk has deprecated HTML Dashboards. If you choose to continue to use HTML dashboards, you are responsible for maintaining the dashboards. You can rebuild your HTML dashboards in Dashboard Studio. Version 8.2.2105

Removed features

Removed feature | What do I need to know? | First deprecated
Splunk Product Guidance (SPG) application | The Splunk Product Guidance (SPG) application is removed in Splunk Cloud Platform versions 9.3.2411 and higher. | Version 9.3.2411
Internal Library Settings | The Internal Library Settings page is removed. Deprecated libraries and unsupported hotlinked imports are restricted, and Splunk Cloud Platform no longer offers a self-service option to use them. For more information about Internal Library Settings, see Control access to jQuery and other internal libraries in the jQuery Upgrade Readiness manual. | Version 9.2.2403
The relevancy command is removed. | Do not use the relevancy command. | Version 9.1.2312
The timeout argument for the append command is removed. | Do not use the timeout argument. It has no effect on searches. | Version 9.1.2312
Removal of the populate_lookup alert action | The legacy alert action, populate_lookup , has been removed. Use the lookup alert action instead. | Version 9.1.2308
Stats V1 removal | Version 1 of the stats command has been removed and replaced with version 2 of the stats command. | Version 9.0.2303
Removed file command | The previously disabled file command is now removed for all customers as of 9.1.2312. | Prior to version 8.2.2202
The etc/searchscripts directory | Support for the etc/searchscripts directory has been removed, as of version 8.2.2201. All search commands must now be declared in the commands.conf file. | Prior to version 8.2.2201
Offload UI state from SHC conf | The ability for Apps to specify custom user interface preferences via ui-prefs.conf such as time picker has been removed. This means that application specific UI preferences will not be applied. Users will still be able to set their UI preferences. | Version 8.2.2105
Removed biased language | Biased language has been removed from the Splunk Web UI, in keeping with Splunk's commitment to equality in our actions and products. | Version 8.2.2105
Documentation set improvements | In response to customer feedback, the information in the Splunk Cloud User Manual has been added to the Splunk Cloud Platform Admin Manual and the Splunk Cloud Security Manual, and the Splunk Cloud User Manual has been removed from the documentation set. | Version 8.2.2105
Removed ability to convert dashboards to HTML | This option is no longer available to users in Splunk Web. | Prior to version 8.0.2004

Original source

Known and fixed issues for Splunk Cloud Platform

This page lists selected known issues and fixed issues for this release of Splunk Cloud Platform. Use the Version drop-down list to see known issues and fixed issues for other versions of Splunk Cloud Platform.

See also the release notes for the Cloud Monitoring Console app and the Admin Configuration Service for their respective known and fixed issues.

Version 10.2.2510

This version includes the following known issues:

• Date filed or added: 2025-12-15
  Issue number: SPL-292559
  Description: In deployments using the Azure Victoria Experience, during DDAA restores, buckets involved in an active restore might be removed from SmartStore. It can occur if the buckets were part of a recent restore that was just cleared. It results in incomplete restores where those buckets don't appear in search results, even though the restore request completes successfully.
  Note: This issue applies only to restored data. It doesn't affect the original archived data.
  Workaround: Avoid quickly repeating the restore, clear, and restore sequences of operations that reuse the same buckets or time ranges in an index. Allow more than 2 hours for any previously scheduled remote freeze operations to complete before starting another restore involving the same buckets.

• Date filed or added: 2025-06-13
  Issue number: SPL-279299
  Description: Some dashboard panels reflect inconsistent results when exported to PDF. If a dashboard panel uses a post-processing search that contains newline characters, the data shown in the exported PDF might not match what is shown in the dashboard itself. This happens because Splunk generates a different cache key for the PDF export compared to the dashboard view, which can cause the PDF to display incorrect or outdated results. For example, you might notice that the "Number of distinct users by privacy setting" column chart shows much lower values in the PDF than in the dashboard panel. You should check your exported PDFs carefully and look for errors in your system logs if your dashboards use post-processing searches with newlines.

• Date filed or added: 2025-02-04
  Issue number: SPL-270271
  Description: Scheduled email exports of large dashboards compress images to approximately 1440 x 960 pixels, leading to blurry PDFs.
  Workaround: Reduce the dimensions of the dashboard, or split up large dashboards into separate smaller dashboards. Scheduled export compresses the studio dashboard to a resolution of approximately 1440 x 960 pixels before it is screenshotted for the PDF. Reducing the dimensions of the dashboard closer to this resolution should improve the visibility and quality of the export. If you split the dashboard into smaller dashboards, and schedule them to export separately, this effectively reduces the dimensions of each dashboard and improves the quality of each exported PDF.

• Date filed or added: 2024-02-02
  Issue number: SPL-270072
  Description: Federated Search for Splunk - Proxy bundles are not reaped when external authentication is enabled on the remote deployment.
  Workaround: On the remote search head, turn external authentication on only for token authentication. On the remote deployment go to Settings, then Authentication methods, then SAML configuration, and then Authentication extensions. Select For Token Authentication Only. Set Get User Info time-to-live to 21600s.

• Date filed or added: 2024-12-11
  Issue number: SPL-267847
  Description: Federated Analytics - Users cannot remove data lake indexes from a federated provider via the UI. When a data lake index is removed, it is no longer part of a federated provider definition, and it no longer ingests data from a Amazon Security Lake dataset. Removed data lake indexes can still be managed through the Indexes page.

• Date filed or added: 2024-08-12
  Issue number: SPL-260620
  Description: When a dashboard's permissions are changed in Dashboard Studio, this creates a new version of the dashboard. If you revert to a previous version of the dashboard, permissions changes are not automatically reverted. To work around this issue, change permissions manually.

• Date filed or added: 2024-08-06
  Issue number: SPL-260273
  Description: If you select the tips actions when comparing dashboards in the Monaco editor, the page might fail to render properly. Do not select the tips, represented by a lightbulb icon, in the dashboard version history source comparison view.

• Date filed or added: 2024-06-04
  Issue number: SPL-237180
  Description: Saved searches on Splunk Cloud Platform that are owned by nobody are scheduled using the default time zone settings in the user-prefs.conf file instead of the system time zone in Splunk Cloud. But, searches are run internally as splunk-system-user, which is tied to system time in Splunk Cloud Platform and is based on UTC (Coordinated Universal Time). The mismatch between the default time zone settings in the user-prefs.conf file and Splunk Cloud system time can lead to potential discrepancies in search results under certain conditions when the time zones for nobody and splunk-system-user get out of sync.
  Workaround: If you're experiencing mismatched time zones with nobody owned searches following migration from Splunk Enterprise to Splunk Cloud Platform, reassign searches to a user account attached to a role, so searches aren't assigned to nobody. An alternative workaround is to set the schedules for nobody-owned saved searches to UTC, which ensures that searches are the same as system time.

• Date filed or added: 2024-05-09
  Issue number: SPL-255559
  Description: Federated Search for Amazon S3: IAM Managed Policy limit of 6144 chars exceeded due to large number of resource level policies. If a Federated Search for Amazon S3 provider configuration within a single provider (or across several providers) for a given user have a large number of AWS Glue data catalog or AWS S3 resources, the IAM policy that is generated for attachment to the stack's IAM role can, in some cases, exceed the default 6144 character limit that is enforced by AWS. When the character limit is exceeded the IAM policy can't be applied and the connection to AWS fails.
  Workaround: To reduce the chance of generating an IAM managed policy that exceeds the 6144 character limit, when listing AWS Glue table names in the AWS Glue tables field, use wildcards to capture all tables that begin with the same prefix. For example, if you have several AWS Glue tables that begin with product_, enter product_* in the AWS Glue tables field. Do not do this for a given set of tables if there are tables beginning with the prefix to which you do not want to grant access.

• Date filed or added: 2024-04-12
  Issue number: SPL-254077
  Description: CIDR match for tstats with ipv6 addresses isn't supported. The tstats command currently doesn't filter events with CIDR match on fields that contain IPv6 addresses. Running tstats searches containing IPv6 addresses might result in the following error indicating that the addresses are treated as non-exact queries: Copy Error in 'TsidxStats': WHERE clause is not an exact query Error in 'TsidxStats': WHERE clause is not an exact query

• Date filed or added: 2024-01-05
  Issue number: SPL-240774
  Description: The DELIMS setting or the kvdelim option may not be applied correctly when the k/v delim character appears 2 or more times in a field value
  Workaround: Perform field extractions by modifying your searches using other commands, such as the rex command or eval command.

• Date filed or added: 2023-07-20
  Issue number: SPL-240969
  Description: props and transforms created with 000-self-services (000-self-services/local/transforms.conf) as the destination app get removed during sync triggered by actions such as saving rulesets in Ingest Actions.
  Workaround: Do not save search time field transformations to the 000-self-services app. Move the existing 000-self-services/local/transformations.conf under a different app.

• Date filed or added: 2023-05-30
  Issue number: Not applicable
  Description: ACS endpoint connections fail after June 4, 2023 or HEC sessions fail after June 14, 2023 with error messages that mention SSL, TLS, or HTTP error 503 or 525. See Cloud Platform Discontinuing support for TLS version 1.0 and 1.1.

• Date filed or added: 2022-08-23
  Issue number: SPL-228969
  Description: Federated Search: In Splunk Web federated index UI you cannot provide data model Dataset Name values that contain a dot ( . ) character
  Workaround: This is a limitation for users of standard mode federated search who want to set up federated indexes that map to data model datasets. It means that such users cannot set up federated indexes for data model datasets that are subordinate to a root dataset. For example, if the root data model dataset is Network_Traffic, you cannot map a federated index to the subordinate data model dataset Network_Traffic.All_Traffic. As a workaround, users can run tstats searches that use the nodename argument to filter out data that does not belong to a specific data model dataset: | tstats ... where nodename=Network_Traffic.All_Traffic.

• Date filed or added: 2022-07-29
  Issue number: SPL-227633
  Description: Error: Script execution failed for external search command 'runshellscript'
  Workaround: The setting precalculate_required_fields_for_alerts=0 can be set on saved searches that have no other alert actions attached aside from the "Run A Script" action, to quash the error. For saved searches that have multiple alert action attached, this might not be safe, because it will disable back propagation of required fields for all alert actions, which might result in the parent search extracting more fields than required, which could negatively impact performance for that search.

• Date filed or added: 2022-06-15
  Issue number: SPL-226877
  Description: Federated Search UI Error: Cannot create saved search dataset for federated index if dataset name contains space
  Workaround: Use REST API to create the federated saved search instead: curl -k -u : -X POST https://localhost:8089/servicesNS/nobody/search/data/federated/index -d name=federated:index_kathy -d federated.dataset='savedsearch:ss with space' -d federated.provider=remote_deployment_1. See Federated search endpoint descriptions in the REST API Reference Manual.

This version fixes the following issues:

• Date filed or added: 2025-09-03
  Issue number: SPL-285235
  Description: SPL: Unbounded count for the makeresults command results in OOM

• Date filed or added: 2023-03-02
  Issue number: SPL-236780, SPL-245274
  Description: Splunk Cloud Platform: Unable to delete SAML users and authorization tokens

Original source

Federated provider names are now case-insensitive

As of this release, federated provider names are case-insensitive for the following products:

• Federated Search for Splunk
• Federated Search for Amazon S3
• Federated Analytics for Amazon Security Lake

For example, say you have a provider named MyProvider and you try to create a new provider with a Provider name of myprovider. In this instance, Splunk software prevents you from creating the new provider until you choose a Provider name that is unique, regardless of alphabetical character case.

Note: If you are upgrading from a previous version of the Splunk platform, this might be a breaking change. If you have two or more federated providers in your Splunk platform deployment with names that differ only by case (such as one named MyProvider and another named myprovider), you must change the duplicate provider names to unique strings.

There are two ways to accomplish this:

• You can delete and recreate the federated providers with duplicate names.
• If you have access to the .conf files for your Splunk platform deployment, you can edit the duplicate federated provider names directly in federated.conf. You cannot edit federated provider names in Splunk Web.

If you choose to not delete or replace duplicate provider names, Splunk software uses the first name that appears in federated.conf. For example, if the MyProvider stanza appears before the myprovider stanza in federated.conf, Splunk software references only the MyProvider stanza when it receives any version of the string "myprovider".

Federated Analytics for Amazon Security Lake: Optional workload optimization for data lake indexes

If you use Federated Analytics for Amazon Security Lake, you now have the option to drive down the storage cost of your data lake indexes by turning off raw term search on those indexes. With this optimization enabled, your data lake indexes have reduced indexing and storage cost, with the trade-off being that the optimized indexes support only key-value search.
For more information, see Set up data ingest and retention rules for data lake indexes.

SPL2

SPL2 extends the existing SPL language by incorporating several powerful features. These features simplify data access and analysis while also providing support for complex investigations and data management workflows. With SPL2, you can write searches using either SPL or SQL syntax. This simplifies learning and using the language, and adds consistency to the language.
SPL2 is a unified search and streaming language, offering a single syntax for searching data in Splunk indexes, accessing federated data stores, and preparing data in-stream across various Splunk products. SPL2 is fully compatible, and can operate in parallel, with SPL.

• For specific release notes for SPL2, see SPL2 release notes
• For more information about SPL2, see What is SPL2? in the SPL2 Overview manual.

TLS verification for inter-sidecar communication

To enhance security, each sidecar uses a server data plane certificate when communicating with other sidecars through the direct port of the destination sidecar. Over a Transport Layer Security (TLS) connection on the direct port, the connecting sidecar verifies the certificate of the destination sidecar to ensure a trusted connection.
For more information, see Inter-sidecar communication.

DDAA supported on Azure

Splunk Dynamic Data Active Archive (DDAA), now supported on Azure, provides secure, long-term data retention for Splunk Cloud Platform. Using this Splunk-managed archive, you can restore your archived data within 24 hours and make it searchable for up to 30 days. DDAA eliminates the need for continuous indexing or additional infrastructure. It ensures data durability and security by extending retention beyond the searchable retention period.

Redesigned workflow: Index Archiving Configuration

To enhance user experience, the Add new index dialog box has been redesigned to offer a clearer and more intuitive workflow for configuring index archive settings. The dialog box now displays the Your Total Retention (days) section that indicates the number of days the archive is retained. The Splunk software calculates this number based on the Searchable retention (days) and Total retention settings that you specify.
For more information, see Configure archive settings for an index.

SPL2 support for Dashboard Studio

In Dashboard Studio, you can use SPL2 data sources in dashboards by doing one of the following:

• Create an SPL2 query from within a dashboard
• Reference an existing view from an SPL2 module
  See Create search-based visualizations with SPL2.

Targeted app installation on Victoria Experience (AWS only) (controlled availability)

Splunk Cloud Platform on Victoria Experience now offers targeted app installation. Previously, Splunk Cloud Platform installed apps by default on all search heads across a Victoria Experience deployment. With targeted app installation, you can now install apps on specific search heads or search head clusters, making it easier to isolate apps and control user access.
This enhancement aligns app installation features in Victoria Experience with Splunk Cloud Platform Classic Experience and Splunk Enterprise.
See Targeted app installation on Victoria Experience.

Original source