Cloud Foundry UAA Release, versions prior to 71.0, allows clients to be configured with an insecure redirect uri. Given a UAA client was configured with a wildcard in the redirect uri's subdomain, a remote malicious unauthenticated user can craft a phishing link to get a UAA access code from the victim.

Cloud Foundry Container Runtime, versions prior to 0.29.0, deploys Kubernetes clusters utilize the same CA (Certificate Authority) to sign and trust certs for ETCD as used by the Kubernetes API. This could allow a user authenticated with a cluster to request a signed certificate leveraging the Kubernetes CSR capability to obtain a credential that could escalate privilege access to ETCD.

Cloud Foundry CLI, versions prior to v6.43.0, improperly exposes passwords when verbose/trace/debugging is turned on. A local unauthenticated or remote authenticated malicious user with access to logs may gain part or all of a users password.

The identity zones feature in Pivotal Cloud Foundry 208 through 229; UAA 2.0.0 through 2.7.3 and 3.0.0; UAA-Release 2 through 4, when configured with multiple identity zones; and Elastic Runtime 1.6.0 through 1.6.13 allows remote authenticated users with privileges in one zone to gain privileges and perform operations on a different zone via unspecified vectors.

Cloud Foundry cf-deployment, versions prior to 7.9.0, contain java components that are using an insecure protocol to fetch dependencies when building. A remote unauthenticated malicious attacker could hijack the DNS entry for the dependency, and inject malicious code into the component.

Cloud Foundry Container Runtime, versions prior to 0.28.0, deploys K8s worker nodes that contains a configuration file with IAAS credentials. A malicious user with access to the k8s nodes can obtain IAAS credentials allowing the user to escalate privileges to gain access to the IAAS account.

Cloud Controller API versions prior to 1.106.0 logs service broker credentials if the default value of db logging config field is changed. CAPI database logs service broker password in plain text whenever a job to clean up orphaned items is run by Cloud Controller.

BOSH System Metrics Server releases prior to 0.1.0 exposed the UAA password as a flag to a process running on the BOSH director. It exposed the password to any user or process with access to the same VM (through ps or looking at process details).

Cloud Foundry UAA, versions prior to v74.3.0, contains an endpoint that is vulnerable to SCIM injection attack. A remote authenticated malicious user with scim.invite scope can craft a request with malicious content which can leak information about users of the UAA.

Cloud Foundry SMB Volume, versions prior to v2.0.3, accidentally outputs sensitive information to the logs. A remote user with access to the SMB Volume logs can discover the username and password for volumes that have been recently created, allowing the user to take control of the SMB Volume.

Cloud Foundry Cloud Controller API (CAPI), version 1.88.0, allows space developers to list all global service brokers, including service broker URLs and GUIDs, which should only be accessible to admins.

Cloud Foundry CAPI (Cloud Controller) versions prior to 1.98.0 allow authenticated users having only the "cloud_controller.read" scope, but no roles in any spaces, to list all droplets in all spaces (whereas they should see none).

Cloud Foundry Cloud Controller (CAPI), versions prior to 1.91.0, logs properties of background jobs when they are run, which may include sensitive information such as credentials if provided to the job. A malicious user with access to those logs may gain unauthorized access to resources protected by such credentials.

Cloud Foundry UAA, versions 60 prior to 66.0, contain an authorization logic error. In environments with multiple identity providers that contain accounts across identity providers with the same username, a remote authenticated user with access to one of these accounts may be able to obtain a token for an account of the same username in the other identity provider.

Cloud Foundry NFS volume release, 1.2.x prior to 1.2.5, 1.5.x prior to 1.5.4, 1.7.x prior to 1.7.3, logs the cf admin username and password when running the nfsbrokerpush BOSH deploy errand. A remote authenticated user with access to BOSH can obtain the admin credentials for the Cloud Foundry Platform through the logs of the NFS volume deploy errand.

Applications in cf-release before 245 can be configured and pushed with a user-provided custom buildpack using a URL pointing to the buildpack. Although it is not recommended, a user can specify a credential in the URL (basic auth or OAuth) to access the buildpack through the CLI. For example, the user could include a GitHub username and password in the URL to access a private repo. Because the URL to access the buildpack is stored unencrypted, an operator with privileged access to the Cloud Controller database could view these credentials.

Windows 2012R2 stemcells, versions prior to 1200.17, contain an information exposure vulnerability on vSphere. A remote user with the ability to push apps can execute crafted commands to read the IaaS metadata from the VM, which may contain BOSH credentials.

In Cloud Controller versions prior to 1.46.0, cf-deployment versions prior to 1.3.0, and cf-release versions prior to 283, Cloud Controller accepts refresh tokens for authentication where access tokens are expected. This exposes a vulnerability where a refresh token that would otherwise be insufficient to obtain an access token, either due to lack of client credentials or revocation, would allow authentication.

Cloud Foundry Container Runtime (kubo-release), versions prior to 0.14.0, may leak UAA and vCenter credentials to application logs. A malicious user with the ability to read the application logs could use these credentials to escalate privileges.

Cloud Foundry UAA version prior to 73.3.0, contain endpoints that contains improper escaping. An authenticated malicious user with basic read privileges for one identity zone can extend those reading privileges to all other identity zones and obtain private information on users, clients, and groups in all other identity zones.

CF UAA versions prior to 74.1.0, allow external input to be directly queried against. A remote malicious user with 'client.write' and 'groups.update' can craft a SCIM query, which leaks information that allows an escalation of privileges, ultimately allowing the malicious user to gain control of UAA scopes they should not have.

CF UAA versions prior to 74.1.0 can request scopes for a client that shouldn't be allowed by submitting an array of requested scopes. A remote malicious user can escalate their own privileges to any scope, allowing them to take control of UAA and the resources it controls.

An issue was discovered in Cloud Foundry Foundation cf-release versions prior to v258; UAA release 2.x versions prior to v2.7.4.15, 3.6.x versions prior to v3.6.9, 3.9.x versions prior to v3.9.11, and other versions prior to v3.16.0; and UAA bosh release (uaa-release) 13.x versions prior to v13.13, 24.x versions prior to v24.8, and other versions prior to v30.1. An authorized user can use a blind SQL injection attack to query the contents of the UAA database, aka "Blind SQL Injection with privileged UAA endpoints."

Cloud Foundry CAPI (Cloud Controller), versions prior to 1.97.0, when used in a deployment where an app domain is also the system domain (which is true in the default CF Deployment manifest), were vulnerable to developers maliciously or accidentally claiming certain sensitive routes, potentially resulting in the developer's app handling some requests that were expected to go to certain system components.

Cloud Foundry Stratos, versions prior to 2.3.0, contains an insecure session that can be spoofed. When deployed on cloud foundry with multiple instances using the default embedded SQLite database, a remote authenticated malicious user can switch sessions to another user with the same session id.

A UAA configured with multiple identity zones, does not properly validate session information across those zones. A User authenticated against a corporate IDP can re-use their jsessionid to access other zones.

Symfony/SecurityBundle is the security system for Symfony, a PHP framework for web and console applications and a set of reusable PHP components. Since the rework of the Remember me cookie in version 5.3.0, the cookie is not invalidated when the user changes their password. Attackers can therefore maintain their access to the account even if the password is changed as long as they have had the chance to login once and get a valid remember me cookie. Starting with version 5.3.12, Symfony makes the password part of the signature by default. In that way, when the password changes, then the cookie is not valid anymore.

IBM Financial Transaction Manager 3.0.1 and 3.0.2 does not properly update the SESSIONID with each request, which could allow a user to obtain the ID in further attacks against the system. IBM X-Force ID: 122293.

An issue was discovered with the JSESSION IDs in Xiamen Si Xin Communication Technology Video management system 3.1 thru 4.1 allows attackers to gain escalated privileges.

ZITADEL is an open source identity management system. Starting in version 2.53.0 and prior to versions 4.0.0-rc.2, 3.3.2, 2.71.13, and 2.70.14, vulnerability in ZITADEL's session management API allows any authenticated user to update a session if they know its ID, due to a missing permission check. This flaw enables session hijacking, allowing an attacker to impersonate another user and access sensitive resources. Versions prior to `2.53.0` are not affected, as they required the session token for updates. Versions 4.0.0-rc.2, 3.3.2, 2.71.13, and 2.70.14 fix the issue.

In VOS user session identifier (authentication token) is issued to the browser prior to authentication but is not changed after the user successfully logs into the application. Failing to issue a new session ID following a successful login introduces the possibility for an attacker to set up a trap session on the device the victim is likely to login with.

IBM Security Privileged Identity Manager Virtual Appliance 2.2.1 does not renew a session variable after a successful authentication which could lead to session fixation/hijacking vulnerability. This could force a user to utilize a cookie that may be known to an attacker. IBM X-Force ID: 144411.

IBM BigFix Platform 9.2.0 through 9.2.14 and 9.5 through 9.5.9 does not renew a session variable after a successful authentication which could lead to session fixation/hijacking vulnerability. This could force a user to utilize a cookie that may be known to an attacker. IBM X-Force ID: 140970.

In multiple products of CODESYS v3 in multiple versions a remote low privileged user could utilize this vulnerability to read and modify system files and OS resources or DoS the device.

Nextcloud Talk is a fully on-premises audio/video and chat communication service. Password protected shared chats in Talk before version 9.0.10, 10.0.8 and 11.2.2 did not rotate the session cookie after a successful authentication event. It is recommended that the Nextcloud Talk App is upgraded to 9.0.10, 10.0.8 or 11.2.2. No workarounds for this vulnerability are known to exist.

An issue was discovered on Gemtek WRTM-127ACN 01.01.02.141 and WRTM-127x9 01.01.02.127 devices. The Monitor Diagnostic network page allows an authenticated attacker to execute a command directly on the target machine. Commands are executed as the root user (uid 0). (Even if a login is required, most routers are left with default credentials.)

In the mtproto_proxy (aka MTProto proxy) component through 0.7.2 for Erlang, a low-privileged remote attacker can access an improperly secured default installation without authenticating and achieve remote command execution ability.

IBM Storage Scale 5.1.0.0 through 5.1.9.2 could allow an authenticated user to steal or manipulate an active session to gain access to the system. IBM X-Force ID: 260208.

IBM Financial Transaction Manager 3.2.4 does not invalidate session any existing session identifier gives an attacker the opportunity to steal authenticated sessions. IBM X-Force ID: 215040.

As of v1.5.0, the default admin password is set to the argocd-server pod name. For insiders with access to the cluster or logs, this issue could be abused for privilege escalation, as Argo has privileged roles. A malicious insider is the most realistic threat, but pod names are not meant to be kept secret and could wind up just about anywhere.