Total
167 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2026-8932 | 1 Haxx | 1 Curl | 2026-09-15 | N/A | 7.5 HIGH |
| libcurl would reuse a previously created connection even when some mTLS config related option had been changed that should have prohibited reuse. libcurl keeps previously used connections in a connection pool for subsequent transfers to reuse if one of them matches the setup. However, some TLS settings related to client certificates were left out from the configuration match checks, making them match too easily. In particular options related to the private key. | |||||
| CVE-2026-5545 | 1 Haxx | 1 Curl | 2026-09-15 | N/A | 6.5 MEDIUM |
| libcurl might in some circumstances reuse the wrong connection when asked to do an authenticated HTTP(S) request after a Negotiate-authenticated one, when both use the same host. libcurl features a pool of recent connections so that subsequent requests can reuse an existing connection to avoid overhead. When reusing a connection a range of criteria must be met. Due to a logical error in the code, a request that was issued by an application could wrongfully reuse an existing connection to the same server that was authenticated using different credentials. An application that first uses Negotiate authentication to a server with `user1:password1` and then does another operation to the same server asking for any authentication method but for `user2:password2` (while the previous connection is still alive) - the second request gets confused and wrongly reuses the same connection and sends the new request over that connection thinking it uses a mix of user1's and user2's credentials when it is in fact still using the connection authenticated for user1... | |||||
| CVE-2026-3784 | 1 Haxx | 1 Curl | 2026-09-15 | N/A | 6.5 MEDIUM |
| curl would wrongly reuse an existing HTTP proxy connection doing CONNECT to a server, even if the new request uses different credentials for the HTTP proxy. The proper behavior is to create or use a separate connection. | |||||
| CVE-2026-1965 | 1 Haxx | 1 Curl | 2026-09-15 | N/A | 6.5 MEDIUM |
| libcurl can in some circumstances reuse the wrong connection when asked to do an Negotiate-authenticated HTTP or HTTPS request. libcurl features a pool of recent connections so that subsequent requests can reuse an existing connection to avoid overhead. When reusing a connection a range of criterion must first be met. Due to a logical error in the code, a request that was issued by an application could wrongfully reuse an existing connection to the same server that was authenticated using different credentials. One underlying reason being that Negotiate sometimes authenticates *connections* and not *requests*, contrary to how HTTP is designed to work. An application that allows Negotiate authentication to a server (that responds wanting Negotiate) with `user1:password1` and then does another operation to the same server also using Negotiate but with `user2:password2` (while the previous connection is still alive) - the second request wrongly reused the same connection and since it then sees that the Negotiate negotiation is already made, it sends the request over that connection thinking it uses the user2 credentials when it is in fact still using the connection authenticated for user1... The set of authentication methods to use is set with `CURLOPT_HTTPAUTH`. Applications can disable libcurl's reuse of connections and thus mitigate this problem, by using one of the following libcurl options to alter how connections are or are not reused: `CURLOPT_FRESH_CONNECT`, `CURLOPT_MAXCONNECTS` and `CURLMOPT_MAX_HOST_CONNECTIONS` (if using the curl_multi API). | |||||
| CVE-2026-81578 | 1 Papercut | 2 Papercut Mf, Papercut Ng | 2026-09-14 | N/A | 9.8 CRITICAL |
| An improper access control vulnerability exists in the web management interface of PaperCut MF and PaperCut NG. Under specific conditions, unauthenticated remote requests targeting administrative functions can trigger backend actions prior to the completion of access validation checks. This allows an unauthenticated remote attacker to modify certain system configurations. | |||||
| CVE-2026-86207 | 2026-09-08 | N/A | N/A | ||
| An authentication bypass in N-central < 2026.3 HF 3 leads to authentication bypass in internal only APIs | |||||
| CVE-2026-19292 | 2026-09-08 | N/A | 8.8 HIGH | ||
| Re-pairing with a legitimate device can use a lower security level than previous making brute-forcing the LTK easier. See V4 in the BLERP paper linked below. | |||||
| CVE-2026-65935 | 2026-09-08 | N/A | N/A | ||
| Passkey entry Bluetooth LE legacy pairing can be bypassed in the RS9116W and SiWx917 by manipulating the temporary key value. See vulnerability B-E3 in the related paper below. | |||||
| CVE-2025-14600 | 2026-08-31 | N/A | N/A | ||
| An insecure deserialization vulnerability in vsDesk allows a remote attacker to gain unauthorized administrative access. By manipulating application configuration data, an attacker can force the system to authenticate against an arbitrary LDAP server and provision a new administrative account. Apply patch from vendor https://vsdesk.ru/ . Versions 14.0402 and on have the patch. | |||||
| CVE-2026-16103 | 1 Redhat | 1 Build Of Keycloak | 2026-08-31 | N/A | 4.3 MEDIUM |
| A flaw was found in the keycloak-services component of Keycloak. This issue is an incomplete fix for CVE-2026-9798, where brute-force protection checks were added to the Client-Initiated Backchannel Authentication (CIBA) initiation handler but were omitted from the token redemption handler. This allows an attacker with valid client credentials to obtain access and refresh tokens for a user account that has been locked due to brute-force protection, provided the authentication request was started before the lockout occurred and was approved by the user. | |||||
| CVE-2026-16895 | 2026-08-28 | N/A | N/A | ||
| A logic vulnerability (fail-open condition) has been identified within the Metasploit Framework's JSON-RPC web service interface. When an exception occurs during the database health check (db.check) and the environment variable MSF_WS_JSON_RPC_API_TOKEN is not explicitly set, the application resets the internal state flag msf.auth_initialized to false. The ApiToken Warden authentication strategy misinterprets this false value as an indicator that authentication is not initialized or required, thereby granting unauthenticated local access to the JSON-RPC request dispatcher. | |||||
| CVE-2026-53561 | 1 Apache | 1 Hive | 2026-08-27 | N/A | 7.4 HIGH |
| An improper authentication vulnerability in HiveServer2 SAML bearer-token validation in Apache Hive 4.0.0 through 4.2.0 (and later unreleased branches) on deployments using HTTP transport with hive.server2.authentication=SAML allows an unauthenticated network attacker to authenticate as an arbitrary Hive user and obtain an authenticated HiveServer2 session via a forged Authorization: Bearer token sent to the /cliservice HTTP endpoint. Users are recommended to upgrade to 4.2.1 version that includes the fix for this issue. Access / authorization required: No Hive credentials, SAML IdP login, or knowledge of the server signing secret is required. The attacker only needs network reachability to the HiveServer2 HTTP port (typically /cliservice), directly or through a reverse proxy such as Apache Knox that forwards unauthenticated requests to HS2. The instance must have SAML authentication enabled in HTTP mode. Deployments where Knox handles SSO and HiveServer2 uses LDAP/Kerberos (not native SAML mode) are not affected by this specific issue. | |||||
| CVE-2026-78619 | 2026-08-26 | N/A | 9.8 CRITICAL | ||
| Punk::Plugin::TOTP versions before 0.05 for Perl accept another account's recovery code at the two-factor challenge because totp_use_recovery compares user identifiers numerically. The helper searches the recovery model for the submitted code's digest alone, across every user's rows, so the ownership test that follows is the only thing binding a code to the account it was issued to. That test compares the row's user_id with the challenged user's id through Perl's integer coercion, and an identifier with no leading digits coerces to zero, so any two of them compare equal. User models keyed on a username, an email address or a UUID hit that case, and a numeric key compares as intended. The challenge route feeds a submitted value to the helper once TOTP verification fails, so an attacker who knows a victim's password and holds a recovery code of their own passes the victim's second factor. | |||||
| CVE-2026-19349 | 2026-08-26 | N/A | 9.8 CRITICAL | ||
| Lemonldap::NG::Portal versions from 2.0.0 before 2.16.9, from 2.17.0 before 2.21.5, from 2.22.0 before 2.23.3 for Perl allow authentication bypass via an OAuth2 state parameter stored as an SSO session in the GitHub and LinkedIn backends. Before redirecting to the identity provider, extractFormInfo() creates the state session with the positional call `getApacheSession( undef, 1, 0, 'GitHubState' )`. getApacheSession() takes a session id followed by a named argument hash, so the trailing arguments become that hash, `kind` defaults to SSO, and the state is written to the global session storage as a regular SSO session. Its identifier is handed to the unauthenticated visitor as the state parameter of the redirection URL. Any visitor who reaches the GitHub or LinkedIn endpoint can replay that identifier as a session cookie and obtain a valid SSO session without authenticating. The session holds neither _user nor authenticationLevel, which the shipped bootstrap configuration accepts because it grants virtual hosts a "default => accept" access rule; deployments whose rules test the user or require an authentication level are less exposed. Only configurations with the GitHub or LinkedIn authentication module enabled are affected. | |||||
| CVE-2026-1621 | 2026-08-26 | N/A | 5.3 MEDIUM | ||
| Authentication bypass by primary weakness vulnerability in Universal Software Inc. E-Municipality allows Exploitation of Trusted Identifiers. This issue affects E-Municipality: from 20251127 before 20260204. | |||||
| CVE-2026-6266 | 2026-08-26 | N/A | 8.3 HIGH | ||
| A flaw was found in the AAP gateway. The user auto-link strategy, introduced in AAP 2.6, automatically links an external Identity Provider (IDP) identity to an existing AAP user account based on email matching without verifying email ownership. This allows a remote attacker to potentially hijack a victim's account or gain unauthorized access to other accounts, including administrative accounts, by manipulating the IDP-provided email. | |||||
| CVE-2026-9798 | 1 Redhat | 1 Build Of Keycloak | 2026-08-20 | N/A | 4.3 MEDIUM |
| A flaw was found in Keycloak, an open-source identity and access management solution. When a user account is temporarily locked due to repeated failed login attempts, an attacker with valid client credentials can exploit the Client-Initiated Backchannel Authentication (CIBA) flow to bypass this brute-force protection. This allows continued authentication attempts and token issuance even when the account should be locked, potentially enabling further unauthorized access attempts. | |||||
| CVE-2023-4501 | 1 Microfocus | 5 Cobol Server, Enterprise Developer, Enterprise Server and 2 more | 2026-08-04 | N/A | 9.8 CRITICAL |
| User authentication with username and password credentials is ineffective in OpenText (Micro Focus) Visual COBOL, COBOL Server, Enterprise Developer, and Enterprise Server (including product variants such as Enterprise Test Server), versions 7.0 patch updates 19 and 20, 8.0 patch updates 8 and 9, and 9.0 patch update 1, when LDAP-based authentication is used with certain configurations. When the vulnerability is active, authentication succeeds with any valid username, regardless of whether the password is correct; it may also succeed with an invalid username (and any password). This allows an attacker with access to the product to impersonate any user. Mitigations: The issue is corrected in the upcoming patch update for each affected product. Product overlays and workaround instructions are available through OpenText Support. The vulnerable configurations are believed to be uncommon. Administrators can test for the vulnerability in their installations by attempting to sign on to a Visual COBOL or Enterprise Server component such as ESCWA using a valid username and incorrect password. | |||||
| CVE-2026-62427 | 2026-07-28 | N/A | 8.8 HIGH | ||
| [This CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] To manage the system, sysctl and platform operations are used by the control domain or a possible Xenstore domain. Some of these operations may not be executed in parallel, so a system-wide lock each is used. The way those locks are acquired is, however, not providing any fairness. Furthermore, with XSM/Flask in use, the lock acquire will, for some operations, occur ahead of any permission checking. The sysctl issue is CVE-2026-62426. The platform-op issue is CVE-2026-62427. | |||||
| CVE-2026-40976 | 1 Vmware | 1 Spring Boot | 2026-07-24 | N/A | 9.1 CRITICAL |
| In certain circumstances, Spring Boot's default web security is ineffective allowing unauthorized access to all endpoints. For an application to be vulnerable, it must: be a servlet-based web application; have no Spring Security configuration of its own and rely on the default web security filter chain; depend on spring-boot-actuator-autoconfigure; not depend on spring-boot-health. If any of the above does not apply, the application is not vulnerable. Affected: Spring Boot 4.0.0–4.0.5; upgrade to 4.0.6 or later per vendor advisory. | |||||