Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions docs/release-notes.asciidoc
Original file line number Diff line number Diff line change
Expand Up @@ -3,6 +3,7 @@

This section summarizes the changes in each release.

* <<release-notes-8.19.23, {elastic-sec} version 8.19.23>>
* <<release-notes-8.19.22, {elastic-sec} version 8.19.22>>
* <<release-notes-8.19.21, {elastic-sec} version 8.19.21>>
* <<release-notes-8.19.20, {elastic-sec} version 8.19.20>>
Expand Down
26 changes: 26 additions & 0 deletions docs/release-notes/8.19.asciidoc
Original file line number Diff line number Diff line change
@@ -1,6 +1,32 @@
[[release-notes-header-8.19.0]]
== 8.19

[discrete]
[[release-notes-8.19.23]]
=== 8.19.23

[discrete]
[[enhancements-8.19.23]]
==== Enhancements
* Adds an **Update to Elastic version** bulk action to the Rule Updates table that force-upgrades prebuilt rules to the exact Elastic version, discarding any customizations on the updated rules ({kibana-pull}290589[#290589]).

[discrete]
[[bug-fixes-8.19.23]]
==== Fixes
* Fixes an issue where Attack Discovery didn't automatically select a connector when multiple were available, which disabled **Run** and caused attack discovery generation to fail with a "No model selected" error ({kibana-pull}293656[#293656]).
* Fixes an issue where detection rule failures caused by an invalid IP field query (such as a wildcard or literal value against an `ip` field) were classified as framework errors, which caused them to count against SLO dashboards ({kibana-pull}291256[#291256]).

@dplumlee dplumlee Oct 2, 2026 •

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm curious what our standard is for reporting/including things like these in the release notes where it's mostly a fix for internal reasons (SLO dashboards) and customers would theoretically not see any difference on their side of things. Not saying it's wrong to include or anything, I'm assuming this is going off the release_note tag but mostly just wondering if there's a defined best practice we have.

@nastasha-solomon nastasha-solomon Oct 6, 2026 •

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good question, and you're correct in that PRs with a non-skip release_note label are included in release notes. To see the full set of criteria that's considered, click on the expandable accordion in this section titled "How are labels used to categorize generated release notes?"

RE your question about release-noting PRs that make internal fixes:

I couldn't find explicit guidance for handling PRs like 291256, which help users avoid future rule failures (if I'm understanding the PR description correctly). For this case, I'd recommend using your best judgement on whether it should be included in the patch release notes. If you'd prefer to keep it in, here's a slightly-revised version of the PR summary that's more relevant to users:

Suggested change
* Fixes an issue where detection rule failures caused by an invalid IP field query (such as a wildcard or literal value against an `ip` field) were classified as framework errors, which caused them to count against SLO dashboards ({kibana-pull}291256[#291256]).
* Fixes an issue where detection rule failures caused by an invalid IP field query (such as a wildcard or literal value against an `ip` field) were incorrectly classified as rule execution errors ({kibana-pull}291256[#291256]).

* Fixes an issue where the Rule details **Alerts** tab could show no results, and throw a `tableById is undefined` error in the console, when the alerts table had not been initialized yet (typical on first visit or in a private window) ({kibana-pull}290076[#290076]).
* Fixes New Terms rule executions failing with `The content length (...) is bigger than the maximum allowed string (...)` when the documents fetched for new terms exceed `elasticsearch.maxResponseSize`. The rule now retries with smaller batches of terms and reports a warning instead of failing ({kibana-pull}290058[#290058]).
* Allows bulk upgrading non-customized prebuilt rules whose rule type changed in the target version (such as `query` to `eql`), instead of blocking the upgrade as a non-solvable conflict ({kibana-pull}288450[#288450]).
* Fixes rule exception items being deleted immediately from the actions menu with no warning. {kib} now shows a confirmation dialog before it deletes the exception item ({kibana-pull}286807[#286807]).
* Fixes high memory usage in {elastic-defend} on Linux when a single process repeatedly calls `exec`.
* Fixes {elastic-defend} retrying Kafka documents that were permanently rejected by the broker due to an invalid topic name. Delivery-report failures now log the topic name alongside the document ID and error code.
* Moves {elastic-defend} diagnostics bundles to its protected data directory instead of shared temporary storage, and removes leftover bundles from previous runs.
* Fixes a bug in {elastic-defend}'s Call Stack Attribution feature that could mis-name DLLs.
* Fixes {elastic-defend} on Linux rejecting Quark and eBPF event sources when only disabled probes were unsupported by the kernel.
* Hardens how {elastic-defend} moves, restores, and stores quarantined files on Linux and macOS.
* Scans the on-disk binaries of already running processes when {elastic-defend} becomes active and MalwareScore is enabled.

[discrete]
[[release-notes-8.19.22]]
=== 8.19.22
Expand Down
Loading