Minor Releases - Release Notes - 6.9 - Cortex XSOAR - Cortex - Security Operations

Cortex XSOAR Release Notes

Product
Cortex XSOAR
Version
6.9
Creation date
2022-09-01
Last date published
2024-02-07
End_of_Life
EoL
Category
Release Notes

Cortex XSOAR Minor Release

Release Date

Cortex XSOAR 6.9.0 (B177754)

November 18, 2022

For details how to download and install the latest version, see Upgrade Your Installation.Upgrade Your Installation

Cortex XSOAR 6.9.0 (B177754)

Cortex XSOAR 6.9.0 (B177754) is a maintenance release that delivers the following new features, breaking changes, and bug fixes:

New Features

  • The release notes build number has changed; the build number now starts with B17x.

  • The SSO endpoint for Marketplace has been updated. You no longer need to add a server configuration to access Marketplace for paid content packs.

  • You can now turn quiet mode on or off for individual manual tasks.

  • (Multi-tenant) When syncing to the tenant, you can now add or remove incident field propagation labels to determine whether incident fields are propagated.

Security Fix

CVE-2022-0031 Cortex XSOAR: Local Privilege Escalation (PE) Vulnerability in Cortex XSOAR Engine was fixed.

Fixed Issues

  • When using a remote repository, it sometimes took a long time to load the local changes.

  • Fixed issue where a value that’s too large was added in the websocket buffer size, causing the server to crash.

  • When writing an automation that called a system automation, the container running the system automation would run the commonUserPython even though it was disabled by a configuration file.

  • The query for loading exclusion list indicators was not optimal.

  • When an incident had an attachment resulting from a data collection task, the attachment could not be downloaded from the incident layout.

  • In some cases, reports in CSV format contained a newline character at the end of the incident name.

  • When a user completed a manual task and did not add a completion note, the user who completed the task was not logged in the task or in the War Room, and was not automatically added to the investigation. This also occurred with automated tasks that stopped on an error and were marked as completed by a user.

  • For queries on incidents in the dashboard, filtering by indicator verdict did not work properly.

  • If you paused a playbook when it was running a sub-playbook and it was not executing the last task in that sub-playbook, the playbook would not resume when you clicked Resume a playbook (play button).

  • When running a playbook, tasks were sometimes marked as completed by random users in the War Room. You can now add the following system configuration, which resolves the issue: server.mail.listener.suppress.user.mail.check : false.

  • In the integration Settings page, timeout errors occurred when migrating settings from development to production environments.

  • An empty chart was displayed in the Dashboard when using a custom widget with a custom time field in group by and decreasing the time increment from days to hours or less.

  • In some cases, when creating a widget for a single day and configuring the Group by to Date Occurred, the results were split over two days.

  • When a pre-processing rule ran a script that searched for incidents, incidents in the temp index were not found.

  • Sometimes indicators extracted from field values were not marked in the War Room field entry, but displayed ^^^ characters instead.

  • The indicator description field did not display data for indicator objects after changing the custom field type.

  • Indicators were not merged correctly, resulting in duplicate indicators and errors that the indicators did not exist, even though they did.

  • Indicator Extraction was performed even when the task was set to Quiet Mode.

  • In some cases, jobs ran repeatedly at short intervals, instead of on the job schedule.

  • When a job in the job table ran with an error, the table displayed the job status for the old incident in error, but redirected to the most recent incident created by the job.

  • When opening very large playbooks, the UI became slow and unresponsive.

  • When Cortex XSOAR was upgraded to v6.6 or later, the playbook.willnotexecute.old.eval server configuration was set to true.

  • If a key in context data had the same name as a playbook task, when the task ran, the value of the key was populated in the Work Plan instead of the task name.

  • When a playbook was running in debugger mode, any artifacts that were created could not be downloaded.

  • In some cases, when a sub-playbook input was shared across multiple tasks in that sub-playbook, a concurrent map read-write error caused the Cortex XSOAR server to crash.

  • In some cases, when opening a sub-playbook after processing an incident, the sub-playbook tab would hang on loading.

  • In some cases, when running playbooks, they did not always complete and some tasks showed incorrect information, due to a cache issue.

  • When running the playbook debugger, if you attempted to use the setPlaybook automation, the playbook did not continue to run. The setPlaybook automation is not supported within the playbook debugger. An error is now displayed with this information.

  • When clicking Ask by in a data collection task, nothing happened.

  • Selected indicators reappeared in other pages in the Threat Intel library after doing a select all for one page of results.

  • When clicking on a link in an email from a data collection task in a playbook, sometimes data was missing from the data collection form.

  • In some cases, playbook error handling did not work as selected. When the Continue or Continue on error path(s) options was selected, a failed task was marked as successful and the next task continued along the main path and not on the error path.

  • After a service restart, the playbooks that were previously in a running state did not continue running when there were more than 50 incidents.

  • In some cases, when opening a sub-playbook after processing an incident, the sub-playbook tab would hang on loading.

  • When the getUsersByUsername command returned multiple roles, all of the roles were returned under key Role.0, instead of as separate keys - Role.0, Role.1, Role.2, etc.

  • In rare cases, after re-indexing a database, the indexing configurations for fields were distorted, causing queries to return the wrong results for historical data.

  • When using the !createNewIndicator command with the merge=false argument, if the indicator value already existed in the database it was duplicated instead of being overwritten.

  • In some cases, when a pre-processing rule attempted to link two incidents and close the duplicate incident, the duplicate incident was not closed.

  • When you purged large Work Plans through either the System Diagnostics page or the API, an error was returned, even though the Work Plan was purged.

  • The no_proxy server configuration in Cortex XSOAR was not passed to command/container runs in Docker/Podman.

  • (Hosted Service) The System Diagnostics page displayed incorrect information for Hosted Service limits.

  • (High Availability) In some cases, daily jobs were running multiple times a day, once on each App server.

  • (High Availability) When trying to assign comments from the War Room to tasks, in some cases an error was returned.

  • (Multi-tenant) When using Elasticsearch, there was an issue when fetching lists using the {lists.XXX} resolver.

  • (Multi-tenant) The host waited for all accounts to start before the host would start.

  • (Multi-tenant) After configuring a DUO integration to authenticate login, DUO authentication failed when logging into Cortex XSOAR.

  • (Multi-tenant with High Availability) When an account was created on one host, errors related to that account appeared on other hosts.

  • (Multi-tenant with Remote Repository) - When the name of a content pack changed, tenants no longer received updates to the content pack.

  • (Elasticsearch) When configuring an incoming mapper, incident fields were not sorted alphabetically, after migrating from BoltDB to Elasticsearch.

  • (Elasticsearch) In Elasticsearch, template creation requests were sent too many times.

  • (Elasticsearch) There was no option to disable large or unqueried fields in Elasticsearch.

  • (Elasticsearch) When using OpenSearch, the System Diagnostics page displayed a warning for Old Elasticsearch version.

  • (Elasticsearch) When closing an investigation, the Incidents I own and Incidents I participated in sections in the sidebar were blank, when the page refreshed.

  • (Elasticsearch) A job that queried many playbooks could crash Elasticsearch.

  • (Elasticsearch) New values for new custom fields were not added to the indices in Elasticsearch.

  • (Elasticsearch) Uppercase boolean fields were not indexed.

  • (Elasticsearch) Many empty requests were sent to the Elasticsearch database causing slow performance.

  • (Elasticsearch) The closeNotes field was not searchable.

  • (Elasticsearch) If elasticsearch.maxContentLength was set by the user in the demisto.conf file, the value was not applied and the value of http.max_content_length from the Elasticsearch settings was used instead.

Installation file hash: 7cc3ebd7eb20c0d661a03ab1406b65f3f1dc93976ae0f0983af7b88d4c264e5c.