| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Insufficiently protected credentials in Microsoft Office allows an unauthorized attacker to perform spoofing over a network. |
| HCL AppScan Azure Boards Plugin is potentially affected by an Information Disclosure vulnerability involving secrets accessible in plaintext during pipeline execution. Depending on the pipeline configuration, these secrets could be exposed through task outputs, debug logs, environment variable dumps, or build agent scripts, despite being masked in the user interface. |
| NT OneAPP developed by NewType Infortech has a Credential Disclosure vulnerability. Unauthenticated remote attackers can trigger an HTTP Basic Authentication challenge from an unvalidated source in the WebView under specific conditions, thereby obtaining the NUP Portal passcode of a logged-in user. |
| 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. |
| Missing Authentication for Critical Function (CWE-306) and Insufficiently Protected Credentials (CWE-522) in the control plane enrollment status handler (HandleEnrollStatus at GET /enroll/status in internal/controlplane/server.go) in Google OSS Agent Mesh (SAM) versions 0.1.0-alpha.1 through 0.1.0-alpha.8 allow an unauthenticated remote attacker to retrieve an approved bootstrap-enrolled peer's signed Biscuit identity token by supplying a peer_id obtainable from the unauthenticated GET /info endpoint. A related flaw in POST /enroll allowed any bootstrap-token holder to re-fetch another peer's credential. An attacker can replay the disclosed Biscuit token as a bearer credential on /policies to read mesh authorization policies and on /routers/lease to overwrite advertised router multiaddrs. Users should upgrade to version 0.1.0-alpha.9 or later, which requires cryptographic proof of possession of the enrollment private key on credential-releasing endpoints, enforces rate limiting, and validates router lease addresses. |
| libcurl could accidentally return a URL for `curl_easy_getinfo()`'s
`CURLINFO_EFFECTIVE_URL` option containing credentials, even though neither
the URL provided to libcurl nor the redirected URL did. |
| 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. |
| IBM Langflow OSS 1.0.0 through 1.12.3 could allow an authenticated attacker with a read or share grant on a target flow to retrieve the flow owner's stored third-party credentials in cleartext from the API response. |
| Nuxt Ollama integrates the official Ollama JavaScript library into Nuxt applications. Prior to 1.3.1, `src/module.ts` unconditionally merges all module options, including a configured cloud `api_key`, into `runtimeConfig.public.ollama`. Nuxt serializes this public configuration into the server-rendered HTML `window.__NUXT__` payload, exposing the API key in plaintext to any unauthenticated client that fetches a page. `src/runtime/composables/useOllama.ts` also reads the public key and sends it as an `Authorization` `Bearer` credential in browser-side Ollama requests. Following the documented cloud configuration is sufficient; the visible application template need not make an Ollama request for the secret to leak. A stolen key permits unauthorized cloud API requests at the operator's expense, quota or rate-limit exhaustion, and access to stored models or conversations if the key grants those permissions. This issue is fixed in version 1.3.1. |
| Arcane is an interface for managing Docker containers, images, networks, and volumes. Prior to 2.5.0, UpdateRegistry and TestRegistry in backend/api/services/container_registry_service.go allow the registry URL to change while preserving the stored encrypted token. When a holder of registries:update and registries:test repoints a generic registry URL without supplying a replacement token, TestRegistry decrypts the preserved token and RegistryLogin sends it to the attacker-controlled host because normalizeRegistryServerAddressInternal does not restrict the destination. This exposes the stored container-registry PAT or password and can enable image access or tampering. This issue is fixed in version 2.5.0. |
| Omnispace Agora Project before 26.10.0 contains a vulnerability where the persistent remember-me token is stored verbatim server-side, making the stored value identical to the bearer credential held in the user's cookie. Attackers who gain access to the stored token, such as through database or backup disclosure, can replay the plaintext value to authenticate as the victim user without needing their password. |
| libgit2 is a portable C implementation of the Git core methods provided as a linkable library with a solid API, allowing to build Git functionality into your application. Prior to 1.8.6 and 1.9.5, the built-in HTTP transport in src/libgit2/transports/http.c follows an offsite initial redirect, and handle_remote_auth and handle_auth pass transport->owner->url instead of transport->server.url to the credential callback when the redirected host returns 401 Unauthorized. A callback that scopes credentials to the original trusted URL can therefore return GIT_CREDENTIAL_USERPASS_PLAINTEXT credentials that libgit2 stores in transport->server.cred and sends as an Authorization header to the redirected host. An attacker who controls a trusted Git host or an open redirect on that host can disclose HTTP Basic credentials, personal access tokens, or equivalent credentials. This issue is fixed in versions 1.8.6 and 1.9.5. |
| When the http:// stream wrapper follows a redirect it forwards the user-supplied Authorization, Cookie and Proxy-Authorization headers unchanged, even when the redirect target is a different host, a different port, or a downgrade from HTTPS to HTTP. A server that can steer a redirect therefore receives credentials that were only meant for the original origin. This is the same class of issue that libcurl fixed in 7.58.0 ( CVE-2018-1000007 https://github.com/advisories/GHSA-g7x2-hrfp-pv5f ). |
| cpp-httplib is a C++ header-only HTTP/HTTPS library. Prior to 0.51.0, create_redirect_client() removes Host, Proxy-Authorization, and Authorization headers when following a cross-origin 301, 302, 307, or 308 redirect but leaves Cookie headers attached. detail::redirect() copies the request for those redirect codes, so cookies supplied directly or through default_headers_ are sent to the redirect target. An attacker who controls a redirect response, or a network position for a non-HTTPS origin, can receive session cookies intended for the original origin. A 303 redirect is not affected because that path clears all request headers. This issue is fixed in version 0.51.0. |
| A2A Java SDK is the official Java SDK for the Agent2Agent (A2A) Protocol. Starting in version 1.3.0.Final and prior to version 1.3.2.Final, the AndroidA2AHttpClient synchronous POST path overrides the disabled-redirect setting in AndroidA2AHttpClient.createConnection() with the PostBuilder default followRedirects value of true, leaving a residual of the earlier credential-redirect fix. JSONRPCTransport and RestTransport add interceptor-produced authentication headers and call synchronous post() without disabling redirects. AuthInterceptor permits X-API-Key, API-Key, X-Auth-Token, and X-Authentication headers; Android's repackaged OkHttp strips Authorization on cross-authority redirects but retains these nonstandard headers, disclosing a complete configured API key or token to another authority. The additional exposure applies when redirect or front-door behavior is compromised separately from the credential-handling component, or those components operate in different trust domains; a completely malicious initial origin already receives the credential on the first request. Autonomous clients require no human action, while user-invoked workflows can require interaction. Explicit followRedirects(false) prevents the redirected request. The demonstrated impact is credential disclosure, not subsequent credential use, integrity or availability impact, code execution, or host compromise. This issue is fixed in version 1.3.2.Final. |
| A insufficiently protected credentials vulnerability in Fortinet FortiOS 7.4.0 through 7.4.1, FortiOS 7.2.0 through 7.2.6, FortiOS 7.0.0 through 7.0.12, FortiOS 6.4.0 through 6.4.14, FortiOS 6.2.0 through 6.2.15, FortiOS 6.0 all versions, FortiProxy 7.4.0 through 7.4.1, FortiProxy 7.2.0 through 7.2.7, FortiProxy 7.0.0 through 7.0.13, FortiProxy 2.0 all versions, FortiProxy 01.02 all versions, FortiProxy 1.2 all versions, FortiProxy 01.01 all versions, FortiProxy 1.1 all versions, FortiProxy 01.00 all versions allows attacker to execute unauthorized code or commands via targeted social engineering attack |
| Coder before 2.29.20, 2.33.0 before 2.33.12, 2.34.0 before 2.34.8, and 2.35.0 before 2.35.4 contains an improper hostname validation flaw in GetWorkspaceProxyByHostname whose SIMILAR TO pattern performs a prefix match, so any domain that is a string prefix of a workspace-proxy access URL is trusted as a proxy. Attackers owning such a domain can lure an authenticated victim to a crafted /api/v2/applications/auth-redirect link, capture the redirected application_connect API key, and replay it to access the victim's workspace apps. |
| Trigger.dev 4.5.0 before 4.6.0 contains an information disclosure vulnerability in the Dashboard Agent input proxy that stores a delegated user-actor token in browser-readable session input records. Attackers holding a chat's public session token can read the in records endpoint to recover the token from payload.metadata.userActorToken and replay it for environment JWT exchange. |
| GDevelop desktop app through 5.6.284 contains a credential leak vulnerability that allows attackers to steal the gd_resource cookie by supplying attacker-controlled resource URLs in project files. Attackers can get victims to open a crafted project, causing downloadLocalFile() to send the cookie to their server and expose private cloud project resources. |
