Falcon LogScale 1.236.0 GA (2026-04-14)

Version?Type?Release Date?Availability?End of SupportSecurity UpdatesUpgrades From?Downgrades To?Config. Changes?
1.236.0GA2026-04-14

Cloud

Next LTSNo1.177.01.177.0No

Hide file download links

Show file download links

Bug fixes and updates

Advance Warning

The following items are due to change in a future release.

  • Security

    • Starting from LogScale version 1.237, support for insecure ldap connections will be removed. Self-Hosted customers using LDAP will only be able to use ldaps secure connections.

Deprecation

Items that have been deprecated and may be removed in a future release.

Behavior Changes

Scripts or environment which make use of these tools should be checked and updated for the new configuration:

  • Queries

    • LogScale Regular Expression Engine V2 is now the default engine for queries. The previous engine remains in use for parsers, meaning for a limited time, the regex syntax in queries will differ from that of parsers unless the F flag is specified for parser regexes. For more information see Regular Expression Flags.

      The following expression constructions change meaning with the Regular Expression Engine V2:

      • Octal notation such as \nnn where n is a digit between 0-7 is no longer supported. Instead, use the hexadecimal notation options \xnn, \x{nnnn}, or \unnnn to achieve similar results.

        This change is being made because octal notation overlapped with the backreference syntax, making it easy for common errors to go unnoticed. For example, when trying to match IP addresses, a misplaced backslash like before 122 in the IP address 10\.82\.\122\.42 could cause the regex to match to an incorrect string like 10.82.R.42 rather than the intended IP address.

      • \v is now understood as vertical whitespace, not just the vertical tabulation (VT) character. To match the vertical tabulation character specifically, use \x0B.

      • \h is now understood as horizontal whitespace, not the literal character h. To match the character specifically, remove the backslash. To match the characters \h together, escape the backslash by using \\h.

      • Unrecognized escape sequences like \l no longer refer to the literal character and now produce an error.

      • \b now uses the same definition of "word character" as \w: any ASCII letter, digit, or the _ character.

      • Inline flags now apply to all branches of an alternation. For example, (?i)foo|bar is now interpreted as (?i)(?:foo|bar), whereas previously it applied only to the first branch (foo).

      These changes make LogScale's regular expressions more consistent with popular regex engines and syntaxes such as PCRE2, Java's regex engine, and ECMAScript's regex engine. Note that LogScale's regular expressions are not fully compatible with those engines.

      Note

      Regular expressions related to any of the previously mentioned non-LogScale regex engines and syntaxes are not compatible with LogScale. However, familiarity with any of them will help users feel more comfortable using LogScale's regular expression variant.

      For more information, see <docref></docref> .

      The Regular Expression Engine V2 also supports the following additional features not available in the previous engine:

      • Possessive quantifications/repetitions like a++ - this feature instructs the engine not to retain backtracking information, acting as "all or nothing" quantifications. Possessive quantifiers are particularly useful when matching non-overlapping character sets, such as \S++\s, and often result in improved performance compared to non-possessive equivalents such as \S+\s.

      • Positive and negative lookarounds like (?=X) - these are zero-width assertions that do not advance the match position, but assert that their bodies either match or do not match at the given position. For example, (?<!\/)\/(.+?)(?<!\\)\/ matches everything but newlines between two forward slashes that are not escaped. This is because `(?<!\/)` asserts that the preceeding character is not a backslash.

      Note

      These features are not available in parsers unless the F flag is used.

      Issues fixed in the new engine include the following:

      • An issue where the previous engine would run indefinitely when matching regular expressions that match the empty string has been resolved.

      • Multiple issues where otherwise valid regular expressions would fail to compile under the previous engine have been resolved.

      • An issue where a regex could cause the Java Virtual Machine (JVM) to crash has been resolved.

      • An issue where the case-insensitivity flag would interfere with boundary conditions has been resolved.

      • An issue where inline case-insensitivity flags would not properly apply to the corresponding group has been resolved.

      • An issue where the negated word character class \W would match digits has been resolved.

      • An issue where the previous engine would produce incorrect group numbering has been resolved.

      Warning and error messages may appear incorrectly formatted during the transition period while the previous regex engine is being phased out. This is expected behavior and messages will become more legible once the previous engine is fully removed.

      For more information, see <docref></docref> .

      For more information, see LogScale Regular Expression Engine V2.

New features and improvements

  • GraphQL API

    • The GraphQL mutation removeExpirationFromLimit has been added, which removes limit expiration.

      The mutation can be called as follows:

      graphql
      mutation removeExpFromLimit {
  removeExpirationFromLimit(input: {id: "<limitid>"}) {
    <some field you want to read from the returned limit after the removal of the expiration>
  }
}

      Previously, it was not possible to remove the expiration from a limit using the existing update call.

      Note

      This mutation requires either ManageClusters or ManageOrganizations permissions on the cluster.

  • Queries

    • Cross-view asset references are now supported in queries and parsers, allowing users to reference saved queries, parsers, and files from other views using the following syntax.

      • Saved queries - $"query://viewName:queryName"() or $"query://viewName/scope/package:queryName"() for package-scoped queries.

      • Parsers - $"parser://viewName:parserName"() or $"parser://viewName/scope/package:parserName"() for package-scoped parsers.

      • Files - file://viewName:fileName or file://viewName/scope/package:fileName for package-scoped files.

      This feature requires ReadAccess permission on both the source view (where the query or parser runs) and the target view (where the asset is located). The feature is supported in:

      • Queries, including join() and defineTable() subqueries, and triggers (alerts and scheduled searches).

      • Parsers - parsers can reference cross-view saved queries and files during data ingestion.

      Note

      This feature's capability is only functional for parsers with view-level tokens that are set up to include the set of views referenced in the parser, and/or organization and system-level tokens.

      Cross-view references are not supported and are actively blocked for parsers and saved queries used by:

      • Event forwarding rules

      • Ingest tokens

      • Ingest listeners

      • Ingest feeds

      • FDR feeds

      Validation is enforced both at assignment time (when associating a parser with one of these features) and when updating a parser or saved query already part of a chain. This includes transitive references through parser and saved query chains.

      Cross-view references are also not supported for:

      • Shared dashboard tokens - these tokens can only query the main view and cannot access cross-view references.

      • The deprecated lookup() query function - use the match() function instead.

      A new GraphQL field qualifiedName has been added to the SavedQuery output type. This field returns the fully qualified reference format, for example query://viewName:queryName or query://viewName/scope/package:queryName for package-scoped queries.

      The existing redirectQueryAssetLookupTo feature continues to work for implicit (non-prefixed) references. Explicit cross-view references using the query:// or file:// prefix override the redirect setting.

      For more information, see Resolving Resources to a Different Named View or Repository.

  • Fleet Management

    • A new column has been added to the Fleet overview section, displaying security findings for each collector.

Fixed in this release

  • User Interface

    • When uploading lookup files, the Import files dialog now correctly rejects invalid file types also when using the drag-and-drop method. Previously, the file validation only occurred when using the Browse computer button.

  • Automation and Triggers

    • Fixed an issue where aggregate alerts could trigger at a future time when an alert was behind and running static queries to catch up, and was configured with trigger mode Immediate (the default for aggregate alerts using @timestamp).

  • Ingestion

    • Fixed an issue where a misconfigured ingest feed would prevent the initialization of other feeds during the initialization process.

  • Queries

    • Fixed an issue where JSON files could be exported as empty files instead of containing the expected content.

Known Issues

  • Storage

    • For clusters using secondary storage where the primary storage on some nodes in the cluster may be getting filled (that is, the storage usage on the primary disk is halfway between PRIMARY_STORAGE_PERCENTAGE and PRIMARY_STORAGE_MAX_FILL_PERCENTAGE), those nodes may fail to transfer segments from other nodes. The failure will be indicated by the error java.nio.file.AtomicMoveNotSupportedException with message "Invalid cross-device link".

      This does not corrupt data or cause data loss, but will prevent the cluster from being fully healthy, and could also prevent data from reaching adequate replication.

Improvement

  • Fleet Management

    • The following improvements have been made to the Fleet Overview section:

      • A badge is now displayed in the hostname column when the collector is running in FIPS mode.

      • A new column has been added that displays the user agent reported by the collector.

  • Auditing and Monitoring

    • The field extraLogFields from query input is now logged in query audit and activity logs, exposed with the prefix customKey. For example, a field in extra log keys named traceId=123 will be logged as customKey.traceId=123 in the audit and activity logs.