| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Dell SCG 5.0 Appliance versions prior to 5.36.00.16 and Dell SCG 5.0 Application versions prior to 5.36.00.00, contains an Improper Validation of Certificate with Host Mismatch vulnerability. An unauthenticated attacker with remote access could potentially exploit this vulnerability, leading to protection mechanism bypass. |
| Dell SCG 5.0 Appliance versions prior to 5.36.00.16 and Dell SCG 5.0 Application versions prior to 5.36.00.00, contains an Improper Certificate Validation vulnerability. An unauthenticated attacker with remote access could potentially exploit this vulnerability, leading to unauthorized access. |
| Dell SCG 5.0 Appliance versions prior to 5.36.00.16 and Dell SCG 5.0 Application versions prior to 5.36.00.00, contains an Improper Certificate Validation vulnerability. A low privileged attacker with local access could potentially exploit this vulnerability, leading to server-side request forgery. |
| Dell SCG 5.0 Appliance versions prior to 5.36.00.16 and Dell SCG 5.0 Application versions prior to 5.36.00.00, contains an Improper Certificate Validation vulnerability. An unauthenticated attacker with remote access could potentially exploit this vulnerability, leading to unauthorized access. |
| Improper certificate validation in the shared HTTP client used by synchronization and integration features in Devolutions Server 2026.2.16 and earlier allows a network-positioned attacker to intercept and tamper with outbound TLS connections via a spoofed or self-signed certificate. |
| Improper certificate validation on LDAPS connections to Active Directory in Devolutions Server 2026.2.16 and earlier allows a network-positioned attacker to intercept privileged directory service credentials via a spoofed domain controller certificate. |
| Under certain conditions a valid SAML IdP response may be used to impersonate another Secret Server user. |
| A routing rule selects between two different authentication mechanisms for the same downstream service based on the value of a client-supplied request header, rather than on any property the client cannot control. An authenticated user in possession of a shared service credential can set this header to route around the primary role-based authorization check and reach the alternate path's fixed, elevated role instead. This allows a low-privileged authenticated attacker who knows the shared credential to perform actions reserved for a higher-privileged role. |
| Requests from the reverse proxy to the identity-provider service for token discovery, introspection, and credential exchange do not verify the identity provider's server certificate. An attacker positioned on the network path between the proxy and the identity provider could impersonate the identity provider and issue forged authentication tokens accepted by the deployment. |
| DIRAC is an interware, meaning a software framework for distributed computing. Prior to versions 8.0.79, 9.0.22, and 9.1.10, WorkloadManagementSystem/Utilities/PilotWrapper.py pilotWrapperScript uses ssl._create_unverified_context to download the second-stage pilot.tar archive without TLS certificate verification and downloads the reference checksum through the same unvalidated channel. An attacker able to redirect or intercept a grid site's network traffic through DNS or routing manipulation can substitute both the executable pilot code and its checksum, causing arbitrary code to run in the pilot context with access to pilot proxy credentials. The fixed implementation validates the server certificate through system trust and X509_CERT_DIR or the grid certificate directory. This issue is fixed in versions 8.0.79, 9.0.22, and 9.1.10. |
| BookStack before 26.05.5 contains an authentication bypass vulnerability in its social login implementation that allows unauthenticated attackers to sign in as arbitrary users by authenticating through a different social provider sharing the same driver_id namespace. Attackers can authenticate at one enabled social provider using a user ID that matches an account linked to a different social provider, bypassing credential verification entirely because the SocialAuthService::handleLoginCallback query ignores the driver column when retrieving linked account records. |
| On affected platforms running Arista EOS with both 802.1X port authentication and the RADIUS proxy feature configured with dynamic authorization, a low-privileged attacker on an adjacent network segment who induces a RADIUS packet through a configured RADIUS proxy client can prevent RADIUS dynamic authorization messages, including Change-of-Authorization (CoA) and Disconnect-Requests as defined in RFC 5176, from being applied to locally authenticated 802.1X sessions.
This allows an endpoint session that a RADIUS server or network access control system has ordered disconnected to remain authorized on the network.
Both 802.1X port authentication with dynamic authorization and RADIUS proxy with dynamic authorization must be explicitly configured for a deployment to be exposed to this issue.
This issue was discovered internally by Arista, and the company is not aware of any malicious exploitation of this vulnerability in customer networks. |
| Socket Firewall (socketdev/socket-registry-firewall) in registry mode before 2.0.0 does not verify upstream TLS certificates by default. When the api_ssl_verify and upstream_ssl_verify configuration keys are omitted from socket.yml, the generated configuration sets SOCKET_API_SSL_VERIFY='false' and UPSTREAM_SSL_VERIFY='false', and the OpenResty/Lua HTTP client used for outbound requests accepts any certificate, including self-signed and otherwise untrusted certificates, without validating the chain. An attacker positioned to intercept traffic between Socket Firewall and the Socket API or an upstream package registry can present a crafted certificate and modify responses in transit, including substituting malicious package content or altering the allow/block decisions the firewall enforces. Setting api_ssl_verify: true and upstream_ssl_verify: true enables verification; however, in versions before 1.1.334, the generated nginx configuration did not emit lua_ssl_trusted_certificate, and thus verification could not be used successfully without manually patching the generated configuration. Version 2.0.0 changes the default for both settings to true. |
| ASE/Kalkitech ASE2000 V2 Communication Test Set 2.35 through 2.37 on Windows contains an improper certificate validation vulnerability in the IEC 60870-5-104 TLS client (Task Mode). This allows a network-positioned attacker to bypass certificate validation via a certificate with multiple simultaneous faults, enabling a Man-in-the-Middle attack on protected communications. |
| Only self-managed Grafana instances with Auth Proxy authentication and identity caching enabled (sync_ttl greater than zero) are affected. The Auth Proxy cache key concatenated the username and forwarded identity attributes without a delimiter, so distinct identities could collide on one key. An authenticated user who shapes their own attributes to collide with a higher-privileged user's, while that user's cache entry is live, is authenticated as that user, up to Administrator (authentication bypass by spoofing). |
| IBM i 7.6, 7.5, 7.4, and 7.3 could allow a remote unauthenticated attacker to gain access to sensitive information through session IP binding bypass in Navigator for i. |
| Kuma is a modern Envoy-based service mesh that can run on every cloud across both Kubernetes and VMs. Prior to 2.7.26, 2.9.16, 2.11.14, 2.12.11, and 2.13.7, Universal mode kuma-dp connections to an HTTPS control plane disable TLS peer verification when --ca-cert-file is not supplied and KUMA_CONTROL_PLANE_CA_CERT is unset. The dataplane authentication token is sent over the unverified connection, allowing an on-path attacker to intercept the token, impersonate the control plane, inject a forged bootstrap configuration, and take over the proxy. Standard Kubernetes installations created by kumactl install control-plane or the official Helm chart are unaffected because the mutating admission webhook injects KUMA_CONTROL_PLANE_CA_CERT into each sidecar. This issue is fixed in versions 2.7.26, 2.9.16, 2.11.14, 2.12.11, and 2.13.7. |
| N-able Mail Assure through April 2026 contains a design-level authorization flaw that allows an authenticated SMTP user to send outbound email using MAIL FROM addresses belonging to other tenants. When connecting to the SMTP TCP port and performing SMTP AUTH with valid credentials, the server accepts arbitrary sender domains without enforcing any domain-to-account binding. As a result, an attacker from any tenant can impersonate other tenant domains, producing messages that pass SPF and DMARC validation. NOTE: N-able's position is that the behavior is intended functionality of its shared SMTP relay architecture and that the service does not represent that it enforces per-tenant sender-domain binding. |
| Cosmos provides users the ability self-host a home server by acting as a secure gateway to your application, as well as a server manager. Prior to 0.22.19, tokenMiddleware in src/proxy/routerGen.go can return through the Constellation tunnel bypass before removing x-cosmos-user, x-cosmos-role, x-cosmos-user-role, and x-cosmos-mfa headers and before invoking AdminOnlyWithRedirect. An attacker with a valid x-cstln-auth API key for an enrolled device who reaches Cosmos through the Constellation Nebula tunnel can supply a chosen x-cosmos-user value to a route with AuthEnabled enabled when the upstream application trusts that forward-auth header. The request can bypass Cosmos JWT, password, MFA, and AdminOnly checks, allowing user impersonation and admin-tier reads or writes exposed by the proxied application. This issue is fixed in version 0.22.19. |
| proxy-addr is a Node.js module that determines a request's client address behind trusted reverse proxies, and it backs Express req.ip and req.ips. In versions 1.1.0 through 2.0.7, a trust subnet written in IPv4-mapped IPv6 notation with an IPv4-sized prefix, such as ::ffff:10.0.0.0/8 instead of the correct ::ffff:10.0.0.0/104, is accepted without error but trusts every IPv4 address on the internet rather than the block it names. Because the socket peer then becomes trusted at hop 0, any unauthenticated client can supply an arbitrary X-Forwarded-For header and control the address the application reads, which defeats IP-based access control, rate limiting, geolocation, and audit logging. This is a fail-open regression introduced in version 1.1.0. The issue is fixed in proxy-addr 2.0.8, and users should upgrade to 2.0.8 or later. As a workaround, ensure any IPv4-mapped IPv6 trust subnet uses a prefix length of at least 97, or express the range in plain IPv4 notation. |
