OctopusDeploy/Issues

Cleartext storage of sensitive information in multiple versions of Octopus Server where in certain situations when running import or export processes, the password used to encrypt and decrypt sensitive values would be written to the logs in plaintext.

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.

In Octopus Deploy 2020.3.x before 2020.3.4 and 2020.4.x before 2020.4.1, if an authenticated user creates a deployment or runbook process using Azure steps and sets the step's execution location to run on the server/worker, then (under certain circumstances) the account password is exposed in cleartext in the verbose task logs output.

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.)

A persistent cross-site scripting (XSS) vulnerability in Octopus Server 3.4.0 through 2019.10.5 allows remote authenticated attackers to inject arbitrary web script or HTML.

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 Deploy versions 2018.8.4 to 2019.7.6, when a web request proxy is configured, an authenticated user (in certain limited special-characters circumstances) could trigger a deployment that writes the web request proxy password to the deployment log in cleartext. This is fixed in 2019.7.7. The fix was back-ported to LTS 2019.6.7 as well as LTS 2019.3.8.

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.