Search vulnerabilities

Use the Query Builder to create your own search query, or check out the documentation to learn the search syntax.

Results 253

Export CSV
CVE-2026-96760

Authlib library contains a signature‑verification bypass vulnerability

Authlib (v1.8.0 and below) contains a signature verification bypass vulnerability. The JsonWebSignature.deserialize_json() method accepts a JSON Serialization JWS object and returns the payload as successfully verified without checking for a signature and without requiring a cryptographic key.

CVSS 3.1 · 9.8 Critical EPSS < 1% KEV · Not listed
Vendors
Authlib
Products
Authlib
CVE-2026-108178

Multiple Vulnerabilities in IBM API Connect

IBM API Connect 10.0.8.0 through 10.0.8.12 and 12.1.0.0 through 12.1.1.2 could allow a token to be accepted that should be rejected due to an improperly implemented security check. Under certain conditions, token validation is incomplete, so a token may be accepted for a purpose it was not intended for.

CVSS 3.1 · 4.2 Medium EPSS < 1% KEV · Not listed
Vendors
Ibm
Products
Api Connect
CVE-2026-63817

f2fs: validate compress cache inode only when enabled

In the Linux kernel, the following vulnerability has been resolved: f2fs: validate compress cache inode only when enabled F2FS_COMPRESS_INO() uses NM_I(sbi)->max_nid as the synthetic inode number for the compressed page cache inode. That inode only exists when the compress_cache mount option is enabled. When compress_cache is disabled, max_nid is outside the valid inode range. A corrupted directory entry that points to ino == max_nid should therefore be rejected by f2fs_check_nid_range(). However, is_meta_ino() currently treats F2FS_COMPRESS_INO() as a meta inode unconditionally, so f2fs_iget() bypasses do_read_inode() and its nid range check, and instantiates a fake internal inode instead. Gate the compressed cache inode case on COMPRESS_CACHE, matching f2fs_init_compress_inode(). With compress_cache disabled, ino == max_nid now follows the normal inode path and is rejected as an out-of-range nid.

CVSS 3.1 · 7.8 High EPSS < 1% KEV · Not listed
Vendors
Linux
Products
Linux Kernel
CVE-2026-123579

Hickory DNS 0.26.0-beta.1 before 0.26.2 DNSSEC Validation Bypass via Wildcard Expansion

DNSSEC validation in Hickory DNS hickory-net 0.26.0-beta.1 before 0.26.2 and hickory-proto through 0.26.0-alpha.1 does not distinguish NODATA responses from wildcard-expanded positive responses. For a query that should return NODATA in a zone with wildcard records, an attacker can combine an NSEC3 record matching the query name with a signed wildcard record into a bogus positive response that validation accepts.

CVSS 4.0 · 6.3 Medium EPSS < 1% KEV · Not listed
Vendors
Hickory-dns
Products
Hickory-dns
CVE-2026-123600

Hickory DNS hickory-proto 0.25.0-alpha.3 through 0.25.2 NSEC3 Apex NODATA Validation Bypass

Hickory DNS hickory-proto 0.25.0-alpha.3 through 0.25.2 and hickory-net 0.26.0-alpha.1 before 0.26.2 contain a DNSSEC validation flaw in DnssecDnsHandle that accepts NSEC3-signed NODATA responses for zone-apex queries as secure without an NSEC3 record matching the hashed QNAME. On-path attackers or malicious authoritative servers can replay a validly signed non-apex NSEC3 with the zone's signed SOA to serve an authenticated (AD=1) denial of any apex RRtype for the negative-cache TTL.

CVSS 4.0 · 6.3 Medium EPSS < 1% KEV · Not listed
Vendors
Hickory-dns
Products
Hickory-dns
CVE-2026-123542

OpenAM before 16.1.4 PKCE Bypass in OAuth 2.0 Device Authorization Flow

OpenAM before 16.1.4 fails to enforce PKCE in the OAuth 2.0 device authorization flow, never validating the code verifier when device codes are exchanged for tokens. Attackers who obtain an approved device code from client logs or shared device storage can redeem it for access and ID tokens to impersonate the user.

CVSS 4.0 · 7.6 High EPSS < 1% KEV · Not listed
Vendors
Openidentityplatform
Products
Openam
CVE-2026-50628

Apache CXF: OAuth2: Inverted IP Binding Check Defeats Security Control

A logic error in OAuthRequestFilter rejects legitimate requests originating from the bound IP address, while blindly allowing requests from any other IP address. Enabling this security feature inadvertently creates an inverse security check. Users are recommended to upgrade to versions 4.2.2 or 4.1.7 or 3.6.12, which fixes this issue.

CVSS 3.1 · 9.8 Critical EPSS < 1% KEV · Not listed
Vendors
Apache Redhat
Products
Cxf Build Of Apache Camel Fuse and 1 more
CVE-2026-45109

Next.js: Middleware / Proxy bypass in App Router applications via segment-prefetch routes

Next.js is a React framework for building full-stack web applications. From 15.2.0 to before 15.5.18 and 16.2.6, it was found that the fix addressing CVE-2026-44575 did not apply to middleware.ts with Turbopack. This vulnerability is fixed in 15.5.18 and 16.2.6.

CVSS 3.1 · 7.5 High EPSS < 1% KEV · Not listed
Vendors
Vercel
Products
Next.js
CVE-2026-116794

russh: Agent server never calls `Agent::confirm`, so keys added with the confirm constraint (`ssh-add -c`) sign without confirmation

russh is a Rust SSH client and server library that includes an SSH agent protocol implementation. From 0.50.0-beta.12 until 0.65.0, the agent server's Connection::try_sign path in russh/src/keys/agent/server.rs recognizes SSH_AGENT_CONSTRAIN_CONFIRM but returns a hard-coded successful result instead of calling Agent::confirm. In applications that override Agent::confirm to require user approval or another policy check, a process that can reach the agent socket, including the remote side of a forwarded agent, can use a key added through ssh-add -c without that check and can authenticate or sign data as the user while the key remains loaded. The separate Agent::confirm_request hook still runs for every signing request, so checks implemented there remain effective, and implementations that retain the default always-successful Agent::confirm do not lose an approval check through this regression. This issue is fixed in version 0.65.0.

CVSS 4.0 · 8.3 High EPSS < 1% KEV · Not listed
Vendors
Eugeny
Products
Russh
CVE-2026-63913

netfilter: conntrack: tcp: do not force CLOSE on invalid-seq RST without direction check

In the Linux kernel, the following vulnerability has been resolved: netfilter: conntrack: tcp: do not force CLOSE on invalid-seq RST without direction check An unintended behavior in the TCP conntrack state machine allows a connection to be forced into the CLOSE state using an RST packet with an invalid sequence number. Specifically, after a SYN packet is observed, an RST with an invalid SEQ can transition the conntrack entry to TCP_CONNTRACK_CLOSE, regardless of whether the RST corresponds to the expected reply direction. The relevant code path assumes the RST is a response to an outgoing SYN, but does not validate packet direction or ensure that a matching SYN was actually sent in the opposite direction. As a result, a crafted packet sequence consisting of a SYN followed by an invalid-sequence RST can prematurely terminate an active NAT entry. This makes connection teardown easier than intended. So, tighten the state transition logic to ensure that RST-triggered CLOSE transitions only occur when the RST is a valid response to a previously observed SYN in the correct direction.

CVSS 3.1 · 8.2 High EPSS < 1% KEV · Not listed
Vendors
Linux
Products
Linux Kernel
CVE-2026-72416

netfilter: nft_compat: ebtables emulation must reject non-bridge targets

In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_compat: ebtables emulation must reject non-bridge targets xtables targets return netfilter verdicts: NF_ACCEPT, NF_DROP, and so on. ebtables targets return incompatible verdicts: EBT_ACCEPT, EBT_DROP, ... We cannot allow fallback to NFPROTO_UNSPEC. ebtables doesn't permit this since 11ff7288beb2 ("netfilter: ebtables: reject non-bridge targets") but that commit missed the nft_compat layer.

CVSS 3.1 · 7.3 High EPSS < 1% KEV · Not listed
Vendors
Linux
Products
Linux Kernel
CVE-2026-89448

iommu/vt-d: Force requesting ACS when tboot is enabled

In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Force requesting ACS when tboot is enabled Currently the conditions of requesting ACS in detect_intel_iommu() don't include tboot, leading to a possible misconfiguration with ACS disabled (e.g. due to user opts) while iommu is later forced on by tboot_force_iommu(). Fix it by checking tboot in detect_intel_iommu().

CVSS 3.1 · 9.3 Critical EPSS < 1% KEV · Not listed
Vendors
Linux
Products
Linux Kernel
CVE-2026-72325

perf/x86/amd/core: Avoid enabling BRS from the SVM reload path

In the Linux kernel, the following vulnerability has been resolved: perf/x86/amd/core: Avoid enabling BRS from the SVM reload path Branch Sampling (BRS) and Last Branch Record (LBR) are mutually exclusive hardware features, and users of both are tracked via cpuc->lbr_users. When SVM is toggled on a CPU, the host perf events are reprogrammed to update the HostOnly filter bit (set when virtualization is enabled, cleared when it is disabled). On PerfMonV2-capable processors, this reprogramming is performed by calling amd_pmu_enable_all() to rewrite the event selectors. However, amd_pmu_enable_all() also calls amd_brs_enable_all(), which enables BRS whenever cpuc->lbr_users > 0. Having active LBR events satisfies this gating on processors that have LBR but not BRS. The kernel then tries to set the BRS enable bit in DebugExtnCfg (MSR 0xc000010f). Since that bit is deprecated on such hardware, the write results in a #GP: Call Trace: <IRQ> amd_pmu_enable_all+0x1d/0x90 amd_pmu_disable_virt+0x62/0xb0 kvm_arch_disable_virtualization_cpu+0xa/0x40 [kvm] hardware_disable_nolock+0x1a/0x30 [kvm] __flush_smp_call_function_queue+0x9b/0x410 __sysvec_call_function+0x18/0xc0 sysvec_call_function+0x69/0x90 </IRQ> <TASK> asm_sysvec_call_function+0x16/0x20 RIP: 0010:cpuidle_enter_state+0xc4/0x450 ? cpuidle_enter_state+0xb7/0x450 cpuidle_enter+0x29/0x40 cpuidle_idle_call+0xf5/0x160 do_idle+0x7b/0xe0 cpu_startup_entry+0x26/0x30 start_secondary+0x115/0x140 secondary_startup_64_no_verify+0x194/0x19b </TASK> Fix this by ensuring that BRS is not enabled from the event selector reprogramming path even when cpuc->lbr_users > 0.

CVSS 3.1 · 5.5 Medium EPSS < 1% KEV · Not listed
Vendors
Linux
Products
Linux Kernel
CVE-2026-68118

tcp: challenge ACK for non-exact RST in SYN-RECEIVED

In the Linux kernel, the following vulnerability has been resolved: tcp: challenge ACK for non-exact RST in SYN-RECEIVED The SYN-RECEIVED request-socket path in tcp_check_req() accepts an in-window RST without requiring SEG.SEQ to exactly match RCV.NXT. A non-exact RST therefore removes the request instead of eliciting a challenge ACK. RFC 9293 section 3.10.7.4 applies the RFC 5961 reset check in SYN-RECEIVED: an exact RST resets the connection, while a non-exact in-window RST must trigger a challenge ACK and be dropped. Apply that check before the ACK-field validation, following the RFC sequence-number, RST, then ACK processing order. Factor the per-netns challenge ACK quota out of tcp_send_challenge_ack() so request sockets can share it. Use the request socket's send_ack() callback and its own out-of-window ACK timestamp to send and rate-limit the response.

CVSS 3.1 · 8.2 High EPSS < 1% KEV · Not listed
Vendors
Linux
Products
Linux Kernel
CVE-2026-114618

Authlib: Default JWT bearer grant accepts assertions for the wrong audience

Authlib is a Python library which builds OAuth and OpenID Connect servers. Prior to 1.9.0, the default RFC 7523 JWTBearerGrant.get_audiences() returns an empty list, causing JWTBearerGrant.verify_claims() to require only that an aud claim exists without matching the current authorization server. An attacker holding a legitimate assertion for another service can present it to a server that shares the signing key and uses the default grant, obtaining an access token across a trust boundary. Implementations that override get_audiences() with the server's valid audience identifiers are not affected. This issue is fixed in version 1.9.0.

CVSS 3.1 · 6.8 Medium EPSS < 1% KEV · Not listed
Vendors
Authlib
Products
Authlib
CVE-2026-62322

Python Social Auth: Login CSRF in LINE backend (LineOAuth2) — missing OAuth state validation (incomplete fix of 5.0.0 campaign)

Python Social Auth is a social authentication/registration mechanism. Prior to 5.0.2, the LINE backend exchanges an authorization code without validating the returned OAuth state. An attacker can begin authorization for an attacker-controlled LINE account and induce a victim to visit the resulting callback URL, causing the application to log the victim into the attacker's account. When account linking is enabled, the same missing validation can link the attacker's LINE identity to the victim's existing account and create a persistent unauthorized login path. Only applications with the LINE backend enabled are affected. This issue is fixed in version 5.0.2.

CVSS 3.1 · 6.5 Medium EPSS < 1% KEV · Not listed
Vendors
Python-social-auth
Products
Social-core
CVE-2026-83374

openjdk: Enhance PKCS5 padding (Oracle CPU 2026-10)

Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Security). Supported versions that are affected are Oracle Java SE: 8u503, 8u503-perf, 11.0.32.1, 17.0.20.1, 21.0.12.1, 25.0.4.1, 27; Oracle GraalVM for JDK: 17.0.20.1 and 21.0.12.1; Oracle GraalVM Enterprise Edition: 21.3.19.1.1. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition. Successful attacks of this vulnerability can result in unauthorized creation, deletion or modification access to critical data or all Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 5.9 (Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N).

CVSS 3.1 · 5.9 Medium EPSS < 1% KEV · Not listed
Vendors
Oracle
Products
Graalvm Graalvm Enterprise Edition Graalvm For Jdk and 2 more
CVE-2026-98479

scsi: libiscsi_tcp: Check the data direction of a Data-In PDU

In the Linux kernel, the following vulnerability has been resolved: scsi: libiscsi_tcp: Check the data direction of a Data-In PDU The Data-In branch of iscsi_tcp_hdr_dissect() resolves the ITT to a task and copies the PDU's data segment into that command's scatterlist without asking whether the command was reading. iscsi_tcp_r2t_rsp() in the same file does ask, and rejects an R2T for a command that is not DMA_TO_DEVICE. A target that answers a WRITE command's ITT with a Data-In therefore has the initiator write target-supplied bytes into the pages that write was about to send. Those are the caller's own pinned pages for an O_DIRECT write, and page cache pages for a buffered one. Observed against a test target that emits one 512-byte Data-In naming a 128 KB write's ITT, after the R2T for that write. With O_DIRECT the caller's buffer ends up holding 512 bytes of the target's data while pwrite() returns 131072. Buffered is quieter: pwrite() and fsync() both succeed, nothing is logged, and reading those blocks back returns the target's bytes out of the page cache without a command going on the wire. Check the direction before using the scatterlist, the way the R2T path already does.

CVSS 3.1 · 7.5 High EPSS < 1% KEV · Not listed
Vendors
Linux
Products
Linux Kernel