Version 5.9.5#

A new release of Sherpa Orchestrator is available: Version 5.9.5.

Release date: 22.10.2026.

1. Local password expiration and change interval#

Two independent settings have been added for local User and Account passwords. Both checks are disabled by default.

USER_PASSWORD_EXPIRATION_ENABLED enables password expiration. USER_PASSWORD_EXPIRATION_DAYS sets the lifetime in days, with a default of 120. When a password expires, the login form prompts for a password change. After changing it successfully, the user must log in with the new password.

USER_PASSWORD_CHANGE_INTERVAL_ENABLED limits local password changes to once every 24 hours. When a change is rejected, the interface shows the next permitted change time in UTC. Password complexity requirements remain in effect.

2. Licenses and Robot group membership#

The Licenses table displays the full key. The API supports searching for a key by a matching substring, an excluded substring or an exact match. Invalid filters are rejected with status 422.

Attended Floating seat counting has been corrected: assigned Robots that have not been deleted are counted regardless of their status and last connection. Sherpa Autopilot can be registered again after its previous license binding is deleted, while active logins remain protected.

A Robot created through the interface, API or import into a regular group is included in its Account's "All Robots" group. Upgrading adds previously omitted Robots from active Accounts to the group. Jobs and Resources assigned to "All Robots" then apply to these Robots.

3. Email Triggers, Task retries and the Coordinator#

Email Trigger execution has been corrected when a message that does not match the filter arrives after matching messages. Trigger enable switches now have localized labels for screen readers.

Task retries work from the scheduler without an open user session. An unavailable Queue no longer causes warnings during retry processing.

The MachineHeartbeat format in the Coordinator heartbeat response on PostgreSQL has been corrected. Windows and Linux Coordinators can parse the time correctly again and reset stalled RDP sessions.

4. OAuth diagnostics and API version access#

When processing an OAuth provider's response fails, the system error log records the failure stage and reason. If login is rejected after the provider's response is processed, the stage is recorded. These events use the oauth channel. Authorization codes, tokens, secrets and logins are not recorded.

Anonymous access to the version through API v1 has been closed. Authorized Users and API clients retain the response format and access without additional permissions.

5. Forms, Job exports and Process Version files#

Saving an empty string, zero and false in My Actions has been corrected. Task filtering by tags compares whole tags, so partial name matches no longer include unrelated Tasks.

CSV and XLSX export from the Jobs table is unavailable without selected rows. The interface does not send an empty export request.

The Process Version file name and size appear in a high-contrast information block that wraps long names. Invalid file hashes are corrected when a Job is issued. A Robot no longer uses another Process's cached file after a version with an empty hash is edited.

6. Data protection and PostgreSQL reliability#

Machine passwords have been excluded from API v1 and legacy API Robot lists. Reading an individual record remains available. TXT and JSON are displayed as literal text in the viewer, while HTML is sanitized before display.

Storage path component and directory boundary checks have been strengthened, including symbolic links. A Folder's identifier does not change during editing.

PostgreSQL identifier counters have been expanded and their state restored after initial seeding. Previously issued identifiers are not reduced. Handling of concurrent Robot admission conflicts in MariaDB has been corrected without creating a Job again.

7. Backups and installation migration#

Backup and restore instructions have been prepared for embedded MariaDB and PostgreSQL, with result verification and safe rollback.

Migration of a local installation to Docker on the same server is documented with preservation of the database, Storage, configuration, certificates and license binding. The procedure includes verification and rollback without deleting data volumes.

Separate license rebinding instructions have been added for moving Orchestrator to another server while retaining the existing PostgreSQL or MariaDB. Moving to a new server requires these steps even when the database is preserved.

8. Component security and distribution preparation#

A base with PHP 8.5.12 has been pinned for the backend. Vault and VNC dependencies have been updated, including Werkzeug, urllib3 and certifi. BusyBox protection fixes have been added, and secret leakage into Snowflake driver diagnostic logs has been eliminated.

Base and release Docker images undergo mandatory vulnerability checks before publication. Vault checks account for secret preservation during upgrades. Tools required only for building have been removed from VNC components.

Embedded private keys and Docker Hub credentials have been removed from the distribution.

Release maintenance now supports selecting base images for a manual weekly build and running a verification build without publishing to Docker Hub. Runner disk cleanup and build fixes reduce the risk of interrupted distribution preparation.