octopus CVE Vulnerabilities & Metrics

In affected versions of Octopus Server it is possible for the OpenID client secret to be logged in clear text during the configuration of Octopus Server.

In affected versions of Octopus Deploy it is possible for a low privileged guest user to craft a request that allows enumeration/recon of an environment.

In affected versions of Octopus Deploy it is possible for a low privileged guest user to interact with extension endpoints.

In affected versions of Octopus Deploy it is possible to discover network details via error message

In affected versions of Octopus Deploy it is possible to upload a zipbomb file as a task which results in Denial of Service

In affected versions of Octopus Deploy it is possible to unmask variable secrets using the variable preview function

In affected versions of Octopus Deploy it is possible to render user supplied input into the webpage

In affected versions of Octopus Deploy it is possible for a user to introduce code via offline package creation

In affected versions of Octopus Deploy it is possible for a user to view Workerpools without being explicitly assigned permissions to view these items

In affected versions of Octopus Deploy it is possible for a user to view Tagsets without being explicitly assigned permissions to view these items

In affected versions of Octopus Deploy it is possible to upload a zipbomb file as a task which results in Denial of Service

In affected versions of Octopus Server the help sidebar can be customized to include a Cross-Site Scripting payload in the support link. This was initially resolved in advisory 2022-07 however it was identified that the fix could be bypassed in certain circumstances. A different approach was taken to prevent the possibility of the support link being susceptible to XSS

In affected versions of Octopus Deploy users of certain browsers using AD to sign-in to Octopus Server were able to bypass authentication checks and be redirected to the configured redirect url without any validation.

In affected versions of Octopus Deploy it is possible for certain types of sensitive variables to inadvertently become unmasked when viewed in variable preview.

In affected versions of Octopus Server it is possible for target discovery to print certain values marked as sensitive to log files in plaint-text in when verbose logging is enabled.

In affected versions of Octopus Server where access is managed by an external authentication provider, it was possible that the API key/keys of a disabled/deleted user were still valid after the access was revoked.

In affected versions of Octopus Server it is possible for a session token to be valid indefinitely due to improper validation of the session token parameters.

In affected versions of Octopus Server it is possible to reveal the existence of resources in a space that the user does not have access to due to verbose error messaging.

In affected versions of Octopus Server it is possible to use the Git Connectivity test function on the VCS project to initiate an SMB request resulting in the potential for an NTLM relay attack.

In affected versions of Octopus Server it is possible to reveal information about teams via the API due to an Insecure Direct Object Reference (IDOR) vulnerability

In affected versions of Octopus Server it was identified that when a sensitive value is a substring of another value, sensitive value masking will only partially work.

In affected versions of Octopus Server it was identified that a session cookie could be used as the CSRF token

In affected versions of Octopus Server it was identified that the same encryption process was used for both encrypting session cookies and variables.

In affected versions of Octopus Deploy it is possible to bypass rate limiting on login using null bytes.

In affected versions of Octopus Deploy it is possible to reveal the Space ID of spaces that the user does not have access to view in an error message when a resource is part of another Space.

In affected versions of Octopus Deploy it is possible to upload a package to built-in feed with insufficient permissions after re-indexing packages.

In affected versions of Octopus Deploy it is possible to perform a Regex Denial of Service targeting the build information request validation.

In affected versions of Octopus Deploy it is possible to perform a Regex Denial of Service using the Variable Project Template.

In affected versions of Octopus Deploy it is possible to perform a Regex Denial of Service via the package upload function.

In affected versions of Octopus Deploy it is possible to unmask sensitive variables by using variable preview.

In affected versions of Octopus Deploy, there is no logging of changes to artifacts within Octopus Deploy.

In affected versions of Octopus Server the help sidebar can be customized to include a Cross-Site Scripting payload in the support link.

In affected versions of Octopus Server an Insecure Direct Object Reference vulnerability exists where it is possible for a user to download Project Exports from a Project they do not have permissions to access. This vulnerability only impacts projects within the same Space.

When generating a user invitation code in Octopus Server, the validity of this code can be set for a specific number of users. It was possible to bypass this restriction of validity to create extra user accounts above the initial number of invited users.

In affected Octopus Server versions when the server HTTP and HTTPS bindings are configured to localhost, Octopus Server will allow open redirects.

When the Windows Tentacle docker image starts up it logs all the commands that it runs along with the arguments, which writes the Octopus Server API key in plaintext. This does not affect the Linux Docker image

When Octopus Tentacle is installed on a Linux operating system, the systemd service file permissions are misconfigured. This could lead to a local unprivileged user modifying the contents of the systemd service file to gain privileged access.

When Octopus Tentacle is installed using a custom folder location, folder ACLs are not set correctly and could lead to an unprivileged user using DLL side-loading to gain privileged access.

When Octopus Server is installed using a custom folder location, folder ACLs are not set correctly and could lead to an unprivileged user using DLL side-loading to gain privileged access.

In Halibut versions prior to 4.4.7 there is a deserialisation vulnerability that could allow remote code execution on systems that already trust each other based on certificate verification.

In Octopus Server after version 2018.8.2 if the Octopus Server Web Request Proxy is configured with authentication, the password is shown in plaintext in the UI.

OctopusDSC is a PowerShell module with DSC resources that can be used to install and configure an Octopus Deploy Server and Tentacle agent. In OctopusDSC version 4.0.977 and earlier a customer API key used to connect to Octopus Server is exposed via logging in plaintext. This vulnerability is patched in version 4.0.1002.

In Octopus Deploy through 2020.4.2, an attacker could redirect users to an external site via a modified HTTP Host header.

An issue was discovered in Octopus Deploy through 2020.4.4. If enabled, the websocket endpoint may allow an untrusted tentacle host to present itself as a trusted one.

In Octopus Deploy 3.1.0 to 2020.4.0, certain scripts can reveal sensitive information to the user in the task logs.

An issue was discovered in Octopus Deploy 3.4. A deployment target can be configured with an Account or Certificate that is outside the scope of the deployment target. An authorised user can potentially use a certificate that they are not in scope to use. An authorised user is also able to obtain certificate metadata by associating a certificate with certain resources that should fail scope validation.

In Octopus Deploy 2018.8.0 through 2019.x before 2019.12.2, an authenticated user with could trigger a deployment that leaks the Helm Chart repository password.

In Octopus Deploy before 2019.12.9 and 2020 before 2020.1.12, the TaskView permission is not scoped to any dimension. For example, a scoped user who is scoped to only one tenant can view server tasks scoped to any other tenant.

In Octopus Deploy before 2020.1.5, for customers running on-premises Active Directory linked to their Octopus server, an authenticated user can leverage a bug to escalate privileges.

In Octopus Deploy before 2019.10.6, an authenticated user with TeamEdit permission could send a malformed Team API request that bypasses input validation and causes an application level denial of service condition. (The fix for this was also backported to LTS 2019.9.8 and LTS 2019.6.14.)

In Octopus Deploy before 2019.10.7, in a configuration where SSL offloading is enabled, the CSRF cookie was sometimes sent without the secure attribute. (The fix for this was backported to LTS versions 2019.6.14 and 2019.9.8.)

In Octopus Deploy 3.3.0 through 2019.10.4, an authenticated user with PackagePush permission to upload packages could upload a maliciously crafted package, triggering an exception that exposes underlying operating system details.

In Octopus Deploy 2019.7.3 through 2019.7.9, in certain circumstances, an authenticated user with VariableView permissions could view sensitive values. This is fixed in 2019.7.10.

In Octopus Tentacle versions 3.0.8 to 5.0.0, when a web request proxy is configured, an authenticated user (in certain limited OctopusPrintVariables circumstances) could trigger a deployment that writes the web request proxy password to the deployment log in cleartext. This is fixed in 5.0.1. The fix was back-ported to 4.0.7.

In Octopus Deploy 2019.4.0 through 2019.6.x before 2019.6.6, and 2019.7.x before 2019.7.6, an authenticated system administrator is able to view sensitive values by visiting a server configuration page or making an API call.

In Octopus Deploy versions 3.0.19 to 2019.7.2, when a web request proxy is configured, an authenticated user (in certain limited circumstances) could trigger a deployment that writes the web request proxy password to the deployment log in cleartext. This is fixed in 2019.7.3. The fix was back-ported to LTS 2019.6.5 as well as LTS 2019.3.7.

In Octopus Deploy 2019.1.0 through 2019.3.1 and 2019.4.0 through 2019.4.5, an authenticated user with the VariableViewUnscoped or VariableEditUnscoped permission scoped to a specific project could view or edit unscoped variables from a different project. (These permissions are only used in custom User Roles and do not affect built in User Roles.)

An Information Exposure issue in the Terraform deployment step in Octopus Deploy before 2019.1.8 (and before 2018.10.4 LTS) allows remote authenticated users to view sensitive Terraform output variables via log files.

In Octopus Deploy 2018.8.0 through 2018.9.x before 2018.9.1, an authenticated user with permission to modify deployment processes could upload a maliciously crafted YAML configuration, potentially allowing for remote execution of arbitrary code, running in the same context as the Octopus Server (for self-hosted installations by default, SYSTEM).

In Octopus Deploy 3.0 onwards (before 2018.6.7), an authenticated user with incorrect permissions may be able to create Accounts under the Infrastructure menu.

In Octopus Deploy version 2018.5.1 to 2018.5.7, a user with Task View is able to view a password for a Service Fabric Cluster, when the Service Fabric Cluster target is configured in Azure Active Directory security mode and a deployment is executed with OctopusPrintVariables set to True. This is fixed in 2018.6.0.

In Octopus Deploy 2018.4.4 through 2018.5.1, Octopus variables that are sourced from the target do not have sensitive values obfuscated in the deployment logs.

In Octopus Deploy 3.4.x before 2018.4.7, an authenticated user is able to view/update/save variable values within the Tenant Variables area for Environments that do not exist within their associated Team scoping. This occurs in situations where this authenticated user also belongs to multiple teams, where one of the Teams has the VariableEdit permission or VariableView permissions for the Environment.

In Octopus Deploy before 2018.4.7, target and tenant tag variable scopes were not checked against the list of tenants the user has access to.

In Octopus Deploy 2.0 and later before 2018.3.7, an authenticated user, with variable edit permissions, can scope some variables to targets greater than their permissions should allow. In other words, they can see machines beyond their team's scoped environments.

An issue was discovered in Octopus Deploy before 4.1.9. Any user with user editing permissions can modify teams to give themselves Administer System permissions even if they didn't have them, as demonstrated by use of the RoleEdit or TeamEdit permission.

In Octopus Deploy versions 3.2.11 - 4.1.5 (fixed in 4.1.6), an authenticated user with ProcessEdit permission could reference an Azure account in such a way as to bypass the scoping restrictions, resulting in a potential escalation of privileges.

In Octopus Deploy before 4.1.3, the machine update process doesn't check that the user has access to all environments. This allows an access-control bypass because the set of environments to which a machine is scoped may include environments in which the user lacks access.

Cross-site scripting (XSS) vulnerability in the All Variables tab in Octopus Deploy 3.4.0-3.13.6 (fixed in 3.13.7) allows remote attackers to inject arbitrary web script or HTML via the Variable Set Name parameter.

Cross-site scripting (XSS) vulnerability in Octopus Deploy 3.7.0-3.17.13 (fixed in 3.17.14) allows remote authenticated users to inject arbitrary web script or HTML via the Step Template Name parameter.

In Octopus before 3.17.7, an authenticated user who was explicitly granted the permission to invite new users (aka UserInvite) can invite users to teams with escalated privileges.

An issue was discovered in Octopus before 3.17.7. When the special Guest user account is granted the CertificateExportPrivateKey permission, and Guest Access is enabled for the Octopus Server, an attacker can sign in as the Guest account and export Certificates managed by Octopus, including the private key.

Octopus before 3.17.7 allows attackers to obtain sensitive cleartext information by reading a variable JSON file in certain situations involving Offline Drop Targets.

In Octopus Deploy 3.x before 3.15.4, an authenticated user with PackagePush permission to upload packages could upload a maliciously crafted NuGet package, potentially overwriting other packages or modifying system files. This is a directory traversal in the PackageId value.