Splunk Release Notes

Last updated: Feb 20, 2026

Splunk Products

All Splunk Release Notes (22)

  • Feb 18, 2026
    • Date parsed from source:
      Feb 18, 2026
    • First seen by Releasebot:
      Feb 20, 2026
    Splunk logo

    Splunk Cloud Platform by Splunk

    The Ingest Processor solution

    Splunk Cloud’s Ingest Processor receives a steady stream of feature releases, from AI-assisted field extraction and batch data aggregation to decryption, XML/JSON tooling, templates, and expanded cloud regions. This is a genuine release log showing new capabilities.

    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 Report a problem
  • Feb 12, 2026
    • Date parsed from source:
      Feb 12, 2026
    • First seen by Releasebot:
      Feb 20, 2026
    Splunk logo

    Splunk Cloud Platform by Splunk

    The Edge Processor solution

    The Edge Processor in Splunk Cloud Platform has a steady stream of release notes through 2025 and 2026, adding real world capabilities like bigger source type sync, batch event aggregation, and new pipeline templates. It also brings decryption, PCRE2 support, HEC improvements, and expanded data handling options.

    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 Report a problem
  • All of your release notes in one feed

    Join Releasebot and get updates from Splunk and hundreds of other software products.

  • Feb 12, 2026
    • Date parsed from source:
      Feb 12, 2026
    • First seen by Releasebot:
      Feb 20, 2026
    Splunk logo

    Splunk Cloud Platform by Splunk

    Splunk Cloud Platform Maintenance Patch Release Information

    Splunk Cloud Platform maintenance patch notes reveal a broad set of fixes across 10.2.2510.x and earlier, including Python 3.13.11 upgrade, improved stability, and performance enhancements. The page confirms a regular weekday release cadence and deployment windows.

    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 Report a problem
  • Feb 5, 2026
    • Date parsed from source:
      Feb 5, 2026
    • First seen by Releasebot:
      Feb 20, 2026
    Splunk logo

    Splunk Cloud Platform by Splunk

    Cloud Monitoring Console

    Promote metrics now appear on Ingest and Workload dashboards with Federated Analytics and standard ingestion, including a 7‑day total ingestion view and a new license usage filter. The release also fixes replication factor display, removes false MC alert for lastchanceindex, and updates Health to properly show Splunk 10.2 forwarders.

    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 Report a problem
  • Feb 4, 2026
    • Date parsed from source:
      Feb 4, 2026
    • First seen by Releasebot:
      Feb 5, 2026
    Splunk logo

    Splunk Enterprise Security by Splunk

    Splunk Enterprise Security 8

    Splunk Enterprise Security 8.4.0 delivers Detection Studio improvements, smarter event and finding based detections, new macros, default detection versioning, enhanced investigations, AI Assistant, GCP with SOAR, unified threat data configuration, and team-based queues. Upgrade notes cover backup and compatibility.

    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 Report a problem
  • Jan 15, 2026
    • Date parsed from source:
      Jan 15, 2026
    • First seen by Releasebot:
      Feb 4, 2026
    • Modified by Releasebot:
      Feb 11, 2026
    Splunk logo

    Splunk Enterprise by Splunk

    Welcome to Splunk Enterprise 10.2

    Splunk Enterprise 10.2 launches with field filters by default, Parquet data in S3, Edge Processor upgrades and SPL2 expansions. It also adds AI Assistant for SPL, OAuth2 support, OTel metrics improvements and revamped dashboards.

    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, and now 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. Field filters are now visible for customer use by default, eliminating the requirement for administrators to turn on the feature by configuring limits.conf and web-features.conf files. 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. Note: Plan carefully before deploying field filters, especially if using downstream configurations or Splunk Enterprise Security.

    • 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) and newer versions are now supported (Debian 12+, RHEL 9+, RockyLinux 9+, SUSE Linux Enterprise 15.0 SP6+, Ubuntu 24.04 LTS). Users must upgrade unsupported OS versions before upgrading their data management control plane to avoid data loss.

    • Edge Processor on Splunk Enterprise support for JSON array format as input: Now supports JSON array format input allowing square brackets and comma-separated objects.

    • Edge Processor on Splunk Enterprise monitoring dashboards: Updated UI to visualize metrics and health of Edge Processors, including inbound/outbound data volume and logs.

    • Updated systemd configuration instructions: Updated to ensure more graceful shutdown procedures by specifying KillMode=mixed in systemd unit file.

    • Support for OAuth2.0 for 3rd party and external applications: Administrators can configure OAuth 2.0 for products like Data Analytics and User Behavior Analysis tools to connect to Splunk platform through REST APIs.

    • Improvements to O11y Metrics & Charts in Splunk Dashboard Studio: Users can leverage observability application service map views in dashboards with incremental improvements and bug fixes.

    • Splunk AI Assistant for SPL in the Search app is now available in Splunk Enterprise: Helps users generate, explain, and translate SPL using natural language, supporting faster onboarding and improved productivity. Requires Splunk AI Assistant for SPL app version 1.3.2 or higher.

    • Remove Node.JS: Node.js is removed; customers must update apps dependent on Node.js to bundle their own version.

    • SPL2: Extends SPL language with powerful features, supports SPL or SQL syntax, unified search and streaming language, fully compatible with SPL. Some Linux versions not supported in 10.2.

    • Federated provider names are now case-insensitive: Provider names must be unique regardless of case; duplicate names must be changed.

    • SPL2 support for Dashboard Studio: Use SPL2 data sources in dashboards by creating SPL2 queries or referencing existing views.

    • Other Dashboard Studio enhancements: See What's new in Dashboard Studio.

    • Ingest-Tier Scaling: High-throughput, scalable data ingestion for self-managed Splunk deployments.

    • Bulk Data Movement between Indexes: Efficiently reorganize indexes and move data using specific search criteria; available only in non-SmartStore clustered environments.

    • Effective configuration of OTel Collectors: View complete active configuration for each OTel Collector agent communicating using OpAMP.

    • Agents lookup: Improves performance in agent management UI by retrieving agent data from cached CSV lookup file.

    • Agent management UI/UX enhancements: Unified forwarders and OpenTelemetry management with automated wizard for server class creation.

    • Destination configuration on agent management: Configure S3 and file system destinations directly from agent management; requires agent management version 10.2 or higher.

    • Queued ad hoc search quotas: Configurable limits on number of ad hoc searches queued at system and role levels to prevent performance issues.

    • TLS verification for inter-sidecar communication: Sidecars use server data plane certificates and verify certificates over TLS connections.

    • Using Nascent to ensure correct configuration on search head clusters: Nascent sidecar manages etcd service for consistent configuration and service discovery.

    • Audit Trail Log v2: Structured audit log format using JSON compliant with Common Information Model (CIM), suitable for compliance.

    • Python 3.13 is available on an opt-in basis: Splunk platform uses Python 3.9 by default; Splunk Web uses Python 3.13 only.

    • KV store server version 8.0 is available: Upgrade from version 7.0; version 7.0 will be removed in future releases.

    • Run Splunk Enterprise without the root option: Splunk Enterprise no longer runs as root by default; use --run-as-root to run as root.

    • Monitoring Console Overview Dashboard (beta) redesign: Updated dashboard for improved user experience and efficiency with personalized metrics and alerts.

    For more detailed information, see the respective linked documentation and release notes.

    Original source Report a problem
  • Jan 15, 2026
    • Date parsed from source:
      Jan 15, 2026
    • First seen by Releasebot:
      Jan 16, 2026
    • Modified by Releasebot:
      Jan 17, 2026
    Splunk logo

    Splunk Enterprise by Splunk

    Splunk Enterprise 10.2

    Splunk Enterprise 10.2 arrives with field filters on by default, Parquet data on S3, Edge Processor OS updates, OAuth2.0 support, SPL2 and AI Assistant for SPL, plus Dashboard Studio and admin UI improvements for a faster, more secure on‑prem experience.

    Splunk Enterprise 10.2

    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, and now 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 General Data Protection Regulation (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: Field filters are now 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. 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: Due to updates in Splunk Enterprise 10.2 that address CVEs, breaking changes have been made to Edge Processor on Splunk Enterprise-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 is 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.

    • 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 or 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-49open_in_new. 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 appsopen_in_new.

    • 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 Report a problem
  • Jan 13, 2026
    • Date parsed from source:
      Jan 13, 2026
    • First seen by Releasebot:
      Feb 20, 2026
    Splunk logo

    Splunk Cloud Platform by Splunk

    SPL2

    SPL2 expands SPL with SQL syntax, a unified search and streaming engine, and parallel SPL compatibility. It simplifies data access across Splunk products and federated stores with a single language workflow.

    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 Report a problem
  • Jan 13, 2026
    • Date parsed from source:
      Jan 13, 2026
    • First seen by Releasebot:
      Feb 20, 2026
    Splunk logo

    Splunk Cloud Platform by Splunk

    Known Issue: Changes to how the Splunk platform automatically maps SAML groups to Splunk roles

    Splunk Cloud Platform briefly disabled auto-mapping of SAML groups to Splunk roles in 9.2.2403.102–104, causing login errors. The behavior is being reversed in 9.2.2403.105+ and a UI-based restore workflow is provided for users to re-enable auto-mapped roles. This change affects SAML only, not native Splunk users.

    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 Report a problem
  • Jan 13, 2026
    • Date parsed from source:
      Jan 13, 2026
    • First seen by Releasebot:
      Feb 20, 2026
    Splunk logo

    Splunk Cloud Platform by Splunk

    Splunk Cloud Platform Field alias behavior change

    Splunk Cloud Platform 7.2.4 fixes field alias behavior by removing alias fields when no source exists and adds ASNEW to keep existing values intact. It also introduces Overwrite field values and guidance on using calculated fields to resolve conflicts.

    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 Report a problem

Related vendors