diff --git a/.docsearch/config.json b/.docsearch/config.json index 67cae1b94..c07ecde84 100644 --- a/.docsearch/config.json +++ b/.docsearch/config.json @@ -8,7 +8,7 @@ "version": [ "docs", "4.0.x", - "5.13.0" + "5.14.0" ] } } diff --git a/docs/.vuepress/setup.js b/docs/.vuepress/setup.js index fc574d177..4e3e2af5f 100644 --- a/docs/.vuepress/setup.js +++ b/docs/.vuepress/setup.js @@ -1,8 +1,8 @@ import { BaseTransition } from "vue" -const RUNDECK_VERSION='5.13.0' -const RUNDECK_VERSION_FULL='5.13.0-SNAPSHOT' -const API_VERSION='52' +const RUNDECK_VERSION='5.14.0' +const RUNDECK_VERSION_FULL='5.14.0-SNAPSHOT' +const API_VERSION='53' const API_DEP_REL='6.0.0' const API_DEP_VER='17' const API_MIN_VER='14' diff --git a/docs/.vuepress/sidebar-menus/history.ts b/docs/.vuepress/sidebar-menus/history.ts index 163c9db34..67ddf017b 100644 --- a/docs/.vuepress/sidebar-menus/history.ts +++ b/docs/.vuepress/sidebar-menus/history.ts @@ -70,6 +70,10 @@ export default [ text: 'Version 5.x', collapsible: true, children: [ + { + text: "5.14.0", + link: "https://docs.rundeck.com/5.14.0/" + }, { text: "5.13.0", link: "https://docs.rundeck.com/5.13.0/" diff --git a/docs/administration/runner/index.md b/docs/administration/runner/index.md index dd4447e22..4bfe06268 100644 --- a/docs/administration/runner/index.md +++ b/docs/administration/runner/index.md @@ -33,56 +33,7 @@ Tasks can be carried out over multiple environments simultaneously, thereby redu - The Runner can be used to discover inventory in secure or remote environments. 8. The Runner can be deployed as a container within Kubernetes clusters to perform actions within the cluster. - -[//]: # (#### Providing Teams with Autonomy & Flexibility) - -[//]: # () -[//]: # () -[//]: # () -[//]: # (![Runners for Distributed Teams](/assets/img/runners-for-distributed-teams.png)
) - - -[//]: # (Building and orchestrating automation in complex multi-cloud and remote environments presents several challenges. The first challenge is that DevOps and Operations engineers need an alternative to run automation in secure application environments that mandate a zero trust architecture where accessing private networks through SSH is deprecated. Next, significant engineering effort is required to deploy and manage automation that performs well across many remote environments and geographical regions. Lastly, creating resilient automation runbooks is time consuming and prone to error when coordinating a variety of complex environments.) - -[//]: # () -[//]: # (We are introducing a next generation architecture to address these challenges. With the new Runbook Automation architecture, DevOps and Operations engineers can easily manage automation in a central UI while delegating job execution within different private networks or multi-cloud environments without needing to open SSH ports for accessing those networks. The new architecture separates workflow orchestration from task execution. It offers next generation remote Runners that include common integration plugins like Ansible and Kubernetes that execute locally to the application environment.) - -[//]: # () -[//]: # (![Next generation automation](/assets/img/architecture-nextgen.png)) - -[//]: # () -[//]: # (The Runner, available for both Runbook Automation, securely opens up network/communication between data centers and the Automation Cluster. The Runner is a Remote Execution hub for Node Steps to run on specified endpoints, rather than from the Automation server itself.) - -[//]: # () -[//]: # (## System Architecture) - -[//]: # () -[//]: # (The Runner is a Java based program which uses a polling model to pick up work from the Automation Server. During each polling cycle (every 5 seconds) the Runner checks for executions that it is responsible for. Communication from the Runner to the Automation Server happens over https and is initiated from the Runner. This allows for enhanced firewall security as ports no longer need to be open for the Automation Server to talk to nodes over more sensitive ports. _(e.g. SSH/22)_) - -[//]: # (![Runner Architecture](/assets/img/runner-arch-diagram.png)) - -[//]: # () -[//]: # (## Example scenario using the runner architecture) - -[//]: # () -[//]: # (With the next generation architecture, automation authors can select which Runners will carry out the tasks for a given job using Runner tags. Authors can also choose if tasks will execute on a Runner or if tasks will be dispatched to nodes through the selected Runner set. There are two types of Runners: Local and Remote. The Local Runner tasks execute from the Rundeck instance. The Remote Runner tasks execute from the Runners installed in the environment.) - -[//]: # () -[//]: # (![Private networks scenario](/assets/img/runner-scenario.png)) - -[//]: # () -[//]: # (In the example below, we have a job that will span three different environments.) - -[//]: # () -[//]: # (1. The 1st step (Check Cloud Services Status) is a reference job that is configured with a Remote Runner which will execute a Kubernetes plugin as a workflow step.) - -[//]: # (1. Steps 2,3, and 4 are configured to run on the Local Runner.) - -[//]: # (1. Step 5 (Check System Resources) is also a reference job similar to step 1, but executes an Ansible playbook through the Ansible plugin and targets nodes in the second environment through a separate Remote Runner.) - -[//]: # (1. Step 7 (Run DB Lock Check) is also a reference job similar to step 1 and 5, but executes a Powershell command through the WinRM plugin and targets nodes in the third environment through a separate Remote Runner.) - -## Enabling the Latest Runner Features +### Enabling the Latest Runner Features To use the latest Enterprise Runner features, the following feature-flag must be enabled in **System Configuration** or optionally in the `rundeck-config.properties` file if using the self-hosted software. diff --git a/docs/administration/runner/runner-installation/creating-runners.md b/docs/administration/runner/runner-installation/creating-runners.md index 182b85404..caddff494 100644 --- a/docs/administration/runner/runner-installation/creating-runners.md +++ b/docs/administration/runner/runner-installation/creating-runners.md @@ -21,14 +21,19 @@ If setting up Enterprise Runners on virtualized environments, here are baseline | | **Minimum** | **Medium** | **Large** | |---------------|-------------|------------|-----------| -| **vCPU** | 4 cores | 8 cores | 12 cores | -| **Memory** | 8 GiB | 16 GiB | 32 GiB | -| **Java Heap** | 6 GiB | 12 GiB | 24 GiB | -| **Storage** | 40 GiB | 40 GiB | 40 GiB | +| **vCPU** | 2 core | 4 cores | 8 cores | +| **Memory** | 4 GiB | 8 GiB | 16 GiB | +| **Java Heap** | 2 GiB | 6 GiB | 12 GiB | +| **Storage** | 8 GiB | 20 GiB | 20 GiB | ### Permissions + +
+ ACL Permissions for Creating Runners at System level + To create a Runner at the **System level**, users will need the following ACL permissions: -``` + +```acl by: group: my-user-group-name description: Allow creating of Runners at the System level @@ -41,42 +46,50 @@ context: --- by: - group: my-user-group-name +group: my-user-group-name description: Allow "write" access within Runner management at the System level for: - resource: - - allow: +resource: +- allow: - admin - equals: + equals: kind: runner -context: - application: rundeck + context: + application: rundeck --- by: - group: my-user-group-name +group: my-user-group-name description: Allow creation of apitokens (general) for: - apitoken: - - allow: +apitoken: +- allow: - create -context: - application: rundeck + context: + application: rundeck --- by: - group: my-user-group-name +group: my-user-group-name description: Restrict apitoken creation to only generate_service_token to be used for Runners for: - resource: - - allow: +resource: +- allow: - generate_service_token - equals: + equals: kind: apitoken -context: - application: rundeck + context: + application: rundeck ``` +* Change **`my-user-group-name`** in the above ACL policy to the name of the user group that needs to have these permissions. + +
+
+
+ ACL Permissions for Creating Runners at Project level + To create a Runner within a Project, users will need the following ACL permissions: -``` + +```acl by: group: my-user-group-name description: Allow "write" for runner feature within specific project @@ -126,6 +139,9 @@ context: * Change **`my-user-group-name`** in the above ACL policy to the name of the user group that needs to have these permissions. +
+ + :::warning Error Without API Permissions If the user does not have the necessary API permissions, the following error will be displayed when attempting to create a Runner: @@ -155,7 +171,7 @@ To create a Runner through at the System level: * **`Windows`** * **`Docker`** * **`Kubernetes`** - :::warning Platform Selection Implications + :::warning Platform Selection Once a platform is selected, it cannot be changed for a given Runner. If the platform needs to be changed in the future, a new Runner will need to be created. ::: 7. Click **Next**. @@ -176,8 +192,8 @@ To create a Runner through at the System level: * **Kubernetes**: The code snippet for installing the Runner as a Kubernetes deployment is provided: ![Install Kubernetes Runner](/assets/img/install-kubernetes-runner.png)
-Copy and paste the code snippet into the terminal of the host where the Runner will be installed. - +Copy and paste the code snippet into the terminal of the host where the Runner will be installed. + 11. Click **Close and Complete**. On the subsequent screen, the new Runner will be listed along with any other Runners that have been created: @@ -231,6 +247,6 @@ To create a Runner within a Project: ![Install Docker Runner](/assets/img/install-docker-runner.png)
* **Kubernetes**: The code snippet for installing the Runner as a Kubernetes deployment is provided: ![Install Kubernetes Runner](/assets/img/install-kubernetes-runner.png)
-12. Click **Close and Complete** to finish the Runner creation process. +12. Click **Close and Complete** to finish the Runner creation process. -On the subsequent screen, the new Runner will be listed along with any other Runners that have been created: +On the subsequent screen, the new Runner will be listed along with any other Runners that have been created. \ No newline at end of file diff --git a/docs/administration/runner/runner-installation/runner-install.md b/docs/administration/runner/runner-installation/runner-install.md index b84995f3a..c44e056db 100644 --- a/docs/administration/runner/runner-installation/runner-install.md +++ b/docs/administration/runner/runner-installation/runner-install.md @@ -162,7 +162,6 @@ docker run -it \ rundeckpro/runner:{{ $rundeckVersion }} ``` - ## Secure the Runner Deployment We recommend installing Runners in private directories that are only accessible by the user/group holding the runner process (e.g.: `C:\Users\runnerUser\` directory) so that other users are not able to access or even modify script files created by the runner. diff --git a/docs/administration/runner/runner-management/managing-runners.md b/docs/administration/runner/runner-management/managing-runners.md index 3e06a505f..825dab13f 100644 --- a/docs/administration/runner/runner-management/managing-runners.md +++ b/docs/administration/runner/runner-management/managing-runners.md @@ -2,15 +2,51 @@ redirectFrom: /administration/runner/management --- -# Managing Runners - -## Overview +# System & Project Runner Management Runners can be managed at the System level as well as at the Project level of Runbook Automation (cloud and self-hosted). Both the System and Project level management interfaces allow users to create, edit, and delete Runners. -However, there are specific actions that can only take place depending on whether operating in the System or Project level. +However, there are specific actions that can only take place in the System Level - such as assigning a Runner to multiple projects - or at the Project level - such as defining the Node Filter for dispatching to nodes. + +## System Level Runner Management +
+
+ ACL Permissions for Managing Runners at System level + +To manage a Runner at the **System level**, users will need the following ACL permissions: -### Managing Runners at the System level +```acl +--- +by: + group: my-user-group-name +description: Update Runners at System Level +for: + runner: + - allow: + - update + - delete + - read +context: + application: rundeck + +--- +by: + group: my-user-group-name +description: Write Access to Runner Feature at System Level +for: + resource: + - allow: + - read + - admin + equals: + kind: runner +context: + application: rundeck +``` + +* Change **`my-user-group-name`** in the above ACL policy to the name of the user group that needs to have these permissions. + +
At the System level, in addition to creating, editing, and deleting Runners, users can also assign Runners to Projects. @@ -30,7 +66,7 @@ From this interface, users can: [//]: # (- Delete Runners. For detailed steps, see [Deleting a Runner](/administration/runner/runner-installation/delete-a-runner).) -#### Assigning Runners to Projects +### Assigning Runners to Projects To assign a Runner to a project, follow these steps: @@ -43,21 +79,45 @@ To assign a Runner to a project, follow these steps: The Runner can now be used within the designated projects for various tasks such as job execution, node discovery, and secrets-management integration. -In order to assign a Runner to a Project, the user must have the following ACL permission: +## Managing Runners within a Project +
+
+ ACL Permissions for Creating Runners at Project level -``` +To create a Runner within a Project, users will need the following ACL permissions: + +```acl +--- by: group: my-user-group-name -description: Allow [update] for runner +description: Manage Existing Runners within Project for: runner: - allow: + - read - update + - delete context: - application: rundeck + project: my-project-name + +--- +by: + group: my-user-group-name +description: Write access to Runners at the Project Level +for: + resource: + - allow: + - read + - admin + equals: + kind: runner +context: + project: my-project-name ``` -### Managing Runners within a Project +* Change **`my-user-group-name`** in the above ACL policy to the name of the user group that needs to have these permissions. + +
At the Project level, users can create, edit, and delete Runners for that specific Project. However, Runners created at the Project level are only available for use within that Project and cannot be used in other Projects. @@ -77,7 +137,7 @@ From this interface, users can: [//]: # (- Delete Runners. For detailed steps, see [Deleting a Runner](/administration/runner/runner-installation/delete-a-runner).) -#### Removing a Runner from a Project +### Removing a Runner from a Project To remove a Runner from a Project, follow these steps: @@ -142,7 +202,7 @@ by: ``` ::: -### Changing Runners from Single to Multiple Projects +## Changing Runners from Single to Multiple Projects When a Runner is assigned to a single Project, then users within a Project and with the appropriate permissions can make any changes to the Runner from the Project level interface. This includes the ability to: - Edit the Runner's Name @@ -158,14 +218,7 @@ However, when a Runner is assigned to multiple Projects, then users within Proje This is because when a Runner spans multiple Projects it is considered a _shared resource_. - -### Viewing Runner details - -A new section Tags is available at the bottom of the Runner information page. Like in the summary page, a list of associated tags are displayed. - -![View details](/assets/img/runner-config-viewdetails.png)
- -### Runner Tags +## Runner Tags Runner Tags are used to select on or more Runners for specific operations - such as for Job execution when using [**Manual Runner Dispatch Configuration**](/administration/runner/runner-management/project-dispatch-configuration.md#manual-runner-selection) or when using [Runners for Node Source](/administration/runner/using-runners/runners-for-node-discovery.md) plugins. @@ -205,4 +258,4 @@ Users can check that a Runner is available via an ad hoc "ping" operation: 3. If the Runner is available, the response show that the message was received: ![Ping Runner Response](/assets/img/runner-ping-response.png)
4. If the Runner is unavailable, the response will show that the ping response timed out: - ![Ping Runner Unavailable](/assets/img/runner-ping-unavailable.png)
\ No newline at end of file + ![Ping Runner Unavailable](/assets/img/runner-ping-unavailable.png)
diff --git a/docs/administration/runner/runner-management/node-dispatch.md b/docs/administration/runner/runner-management/node-dispatch.md index e6821bd5d..fe472a129 100644 --- a/docs/administration/runner/runner-management/node-dispatch.md +++ b/docs/administration/runner/runner-management/node-dispatch.md @@ -12,10 +12,21 @@ The Node Dispatch settings of a Runner defines which nodes are assigned to a Run Enabling the _**Runner as a Node**_ adds the Runner as a node to the node inventory. When this node is targeted with a node-step within a Job or with a command from the Commands page, the Runner will execute the step locally. This is useful for running automation tasks that require the Runner to execute a command or script on the local host. + :::warning Runner Version Requirement To use the Runner as a Node feature and target the Runner's host with command and script steps, the Runner must be at version 5.5.0 or later. ::: + +:::warning Local Node Source Requirement +If Run on Runner option is selected in the job **Local** Node Source to be configured. Removing the Local Node Source will result in the removal of the Runner nodes from the inventory. + +![Local node source](/assets/img/local-node-source.png)
+ +To still use the Local Node Source, but prevent the execution of commands and scripts on the Runbook Automation cluster members, set the JVM system property **`rundeck.localExecutor.disabled=true`** or **`DISABLED_LOCAL_EXECUTOR=true`** for Docker installations. +::: + + Nodes that represent Runners are designated with a Runner icon in the node inventory and do not require configuring a node source for the Runner's to be added to the inventory. ![Runner as a Node](/assets/img/runners-as-nodes-inventory.png)
@@ -36,17 +47,9 @@ Nodes that represent Runners are dependent on the **Local** Node Source to be co To still use the Local Node Source, but prevent the execution of commands and scripts on the Runbook Automation cluster members, set the JVM system property **`rundeck.localExecutor.disabled=true`** or **`DISABLED_LOCAL_EXECUTOR=true`** for Docker installations. ::: -:::warning Local Node Source Requirement -If Run on Runner option is selected in the job **Local** Node Source to be configured. Removing the Local Node Source will result in the removal of the Runner nodes from the inventory. - -![Local node source](/assets/img/local-node-source.png)
- -To still use the Local Node Source, but prevent the execution of commands and scripts on the Runbook Automation cluster members, set the JVM system property **`rundeck.localExecutor.disabled=true`** or **`DISABLED_LOCAL_EXECUTOR=true`** for Docker installations. -::: - ## Remote Node Dispatch -Enabling the _**Remote Node Dispatch**_ setting allows the Runner to dispatch commands, scripts and api-calls to _remote_ nodes using protocols such as SSH, WinRM and HTTP/S. This is necessary for securely dispatching to nodes from Runbook Automation Cloud or to nodes that are not directly accessible from the self-hosted cluster. +Enabling the _**Remote Node Dispatch**_ setting allows the Runner to dispatch commands, scripts and API calls to _remote_ nodes using protocols such as SSH, WinRM and HTTP/S. This is necessary for securely dispatching to nodes from Runbook Automation Cloud or to nodes that are not directly accessible from the self-hosted cluster. The mapping of which nodes a given Runner is responsible for is defined using a [**Node Filter**](/manual/11-node-filters.md). When the Node Filter is defined for a Runner, then Job steps that target the nodes that match the filter will be dispatched _through_ the Runner for execution. @@ -61,13 +64,14 @@ To define the Node Filter for a Runner: ![Remote Node Dispatch](/assets/img/runner-node-filter.png) _Runners are dynamically chosen for Job execution based on the Runner's Node Filter_ -:::tip Nodes Without a Runner Association +:::warning Nodes Without a Runner Association Nodes that do not match the Node Filter of any Runner will be dispatched to using the Runbook Automation cluster (self-hosted). When using Runbook Automation Cloud, commands and scripts can be dispatched to these nodes using the [AWS Systems Manager](/manual/projects/node-execution/aws-ssm.md) Node Executor. Node Step plugins that target public endpoints - such as AWS or Datadog node step plugins - can also be used through Runbook Automation Cloud when no Runner is assigned to those nodes. This ensures that all nodes are dispatched for execution, even if they do not match the Node Filter of a Runner. ::: -### Example Remote Dispatch Node Filter +::: tip Example +## Remote Dispatch Node Filter Example A common use-case for defining a Node Filter for a Runner is to declare a given region or data-center that a Runner is responsible for. @@ -82,7 +86,7 @@ Taking this a step further, a Runner could be responsible for only **_Windows_** ![Remote node dispatch windows example](/assets/img/remote-node-dispatch-windows-example.png)
For more information on defining Node Filters, see the [Node Filters](/manual/11-node-filters.md) documentation. - +::: ## Overlapping Node Filters When defining Node Filters for Runners, it is possible to have filters on multiple Runners that overlap their assignments of the node inventory. In other words, a given node may be mapped to more than one Runner. @@ -92,4 +96,4 @@ In this case, Jobs steps that target _Windows_ nodes in the _US-WEST-1_ region c While this can be useful for redundancy purposes, it requires careful considering that both Runners and their hosts are configured as identically as possible to reduce the likelihood of unpredictable behavior. -Native high-availability and horizontal scaling of Runners is planned for a future release. +Native high-availability and horizontal scaling of Runners is planned for a future release. \ No newline at end of file diff --git a/docs/administration/runner/using-runners/runner-using.md b/docs/administration/runner/using-runners/runner-using.md index cf63e7ed9..2dcbdccd2 100644 --- a/docs/administration/runner/using-runners/runner-using.md +++ b/docs/administration/runner/using-runners/runner-using.md @@ -47,11 +47,6 @@ This is possible only If the “Runnerset Can be Changed at Runtime” option wa Once you have picked a Runnerset for the Job, you can choose how the Runner should behave by selecting a Dispatch mode: “Run on Runner” or “Dispatch to Nodes through Runner”. If you select “Dispatch to Nodes through Runner”, the nodes related options will display and those are identical to previous versions of Runbook Automation.
![Dispatching jobs through runners](/assets/img/runner-use-dispatch-nodes.png) -#### Job Output with Manual Runner Selection - -The runner carrying out the job execution is displayed at the top of the Job execution activity. Example below: The job below was executed through the “Ansible-Runner”
-![View runner in a job execution](/assets/img/runner-use-view-activity.png) - #### Manual Runner Selection through Job options Runner matching and filtering supports Job Options - `${option.NAME}`, which allows changing the Runners for the job based on dynamic input through API calls or the rundeck-cli. The Job Options behavior is the same for Runner selection as with using it with commands or other workflow steps. For example: @@ -68,3 +63,7 @@ Here's an example of a job option and runner filter configurations: #### Migrating Jobs to use Runners with Manual Runner Selection When **Manual** is selected in [**Project Dispatch Configuration**](/administration/runner/runner-management/project-dispatch-configuration.md), existing jobs will default to the Local Runner even if no Runner selection is made in the job definition. The Local Runner operates with an execution context equivalent to that of the Runbook Automation service. +## Job Output with Manual Runner Selection + +The runner carrying out the job execution is displayed at the top of the Job execution activity. Example below: The job below was executed through the “Ansible-Runner”
+![View runner in a job execution](/assets/img/runner-use-view-activity.png) \ No newline at end of file diff --git a/docs/history/5_x/version-5.14.0.md b/docs/history/5_x/version-5.14.0.md new file mode 100644 index 000000000..b7a697e93 --- /dev/null +++ b/docs/history/5_x/version-5.14.0.md @@ -0,0 +1,96 @@ +--- + +title: "5.14.0 Release Notes" +date: 2025-08-04 +image: /images/chevron-logo-red-on-white.png +description: "Rundeck | Runbook Automation Releases 5.14.0 | Security and Stability improvements" +feed: + enable: true + description: "Lots of fixes and Security enhancements" + +--- + +# 5.14.0 Release Notes + +## Overview + +Rundeck 5.14.0 is a maintenance release focused on security enhancements and bug fixes. This release addresses multiple CVEs including CVE-2023-3635, CVE-2025-48734, CVE-2025-48976, and CVE-2025-7783 through dependency updates across the platform. + +Key improvements include enhanced character escaping for Unix, PowerShell, and CMD commands, fixes for execution reporting issues, and updates to the Ansible plugin. The release also includes authorization improvements and various plugin enhancements for Jira integration and ROI/Job Metrics functionality. + +While this release doesn't introduce major new features, it significantly strengthens the security posture and stability of your Rundeck environment. We recommend upgrading to ensure your installation benefits from these important security fixes. + +## Runbook Automation Updates + +> Also includes all Open Source updates from below + +### Additional Updates + + +* Addresses CVE-2025-48734 by updating beanutils to version 1.11.0 +* Jira assignee field issue +* Jira plugins - Error with Numeric Custom Field +* Minor Improvements/fixes for ROI/Job Metrics plugins +* Update MongoDB Field Descriptions + + +## Rundeck Open Source Product Updates + +* [Address CVE-2023-3635 and CVE-2025-48734](https://github.com/rundeck/rundeck/pull/9732) +* [Update File Commons Version for CVE-2025-48976](https://github.com/rundeck/rundeck/pull/9731) +* [Address CVE-2023-3635 and CVE-2025-48734 ](https://github.com/rundeck/rundeck/pull/9729) +* [Address CVE-2025-7783 by updating axios](https://github.com/rundeck/rundeck/pull/9728) +* [Add feature flag to allow hiding ROI setup instructions](https://github.com/rundeck/rundeck/pull/9726) +* [Improve Escaping chars for unix, ps and cmd](https://github.com/rundeck/rundeck/pull/9717) +* [Avoid creating multiple execution reports if notification fails](https://github.com/rundeck/rundeck/pull/9714) +* [Addresses CVE-2025-48734 by updating beanutils to version 1.11.0](https://github.com/rundeck/rundeck/pull/9711) +* [Add missing authorization check for plugin details](https://github.com/rundeck/rundeck/pull/9707) +* [Address CVE-2023-3635 by updating retrofit to version 3.0.0](https://github.com/rundeck/rundeck/pull/9698) +* [Updated Ansible plugin release to 4.0.9](https://github.com/rundeck/rundeck/pull/9696) +* [Include Last Login on API Responses](https://github.com/rundeck/rundeck/pull/9674) +* [Fix a bug: using ?max=100 URL params on the activity page causes a 500 error](https://github.com/rundeck/rundeck/pull/9637) + + +[Here is a link to the full list of public PRs](https://github.com/rundeck/rundeck/pulls?q=is%3Apr+milestone%3A5.14.0+is%3Aclosed) + +## Ansible Plugin Updates +* [Bump rundeck-core dependency to 5.14 to address CVEs](https://github.com/rundeck-plugins/ansible-plugin/pull/415) +* [Error when running ansible plugin with encrypt extra vars](https://github.com/rundeck-plugins/ansible-plugin/pull/413) + + +## Links + +- Download the Releases: [Open Source](https://www.rundeck.com/community-downloads/5.14.0) | [Self-Hosted](https://www.rundeck.com/enterprise-downloads/5.14.0) +- [Sign up for Release Notes](https://www.rundeck.com/release-notes-signup) +- [Upgrade instructions](/upgrading/index.md) +- [Catch us on LinkedIn for the Live Stream Release Videos](https://www.linkedin.com/company/pagerduty/events) + +## Version Info + +Name: "Logan violet paperclip" + +Release Date: August 4th, 2025 + + +## Community Contributors + +Submit your own Pull Requests to get recognition here! + +* ([cwaltherpd](https://github.com/cwaltherpd)) +* Rui Melo Amaro ([rmeloamaro](https://github.com/rmeloamaro)) + + +## Staff Contributors + +* Greg Schueler ([gschueler](https://github.com/gschueler)) +* Carlos Eduardo ([carlosrfranco](https://github.com/carlosrfranco)) +* Eduardo Baltra ([edbaltra](https://github.com/edbaltra)) +* Forrest Evans ([fdevans](https://github.com/fdevans)) +* Jake Cohen ([jsboak](https://github.com/jsboak)) +* Jaya Singh ([jayas006](https://github.com/jayas006)) +* Jason Brooks ([jbrookspd](https://github.com/jbrookspd)) +* Jesus Osuna ([Jesus-Osuna-M](https://github.com/Jesus-Osuna-M)) +* José Vásquez ([hiawvp](https://github.com/hiawvp)) +* Luis Toledo ([ltamaster](https://github.com/ltamaster)) +* Rodrigo Navarro ([ronaveva](https://github.com/ronaveva)) +* Sarah Martinelli Benedetti ([smartinellibenedetti](https://github.com/smartinellibenedetti)) \ No newline at end of file diff --git a/docs/history/cves/CVE-2025-48924.md b/docs/history/cves/CVE-2025-48924.md new file mode 100644 index 000000000..8c44dea2c --- /dev/null +++ b/docs/history/cves/CVE-2025-48924.md @@ -0,0 +1,15 @@ +--- +order: 51 +--- + +# CVE-2025-48924 + +## Issue in Apache Commons Lang + +::: danger FALSE POSITIVE + Rundeck and Runbook Automation are not vulnerable to this CVE. +::: + +[CVE-2025-48924](https://nvd.nist.gov/vuln/detail/CVE-2025-48924) describes an Uncontrolled Recursion vulnerability in Apache Commons Lang. This issue affects commons-lang:commons-lang versions 2.0 to 2.6, and org.apache.commons:commons-lang3 versions 3.0 before 3.18.0. The vulnerability is present in the `ClassUtils.getClass(...)` method, which can throw a `StackOverflowError` on very long inputs. Since errors of this type are typically not handled, this could cause an application to stop unexpectedly. The recommended mitigation is to upgrade to version 3.18.0 or later. + +After review, we have confirmed that neither Rundeck nor Runbook Automation use the affected `ClassUtils.getClass(...)` method, so this vulnerability does not impact our products. diff --git a/docs/history/release-calendar.md b/docs/history/release-calendar.md index a13b91a35..602fd70de 100755 --- a/docs/history/release-calendar.md +++ b/docs/history/release-calendar.md @@ -9,6 +9,7 @@ Upgrade instructions [can be found here](/upgrading/index.md). | Release Version | Release Date | Enterprise Support Status | |------------------------------------------|----------------------|---------------------------| +| [5.14.0](/history/5_x/version-5.14.0.md) | August 4th, 2025 | Supported | | [5.13.0](/history/5_x/version-5.13.0.md) | June 25th, 2025 | Supported | | [5.12.0](/history/5_x/version-5.12.0.md) | May 7th, 2025 | Supported | | [5.11.1](/history/5_x/version-5.11.1.md) | April 16th, 2025 | Supported | @@ -20,7 +21,6 @@ Upgrade instructions [can be found here](/upgrading/index.md). | [5.7.0](/history/5_x/version-5.7.0.md) | October 21, 2024 | Supported | | [5.6.1](/history/5_x/version-5.6.1.md) | October 14, 2024 | Supported | | [5.6.0](/history/5_x/version-5.6.0.md) | September 12, 2024 | Supported | -| [5.5.0](/history/5_x/version-5.5.0.md) | August 8th, 2024 | Supported | ::: warning Any versions not listed here are now out of support. We encourage everyone on older versions to update to a currently supported version.