Insecure XFT Transport in Progress WS_FTP Server

Insufficient protection of communications in Progress WS_FTP Server versions prior to 2025.0.5 could allow a network attacker to intercept sensitive information or modify requests when unencrypted connections are used.

Windows Ancillary Function Driver for WinSock Information Disclosure Vulnerability

Cleartext transmission of sensitive information in Windows Ancillary Function Driver for WinSock allows an authorized attacker to disclose information locally.

OAuth2 access token could be sent over an unencrypted connection with Exchange accounts

For Exchange accounts using EWS or Microsoft Graph with OAuth2 authentication, Thunderbird sent the OAuth2 access token to the server even when the configured server URL used unencrypted HTTP. An attacker able to observe network traffic could obtain the token and use it to access the user's mailbox until the token expired. An attacker positioned on the network during account setup could cause such a URL to be configured. This vulnerability was fixed in Thunderbird 160 and Thunderbird 153.7.

Vikunja veans before 2.7.1 HTTPS to HTTP Downgrade in Server Discovery

Vikunja veans before 2.7.1 contains a protocol downgrade vulnerability in serverCandidates that allows on-path attackers to force plain HTTP during veans init and login. Attackers can block HTTPS ports so discovery accepts an unverified HTTP response, capturing passwords, TOTP codes or bot tokens and persisting cleartext API traffic.

Cleartext transmission of sensitive information in the email configuration test in Devolutions Server 2026.3.13.0 and earlier allows an authenticated user with access to the test action to obtain the stored SMTP password via a request that names an attacker-controlled SMTP host.

Cleartext transmission of sensitive information in the Agent of Ivanti Endpoint Manager before version 2024 SU8 allows a remote unauthenticated attacker to in a MITM position to read and modify HTTP traffic.

`HTTPPasswordMgr` can send saved HTTPS credentials via HTTP because of incorrect scheme matching

The HTTPPasswordMgr class in the urllib.request module, along with its subclasses HTTPPasswordMgrWithDefaultRealm and HTTPPasswordMgrWithPriorAuth, did not take the URL scheme into account when matching stored credentials against a requested URL. Credentials added for an https:// URL were also used for requests to the same host over http://, so an attacker able to redirect or downgrade a client to plain HTTP (for example, via an HTTPS-to-HTTP redirect or an on-path position) could capture credentials in cleartext. Credentials added for http:// URLs could likewise be sent over https://. Credential matching is now scoped by URL scheme. Credentials registered with a URL that includes a scheme are only used for requests with the same scheme. Credentials registered with a bare authority (such as example.com or example.com:8080) continue to match any scheme, preserving compatibility with existing code, including proxy authentication. Users who cannot upgrade immediately can mitigate by ensuring that applications never make plain http:// requests to hosts for which credentials are registered, for example by not following redirects to http:// URLs.

Unauthorized Access to vSolution Matrix RTSP

When the vSolution Matrix feature is enabled, affected devices may make current screen content available through an unauthenticated RTSP/RTP stream to hosts on the same network segment. The stream is not encrypted, which may allow an unauthenticated host to view or capture presentation content where network access is not otherwise restricted. This vulnerability only affects devices with the vSolution Matrix feature enabled.

Unencrypted HTTP Traffic Exposing Sensitive User Credentials in GV-Face Android Application v2.2.1

GV-Face transmits sensitive user credentials and related authentication data over unencrypted HTTP connections. The HTTP traffic is not encrypted, an attacker with the ability to intercept network traffic.

VitaFit Android < 2.8.1.0 Cleartext Traffic via Missing Network Security Config

VitaFit Android application (com.vt.vitafit) before 2.8.1.0 contains a cleartext traffic vulnerability that allows network-based attackers to intercept or modify unencrypted HTTP communications due to the absence of an Android network security configuration. Attackers on an untrusted network can manipulate support content displayed to the user by tampering with unencrypted HTTP traffic between the app and server.

Keycloak-services: keycloak-services: smtp starttls plaintext credential and message downgrade

A flaw was found in the SMTP email configuration handling of the keycloak-services component. When the STARTTLS option is enabled, Keycloak fails to strictly enforce an encrypted connection, allowing it to fall back to unencrypted communication if the encryption request is tampered with. An attacker who can intercept network traffic can exploit this to capture sensitive email credentials and message content in plain text.

rxrpc: Fix conn-level packet handling to unshare RESPONSE packets

In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix conn-level packet handling to unshare RESPONSE packets The security operations that verify the RESPONSE packets decrypt bits of it in place - however, the sk_buff may be shared with a packet sniffer, which would lead to the sniffer seeing an apparently corrupt packet (actually decrypted). Fix this by handing a copy of the packet off to the specific security handler if the packet was cloned.

Libsoup: libsoup: information disclosure via cleartext transmission of cookies during https tunnel establishment

A flaw was found in libsoup. When establishing HTTPS tunnels through a configured HTTP proxy, sensitive session cookies are transmitted in cleartext within the initial HTTP CONNECT request. A network-positioned attacker or a malicious HTTP proxy can intercept these cookies, leading to potential session hijacking or user impersonation.

LibreSSL ocspcheck through 4.4.0 Cleartext Transmission of OCSP Requests via url2host()

LibreSSL ocspcheck through 4.4.0 contains a cleartext transmission vulnerability because url2host() discards the OCSP URL scheme and http_alloc() only selects TLS for port 443. On-path network attackers can read OCSP requests sent to https responder URLs on non-443 ports, exposing certificate serial numbers, issuer hashes, and nonces.

Mobile VPN with SSL Client for Windows: Cleartext Transmission of VPN Credentials over Local Management Socket

Cleartext Transmission of Sensitive Information vulnerability in the WatchGuard Mobile VPN with SSL client for Windows allows a local attacker who can capture loopback traffic to obtain the user’s VPN username and password.

Rclone before v1.75.2 B2 Credential Leak on Redirect via --b2-download-url

Rclone before v1.75.2 contains a credential exposure vulnerability in the b2 backend that leaks the live account Authorization token and SSE-C keys on HTTP redirects from --b2-download-url hosts. Attackers can observe a same-host HTTPS-to-HTTP downgrade redirect to capture the cleartext B2 token, or receive cross-host redirects disclosing SSE-C customer encryption keys.

Snipe-IT before 8.6.3 LDAP StartTLS Downgrade via connectToLdap()

Snipe-IT before 8.6.3 ignores the ldap_start_tls() return value in Ldap::connectToLdap(), allowing on-path attackers to force cleartext LDAP binds. Attackers can answer the StartTLS request with a protocol error to capture service-account credentials and end-user login passwords.

InterSystems Corporation InterSystems IRIS for Health Cleartext Transmission of Sensitive Information

InterSystems IRIS for Health has TLS/SSL encryption turned off by default, which may enable an attacker to view transmitted data and use that data to log into the device.

Rhn-proxy: rhn-satellite: rhn-proxy: information disclosure via clear-text credential transmission when accessing rhn satellite

A flaw was found in rhn-proxy. This vulnerability may allow the rhn-proxy to transmit user credentials in clear-text when it accesses RHN Satellite. This could lead to information disclosure, where sensitive authentication details are exposed to unauthorized parties.

tcp: prevent collapsing skbs across boundary in rtx queue

In the Linux kernel, the following vulnerability has been resolved: tcp: prevent collapsing skbs across boundary in rtx queue tcp_write_collapse_fence() sets TCP_SKB_CB(skb)->eor = 1 on tcp_write_queue_tail(sk) to prevent skbs queued after a switch to device encryption from being collapsed into earlier skbs. The fence is a no-op if all earlier data has already been transmitted when the switch happens: sk->sk_write_queue is empty. The not yet acknowledged earlier skbs wait in sk->tcp_rtx_queue with eor 0. On a subsequent retransmit or SACK shift, tcp_retrans_try_collapse() or tcp_shift_skb_data() can then merge an skb queued after the switch into one queued before it. Both users of the fence are affected: - psp: devices only encrypt skbs with skb->decrypted set. The merged skb keeps decrypted = 0 from the earlier skb, so merged data sent after psp_sock_assoc_set_tx() is retransmitted in cleartext. - tls device offload: the merged skb straddles the start marker set in tls_set_device_offload(). The software fallback (fill_sg_in() returns -EINVAL) and the mlx5, nfp and funeth drivers cannot handle such an skb and drop it. Every retransmit rebuilds the same skb, so the connection stalls. Fix this in two places, for defense in depth: 1. Fall back to tcp_rtx_queue_tail(sk) in tcp_write_collapse_fence() when tcp_write_queue_tail(sk) is NULL. 2. Check !skb_cmp_decrypted(to, from) in tcp_skb_can_collapse(), as tcp_skb_can_collapse_rx() does on receive. skb_shift(), which both collapse paths call, already has a DEBUG_NET_WARN_ON_ONCE() for this condition.