Apache SkyWalking versions from 9.6.0 through 11.0.0 have a vulnerability where the PagerDuty alarm hook transmits the integration routing key over unencrypted HTTP. Although PagerDuty redirects HTTP requests to HTTPS, the initial POST containing sensitive information is sent in cleartext before the redirect occurs. This exposure could allow interception of the routing key during transmission. Users are advised to upgrade to version 11.0.0 where this issue is fixed.
### Summary
httpcore2 does not start TLS for `wss://` connections routed through a SOCKS5 proxy. The WebSocket opening handshake and all subsequent frames are sent in plaintext through the proxy path, despite the caller selecting the secure `wss` scheme.
The transport flaw affects httpcore2 releases before `2.10.0`. HTTPX2 exposed this behavior through its public `Client.websocket()` and `AsyncClient.websocket()` APIs from `2.6.0` through `2.9.1`.
### Details
The synchronous and asynchronous SOCKS5 connection implementations upgrade the established proxy tunnel to TLS only when the remote origin scheme is `https`. The equivalent check does not include `wss`. After the SOCKS5 handshake succeeds, the raw stream is therefore passed directly to the HTTP/1.1 connection, which writes the WebSocket upgrade request without first performing a TLS handshake or verifying the destination certificate.
For example, an application using HTTPX2 `2.6.0` through `2.9.1` may open an authenticated WebSocket through a SOCKS proxy:
```python
import httpx2
with httpx2.Client(proxy="socks5://proxy.example:1080") as client:
with client.websocket(
"wss://service.example/private?token=query-secret",
headers={"Authorization": "Bearer header-secret"},
cookies={"session": "cookie-secret"},
) as websocket:
websocket.send_text("private message")
```
On affected versions, the stream passing through the SOCKS proxy begins with a plaintext request such as:
```text
GET /private?token=query-secret HTTP/1.1
Host: service.example
Authorization: Bearer header-secret
Cookie: session=cookie-secret
```
Before HTTPX2 `2.6.0`, the same underlying httpcore2 behavior could be reached by integrations constructing a WebSocket upgrade request through the low-level transport API, but HTTPX2 did not yet provide its native WebSocket client API.
A normal secure WebSocket server will usually reject these plaintext bytes because it expects a TLS ClientHello. However, a malicious or compromised SOCKS proxy can accept the SOCKS connection, observe the plaintext handshake, return a forged `101 Switching Protocols` response, and then read or modify WebSocket frames in both directions. An observer between the proxy and destination may also read the plaintext traffic.
RFC 6455 requires a client using a secure WebSocket connection to perform the TLS handshake before sending the WebSocket opening handshake. A `wss` URI promises confidentiality, integrity, and endpoint authentication through TLS.
### Impact
An attacker able to control or observe the SOCKS proxy path can obtain URL query parameters, authorization headers, cookies, and application messages that the caller expected TLS to protect. Because no TLS handshake occurs, certificate verification also does not occur, allowing an attacker controlling the proxy to impersonate the WebSocket server and inject or alter messages.
Only `wss://` connections routed through a SOCKS5 proxy are affected. Direct `wss://` connections and ordinary `https://` requests through SOCKS already start TLS correctly.
### Mitigation
Upgrade HTTPX2 and httpcore2 to `2.10.0` or later. Patched versions start TLS for both `https` and `wss` origins in the synchronous and asynchronous SOCKS5 connection paths.
If upgrading is not immediately possible, do not route `wss://` connections through a SOCKS proxy. Use a direct secure WebSocket connection or another transport that performs and verifies TLS to the WebSocket origin.
MariaDB Connector/R2DBC versions prior to 1.4.1 do not prevent cleartext password authentication plugins from being used over unencrypted connections. This allows a malicious or man-in-the-middle MariaDB server to request cleartext password authentication over plain TCP, exposing user credentials in transit. The vulnerability is fixed in version 1.4.1.
MariaDB Connector/J versions prior to 2.7.14, 3.3.5, 3.4.3, and 3.5.9 have a vulnerability where PAM dialog authentication can transmit the account password in cleartext over insecure connections. This occurs because the PAM handler 'dialog' does not require secure transport, unlike the mysql_clear_password plugin. A malicious or man-in-the-middle server can exploit this by sending an Authentication Switch Request over plain TCP, causing the driver to expose the password if sslMode=DISABLE and restrictedAuth=null (default settings). The issue is fixed in the specified versions.
MariaDB Connector/Node.js versions prior to 3.2.4, 3.3.3, 3.4.6, and 3.5.3 can expose account passwords in cleartext during PAM dialog authentication over insecure transport. This occurs because the connector does not enforce secure transport for the PAM password authentication dialog, allowing a hostile or on-path server to trigger password disclosure over plain TCP. The issue is mitigated by using properly verified TLS or local Unix sockets. The vulnerability has a CVSS score of 5.9 (medium severity) and is fixed in the specified versions.
The Ebyte NA111-M firmware version 9013-2-17 transmits MQTT credentials and control traffic in cleartext, exposing sensitive information to attackers on the network. This vulnerability is classified as CWE-319 and has a critical CVSS score of 9.8. Exploitation could allow unauthorized device impersonation and disruption of messaging functions.
CVE-2026-73809 is a vulnerability in the Ebyte NA111-M Firmware version 9013-2-17 where sensitive information is transmitted in cleartext via the web management interface. This allows attackers with network access to intercept authentication or session data. The vulnerability has a high severity with a CVSS score of 7.5 and could lead to unauthorized access to device management functions.
CVE-2026-19854 is a vulnerability in the Grafana Clickhouse Datasource plugin version 3.1.0 where the Native protocol connection ignores TLS requests when using PDC or secure SOCKS proxies. This results in cleartext transmission of sensitive information such as usernames, passwords, queries, and results. Additionally, the server certificate is never verified, and client certificates configured are not sent.
CVE-2026-29988 is a high-severity vulnerability affecting the NFC interface of multiple Milesight AM102/102L V2 IoT devices. It allows an unauthenticated attacker with physical proximity to retrieve sensitive LoRaWAN keys transmitted in cleartext. These keys include NwkSKey, AppSKey, and D2D keys, which can be exploited to decrypt traffic, forge frames, submit false data, and disrupt legitimate communications.
The TYPO3 extension "SYSSY - TYPO3 Monitoring & Security Checks" transmits system information in cleartext when OpenSSL is unavailable on the server. This vulnerability requires the attacker to already have control of the SYSSY project's API key to exploit. It affects versions from 0 up to but not including 3.0.6. The CVSS 4.0 base score is 5.3, indicating a medium severity risk.
Potential security vulnerabilities have been identified in HP Easy Start for macOS, versions prior to 2.16.7.260722. These potential vulnerabilities may lead to escalation of privilege. HP is releasing updates to mitigate these potential vulnerabilities.
A vulnerability exists in the Dynamic DNS (DDNS) functionality of TP-Link Omada Gateways. During communication with a third-party DDNS service, authentication credentials are transmitted over an unencrypted channel. An attacker who can observe or manipulate traffic between an affected device and the DDNS service may obtain sensitive authentication information or interfere with DDNS update operations. Exploitation requires DDNS to be configured, communication with an external DDNS service, and attacker visibility or control of the relevant network path.
Successful exploitation may result in disclosure of DDNS account credentials, unauthorized access to DDNS management functionality, or modification of DNS records associated with the affected deployment.
CVE-2026-22306 is a critical vulnerability in Ozols Grupa's OZOLS product prior to version 1.1.1233. It involves the download of code without integrity checks, inclusion of functionality from an untrusted control sphere, and cleartext transmission of sensitive information. The issue stems from an abandoned auto-update domain affecting the automatic update channel, specifically the OzolsSQL client update path, a SQL Server Agent job, and a VBScript file. This vulnerability allows remote attackers to potentially execute arbitrary code without user interaction and without requiring privileges.
CVE-2026-15806 is a vulnerability in the Python CPython urllib.request module where HTTPPasswordMgr classes did not consider the URL scheme when matching stored credentials. This caused credentials registered for HTTPS URLs to be sent over HTTP requests to the same host, exposing them to interception if an attacker could redirect or downgrade connections to plain HTTP. The issue is fixed by scoping credential matching to the URL scheme. Users unable to upgrade immediately should avoid making plain HTTP requests to hosts with stored credentials.
Data::Entropy versions before 0.010 for Perl read remote entropy sources over plain HTTP.
The Data::Entropy::RawSource::RandomOrg and Data::Entropy::RawSource::RandomnumbersInfo remote sources are accessed over plain HTTP.
The Data::Entropy::RawSource::RandomOrg integrity check trivially matches any non-empty byte string.
Any on-path attacker, such as open WiFi, a compromised ISP, captive portal, or a hostile egress proxy substitutes the response and thereby chooses the bytes returned by rand_bits and rand_int for every application that selected one of these sources via with_entropy_source. The _checkbuf method response is equally attacker-controlled, so the retry/sleep behaviour is steerable too.
CVE-2026-47255 is a high-severity vulnerability affecting the @agenticmail/api and @agenticmail/core packages prior to versions 0.9.32 and 0.9.10 respectively. The issue involves improper input validation and weaknesses in several security controls including inactive-agent hour filtering, SQL identifier validation, metadata ownership checks, blocking unauthorized SQL metadata access, secure handling of outbound worker secrets, SMTP envelope/header validation, and TLS certificate verification. These flaws could lead to integrity violations and partial denial of service. The vulnerability has been patched in the stated versions.
@hapi/wreck is an HTTP client utility. Prior to 18.1.2, Wreck strips credential headers including Authorization, Cookie, and Proxy-Authorization before following a cross-origin redirect, but the origin check compares hostnames only and ignores scheme and port, so credentials are forwarded intact across same-host port changes and HTTPS-to-HTTP downgrades, allowing a co-tenant on an adjacent port or a network-position attacker capable of forging a redirect to capture bearer tokens, session cookies, and proxy credentials and impersonate the victim against the upstream service. This issue is fixed in version 18.1.2.
oras-go is a Go library for managing OCI artifacts. Prior to 2.6.1, auth.Client follows the realm URL from a registry's WWW-Authenticate: Bearer challenge without validating the scheme or host, allowing a malicious or compromised registry to cause SSRF to internal networks such as http://169.254.169.254/, http://10.0.0.x/, and http://127.0.0.1/, or to downgrade a registry contacted over https:// to an http:// token endpoint in registry/remote/auth/client.go through Client.Do(), Client.fetchBearerToken(), fetchDistributionToken, and fetchOAuth2Token. This issue is fixed in version 2.6.1.
Cleartext transmission of sensitive information in Windows Ancillary Function Driver for WinSock allows an authorized attacker to disclose information locally.