Search vulnerabilities

Results 36,461

Export CSV
CVE-2023-21704

Microsoft ODBC Driver for SQL Server Remote Code Execution Vulnerability

Microsoft ODBC Driver for SQL Server Remote Code Execution Vulnerability

CVSS 3.1 · 7.8 High EPSS < 1% KEV · Not listed
Vendors
Products
CVE-2023-21528

Microsoft SQL Server Remote Code Execution Vulnerability

Microsoft SQL Server Remote Code Execution Vulnerability

CVSS 3.1 · 7.8 High EPSS < 1% KEV · Not listed
Vendors
Products
CVE-2022-41083

Visual Studio Code Elevation of Privilege Vulnerability

Visual Studio Code Elevation of Privilege Vulnerability

CVSS 3.1 · 7.8 High EPSS < 1% KEV · Not listed
Vendors
Products
CVE-2022-34382

Dell Command Update, Dell Update and Alienware Update versions prior to 4.6.0 contains a Local Privilege Escalation Vulnerability in the custom catalog configuration. A local malicious user may potentially exploit this vulnerability in order to elevate their privileges.

CVSS 3.1 · 7.8 High EPSS < 1% KEV · Not listed
Vendors
CVE-2022-29546

HtmlUnit NekoHtml Parser before 2.61.0 suffers from a denial of service vulnerability. Crafted input associated with the parsing of Processing Instruction (PI) data leads to heap memory consumption. This is similar to CVE-2022-28366 but affects a much later version of the product.

CVSS 3.1 · 7.5 High EPSS 1.2% KEV · Not listed
Vendors
Products
CVE-2022-29143

Microsoft SQL Server Remote Code Execution Vulnerability

Microsoft SQL Server Remote Code Execution Vulnerability

CVSS 3.1 · 7.5 High EPSS 2.3% KEV · Not listed
Vendors
Products
CVE-2026-63917

ip6: vti: Use ip6_tnl.net in vti6_changelink().

In the Linux kernel, the following vulnerability has been resolved: ip6: vti: Use ip6_tnl.net in vti6_changelink(). ip netns add ns1 ip netns add ns2 ip -n ns1 link add vti6_test type vti6 remote ::1 local ::2 key 7 ip -n ns1 link set vti6_test netns ns2 ip -n ns2 link set vti6_test type vti6 remote ::3 local ::4 key 9 ip netns del ns2 ip netns del ns1 [ 132.495484] ------------[ cut here ]------------ [ 132.497609] kernel BUG at net/core/dev.c:12376! Commit 61220ab34948 ("vti6: Enable namespace changing") dropped NETIF_F_NETNS_LOCAL from vti6 devices. A vti6 tunnel can then move through IFLA_NET_NS_FD. After the move dev_net(dev) points at the new netns while t->net stays at the creation netns. vti6_changelink() and vti6_update() still use dev_net(dev) and dev_net(t->dev). They unlink from one per netns hash and relink into another. The creation netns is left with a stale entry. cleanup_net() of that netns later walks freed memory. Reachable from an unprivileged user namespace (unshare --user --map-root-user --net). Cross tenant scope on container hosts.

CVSS 3.1 · 8.8 High EPSS < 1% KEV · Not listed
Vendors
Products
CVE-2026-63963

usb: typec: tcpm: validate VDO count in Discover Identity ACK handlers

In the Linux kernel, the following vulnerability has been resolved: usb: typec: tcpm: validate VDO count in Discover Identity ACK handlers Properly validate the count passed from a device when calling svdm_consume_identity() or svdm_consume_identity_sop_prime() as the device-controlled value could index off of the static arrays, which could leak data.

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

usb: typec: tcpm: bound altmode_desc[] per iteration in svdm_consume_modes()

In the Linux kernel, the following vulnerability has been resolved: usb: typec: tcpm: bound altmode_desc[] per iteration in svdm_consume_modes() svdm_consume_modes() checks pmdata->altmodes against the array size once before the loop over the count, but forgot to check the bound at every point in the loop. In the well-behaved SVDM discovery flow this is harmless because each of at most SVID_DISCOVERY_MAX SVIDs contributes at most MODE_DISCOVERY_MAX modes, exactly filling altmode_desc[ALTMODE_DISCOVERY_MAX]. But the CMDT_RSP_ACK handler in tcpm_pd_svdm() does not correlate an incoming ACK with any request the port actually sent. Once port->partner is set, an unsolicited Discover Modes ACK is consumed unconditionally. A broken or malicious port partner can therefore drive altmodes to ALTMODE_DISCOVERY_MAX - 1 via the normal flow, and then send one extra Discover Modes ACK with seven VDOs. Because the pre-loop check passes, the loop could then writes up to five entries past altmode_desc[]. For mode_data_prime the next field in struct tcpm_port is the partner_altmode[] pointer array, which then receives partner-chosen SVID/VDO bytes. Move the bound check inside the loop so the array can never be indexed past ALTMODE_DISCOVERY_MAX regardless of how many VDOs the partner supplies or how the function was reached.

CVSS 3.1 · 5.5 Medium EPSS < 1% KEV · Not listed
Vendors
Products