In Eclipse BaSyx Helm Charts version 2.2.0 of the `aas-basyx-v2-full` chart, deployments with the bundled Keycloak enabled store the client secret of the `basyx-technical-user` OAuth2 client in cleartext in a Kubernetes ConfigMap. This client uses the client-credentials grant and its service account holds the realm `admin` role.
The chart correctly writes `keycloak.technicalUser.clientSecret` to a Kubernetes Secret, but the template `basyx-keycloak-realm.yaml` also substitutes the same value into the Keycloak realm-import JSON, which is stored in the ConfigMap `<keycloak.fullnameOverride>-realm`. A principal that can read ConfigMaps but not Secrets in the release namespace, such as a holder of the built-in Kubernetes `view` ClusterRole, can read the client secret from the ConfigMap. They can then exchange it at the Keycloak token endpoint for an access token with the `admin` role. That token grants full create, read, update, delete and execute rights on all BaSyx repositories and registries in the deployment.
The bundled Keycloak is disabled by default. No fixed release of the `aas-basyx-v2-full` chart exists. Affected users should migrate to the `basyx` chart, or deploy without the bundled Keycloak and rotate the `basyx-technical-user` client secret.
In Eclipse BaSyx Helm Charts versions 3.0.0-rc.1 to 3.12.1 of the `basyx` chart, deployments with the bundled Keycloak enabled store the passwords of the Keycloak users that the chart creates in cleartext in a Kubernetes ConfigMap.
The template `keycloak-init-config.yaml` rendered `keycloak.initialization.users`, including each user's `credentials[].value`, as `users.json` into the persistent ConfigMap `<release>-basyx-keycloak-init-config`. By default this includes the bootstrap administrator user. That user holds the `admin` role and has a non-temporary password. A principal that can read ConfigMaps but not Secrets in the release namespace, such as a holder of the built-in Kubernetes `view` ClusterRole, can read the password from the ConfigMap and log in to Keycloak as this user. The resulting token carries the `admin` role, which the default BaSyx ABAC rules map to full rights on all BaSyx APIs in the deployment.
The bundled Keycloak is disabled by default. The issue is fixed in version 3.12.2 of the `basyx` chart, which moves the initialization users to the Keycloak credentials Secret. Affected users should upgrade and change the passwords of users that were created through the chart.
CVE-2026-73116 is a critical vulnerability in Apache Juneau through version 9.2.0 where the RestClient improperly retains credential headers during HTTP redirects. This allows sensitive headers such as Authorization, Cookie, Proxy-Authorization, and X-API-Key to be sent to unintended hosts or downgraded protocols. The issue is fixed in version 9.2.1.
CVE-2026-97693 is a critical command injection vulnerability in the Yuxi platform versions from 0.6.0.beta1 up to but not including 0.7.1. It allows a low-privileged authenticated user with command execution in their own Docker sandbox to access and manipulate other tenants' sandboxes and data without needing administrator credentials. The vulnerability arises from insufficient isolation between Docker sandboxes and trusted services, enabling cross-tenant API access, file and secret exposure, sandbox management, and potential command execution in shared internal services if default credentials remain unchanged. The issue is fixed in version 0.7.1, but deployments must also rotate persisted credentials for PostgreSQL, Neo4j, and MinIO if they were set to default values, as upgrading alone does not rotate these credentials.
Sonatype Nexus Repository 3 versions 3.93.0 through 3.97.x contain a vulnerability where the signing passphrase for APT or YUM repositories is exposed via an internal REST endpoint. This endpoint returns the passphrase to user accounts with only read privileges, which do not require editing rights. This exposure can lead to unauthorized access to sensitive credentials.
Sonatype Nexus Repository 3 versions 3.93.0 through 3.97.x have a vulnerability where an account with only read privileges on a YUM proxy or group repository can obtain the private signing key. This key allows signing of repository metadata, which should require higher privileges. The issue is fixed in version 3.98.0.
The component ScopingHttpClient in Symfony HttpClient merges the options of its default scope (such as auth_bearer or auth_basic) into a request before resolving a relative URL against the base_uri, allowing a network-path reference such as "//evil.example/steal" to be sent to another origin together with the default scope’s credentials, and resulting in potential disclosure of those credentials to an attacker-controlled server. This affects Symfony in versions 5.x prior to 5.4.56, 6.x prior to 6.4.50, 7.x prior to 7.4.23, and 8.x prior to 8.1.11.
The resolved URL falls outside the origin of the base URI, yet it keeps the merged options, whereas the absolute spelling "https://evil.example/steal" receives none. The same happens with a different port or user-info part on the same host.
This is reachable whenever an attacker controls the beginning of a URL passed to a client built with a base_uri and credentials, including those created with HttpClient::createForBaseUri() or configured under framework.http_client.scoped_clients.
To solve the issue, after resolving a relative URL against the base URI of the default scope, ScopingHttpClient now compares the scheme and authority of the result with those of the base URI, parsed the way the request is sent.
A vulnerability in Django versions 6.0 before 6.0.10 and 6.1 before 6.1.3 allows authenticated staff users with view-only permissions on certain user models to view full password hashes. This occurs because the password field is not obfuscated in the admin display for user models other than the default AUTH_USER_MODEL or those inheriting the password field via multi-table inheritance. The issue has been fixed in Django 6.0.10 and 6.1.3.
In Eclipse Mnestix Browser versions 1.6.0 up until but excluding 2.3.0 it was possible for an unauthenticated attacker to exfiltrate the MNESTIX_BACKEND_API_KEY for all configured Infrastructures.
kaniko before 1.25.20 can send a Microsoft Entra ID (Azure AD) access token for Azure Resource Manager to an attacker-controlled registry host. kaniko uses the Azure Container Registry credential helper github.com/chrismellard/docker-credential-acr-env, which decides whether a host is an ACR registry with an unanchored regular expression, so any hostname containing .azurecr.io, .azurecr.cn, .azurecr.de or .azurecr.us is accepted. kaniko consults this helper for any registry that has no credentials in the Docker config and is not a Google or Amazon ECR registry, before contacting the registry. A Dockerfile that references an image on a lookalike host, such as FROM x.azurecr.io.attacker.com/img or COPY --from=<image>, causes the helper to obtain a token from the build's Azure identity (service principal environment variables, federated workload identity token, or managed identity) and POST it to https://<host>/oauth2/exchange. The attacker can use the token against Azure Resource Manager with the identity's role assignments until it expires, and can exchange it for credentials to any ACR registry the identity can access. No RUN instruction or push is required. This issue is fixed in 1.25.20.
pgAdmin 4 versions before 9.19 contain an argument injection vulnerability in the materialized view refresh feature. The database name passed to the psql --dbname argument was not properly sanitized, allowing a specially crafted database name to redirect connections to arbitrary hosts and ports. This could expose the connecting user's saved server password to an attacker-controlled endpoint. The issue was fixed in version 9.19 by properly routing the database name through a helper function that ensures it is treated strictly as a database name.
CVE-2026-116247 is a vulnerability in pgAdmin 4 before version 9.19 where insufficient protection of credentials in server mode allows any user to connect using the service account's saved passwords or client certificate. This occurs when no password file, client certificate, or client key is configured or found, causing libpq to fall back to default credential files of the operating system account running pgAdmin. The issue is fixed in version 9.19 by ensuring connection parameters explicitly specify user-specific credential files or invalid paths to prevent unauthorized access.
CVE-2026-116245 is a vulnerability in pgAdmin 4 before version 9.19 where insufficient protection of credentials allows unauthorized users in server mode to connect using stored service credentials. The issue arises because libpq uses connection service entries from the operating system account running pgAdmin 4, which can include passwords or references to password files or client certificates. The vulnerability is addressed in pgAdmin 4 version 9.19 by introducing a SERVER_MODE_ALLOWED_SERVICES setting that restricts allowed services, disallows the servicefile parameter, and removes sensitive environment variables at startup.
CVE-2026-116244 is a vulnerability in pgAdmin 4 before version 9.19 where Kerberos credentials were insufficiently protected. The issue allowed any user to connect as the service account's Kerberos principal in server mode due to improper handling of Kerberos credential caches. The vulnerability was fixed in pgAdmin 4 version 9.19 by restricting credential cache usage and enforcing stricter authentication requirements.
pgAdmin 4 versions before 9.19 have a vulnerability where SSH tunnels in server mode improperly use the service account's SSH keys and configuration, allowing any user to create tunnels to hosts accepting the service account's key without their own credentials. This issue is fixed in version 9.19 by restricting tunnel authentication to only the user's configured identity file or password.
SOCFortress CoPilot focuses on providing a single pane of glass for all your security operations needs. In affected deployments, the unauthenticated `/scoutsuite-report` `StaticFiles` mount in `backend/copilot.py` exposes the `scoutsuite-report` directory even though normal /api routes require JWT authentication. Generated HTML reports and `scoutsuite-results/scoutsuite_results_<name>.js` files disclose AWS, Azure and GCP IAM principals, resource inventories, misconfigurations and findings. Report names derive from caller-selected names with predictable defaults. During an admin- or analyst-initiated GCP scan, `backend/app/integrations/scoutsuite/routes/scoutsuite.py` saves the uploaded Google service-account JSON key into that same web-served directory. In `backend/app/integrations/scoutsuite/services/scoutsuite.py`, `generate_gcp_report_background` removes the key only after the scan finishes. Any anonymous client that can reach the host and request the file path can therefore retrieve the private key during the scan and use the service account's cloud permissions, as well as read retained cloud-security reports. Credential isolation is released in version 0.1.77; a release fully remediating the report-disclosure component has not been established.
Dell OpenManage Enterprise versions prior to 4.8.0 contain a vulnerability where credentials are insufficiently protected. This flaw could allow a low privileged attacker with remote access to potentially disclose sensitive information. The vulnerability has a medium severity rating and is addressed in version 4.8.0 and later.
sigstore-js provides JavaScript libraries for interacting with Sigstore services. Prior to 0.7.2, packages/oci/src/registry.ts contains a RegistryClient.signIn() method that stores registry Authorization and Docker configuration headers as defaults on a shared HTTP client, while RegistryClient.uploadBlob() sends a fresh PUT to an absolute blob-upload Location supplied by the registry without checking that its origin or scheme matches the registry. A malicious or compromised registry can therefore direct a user pushing an artifact through attachArtifactToImage() to an attacker-controlled host and receive the registry bearer token, Basic credentials, or custom authentication headers. Redirect-time header stripping does not prevent the leak because the cross-host PUT is a new explicit request rather than a followed redirect. This is a residual of CVE-2026-59891, whose fix changed credential selection in credentials.ts but did not constrain where credentials are sent from registry.ts. Version 0.7.2 fixes the issue by separating registry credentials from client-wide defaults and sending them only to the registry origin.
Progress Software WS_FTP Server versions prior to 2024.0.7 and 2025.0.4 on Windows may expose a user's password in clear text to another administrator, who could use it to gain broader administrative access to the server.
Improper authentication in Progress Software WS_FTP Server versions prior to 2024.0.6 and 2025.0.3 on Windows could allow an unauthenticated remote attacker to access sensitive information, including administrative credentials.