Automation | When an automation had an argument containing a list, the window was not sized correctly to view all of the predefined list values in a dropdown when the automation was used in an incident layout. 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.
|
Dashboard | |
Engines | Upgrading an engine from the UI without downloading tools using -- -tools=false was not supported. After upgrade, in the Engine table, the Status was blank (it usually shows up to date or update required) and the XSOAR version still showed the old version.
|
Elasticsearch | In Elasticsearch, template creation requests were sent too many times. There was no option to disable large or non-queried fields in Elasticsearch. New values for new custom fields were not added to the indices in Elasticsearch. When configuring an incoming mapper, incident fields were not sorted alphabetically, after migrating from BoltDB to Elasticsearch. When using OpenSearch, the System Diagnostics page displayed a warning for Old Elasticsearch version. When closing an investigation, the Incidents I own and Incidents I participated in sections in the sidebar were blank when the page refreshed. A job that queried many playbooks could crash Elasticsearch. Uppercase Boolean fields failed to be indexed. Many empty requests were sent to the Elasticsearch database causing slow performance. The closeNotes field was not searchable. 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. 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.
|
High Availability | In some cases, daily jobs were running multiple times a day, once on each App server. When trying to assign comments from the War Room to tasks, in some cases an error was returned.
|
Hosted | The System Diagnostics page displayed incorrect information for Hosted Service limits. |
Incidents | When you created a custom incident field and configured a tooltip description for it, the field tooltip displayed the field name instead of the tooltip description when you hovered over it. In some cases, custom incident types were not populated with values. After selecting multiple incidents and performing an action on them, the incidents appeared to be still selected in the UI. When an incident had an attachment resulting from a data collection task, the attachment could not be downloaded from the incident layout. When you created an Incidents Widget with a table view, the last row of the table was cut in half vertically and the contents of that row were difficult to read. When some interface fields of type array were used in the pre-processing rules, the pre-processing rules were not applied. When switching quickly between incidents in the → , the incidents got stuck loading. In the notes section of an incident, double carats (^^) were being used incorrectly to highlight text, which caused inconsistent highlighting when indicators were included in the note. Double equals (==) can be used to highlight text. In the Incidents page, clicking Load next incidents reloaded the first page, not the next page. The custom Close Form for an incident type did not display if you clicked the Select All # items option to select more than a single page of incidents of the same incident type, and then clicked Close. When a pre-set query was defined for the incidents page, the current query was overwritten by the preset after leaving and returning to the incident page. Changes could be made to a closed incident from the incident page, without reopening the incident. 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 a pre-processing rule ran a script that searched for incidents, incidents in the temp index were not found. Pivoting to related incidents or indicators did not work when the user’s role had a predefined default incident query. When a user attempted to pivot to related incidents or indicators, if a predefined query was set for the user’s role, the search showed the incidents based on the predefined query and not the related incidents or indicators. After creating and saving a grid (table) field, column field types (boolean, short text, single select, etc.) could be changed. Could not edit the Grid (table) incident field after the table was emptied.
|
Indicators | The Tags field in the Edit Indicator window did not show auto-complete options. When editing an indicator, the tags field dropdown did not populate with existing tags. Selected indicators reappeared in other pages in the Threat Intel library after doing a select all for one page of results. Indicators were not merged correctly, resulting in duplicate indicators and errors that the indicators did not exist, even though they did. 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.
|
Integrations | Under → , when saving edits in an integration source code, the cursor went to a different line. |
Jobs | In some cases, when creating or editing a job, changing the incident type either cleared the playbook field or completely removed the field from the New Job window, which prevented the user from saving the job. When creating or editing a job, if the date was removed from the Start at field, the job reset to January 1, 1970, and did not run. 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. In some cases, jobs ran repeatedly at short intervals, instead of by the job schedule.
|
Lists | After editing a list under → → , the List editor window covered the main menu on the left. |
Live Backup | When transitioning to the backup server, incidents were duplicated. |
Playbooks | 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. Adding the system configuration server.mail.listener.suppress.user.mail.check : false resolved the issue. When opening very large playbooks, the UI became slow and unresponsive. 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 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 a data collection task included an attachment, content submitted in the optional Add Comment field was not saved in context or available in the task output. 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. 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. After a service restart, the playbooks that were previously in a running state did not continue running when there were more than 50 incidents.
|
Podman | |
Podman or Docker | The no_proxy server configuration in Cortex XSOAR was not passed to command/container runs in Docker/Podman. |
Remote Repositories | When using a remote repository, in some cases it took an extended period of time to load the local changes. In the integration Settings page, timeout errors occurred when migrating settings from development to production environments.
|
Reports | In some cases, reports in CSV format contained a new line character at the end of the incident name. In a report, regardless of the function/calculation (Avg, Count, etc.), the tooltip in the chart always displayed Sum. When a PDF report was generated, section images were not displayed correctly. In some cases, when exporting a report to PDF, the text overlapped and was not readable. When exporting a report that included a date to a PDF, the date did not display.
|
SLA | Filtering from a SLA pie chart widget led to a JavaScript error and the filter was not applied. |
System | Fixed issue where a value that’s too large was added in the websocket buffer size, causing the server to crash. When Cortex XSOAR was upgraded to v6.6 or later, the playbook.willnotexecute.old.eval server configuration was set to true. 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. A resource leak could lead to a large number of open file descriptors and other server resources accumulating over time.
|
System diagnostics | In the → → tab, when clicking View details you could not see the details at the end of the table. The System Diagnostics page showed an alert for incidents with exceptionally big context, even after the incidents had been deleted. 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.
|
TIM | In some cases, customers with a TIM only license were not able to run Cortex XSOAR operations. |
War Room | In the dynamic TableToMarkdown section, when the script executed in the War Room, it displayed the result as expected in one line. But when the same script ran in a playbook the same result displayed in two lines, even though there was enough space in the table to display it as a single line. In some cases, when editing evidence notes, the field would reset after 30 seconds, deleting the user's input. Sometimes indicators extracted from field values were not marked in the War Room field entry, but displayed ^^^ characters instead. When a username had a comma separating the first and last names, the War Room logged them as two separate users. Users are now prevented from creating usernames with a comma. 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. Strings similar to domains would sometimes be highlighted in the War Room or field values.
|
Users & Roles | A default admin user could not edit an account created by a non-default admin role. 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.
|
Widgets | Decimal values did not display in widget charts. When a dashboard widget only had one row, the row values did not display. When a chart contained only one type (one type of incident, one type of indicator, etc.), the legend did not display. An empty chart was displayed for a custom widget in the Dashboard when using 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.
|
Multi-tenant | When using Elasticsearch, there was an issue when fetching lists using the {lists.XXX} resolver. The host waited for all accounts to start before the host would start. After configuring a DUO integration to authenticate login, DUO authentication failed when logging into Cortex XSOAR. After creating a new default admin user, you could not delete or disable the original default admin. (Multi-tenant with HA) In the main account, the → → page displayed with empty content for high availability multi-tenant deployments. (Multi-tenant with HA) When an account was created on one host, errors related to that account appeared on other hosts. (Multi-tenant with remote repositories ) When the name of a content pack changed, tenants no longer received updates to the content pack. When a SAML integration was pushed from main to host, there were synchronization issues.
|