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

The release notes build number has changed, so it 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.

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

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

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.

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.

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.

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.

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 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.

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.

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.

(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) 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) The closeNotes field was not searchable.

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

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

(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.