Vulnerabilities exploitable today
369,690in current view
Single score combining CVSS, KEV membership and EPSS. Every CVE with its own record — timeline from publication to active exploitation.
In KEV catalog1,695
New KEV · 24H0
Exploit Today ≥ 701,637
Distribution · last window
- Critical2,132
- High7,668
- Medium5,756
- Low559
Window
Severity
Flags
CVECVSSEPSSKEVRExploitTitleMod.
CVE-2025-14549—21.6%
——6——CVE-2025-31147—21.6%
——6——CVE-2026-17599—21.6%
——6Nexus Repository 3 contained an endpoint used to change the administrator account password during initial onboarding. This endpoint did not verify that onboarding was still in progress before allowing the password change, relying instead on the presence of a local onboarding artifact. As a result, an account holding the nexus:* permission could invoke the endpoint outside the intended onboarding flow to replace the administrator password, and existing sessions were not invalidated after the change.7dCVE-2023-542148.8 HIG21.6%
——6In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: Fix potential user-after-free
This fixes all instances of which requires to allocate a buffer calling
alloc_skb which may release the chan lock and reacquire later which
makes it possible that the chan is disconnected in the meantime.35dCVE-2025-4000—21.6%
——6——CVE-2024-12851—21.6%
——6——CVE-2024-3635—21.6%
——6——CVE-2025-0706—21.6%
——6——CVE-2026-17597—21.6%
——6Nexus Repository 3 contains a Server-Side Request Forgery (SSRF) vulnerability in the email configuration verification feature. A user holding the nexus:settings:update permission could submit arbitrary host and port values to the email test/verification endpoint, causing the server to attempt outbound network connections to internal or otherwise restricted network addresses. Differences in the server's response could be used to infer whether internal hosts and ports are reachable. This issue affects Nexus Repository 3 CE/Pro versions up to and including 3.94.1, and is fixed in version 3.95.0.7dCVE-2026-31719—21.6%
——6——CVE-2025-37862—21.6%
——6——CVE-2025-4051—21.6%
——6——CVE-2024-50413—21.6%
——6——CVE-2025-30904—21.6%
——6——CVE-2026-628349.3 CRI21.6%
——6Improper verification of cryptographic signature in Azure Data Factory allows an unauthorized attacker to elevate privileges over a network.15dCVE-2024-3977—21.6%
——6——CVE-2024-13143—21.6%
——6——CVE-2022-3027—21.6%
——6——CVE-2020-4918—21.6%
——6——CVE-2026-446938.8 HIG21.6%
——6Pi-hole FTL is the core engine of the Pi-hole network-level advertisement and tracker blocker. Prior to version 6.6.1, Pi-hole FTL contains a race condition vulnerability in the HTTP session management subsystem, introduced with the v6.0 rewrite of the embedded CivetWeb-based web server. This issue has been patched in version 6.6.1.47dCVE-2026-65931—21.6%
——6LimeSurvey Community Edition 7.0.5 contains an authenticated improper authorization vulnerability in the survey menu entry creation endpoint.
An authenticated user with only the global settings:read permission can directly invoke POST /index.php/admin/menuentries/sa/create and create new survey menu entries without the expected settings:update privilege. The endpoint also allows the attacker to submit menu IDs that the normal interface and intended update workflow restrict for non-superadministrators, enabling unauthorized changes to administrative navigation records.
This issue affects LimeSurvey: 7.0.5.11dCVE-2025-37859—21.6%
——6——CVE-1999-0164—21.6%
——6——CVE-2026-76613—21.6%
——6Joomla Extension - yootheme.com - Authenticated, privileged SQL injection in YOOtheme Pro 1.0.0-5.0.40 - An SQL injection allowed any contributor-level user to inject own content into SQL queries.16dCVE-2026-138936.5 MED21.6%
——6Insufficient validation of untrusted input in WebUI in Google Chrome prior to 150.0.7871.47 allowed a remote attacker to leak cross-origin data via malicious network traffic. (Chromium security severity: Medium)68dCVE-2026-4292—21.6%
——6——CVE-2026-480889.4 CRI21.6%
——6OpenReception's appointment booking software provides an end-to-end encrypted appointment booking platform. Prior to version 1.0.4, the route `POST /api/tenants/{tenantId}/staff/{staffId}/crypto` accepts and stores attacker-controlled ML-KEM-768 public keys against any tenant on the platform without authentication. The handler logs an "Unauthorized crypto key storage attempt" warning when neither a session nor a registration cookie is present, then proceeds to insert the row regardless. The platform's E2E claim that "even administrators cannot view sensitive information" is broken: any unauthenticated network attacker can register themselves as an additional encryption recipient for any tenant's future patient appointments. A second variant of the bug suppresses the unauthorized-warning log entry. The Zod schema makes the `email` field optional. When the request body omits `email` and the request carries no registration cookie, the comparison `registrationEmail === email` becomes `undefined === undefined`, which evaluates to `true`. The handler treats the request as a legitimate registration flow, skips the warning entirely, and stores the row. Successful storage is still recorded as an `[info]` log line, but the security-relevant warning that operators are most likely to monitor or alert on is gone. The `staff_crypto` table has no unique constraint on `user_id`, so an arbitrary number of attacker rows can coexist for the same staff identifier and all return as `is_active=true`. The supplied `staffId` does not need to match any existing user or pending invite. Schema validation on `passkeyId`, `publicKey`, and `privateKeyShare` is also weak: the literal string `<placeholder-base64>` was accepted, indicating no length, format, or cryptographic-validity check beyond field presence. This weakness is independent of the auth bypass but compounds it: a poisoned directory can also be filled with malformed entries that break legitimate booking flows. The injected key is consumed by the public booking flow. After completing the unauthenticated `bootstrap-challenge` and `bootstrap-verify` ceremony as a "patient", the resulting `bookingAccessToken` is accepted by `GET /api/tenants/{id}/appointments/staff-public-keys`, which returns the attacker-controlled keys alongside any legitimate ones. A new appointment encrypts its tunnel key with ML-KEM to all listed recipients, so the attacker becomes a co-recipient of the encryption and can decapsulate the tunnel key with the matching secret. From there, all appointment payloads for that booking are decryptable. Version 1.0.4 patches the issue.31dCVE-2025-32680—21.6%
——6——CVE-2001-0019—21.6%
——6——CVE-2021-3669—21.6%
——6——CVE-2014-5579—21.6%
——6——CVE-2020-24366—21.6%
——6——CVE-2024-29141—21.6%
——6——CVE-2024-0554—21.6%
——6——CVE-2025-533458.8 HIG21.6%
——6Missing Authorization vulnerability leading to code execution after installing malicious vulnerable plugin in ThimPress Thim Core.
This issue affects Thim Core: from n/a through 2.3.3.48dCVE-2025-9105—21.6%
——6——CVE-2025-31941—21.6%
——6——CVE-2018-8838—21.6%
——6——CVE-2025-1081—21.6%
——6——CVE-2022-1799—21.6%
——6——