Skip to main content
Press slash or control plus K to focus the search. Use the arrow keys to navigate results and press enter to open a threat.

Null Severity Threats

Comprehensive database of the latest cyber threats affecting organizations worldwide. Filter and search to find specific threat intelligence relevant to your organization.

Pro Console Lifetime

Stop chasing alerts. Route them.

Start free, then upgrade once to turn Radar into an automated delivery engine for your security stack.

Custom feeds / Automations: email, Slack, webhooks, SIEM/MISP / API access (baseline limits)

View Plans & Pricing

API access activates after upgrading in Console -> Billing.

Breach by OffSeqOFFSEQFRIENDS — 25% OFF

Check if your credentials are on the dark web

Instant breach scanning across billions of leaked records. Free tier available.

Scan now

Filter Threats

Narrow down the results by type, severity, or affected countries

Search threats by title, CVE ID, or description. Maximum 100 characters.
Active filters (2):Severity: Null

Filtered Threats

Click on any threat for detailed analysis and mitigation recommendations

In the Linux kernel, the following vulnerability has been resolved: net: nexthop: Increase weight to u16 In CLOS networks, as link failures occur at… (CVE-2024-14040)CVE-2024-14040
0

In the Linux kernel, the following vulnerability has been resolved: net: nexthop: Increase weight to u16 In CLOS networks, as link failures occur at various points in the network, ECMP weights of the involved nodes are adjusted to compensate. With high fan-out of the involved nodes, and overall high number of nodes, a (non-)ECMP weight ratio that we would like to configure does not fit into 8 bits. Instead of, say, 255:254, we might like to configure something like 1000:999. For these deployments, the 8-bit weight may not be enough. To that end, in this patch increase the next hop weight from u8 to u16. Increasing the width of an integral type can be tricky, because while the code still compiles, the types may not check out anymore, and numerical errors come up. To prevent this, the conversion was done in two steps. First the type was changed from u8 to a single-member structure, which invalidated all uses of the field. This allowed going through them one by one and audit for type correctness. Then the structure was replaced with a vanilla u16 again. This should ensure that no place was missed. The UAPI for configuring nexthop group members is that an attribute NHA_GROUP carries an array of struct nexthop_grp entries: struct nexthop_grp { __u32 id; /* nexthop id - must exist */ __u8 weight; /* weight of this nexthop */ __u8 resvd1; __u16 resvd2; }; The field resvd1 is currently validated and required to be zero. We can lift this requirement and carry high-order bits of the weight in the reserved field: struct nexthop_grp { __u32 id; /* nexthop id - must exist */ __u8 weight; /* weight of this nexthop */ __u8 weight_high; __u16 resvd2; }; Keeping the fields split this way was chosen in case an existing userspace makes assumptions about the width of the weight field, and to sidestep any endianness issues. The weight field is currently encoded as the weight value minus one, because weight of 0 is invalid. This same trick is impossible for the new weight_high field, because zero must mean actual zero. With this in place: - Old userspace is guaranteed to carry weight_high of 0, therefore configuring 8-bit weights as appropriate. When dumping nexthops with 16-bit weight, it would only show the lower 8 bits. But configuring such nexthops implies existence of userspace aware of the extension in the first place. - New userspace talking to an old kernel will work as long as it only attempts to configure 8-bit weights, where the high-order bits are zero. Old kernel will bounce attempts at configuring >8-bit weights. Renaming reserved fields as they are allocated for some purpose is commonly done in Linux. Whoever touches a reserved field is doing so at their own risk. nexthop_grp::resvd1 in particular is currently used by at least strace, however they carry an own copy of UAPI headers, and the conversion should be trivial. A helper is provided for decoding the weight out of the two fields. Forcing a conversion seems preferable to bending backwards and introducing anonymous unions or whatever.

Join the discussion
In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_api: Handle TC_ACT_CONSUMED in tcf_qevent_handle tcf_classify()… (CVE-2026-64530)CVE-2026-64530
0

In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_api: Handle TC_ACT_CONSUMED in tcf_qevent_handle tcf_classify() can return TC_ACT_CONSUMED while the skb is held by the defragmentation engine (e.g. act_ct on out-of-order fragments). When that happens the skb is no longer owned by the caller and must not be touched again. tcf_qevent_handle() did not handle TC_ACT_CONSUMED: it fell through the switch and returned the skb to the caller as if classification had passed. The only qdisc that wires up qevents today is RED, via three call sites (qe_mark on RED_PROB_MARK/HARD_MARK, qe_early_drop on congestion_drop) red_enqueue() was continuing to operate on an skb it no longer owns in this case -- enqueueing it, dropping it, or updating statistics. Resulting in a UAF. tc qdisc add dev eth0 root handle 1: red ... qevent early_drop block 10 tc filter add block 10 ... action ct (with ct defrag enabled and traffic that produces out-of-order fragments, e.g. a fragmented UDP stream) Handle TC_ACT_CONSUMED in tcf_qevent_handle() the same way the ingress and egress fast paths do: treat it as stolen and return NULL without touching the skb. Unlike the TC_ACT_STOLEN case, the skb must not be dropped/freed here, as it is no longer owned by us.

Join the discussion
linux-azure-fde-6.8 vulnerabilities
0

It was discovered that some AMD processors did not properly clear data in the floating point divider unit during speculative execution. A local attacker could use this to expose sensitive information. (CVE-2025-54505) It was discovered that some AMD Zen 2 processors did not properly isolate shared resources in the operation cache. A local attacker could possibly use this issue to corrupt instructions executed at a higher privilege level, resulting in privilege escalation. (CVE-2025-54518) It was discovered that some AMD Zen 5 processors supporting RDSEED instruction did not properly handle entropy, potentially resulting in the consumption of insufficiently random values. A local attacker could possibly use this issue to influence the values returned by the RDSEED instruction causing loss of confidentiality and integrity. (CVE-2025-62626) Several security issues were discovered in the Linux kernel. An attacker could possibly use these to compromise the system. This update corrects flaws in the following subsystems: - ARM64 architecture; - MIPS architecture; - PowerPC architecture; - RISC-V architecture; - S390 architecture; - x86 architecture; - Block layer subsystem; - Cryptographic API; - Compute Acceleration Framework; - ACPI drivers; - Serial ATA and Parallel ATA drivers; - ATM drivers; - Drivers core; - Power management core; - DRBD Distributed Replicated Block Device drivers; - Rados block device (RBD) driver; - RNBD block device driver; - Ublk userspace block driver; - Compressed RAM block device driver; - Bluetooth drivers; - Bus devices; - Character device driver; - TPM device driver; - Clock framework and drivers; - Clocksource drivers; - Data acquisition framework and drivers; - Counter interface drivers; - CPU frequency scaling framework; - CPU idle management framework; - Hardware crypto device drivers; - CXL (Compute Express Link) drivers; - DMA engine subsystem; - EDAC drivers; - EFI core; - GPIO subsystem; - GPU drivers; - Greybus drivers; - HID subsystem; - Hardware monitoring drivers; - I2C subsystem; - IIO subsystem; - IIO ADC drivers; - InfiniBand drivers; - Input Device (Miscellaneous) drivers; - IOMMU subsystem; - IRQ chip drivers; - LED subsystem; - Mailbox framework; - Multiple devices driver; - Media drivers; - MediaTek SMI driver; - NVIDIA Tegra memory controller driver; - Multifunction device drivers; - Broadcom VK accelerator driver; - Fastrpc Driver; - IBM Advanced System Management driver; - MMC subsystem; - MOST (Media Oriented Systems Transport) drivers; - MTD block device drivers; - Network drivers; - Ethernet bonding driver; - Mellanox network drivers; - Microsoft Azure Network Adapter (MANA) driver; - STMicroelectronics network drivers; - Ethernet team driver; - MediaTek network drivers; - Near Field Communication (NFC) drivers; - NTB driver; - NVDIMM (Non-Volatile Memory Device) drivers; - NVME drivers; - Device tree and open firmware driver; - PCI subsystem; - Performance monitor drivers; - Pin controllers subsystem; - x86 platform drivers; - Broadcom BCM2835 power domain driver; - Generic PM domains; - i.MX PM domains; - Power supply drivers; - RapidIO drivers; - RAS (Reliability, Availability, Serviceability) subsystem; - Remote Processor subsystem; - RPMSG subsystem; - S/390 drivers; - SCSI subsystem; - SLIMbus drivers; - Freescale SoC drivers; - MediaTek SoC drivers; - Microchip PolarFire SoC system controller driver; - Texas Instruments SoC drivers; - SPI subsystem; - Greybus lights staging drivers; - Media staging drivers; - Realtek RTL8723BS SDIO drivers; - SM750 framebuffer staging driver; - TCM subsystem; - Thermal drivers; - TTY drivers; - UFS subsystem; - Cadence USB3 driver; - ChipIdea USB driver; - USB Device Class drivers; - ULPI bus; - USB core drivers; - DesignWare USB2 driver; - DesignWare USB3 driver; - USB Gadget drivers; - USB Host Controller drivers; - Mustek MDC800 USB digital camera driver; - USB YUREX driver; - Renesas USBHS Controller drivers; - USB Type-C Connector System Software Interface driver; - USB over IP driver; - vDPA drivers; - VFIO drivers; - Virtio Host (VHOST) subsystem; - Framebuffer layer; - TSM TDX Guest driver; - Xen hypervisor drivers; - File systems infrastructure; - BTRFS file system; - Ceph distributed file system; - EROFS file system; - Ext4 file system; - F2FS file system; - FAT file system; - FUSE (File system in Userspace); - GFS2 file system; - HFS+ file system; - Journaling layer for block devices (JBD2); - JFS file system; - Network file systems library; - Network file system (NFS) server daemon; - NILFS2 file system; - File system notification infrastructure; - NTFS3 file system; - OCFS2 file system; - Proc file system; - Pstore file system;

Join the discussion
Linux hwe edge: In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free and NULL deref in smb_grant_oplock()…
0

In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free and NULL deref in smb_grant_oplock() smb_grant_oplock() has two issues in the oplock publication sequence: 1) opinfo is linked into ci->m_op_list (via opinfo_add) before add_lease_global_list() is called. If add_lease_global_list() fails (kmalloc returns NULL), the error path frees the opinfo via __free_opinfo() while it is still linked in ci->m_op_list. Concurrent m_op_list readers (opinfo_get_list, or direct iteration in smb_break_all_levII_oplock) dereference the freed node. 2) opinfo->o_fp is assigned after add_lease_global_list() publishes the opinfo on the global lease list. A concurrent find_same_lease_key() can walk the lease list and dereference opinfo->o_fp->f_ci while o_fp is still NULL. Fix by restructuring the publication sequence to eliminate post-publish failure: - Set opinfo->o_fp before any list publication (fixes NULL deref). - Preallocate lease_table via alloc_lease_table() before opinfo_add() so add_lease_global_list() becomes infallible after publication. - Keep the original m_op_list publication order (opinfo_add before lease list) so concurrent opens via same_client_has_lease() and opinfo_get_list() still see the in-flight grant. - Use opinfo_put() instead of __free_opinfo() on err_out so that the RCU-deferred free path is used. This also requires splitting add_lease_global_list() to take a preallocated lease_table and changing its return type from int to void, since it can no longer fail.

Join the discussion
Malicious code in random-ua-generator (PyPI)
0

--- _-= Per source details. Do not edit below this line.=-_ ## Source: kam193 (543206058a0b8e85c8227a0bfdd4752fc61779b24968a0bd5d50ae6b3040387b) During import, the code starts a keylogger and exfiltrates data from cryptowallets. --- Category: MALICIOUS - The campaign has clearly malicious intent, like infostealers. Campaign: 2026-07-random-ua-generator Reasons (based on the campaign): - keylogger - exfiltration-crypto

Join the discussion
Apache2: readfilemap.c in expat before 2.1.0 allows context-dependent attackers to cause a denial of service (file descriptor consumption) via a large number…
0

readfilemap.c in expat before 2.1.0 allows context-dependent attackers to cause a denial of service (file descriptor consumption) via a large number of crafted XML files.

Join the discussion
Apache2: Apache HTTP Server versions 2.4.6 to 2.4.46 mod_proxy_wstunnel configured on an URL that is not necessarily Upgraded by the origin server was…
0

Apache HTTP Server versions 2.4.6 to 2.4.46 mod_proxy_wstunnel configured on an URL that is not necessarily Upgraded by the origin server was tunneling the whole connection regardless, thus allowing for subsequent requests on the same connection to pass through with no HTTP validation, authentication or authorization possibly configured.

Join the discussion
imagemagick vulnerabilities
0

It was discovered that ImageMagick did not limit mutual references between MVG files. An attacker could possibly use this issue to cause a stack overflow, resulting in a denial of service. This issue only affected Ubuntu 14.04 LTS, Ubuntu 16.04 LTS, Ubuntu 18.04 LTS, Ubuntu 20.04 LTS, Ubuntu 22.04 LTS, and Ubuntu 24.04 LTS. (CVE-2025-68950) It was discovered that the ImageMagick MSL coder destroyed a cloned image twice when an MSL script failed. An attacker could possibly use this issue to cause a use-after-free, resulting in a denial of service, or arbitrary code execution. This issue only affected Ubuntu 14.04 LTS, Ubuntu 16.04 LTS, Ubuntu 18.04 LTS, Ubuntu 20.04 LTS, Ubuntu 22.04 LTS, and Ubuntu 24.04 LTS. (CVE-2026-28688) It was discovered that the ImageMagick VIFF image encoder did not properly validate the packet count, leading to an integer overflow on 32-bit systems. An attacker could possibly use this issue to cause an out-of- bounds heap write, resulting in a denial of service. (CVE-2026-33900) It was discovered that ImageMagick did not properly handle the column offset when sampling an image. An attacker could possibly use this issue to cause ImageMagick to read out of bounds, resulting in a denial of service. This issue only affected Ubuntu 16.04 LTS, Ubuntu 18.04 LTS, Ubuntu 20.04 LTS, Ubuntu 22.04 LTS, Ubuntu 24.04 LTS, and Ubuntu 26.04 LTS. (CVE-2026-33905)

Join the discussion
Snapd: On Ubuntu, if the systemd-userdbd package is installed, then a strictly confined snap is able to access hashed user passwords via its varlink…
0

On Ubuntu, if the systemd-userdbd package is installed, then a strictly confined snap is able to access hashed user passwords via its varlink interface.

Join the discussion
A sandbox confinement bypass vulnerability exists in Canonical snapd within its internal execution environment compiler (snap-confine).
0

A sandbox confinement bypass vulnerability exists in Canonical snapd within its internal execution environment compiler (snap-confine). The default seccomp security templates generated by the engine to restrict system calls do not filter or reject process operations capable of creating or manipulating file execution flags with set-user-ID attributes. Consequently, an application running within a strictly confined snap environment can successfully compile or drop binaries and apply setuid properties to them. If a compromised or malicious process inside the snap sandbox executes these generated setuid binaries, it can potentially circumvent architectural sandboxing assumptions, drop intended restriction policies, or execute privileged actions inside the container namespace that should otherwise be strictly blocked. The vulnerability has been resolved by hardening the seccomp template engine to block the execution and creation of setuid executables by sandboxed snap processes.

Join the discussion

Showing 1 to 10 of 2827 results

Filters:Severity: Null
Page 1 of 283
OffSeq TrainingCredly Certified

Lead Pen Test Professional

Technical5-day eLearningPECB Accredited
View courses