8.18

Details
On July 8, 2025, a known issue was discovered in Elastic Defend’s network driver that may lead to kernel pool corruption, resulting in bug checks (BSODs) on Windows systems with a large number of long-lived network connections that remain inactive for 30+ minutes.

The system may bug check with any of a variety of codes such as SYSTEM_SERVICE_EXCEPTION or PAGE_FAULT_IN_NONPAGED_AREA.

For more information, check #90

Workaround
Upgrade to the fixed version: 8.18.3+build202507101319.

If you’re unable to upgrade or downgrade, set the advanced.kernel.network advanced setting to false in your Elastic Defend integration policy.

Resolved
This issue is fixed in Elastic Stack version 8.18.4.

Details
On May 30, 2025, it was discovered that the entity risk score feature may stop persisting risk score documents if risk scoring was turned on before you upgraded to Elastic Stack 8.18.0 or higher.

This is due to a bug that prevents the entity_analytics_create_eventIngest_from_timestamp-pipeline-<space_name> ingest pipeline (which is set as a default pipeline for the risk scoring index in Elastic Stack 8.18.0) from being created when Kibana starts up.

While document persistence may initially succeed, it will eventually fail after 0 to 30 days. This is how long it takes for the risk score data stream to roll over and apply its underlying index settings to the new default pipeline.

Workaround

To resolve this issue, apply the following workaround before or after upgrading to Elastic Stack 8.18.0 or higher.

First, manually create the ingest pipeline in each space that has entity risk scoring turned on. You can do this using a PUT request, which is described in the example below. When reviewing the example, note that default in the example ingest pipeline name below is the Kibana space ID.

PUT /_ingest/pipeline/entity_analytics_create_eventIngest_from_timestamp-pipeline-default
{
  "_meta": {
    "managed_by": "entity_analytics",
    "managed": true
  },
  "description": "Pipeline for adding timestamp value to event.ingested",
  "processors": [
    {
      "set": {
        "field": "event.ingested",
        "value": "{{_ingest.timestamp}}"
      }
    }
  ]
}

After you complete this step, risk scores should automatically begin to successfully persist during the entity risk engine’s next run. Details for the next run time are described on the Entity risk score page, where you can also manually run the risk score by clicking Run Engine.

Resolved
This issue is fixed in Elastic Stack version 8.18.3.

Details
On May 30, 2025, it was discovered that the entity risk score feature may stop persisting risk score documents if risk scoring was turned on before you upgraded to Elastic Stack 8.18.0 or higher.

This is due to a bug that prevents the entity_analytics_create_eventIngest_from_timestamp-pipeline-<space_name> ingest pipeline (which is set as a default pipeline for the risk scoring index in Elastic Stack 8.18.0) from being created when Kibana starts up.

While document persistence may initially succeed, it will eventually fail after 0 to 30 days. This is how long it takes for the risk score data stream to roll over and apply its underlying index settings to the new default pipeline.

Workaround

To resolve this issue, apply the following workaround before or after upgrading to Elastic Stack 8.18.0 or higher.

First, manually create the ingest pipeline in each space that has entity risk scoring turned on. You can do this using a PUT request, which is described in the example below. When reviewing the example, note that default in the example ingest pipeline name below is the Kibana space ID.

PUT /_ingest/pipeline/entity_analytics_create_eventIngest_from_timestamp-pipeline-default
{
  "_meta": {
    "managed_by": "entity_analytics",
    "managed": true
  },
  "description": "Pipeline for adding timestamp value to event.ingested",
  "processors": [
    {
      "set": {
        "field": "event.ingested",
        "value": "{{_ingest.timestamp}}"
      }
    }
  ]
}

After you complete this step, risk scores should automatically begin to successfully persist during the entity risk engine’s next run. Details for the next run time are described on the Entity risk score page, where you can also manually run the risk score by clicking Run Engine.

Resolved
This issue is fixed in Elastic Stack version 8.18.3.

Details
On April 8, 2025, it was discovered that alert suppression for event correlation rules is incorrectly shown as being in technical preview when you create a new rule. For more information, check #1021.

Resolved
This issue is fixed in Elastic Stack version 8.18.2.

Details
On May 30, 2025, it was discovered that the entity risk score feature may stop persisting risk score documents if risk scoring was turned on before you upgraded to Elastic Stack 8.18.0 or higher.

This is due to a bug that prevents the entity_analytics_create_eventIngest_from_timestamp-pipeline-<space_name> ingest pipeline (which is set as a default pipeline for the risk scoring index in Elastic Stack 8.18.0) from being created when Kibana starts up.

While document persistence may initially succeed, it will eventually fail after 0 to 30 days. This is how long it takes for the risk score data stream to roll over and apply its underlying index settings to the new default pipeline.

Workaround

To resolve this issue, apply the following workaround before or after upgrading to Elastic Stack 8.18.0 or higher.

First, manually create the ingest pipeline in each space that has entity risk scoring turned on. You can do this using a PUT request, which is described in the example below. When reviewing the example, note that default in the example ingest pipeline name below is the Kibana space ID.

PUT /_ingest/pipeline/entity_analytics_create_eventIngest_from_timestamp-pipeline-default
{
  "_meta": {
    "managed_by": "entity_analytics",
    "managed": true
  },
  "description": "Pipeline for adding timestamp value to event.ingested",
  "processors": [
    {
      "set": {
        "field": "event.ingested",
        "value": "{{_ingest.timestamp}}"
      }
    }
  ]
}

After you complete this step, risk scores should automatically begin to successfully persist during the entity risk engine’s next run. Details for the next run time are described on the Entity risk score page, where you can also manually run the risk score by clicking Run Engine.

Resolved
This issue is fixed in Elastic Stack version 8.18.3.

Details
If rule saved objects were corrupted when you upgraded from 7.17.x to 8.x, you may run into an error when turning on your rules.

Workaround

Duplicate your rules and enable them.

Details
On April 8, 2025, it was discovered that alert suppression for event correlation rules is incorrectly shown as being in technical preview when you create a new rule. For more information, check #1021.

Resolved
This issue is fixed in Elastic Stack version 8.18.2.

Details
When you install an Elastic Defend integration or a new agent policy for this integration, all the installed prebuilt detection rules are upgraded to their latest versions (if any new versions are available). The upgraded rules lose any user-added rule actions and exceptions, as well as any user customizations, if you customized any other rule fields.

Workaround
To resolve this issue, before you add an Elastic Defend integration to a policy in Fleet, apply any pending prebuilt rule updates. This will prevent rule actions, exceptions, and customizations from being overwritten.

Resolved
This issue is fixed in Elastic Stack versions 8.17.6, 8.18.1, and 9.0.1.

Details

An IRQL_NOT_LESS_EQUAL bugcheck in the Elastic Defend driver happens due to an interaction with Trellix Access Protection (mfehidk.sys). This issue can occur when elastic-endpoint-driver.sys calls FwpmTransactionBegin0 to initialize its network driver. FwpmTransactionBegin0 performs a synchronous RPC call to the user-mode Base Filtering Engine service. Trellix’s driver intercepts this service’s operations, causing FwpmTransactionBegin0 to hang or slow significantly. This delay prevents Elastic Defend driver from properly initializing in a timely manner. Subsequent system activity can invoke Elastic Defend’s driver before it has fully initialized, leading to a IRQL_NOT_LESS_EQUAL bugcheck. This issue affects Elastic Defend versions 8.16.0-8.16.6, 8.17.0-8.17.5, 8.18.0, and 9.0.0.

Workaround

If you can’t upgrade, either disable Trellix Access Protection or add a Trellix Access Protection exclusion for the Base Filtering Engine service (C:\Windows\System32\svchost.exe).

Resolved
This issue is fixed in Elastic Defend versions 8.17.6, 8.18.1, and 9.0.1.

Details

An unbounded kernel non-paged memory growth issue in Elastic Defend’s kernel driver occurs during extremely high event load situations on Windows. Systems affected by this issue will slow down or become unresponsive until the triggering event load (for example, network activity) subsides. We are only aware of this issue occurring on very busy Windows Server systems running Elastic Defend versions 8.16.0-8.16.6, 8.17.0-8.17.5, 8.18.0, and 9.0.0.

Workaround

If you can’t upgrade, turn off the relevant event source at the kernel level using your Elastic Defend advanced policy settings:

Resolved
This issue is fixed in Elastic Defend versions 8.17.6, 8.18.1, and 9.0.1.