Kubernetes C# Client: improper certificate validation in custom CA mode may lead to man-in-the-middle attacks

A vulnerability exists in the Kubernetes C# client where the certificate validation logic accepts properly constructed certificates from any Certificate Authority (CA) without properly verifying the trust chain. This flaw allows a malicious actor to present a forged certificate and potentially intercept or manipulate communication with the Kubernetes API server, leading to possible man-in-the-middle attacks and API impersonation.

2100 Technology｜Official Document Management System - Authentication Bypass

Official Document Management System developed by 2100 Technology has an Authentication Bypass vulnerability, allowing unauthenticated remote attackers to obtain any user's connection token and use it to log into the system as that user.

Improper session management in GCOM EPON 1GE ONU version C00R371V00B01 allows attackers to execute a session hijacking attack via spoofing the IP address of an authenticated user.

Weak Security in the PF-50 1.2 keyfob of PGST PG107 Alarm System 1.25.05.hf allows attackers to compromise access control via a code replay attack.

The KDE Connect protocol 8 before 2025-11-28 does not correlate device IDs across two packets. This affects KDE Connect before 25.12 on desktop, KDE Connect before 0.5.4 on iOS, KDE Connect before 1.34.4 on Android, GSConnect before 68, and Valent before 1.0.0.alpha.49.

An authentication bypass vulnerability was found in Stilog Visual Planning 8. It allows an unauthenticated attacker to receive an administrative API token.

GoSign Desktop through 2.4.1 disables TLS certificate validation when configured to use a proxy server. This can be problematic if the GoSign Desktop user selects an arbitrary proxy server without consideration of whether outbound HTTPS connections from the proxy server to Internet servers succeed even for untrusted or invalid server certificates. In this scenario (which is outside of the product's design objectives), integrity protection could be bypassed. In typical cases of a proxy server for outbound HTTPS traffic from an enterprise, those connections would not succeed. (Admittedly, the usual expectation is that a client application is configured to trust an enterprise CA and does not set SSL_VERIFY_NONE.) Also, it is of course unsafe to place ~/.gosign in the home directory of an untrusted user and then have other users execute downloaded files.

go-witness Improper Verification of AWS EC2 Identity Documents

go-witness and witness are Go modules for generating attestations. In go-witness versions 0.8.6 and earlier and witness versions 0.9.2 and earlier the AWS attestor improperly verifies AWS EC2 instance identity documents. Verification can incorrectly succeed when a signature is not present or is empty, and when RSA signature verification fails. The attestor also embeds a single legacy global AWS public certificate and does not account for newer region specific certificates issued in 2024, making detection of forged documents difficult without additional trusted region data. An attacker able to supply or intercept instance identity document data (such as through Instance Metadata Service impersonation) can cause a forged identity document to be accepted, leading to incorrect trust decisions based on the attestation. This is fixed in go-witness 0.9.1 and witness 0.10.1. As a workaround, manually verify the included identity document, signature, and public key with standard tools (for example openssl) following AWS’s verification guidance, or disable use of the AWS attestor until upgraded.

Changing Information Technology CGFIDO - Authentication Bypass

The login mechanism via device authentication of CGFIDO from Changing Information Technology has an Authentication Bypass vulnerability. If a user visits a forged website, the agent program deployed on their device will send an authentication signature to the website. An unauthenticated remote attacker who obtains this signature can use it to log into the system with any device.

2100 Technology Electronic Official Document Management System - Authentication Bypass

The Electronic Official Document Management System from 2100 Technology has an Authentication Bypass vulnerability. Although the product enforces an IP whitelist for the API used to query user tokens, unauthenticated remote attackers can still deceive the server to obtain tokens of arbitrary users, which can then be used to log into the system.

WordPress WordPress Manutenção plugin <= 1.0.6 - Bypass vulnerability

Authentication Bypass by Spoofing vulnerability in Filipe Seabra WordPress Manutenção allows Functionality Bypass.This issue affects WordPress Manutenção: from n/a through 1.0.6.

Akka.Remote TLS did not properly implement certificate-based authentication

Akka.NET is a .NET port of the Akka project from the Scala / Java community. In all versions of Akka.Remote from v1.2.0 to v1.5.51, TLS could be enabled via our `akka.remote.dot-netty.tcp` transport and this would correctly enforce private key validation on the server-side of inbound connections. Akka.Remote, however, never asked the outbound-connecting client to present ITS certificate - therefore it's possible for untrusted parties to connect to a private key'd Akka.NET cluster and begin communicating with it without any certificate. The issue here is that for certificate-based authentication to work properly, ensuring that all members of the Akka.Remote network are secured with the same private key, Akka.Remote needed to implement mutual TLS. This was not the case before Akka.NET v1.5.52. Those who run Akka.NET inside a private network that they fully control or who were never using TLS in the first place are now affected by the bug. However, those who use TLS to secure their networks must upgrade to Akka.NET V1.5.52 or later. One patch forces "fail fast" semantics if TLS is enabled but the private key is missing or invalid. Previous versions would only check that once connection attempts occurred. The second patch, a critical fix, enforces mutual TLS (mTLS) by default, so both parties must be keyed using the same certificate. As a workaround, avoid exposing the application publicly to avoid the vulnerability having a practical impact on one's application. However, upgrading to version 1.5.52 is still recommended by the maintainers.

TP-Link Tether versions prior to 4.5.13 and TP-Link Tapo versions prior to 3.3.6 do not properly validate certificates, which may allow a remote unauthenticated attacker to eavesdrop on an encrypted communication via a man-in-the-middle attack.

Autoeastern Smart Keyless Entry System Replay Attack

Use of fixed learning codes, one code to lock the car and the other code to unlock it, in the Key Fob Transmitter in Cyclone Matrix TRF Smart Keyless Entry System, which allows a replay attack. Research was completed on the 2024 KIA Soluto.  Attack confirmed on other KIA Models in Ecuador.

org.bouncycastle: Use of Incorrectly-Resolved Name or Reference

An issue was discovered in the Bouncy Castle Crypto Package For Java before BC TLS Java 1.0.19 (ships with BC Java 1.78, BC Java (LTS) 2.73.6) and before BC FIPS TLS Java 1.0.19. When endpoint identification is enabled in the BCJSSE and an SSL socket is created without an explicit hostname (as happens with HttpsURLConnection), hostname verification could be performed against a DNS-resolved IP address in some situations, opening up a possibility of DNS poisoning.

An issue was discovered in Ada Web Server 20.0. When configured to use SSL (which is not the default setting), the SSL/TLS used to establish connections to external services is done without proper hostname validation. This is exploitable by man-in-the-middle attackers.

Mengshen Wireless Door Alarm M70 2024-05-24 allows Authentication Bypass via a Capture-Replay approach.

When deploying Cloud Foundry together with the haproxy-boshrelease and using a non default configuration, it might be possible to craft HTTP requests that bypass mTLS authentication to Cloud Foundry applications.  You are affected if you have route-services enabled in routing-release and have configured the haproxy-boshrelease property “ha_proxy.forwarded_client_cert” to “forward_only_if_route_service”.

WTW-EAGLE App does not properly validate server certificates, which may allow a man-in-the-middle attacker to monitor encrypted traffic.

CVE-2024-38807: Signature Forgery Vulnerability in Spring Boot's Loader

Applications that use spring-boot-loader or spring-boot-loader-classic and contain custom code that performs signature verification of nested jar files may be vulnerable to signature forgery where content that appears to have been signed by one signer has, in fact, been signed by another.