Export limit exceeded: 400301 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (2920 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-103655 | 1 Misp | 1 Misp | 2026-10-01 | N/A |
| MISP contains a vulnerability in its two-factor authentication (TOTP) verification process that permits a valid one-time code to be accepted more than once within its time-based validity window. The issue exists in the user login flow where a TOTP code is verified as a second authentication factor. Because the system did not record whether a given TOTP period had already been consumed, the same code remained valid for its entire time window (typically 30 seconds). An attacker who captures a legitimate code during a user's login could replay it to authenticate a second session as that user. Preconditions: - The target user has TOTP-based two-factor authentication enabled. - The attacker is in a position to observe or intercept the TOTP code during a legitimate login (e.g., network-level interception, shoulder surfing, or a compromised client). - The replay must occur within the TOTP validity period. Security impact: - Unauthorized account access by replaying a captured one-time code. - Potential compromise of threat-intelligence data and administrative functions accessible to the targeted user. Affected versions: <v2.5.48. | ||||
| CVE-2026-19553 | 1 Python | 1 Cpython | 2026-10-01 | 7.4 High |
| ssl.SSLContext.wrap_bio() didn't require the server_hostname argument to not be None if ssl.SSLContext.check_hostname was set. Due to a missing parameter check in SSLObject, if the server_hostname argument isn't supplied then hostname verification would be silently skipped. This defect could lead to programs where certificate hostname verification *appeared* to be succeeding with SSLContext.check_hostname = True and no ValueError being raised due to misconfiguration. If the program passes a server_hostname value that isn't an empty string or None to any of these APIs then certificate hostname verification proceeds as expected and the program is not affected by this vulnerability. Mitigating this vulnerability doesn't require updating Python or applying the patch. To mitigate, pass a valid non-None and non-empty server_hostname value to SSLContext.wrap_bio(), asyncio.create_connection(), or asyncio.loop.start_tls() and certificate hostname verification will proceed as expected. Upgrading to the latest version of Python or applying the patch only changes the behavior from silently skipping hostname verification to raising a ValueError, similar to SSLContext.wrap_socket(), when server_hostname isn't supplied. | ||||
| CVE-2026-97687 | 1 Urllib3 | 1 Urllib3 | 2026-09-30 | 7.4 High |
| urllib3 is an HTTP client library for Python. From 1.26.0 until 2.8.0, the proxy_ssl_context, proxy_assert_hostname, proxy_assert_fingerprint, ssl_context, cert_reqs, verify_mode, use_forwarding_for_https=True, and CERT_NONE configuration paths fail to remain separated because target-server TLS settings are incorrectly applied to the HTTPS proxy connection. The trigger is that an application uses an HTTPS proxy and configures target-server TLS settings that must remain separate from the proxy TLS handshake, including HTTPS forwarding with target-specific identity or credentials. Applying cert_reqs=CERT_NONE can overwrite proxy_ssl_context.verify_mode in place, and the mutation persists so later connections reusing the same context may connect to the HTTPS proxy without certificate verification. The attack mechanism is that an attacker intercepts and impersonates the HTTPS proxy after the effective proxy policy accepts the attacker's certificate. The impact is that the attacker can observe or modify forwarded traffic or receive a target TLS client certificate, while CONNECT tunneling still preserves the separate end-to-end target TLS connection. This issue is fixed in version 2.8.0. | ||||
| CVE-2026-92868 | 1 Pgpool Global Development Group | 1 Pgpool-ii | 2026-09-30 | N/A |
| An improper certificate validation vulnerability exists in Pgpool-II, which may allow an unauthenticated attacker to bypass client certificate authentication. | ||||
| CVE-2026-58575 | 1 Dell | 13 Powerstore 1000t, Powerstore 1200t, Powerstore 3000t and 10 more | 2026-09-30 | 8.8 High |
| Dell PowerStore contains an Authentication Bypass by Spoofing vulnerability. An authenticated attacker could potentially exploit this vulnerability to escalate privileges to Administrator. | ||||
| CVE-2026-100834 | 1 Http4k | 1 Http4k | 2026-09-30 | 5.9 Medium |
| http4k's Digest authentication module (org.http4k:http4k-security-digest) before versions 6.48.0.0, 5.42.0.0 and 4.51.0.0 defaults the nonceVerifier parameter of ServerFilters.DigestAuth and DigestAuthProvider to { true }, so every nonce is accepted regardless of its value, age, or prior use. Applications relying on this default have no replay protection on Digest authentication: an attacker who can capture a valid 'Authorization: Digest' response (for example by observing network traffic or reading logs) can replay it indefinitely against the same protected resource. | ||||
| CVE-2026-89102 | 1 Wolfssl | 1 Wolfssl | 2026-09-30 | 6.5 Medium |
| In wolfSSL versions 5.7.2 through 5.9.2 there is a client-side implementation flaw in RFC 6961, multiple OCSP response stapling, which can lead to certificate forgery. When a wolfSSL client enables OCSP stapling with the HAVE_CERTIFICATE_STATUS_REQUEST_V2 feature and calls wolfSSL_UseOCSPStaplingV2(ssl, WOLFSSL_CSR2_OCSP_MULTI, options), the client accepts any certificate in the peer's chain as a certificate authority without verifying that the certificate is actually authorized to act as one. This means that an attacker who possesses any certificate that chains to a CA trusted by the client (along with its private key) can forge certificates for arbitrary identities that will be accepted as valid by the client. The end entity certificate of the server is stored in the persistent trust store, affecting subsequent connections that reuse the context even when OCSP multi usage is not employed. Found by internal wolfSSL testing. | ||||
| CVE-2026-86131 | 1 Watchguard | 1 Fireware Os | 2026-09-30 | N/A |
| A code injection vulnerability in WatchGuard Fireware OS's BOVPN Over TLS client configuration handling allows an attacker who controls the remote VPN server to execute arbitrary commands as root on the connecting Firebox. | ||||
| CVE-2026-95291 | 2 Apple, Google | 2 Iphone Os, Chrome | 2026-09-30 | 5.4 Medium |
| UI misrepresentation in SecurityIndicators in Google Chrome on on iOS prior to 154.0.8037.57 allowed a remote attacker to spoof address bar via a crafted HTML page. (Chromium security severity: High) | ||||
| CVE-2026-100835 | 1 Edgelesssys | 1 Contrast | 2026-09-30 | 7.4 High |
| Contrast before 1.16.0 is susceptible to remote attestation relay attacks. Contrast accepted any TEE attestation report that verified correctly and contained the expected firmware patch levels and software measurements, regardless of which machine produced it, so attestation was not bound to specific, physically trusted hardware. An attacker who can both intercept network traffic between the CLI and the Coordinator (or between the Coordinator and an attested component) and forge reports or extract secrets from any single TEE machine under their physical control can relay such a report to impersonate a Contrast Coordinator or a Contrast workload, defeating identity verification in Contrast's attested TLS (aTLS). | ||||
| CVE-2026-10726 | 1 Catonetworks | 1 Sdp Client | 2026-09-30 | N/A |
| Cato Windows SDP Client before version 6.12.6 contains an arbitrary file disclosure vulnerability. A low-privileged local user can cause the Windows service, running as Local System, to read and disclose arbitrary local files due to improper file path validation and missing TLS certificate enforcement. | ||||
| CVE-2026-102508 | 1 Apache | 1 Plc4x | 2026-09-30 | N/A |
| Improper Verification of Cryptographic Signature and Improper Certificate Validation in the OPC UA driver of Apache PLC4X (PLC4J) allows an attacker in a network position between client and server to impersonate the OPC UA server and to read, forge or modify secure-channel traffic, including user credential ssent by the client. The defect manifests differently depending on the version: - In 0.9.0 through 0.11.0 a failed message-signature check is only logged and never enforced, and there is no mechanism to verify the server certificate: it is taken from the unauthenticated GetEndpoints discovery response and used to encrypt the user's password. - In 0.12.0 through 0.13.1 the signature check is inverted (valid signatures are rejected, invalid ones accepted), and server certificates are accepted without a trust anchor by default. - In all affected versions the default security policy is None. Starting with 0.12.0 the driver additionally continues silently at a weaker security policy than the one configured, and starting with 0.13.0 endpoint selection prefers the weakest matching endpoint. Users checking only for one of these mechanisms may wrongly conclude they are unaffected. This issue affects Apache PLC4X: from 0.9.0 before 1.0.0. Users are recommended to upgrade to version 1.0.0, which fixes the issue. Version 1.0.0 verifies message signatures correctly, refuses to connect unless the server certificate can be verified against a configured trust store or pinned certificate, defaults to Basic256Sha256 with SignAndEncrypt, and fails the connection if the negotiated security policy is weaker than the configured one. | ||||
| CVE-2026-73581 | 2 Apache, Redhat | 2 Tomcat, Hummingbird | 2026-09-30 | 6.5 Medium |
| Improper Check for Certificate Revocation vulnerability in Apache Tomcat. Both the OpenSSL and OpenSSL-FFM TLS implementations ignore CRLs when certificate uses a keystore. This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.25, from 10.1.0-M1 through 10.1.59, from 9.0.0-M1 through 9.0.121. The following versions were EOL at the time the CVE was created but are known to be affected: from 8.5.0 through 8.5.100. Other unsupported versions may also be affected. Users are recommended to upgrade to version 11.0.26, 10.1.59, 9.0.122, which fixes the issue. | ||||
| CVE-2026-103397 | 2026-09-30 | 5.6 Medium | ||
| OpenSave before 2.4.0-beta.1 fails to validate sender identity in WAN relay requests, allowing unpaired room members to impersonate paired devices by spoofing the RelayMessage From field. Attackers who know the room code can join, read paired peer identifiers from announcements, and send forged requests to access protected sync routes including save data, snapshots, and file operations. | ||||
| CVE-2026-97249 | 2026-09-30 | 5.3 Medium | ||
| Unauthenticated Bypass Vulnerability in Paid Member Subscriptions <= 3.0.9 versions. | ||||
| CVE-2026-96825 | 2026-09-30 | 4.2 Medium | ||
| Subscriber Bypass Vulnerability in All In One WP Security & Firewall <= 5.4.8 versions. | ||||
| CVE-2026-92899 | 1 Apache | 1 Wss4j | 2026-09-30 | 4.8 Medium |
| Apache WSS4J remembers the Nonce of each UsernameToken it accepts, so a captured token cannot be reused. It stored the Nonce as raw base64 text, but authentication decodes that text and uses the bytes.The same bytes can be written as base64 in several ways. An attacker who captured an authenticated request could re-send it with a space added to the Nonce: the password digest still verified, but the token no longer matched the remembered one, so the replay was accepted. Since a UsernameToken does not cover the message body, the captured token could then be reused on requests of the attacker's choosing until it expired. Affects deployments with a nonce replay cache configured, as Apache CXF has by default, and only tokens using a password digest. The cache is now keyed on the decoded Nonce. Users are recommended to upgrade to versions 4.0.2 or 3.0.6 or 2.4.4, which fix this issue. | ||||
| CVE-2026-97274 | 2026-09-30 | 9.8 Critical | ||
| Unauthenticated Bypass Vulnerability in OAuth Single Sign On – SSO (OAuth Client) <= 7.1.2 versions. | ||||
| CVE-2026-73594 | 2026-09-30 | 6.4 Medium | ||
| Dell Secure Connect Gateway (SCG) Policy Manager, versions prior to 5.34.00.16, Versions prior to 5.36, contains an Improper Certificate Validation vulnerability. An unauthenticated attacker with adjacent network access could potentially exploit this vulnerability, leading to Information disclosure, Information tampering, and Protection mechanism bypass. | ||||
| CVE-2026-84465 | 1 Zammad | 1 Zammad | 2026-09-29 | N/A |
| Zammad is a web based open source helpdesk/customer support system. Prior to 7.1.2, when Zammad checks the digital signature on an incoming S/MIME-signed email, it does not verify that the signing certificate is genuinely trusted, it only checks whether a certificate with a matching name is already stored in the system. An attacker can create their own certificate using the name of a real, previously trusted sender and use it to send a forged email. Zammad will display that email with the same "validly signed" indicator as a genuine message from the real sender, even though the attacker never had access to that sender's actual certificate or private key. This issue is fixed in version 7.1.2. | ||||