| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| A flaw was found in hawtio-operator. The operator reads the OpenShift Service CA private signing key from the openshift-service-ca namespace and uses it to mint client certificates with a Subject Common Name (CN) supplied by the author of a namespaced Hawtio custom resource. Because the operator ships a ClusterRole that aggregates Hawtio CR permissions into the edit and admin roles, any user with edit access in any namespace can obtain a Service-CA-signed certificate with an arbitrary subject. This certificate can be used to impersonate any in-cluster service identity to peers that trust the Service CA for client authentication, including Jolokia agents and other Service-CA-trusting components. |
| SAP Approuter does not correctly validate client certificates in certain callback flows. An attacker with low privileges, holding a certificate from the same trusted authority with matching subject values, could bypass the identity check. This complexity makes the attack difficult to execute. Successful exploitation could allow impersonation of a trusted internal component, resulting in a high impact on integrity and a low impact on confidentiality and availability. |
| Grav API plugin versions before 1.0.20 build password reset links from the untrusted Host header in the forgot-password endpoint, allowing unauthenticated attackers to redirect reset tokens to attacker-controlled domains. Attackers can send password reset requests for any account with a malicious Host header, intercept the reset token from victim emails, and complete account takeover including super-admin accounts. |
| The BLOCKED access control list items that are evaluated to deny access on the the proxy protocol port can be bypassed completely when connecting over TCP or TLS and sending the query twice on connection that is kept open. |
| Authen::SASL::Perl::DIGEST_MD5 versions before 2.2100 for Perl accept replayed authentication responses via unverified nonce in server_step.
server_start generates a fresh nonce and sends it in the challenge, and nothing later compares that value against the nonce the client returns. server_step derives the expected digest from the client's own parameters, so a response verifies whenever its digest matches the nonce it carries. The count table it also checks is keyed on the client-supplied nonce and starts empty in each new server object, so a captured first response, carrying `nc=00000001`, passes that too. RFC 2831 defines the nonce in the response as the value the server sent in the preceding challenge.
An attacker who observes one successful `qop=auth` exchange can replay the captured response against a later session for the same service, host, realm and user, and authenticate as that user without knowing the password. |
| Bilibili Desktop through 1.18.0 disables TLS certificate verification process-wide and executes unsigned remote JavaScript configuration without integrity checks. An attacker in an on-path network position can intercept configuration fetches, inject arbitrary JavaScript executed in the renderer with access to the privileged IPC bridge, and execute system commands or steal login credentials. |
| A improper validation of certificate with host mismatch vulnerability in Fortinet FortiOS 7.6.1 through 7.6.6, FortiProxy 7.6.2 through 7.6.6 may allow attacker to information disclosure via <insert attack vector here> |
| Vulnerability involving incorrect access control in the Tools::getRemoteAddr() function in PrestaShop, which allows the client’s IP address to be spoofed via the X-Forwarded-For header when the application is running behind a reverse proxy, load balancer or CDN. The application incorrectly processes the IP address string and uses the address controlled by the visitor rather than the one provided by the trusted infrastructure, allowing an unauthenticated remote attacker to cause the application to interpret their connection as originating from an arbitrary IP address. This condition allows IP-based controls, such as the maintenance mode allowlist, to be bypassed, as well as enabling the forgery of security and audit logs and the evasion of third-party mechanisms that rely on the IP address, such as geolocation checks, fraud detection or request throttling. |
| nebula-mesh is a self-hosted control plane for Slack Nebula mesh VPN. Prior to version 0.7.1, revocation is the only in-band mechanism that isolates a compromised/offboarded host from a Nebula mesh. Because the blocklist never reaches any peer's config.yml, a Blocked host retains full overlay reachability to every peer under its CA (and internal services on the mesh) for up to 30d (agent) / 365d (mobile). An attacker who exfiltrates host.key+host.crt can run stock slackhq/nebula directly, ignore the agent's 403/410 poll responses, and stay connected after the operator revokes the host. Operator-visible state (UI shows blocked, audit log records it) is misleading. This issue has been patched in version 0.7.1. |
| In JetBrains YouTrack before 2026.2.18634 iP spoofing via HTTP headers allowed forged Bitbucket webhooks |
| In JetBrains YouTrack before 2025.3.161254,
2026.1.14042 improper authentication in YouTrack Helpdesk allowed unauthenticated account takeover via a self-asserted email address |
| Unauthenticated Bypass Vulnerability in Pre-Orders for WooCommerce <= 2.3 versions. |
| Unauthenticated Bypass Vulnerability in FluentBooking Pro <= 2.2.1 versions. |
| Improper certificate validation in Checkmk <2.5.0p10 allows a relay and a push agent that share the same UUID to reuse each other's mTLS certificate to authenticate against agent receiver endpoints in either direction, because the endpoints do not verify that the certificate was issued by their own root certificate. |
| MOOS core-moos through 10.4.0 fails to validate client identity in MOOSDB message processing, allowing authenticated attackers to attribute writes to other clients by supplying arbitrary source identifiers in serialized messages. Attackers can forge message origins and cancel third-party subscriptions by exploiting the disconnect between authenticated connection identity and wire-supplied source attribution. |
| In specific scenarios, Reactor Netty HTTP Server may incorrectly evaluate the remote IP address when HAProxy Protocol is enabled. In order for this to happen, the application must be configured to use HAProxy Protocol.
Reactor Netty 1.3.0 - 1.3.6
Reactor Netty 1.1.0 - 1.2.18
Reactor Netty 1.0.52 and earlier |
| Wss4jSecurityInterceptor did not consistently wire Apache WSS4J ReplayCache instances into RequestData for validation-time checks. As a result, protections against replay of UsernameToken nonces and creation timestamps, Timestamp elements, and certain SAML one-time-use semantics could be ineffective even when operators configured a replay cache on the interceptor.
Affected versions:
Spring Web Services 5.0.0 through 5.0.1; 4.1.0 through 4.1.3; 4.0.0 through 4.0.18; 3.1.0 through 3.1.8. |
| Spring Boot's Mail auto-configuration does not enable hostname verification. Applications that set the relevant JavaMail property, such as spring.mail.properties.mail.smtp.ssl.checkserveridentity=true, are not affected.
Affected versions:
Spring Boot 4.0.0 through 4.0.6; 3.5.0 through 3.5.14; 3.4.0 through 3.4.16. |
| A flaw was found in Rancher Manager. The SAML assertion replay protection introduced by the fix for CVE-2026-44946 recorded consumed assertion IDs in a per-process cache, so each replica only detected replays that reached the same pod. In a high-availability deployment, an attacker holding a captured assertion could replay it once against every other replica to obtain additional authenticated sessions as the victim.
This issue affects Rancher: before 2.15.1. |
| Filament is a collection of full-stack components for accelerated Laravel development. From 4.0.0 until 4.12.6 and 5.7.6, packages/panels/src/Auth/MultiFactor/App/AppAuthentication.php uses AppAuthentication::verifyCode() with a used-code cache key derived from both the app authentication secret and the submitted TOTP code. This isolates the newest accepted timestep by code instead of by secret, allowing a previously issued app-based MFA code to be accepted after a newer code has already been used. Reuse of the exact same code was already prevented, but another code inside the accepted time window remained usable. An attacker who obtains the target account's password and one app-based MFA code can use that code for the remainder of the configured window, which is approximately four minutes with the default settings, even after the legitimate account holder logs in with a newer code. Email-based MFA is not affected. This issue is fixed in versions 4.12.6 and 5.7.6. |
