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.

Permissions were not properly verified in the API on projects using version control in Git. This allowed projects to be modified by users with only ProjectView permissions.

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

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.

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.

Affected versions of Octopus Server are prone to an authenticated SQL injection vulnerability in the Events REST API because user supplied data in the API request isn’t parameterised correctly. Exploiting this vulnerability could allow unauthorised access to database tables.

When configuring Octopus Server if it is configured with an external SQL database, on initial configuration the database password is written to the OctopusServer.txt log file in plaintext.

When configuring Octopus Server if it is configured with an external SQL database, on initial configuration the database password is written to the OctopusServer.txt log file in plaintext.

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.

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.

Cleartext Storage of Sensitive Information

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.

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 through 2020.4.2, an attacker could redirect users to an external site via a modified HTTP Host header.

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.