Octopus Server any version

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 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 Deploy it is possible to bypass rate limiting on login using null bytes.

SQL Injection in the Octopus Server REST API

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 version of Octopus Deploy it was possible to remove files and/or contents of files on the host using an API endpoint. The field lacked validation which could potentially result in ways to circumvent expected workflows.

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 affected versions of Octopus Deploy it is possible for a user to introduce code via offline package creation

A race condition was identified through which privilege escalation was possible in certain configurations.

In affected Microsoft Windows versions of Octopus Deploy, the server can be coerced into sending server-side requests that contain authentication material allowing a suitably positioned attacker to compromise the account running Octopus Server and potentially the host infrastructure itself.

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

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.

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 affected versions of Octopus Deploy it is possible to upload a zipbomb file as a task which results in Denial of Service

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 affected versions of Octopus Deploy it is possible to perform a Regex Denial of Service using the Variable Project Template.

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 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 via the package upload function.

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 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 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 the OpenID client secret to be logged in clear text during the configuration of Octopus Server.

In affected versions of Octopus Server the preview import feature could be leveraged to identify the existence of a target file. This could provide an adversary with information that may aid in further attacks against the server.

In affected versions of Octopus Server under certain circumstances it is possible for sensitive variables to be printed in the deployment variable snapshot in clear-text.

In affected versions of Octopus Deploy where customers are using Active Directory for authentication it was possible for an unauthenticated user to make an API request against two endpoints which would retrieve some data from the associated Active Directory. The requests when crafted correctly would return specific information from user profiles (Email address/UPN and Display name) from one endpoint and group information ( Group ID and Display name) from the other. This vulnerability does not expose data within the Octopus Server product itself.

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 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 Deploy it is possible to upload a package to built-in feed with insufficient permissions after re-indexing packages.

In affected versions of Octopus Server, permissions were not checked correctly resulting in any authenticated user being able to make server level changes using a certain API endpoint despite receiving an error.

In affected versions of Octopus Server under certain circumstances it is possible for sensitive variables to be printed in the task log in clear-text.

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

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 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 Server it was possible for a user with sufficient access to set custom headers in all server responses. By submitting a specifically crafted referrer header the user could ensure that all subsequent server responses would return 500 errors rendering the site mostly unusable. The user would be able to subsequently set and unset the referrer header to control the denial of service state with a valid CSRF token whilst new CSRF tokens could not be generated.

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 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 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 it was possible to upload files to unexpected locations on the host using an API endpoint. The field lacked validation which could potentially result in ways to circumvent expected workflows.