Addressed Issues - Release Notes - 6.5 - Cortex XSOAR - Cortex - Security Operations

When creating a new indicator and setting the tag in the new indicator modal, the feeds did not append the tags.

Number fields were formatted differently in the Incident view and Incident overview. Numbers are now always formatted without commas (,).

Creating a playbook task in the playground caused an error to occur.

When testing a filter and transformer, an error appeared when a child incident was selected for the test context.

When using the CreateNewIndicators command for any existing indicator that was fetched by a feed, the sourceBrands and sourceInstances fields were overridden.

If you deleted the last tag from a tag field, when closing the incident, a message appeared that the field was mandatory even though the actual field was not mandatory.

In a manual Data Collection task with a multi-select option, if there was only one option and it was selected by default, the option was not recognized as selected.

After creating a playbook, you could not edit a Data Collection task.

After configuring self-service read-only users with the SAML 2.0 integration (with Okta), read-only users (no role assigned) could not login, when authenticating via SAML, due to a permission error.

When using Elasticsearch and creating a new indicator, in some cases it was not possible to update the indicator immediately (without waiting for the index to refresh).

After installing the Common Types Content Pack, while getting installation warnings, some fields did not install.

Child incidents did not show in the incident info tab after the incident was closed.

TLS handshake errors were written to stdout.

When creating a new list, if you granted read only access to all roles and then also granted read-write access to one or more roles, no read-only users could view the list.

When emojis were used in markdown, in some cases ^^^ appeared in the output.

Large URL indicators could not be purged from the System Diagnostics page.

When a parent playbook had a restricted task which was then followed by sub-playbook A and sub-playbook A included sub-playbook B, the tasks in sub-playbook B would not execute and the parent playbook would not proceed.

Markdown tables with blank fields or spaces in fields did not display correctly in the artifact viewer.

When running Cortex XSOAR with a remote database, the Integrations & Incidents Health Check playbook failed.

When entering input and output overrides in the debugger, changes were saved even if Cancel was later selected.

During upgrade or re-installation, when using the --target option, the installer might have used an RPM belonging to a previously installed version.

Playground and debug sessions were listed in the System Diagnostics page, resulting in a failed search when users attempted to view the incident.

In certain cases when using Live Backup, after a failover to the disaster recovery server, new incidents were created using existing incident IDs and a subsection of earlier data was inaccessible.

Incident IDs were missing from the Audit trail when certain batch actions were performed on incidents.

When reopening an integration instance configuration page that contained an encrypted field that is both mandatory and had an initial default value, the form validation failed.

Users could not add multiple notes to an incident in succession without refreshing the browser first.

When files are created by tasks in playbooks that are in Quiet Mode, the system displayed the file ID, as the EntryID in the context data. In this situation, the system was unable to handle the file ID when returning the file from the entry.

When creating a load balancing group and adding an integration instance to the load balancing group, the Modules column in the Engines page displayed N/a.

If using an engine with a long running integration instance, when renaming the integration instance, a new container was created and the integration would not stop.

When typing a command in the War Room, after an incident was closed, Dbot returned an error message that the incident was closed with a link to reopen the Incident. After clicking the link to reopen the incident, the same message appeared again.

In a Live Backup environment, after a switchover to the backup server, some queries for custom fields did not return results.

When exporting a playbook to a PNG image, a delay in the export process led to an error message when the Export to PNG button was clicked twice.

If the audit bucket was missing, the System Diagnostics page did not load and the error 'Failed to retrieve the diagnostics data' was displayed.

In some cases, users could not select a saved query to use as the default query.

Dbot suggested assigning incidents to disabled users.

In an Elasticsearch deployment, when a user attempted to edit more than one indicator field, an error occurred.

The Data Collection task URL was sometimes truncated. When you clicked the link, it led to an error or a blank page.

When creating multiple new incidents from a JSON file in the same session, an error occurred.

In the Jobs page, the information for the last run of a job would sometimes be missing.

In a remote repository, when exporting a custom dashboard, the user who created and shared the dashboard couldn’t view it, after it was imported into the production environment.

In rare cases, when exporting a custom layout, if the file was large, some entries were truncated in the JSON file.

When accessing Cortex XSOAR through a reverse proxy and sending data from the reverse proxy to Cortex XSOAR, in the Audit trail, the Host/IP address of the Client IP of the reverse proxy was shown, rather than the real IP of the remote client.

In an incident, when clicking on Related Incidents in the Indicators section an all time search was undertaken, which may lead to a decrease in performance.

Under certain rare circumstances, the following error was returned when running the setIndicator command to update indicator tags: Following field is invalid: 'tags' (8902).

Under certain circumstances, integrations were unable to automatically fetch cases due to a deadlock caused between trigger scripts and certain commands, when both were executed on the same incident.

Under certain circumstances, an app server restart led to cascading engine failures, resulting in the engines failing to connect.

The Full view option (toggled from the bottom right of the page) was not available on the Dashboards page.

Marking tasks as Complete in the Cortex XSOAR Enterprise mobile app while adding a completion note resulted in an error. The note was not visible via the mobile app or the web.

When the engine time was not the same as the server time, incidents were sometimes fetched with a delay, and not according to the configured incident fetch interval.

When a custom automation script is used in a playbook, the UUID of the script is displayed instead of the script name in tooltips within the playbook.

The quick scroll arrow buttons did not appear in the War Room when the Incident side pane (e.g. Quick View) was open.

When attempting to delete a large number of records in the Audit Trail, the page would hang until completed.

When editing and saving the code in a custom integration, the cursor moved to the middle of the code due to font issue.

In Cortex XSOAR using elasticsearch, when changing the value of the log.rolling.backups server configuration, the increase did not take effect

Running a timer breach script that changed the same timer, blocked it from running the script the next time.

A pre-process rule that dropped job related incidents caused a confusing UI.

(Multi-tenant) When adding a role to a specific account, it automatically added its nested roles and their users.

(Multi-tenant) After installing Cortex XSOAR in a multi-tenant deployment with Elasticsearch, Failed to invalidate cache item error messages appeared in the server log.

(Multi-tenant) In some cases, new tenant accounts could not be created, due to API keys that were not propagated to accounts while hosts were down or disconnected.

(Multi-tenant) The App Servers page (Settings → Advanced → App Servers) was displayed on the tenant level and not on the main account.

(Multi-tenant) When a tenant was moved from the main server to a host server, the tenant still appeared on the main server's disaster recovery server.