Vulnerability database
Every flaw the U.S. government’s cybersecurity agency (CISA) has confirmed attackers are using, plus the new WordPress plugin and theme bugs published each day, sorted by what they mean for a small business. We refresh it twice a day. If you see something your website or office runs, tell us.
2,213 results · page 11 of 45
Aug 15, 2026In the Linux kernel, the following vulnerability has been resolved: apparmor: fail policy unpack on accept2 allocation failure unpack_pdb() may need to allocaCVE-2026-72457 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: apparmor: fail policy unpack on accept2 allocation failure unpack_pdb() may need to allocate a missing ACCEPT2 table for older policy data. If that allocation failed, it set an error message but jumped to the success path, returning a policydb with the required table missing. Return -ENOMEM through the normal failure path when the ACCEPT2 allocation fails. Remove the now-unused out label.
- Product
- Linux
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgit.kernel.orggit.kernel.org
Aug 15, 2026In the Linux kernel, the following vulnerability has been resolved: bpf: Guard conntrack opts error writes The conntrack lookup and allocation kfuncs take an CVE-2026-72423 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 8.8
In the Linux kernel, the following vulnerability has been resolved: bpf: Guard conntrack opts error writes The conntrack lookup and allocation kfuncs take an opts pointer together with an opts__sz argument. The verifier checks only the memory range described by opts__sz, but the wrappers unconditionally write opts->error whenever the internal lookup or allocation helper returns an error. For an invalid size smaller than the end of opts->error, that write can land outside the verifier-checked range. Keep returning NULL for invalid arguments, but only report the error through opts->error when the supplied size includes the field. This preserves error reporting for the supported 12-byte and 16-byte layouts, and for other invalid sizes that still include opts->error.
- Product
- Linux
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgit.kernel.orggit.kernel.org
Aug 15, 2026In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix HV VHCA stats zero-sized buffer allocation mlx5e_hv_vhca_stats_create() is CVE-2026-72343 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 8.4
In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix HV VHCA stats zero-sized buffer allocation mlx5e_hv_vhca_stats_create() is called from mlx5e_nic_enable(), before mlx5e_open(). At that point priv->stats_nch is still zero, because it is only ever incremented in mlx5e_channel_stats_alloc(), which is reached only from mlx5e_open_channel(). mlx5e_hv_vhca_stats_buf_size() therefore returns 0, and kvzalloc(0, GFP_KERNEL) returns ZERO_SIZE_PTR ((void *)16) rather than NULL. The "if (!buf)" guard does not catch this, and mlx5e_hv_vhca_stats_create() completes "successfully" with priv->stats_agent.buf set to ZERO_SIZE_PTR. Once channels are opened (priv->stats_nch > 0) and the hypervisor enables stats reporting, mlx5e_hv_vhca_stats_work() recomputes buf_len using the new non-zero stats_nch and calls memset(buf, 0, buf_len) on ZERO_SIZE_PTR, faulting at address 0x10. Allocate the buffer based on priv->max_nch, which is set in mlx5e_priv_init() and is the upper bound on stats_nch: - Add a separate helper mlx5e_hv_vhca_stats_buf_max_size() that returns sizeof(per_ring_stats) * max(max_nch, stats_nch), and use it for the kvzalloc() in mlx5e_hv_v
- Product
- Linux
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgit.kernel.orggit.kernel.org
Aug 15, 2026In the Linux kernel, the following vulnerability has been resolved: tracing/remotes: Fix leak in trace_remote_alloc_buffer() error path If page allocation faiCVE-2026-72309 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: tracing/remotes: Fix leak in trace_remote_alloc_buffer() error path If page allocation fails in trace_remote_alloc_buffer(), desc->nr_cpus is not yet incremented for the current CPU. As a consequence, on error, half-allocated rb_desc will not be freed in trace_remote_free_buffer(). Increment desc->nr_cpus as soon as the first allocation for the current CPU has succeeded.
- Product
- Linux
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgit.kernel.orggit.kernel.org
Aug 15, 2026In the Linux kernel, the following vulnerability has been resolved: nvdimm/btt: Free arena sub-allocations on discover_arenas() error path Memory allocated byCVE-2026-72223 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: nvdimm/btt: Free arena sub-allocations on discover_arenas() error path Memory allocated by btt_freelist_init(), btt_rtt_init(), and btt_maplocks_init() is not freed on some discover_arenas() error paths. This leaks memory when arena discovery fails. Add the missing kfree() calls to release the allocations before returning an error. [ as: commit message and log edits ]
- Product
- Linux
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgit.kernel.orggit.kernel.org
Aug 15, 2026In the Linux kernel, the following vulnerability has been resolved: MIPS: DEC: Ensure 32-bit stack location for o32 prom_printf() In 64-bit configurations calCVE-2026-72215 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: MIPS: DEC: Ensure 32-bit stack location for o32 prom_printf() In 64-bit configurations calling any firmware entry points from a kernel thread other than the initial one will result in a situation where the stack has been placed in the XKPHYS 64-bit memory segment. Consequently the stack pointer is no longer a 32-bit value and when the 32-bit firmware code called uses 32-bit ALU operations to manipulate the stack pointer, the calculated result is incorrect (in fact in the 64-bit MIPS ISA almost all 32-bit ALU operations will produce an unpredictable result when executed on 64-bit data) and control goes astray. This may happen when no final console driver has been enabled in the configuration and consequently the initial console continues being used late into bootstrap, or with an upcoming change that will switch the zs driver to use a platform device, which in turn will make the console handover happen only after other kernel threads have already been started, and the kernel will hang at: pid_max: default: 32768 minimum: 301 or somewhat later, but always before: cblist_init_generic: Setting adjustable num
- Product
- Linux
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgit.kernel.orggit.kernel.org
Aug 15, 2026In the Linux kernel, the following vulnerability has been resolved: ntfs: avoid heap allocation for free-cluster readahead state get_nr_free_clusters() allocaCVE-2026-72202 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.5
In the Linux kernel, the following vulnerability has been resolved: ntfs: avoid heap allocation for free-cluster readahead state get_nr_free_clusters() allocates a temporary file_ra_state before it publishes the precomputed free cluster count, sets NVolFreeClusterKnown(), and wakes vol->free_waitq. If that allocation fails, the worker returns without setting the flag or waking waiters, so callers waiting for the free count can block indefinitely. The readahead state is only used synchronously while scanning the bitmap. Keep it on the stack and pass it by address to the readahead helper. This eliminates the early allocation failure path instead of adding a special case that publishes a conservative count and wakes the waitqueue. Zero-initialize the on-stack state because file_ra_state_init() only sets ra_pages and prev_pos. Apply the same treatment to __get_nr_free_mft_records(), which scans the MFT bitmap with the same short-lived readahead state.
- Product
- Linux
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgit.kernel.orggit.kernel.org
Aug 15, 2026In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: bound DeleteIndexEntryAllocation memmove length In do_action()'s DeleteIndexEntrCVE-2026-72197 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 8.4
In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: bound DeleteIndexEntryAllocation memmove length In do_action()'s DeleteIndexEntryAllocation case, e->size comes from an on-disk INDEX_BUFFER entry. When e->size makes e + e->size point past hdr + hdr->used, PtrOffset(e1, Add2Ptr(hdr, used)) returns a negative ptrdiff_t that is silently cast to a quasi-infinite size_t when passed to memmove(). The memmove then walks past the destination buffer. The sibling DeleteIndexEntryRoot case at fslog.c:3540-3543 already carries the corresponding guard: if (PtrOffset(e1, Add2Ptr(hdr, used)) < esize || Add2Ptr(e, esize) > Add2Ptr(lrh, rec_len) || used + esize > le32_to_cpu(hdr->total)) { goto dirty_vol; } Apply the same shape to the allocation-path case. Also reject esize == 0: memmove(e, e, ...) is a no-op and leaves hdr->used unchanged, hiding a malformed entry from the existing check_index_header() walk. Reproduced under UML+KASAN on mainline 8d90b09e6741 by mounting a crafted NTFS image: the unguarded memmove takes a length of 0xffffffffffffff00 and the kernel oopses in memmove+0x81/0x1a0 on the do_action+0x36a2 frame. [almaz.alexandrovich@
- Product
- Linux
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgit.kernel.orggit.kernel.org
Aug 15, 2026In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: pl353: fix probe resource allocation During probe(), the devm_ioremap() is cCVE-2026-72167 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: pl353: fix probe resource allocation During probe(), the devm_ioremap() is called with the parent device instead of the current one. So when the module is unloaded, the register area isn't released. Target the pl35x device in the devm_ioremap() instead of its parent.
- Product
- Linux
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgit.kernel.orggit.kernel.org
Aug 15, 2026In the Linux kernel, the following vulnerability has been resolved: can: bcm: defer rx_op deallocation to workqueue to fix thrtimer UAF Commit f1b4e32aca08 ("CVE-2026-72123 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8
In the Linux kernel, the following vulnerability has been resolved: can: bcm: defer rx_op deallocation to workqueue to fix thrtimer UAF Commit f1b4e32aca08 ("can: bcm: use call_rcu() instead of costly synchronize_rcu()") replaced synchronize_rcu() in bcm_delete_rx_op() with call_rcu() and introduced the RX_NO_AUTOTIMER flag. However, this flag check was omitted for thrtimer in the packet rx fast-path. During BCM RX operation teardown, a concurrent RCU reader (bcm_rx_handler) can race and re-arm thrtimer via bcm_rx_update_and_send() after call_rcu() has been scheduled. Once the RCU grace period elapses, bcm_op is freed. The subsequently firing thrtimer then dereferences the deallocated op, causing a UAF. Adding flag checks to the rx fast-path (bcm_rx_update_and_send) does not fully close the TOCTOU race and introduces latency for every CAN frame. Conversely, calling hrtimer_cancel() directly inside the RCU callback (softirq context) is fatal as hrtimer_cancel() can sleep, triggering a "scheduling while atomic" panic. Resolve this by deferring the timer cancellation and memory free to a dedicated unbound workqueue (bcm_wq). The RCU callback now queues a work item to bcm_wq, w
- Product
- Linux
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgit.kernel.orggit.kernel.org
Aug 15, 2026In the Linux kernel, the following vulnerability has been resolved: net: ixp4xx_hss: fix duplicate HDLC netdev allocation ixp4xx_hss_probe() allocates two HDLCVE-2026-72058 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: net: ixp4xx_hss: fix duplicate HDLC netdev allocation ixp4xx_hss_probe() allocates two HDLC netdevs. The first one is stored in ndev, initialized, and registered with register_hdlc_device(). The second one is stored in port->netdev and later used by the remove path for unregister_hdlc_device() and free_netdev(). This means that the registered netdev is not the same object that is unregistered and freed on remove. It also leaks the first allocation if the second alloc_hdlcdev() call fails, and the first allocation is not checked before ndev is used. Older code allocated the HDLC netdev only once and stored the same object in both the local variable and port->netdev. The buggy conversion split this into two alloc_hdlcdev() calls. A later rename changed the local variable name to ndev, but the underlying mismatch remained. Fix this by allocating the HDLC netdev only once and assigning the same object to port->netdev.
- Product
- Linux
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgit.kernel.orggit.kernel.org
Aug 15, 2026In the Linux kernel, the following vulnerability has been resolved: bnx2x: fix potential memory leak in bnx2x_alloc_mem_bp() If the allocation of fp[i].tpa_inCVE-2026-72039 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: bnx2x: fix potential memory leak in bnx2x_alloc_mem_bp() If the allocation of fp[i].tpa_info fails, the error path will not free the struct bnx2x_fastpath allocated earlier, as it is not linked to the bp structure yet. Fix that by linking it immediately after allocation.
- Product
- Linux
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgit.kernel.orggit.kernel.org
Aug 15, 2026In the Linux kernel, the following vulnerability has been resolved: ipvs: reload ip header after head reallocation __ip_vs_get_out_rt() calls skb_ensure_writaCVE-2026-68476 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67Critical 9.8
In the Linux kernel, the following vulnerability has been resolved: ipvs: reload ip header after head reallocation __ip_vs_get_out_rt() calls skb_ensure_writable() which may reallocate skb->head.
- Product
- Linux
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgit.kernel.orggit.kernel.org
Aug 14, 2026IBM Db2 Mirror for i 7.4, 7.5, and 7.6 could allow a remote attacker to write files to arbitrary locations due to path traversal.CVE-2026-17181 · Other software · IBM · reported by psirt@us.ibm.comCritical 9.3
IBM Db2 Mirror for i 7.4, 7.5, and 7.6 could allow a remote attacker to write files to arbitrary locations due to path traversal.
- Product
- Db2 Mirror for i
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Aug 13, 2026Allocation of Resources Without Limits or Throttling (CWE-770) in Kibana can lead to a denial of service via Excessive Allocation (CAPEC-130).CVE-2026-72674 · Other software · Elastic · reported by security@elastic.coMedium 6.5
Allocation of Resources Without Limits or Throttling (CWE-770) in Kibana can lead to a denial of service via Excessive Allocation (CAPEC-130). A user-supplied list of document fields accepted by the Kibana Playground for RAG feature was neither bounded in length nor de-duplicated before it was used to assemble the response for each matching document. A single crafted request could therefore make Kibana build a response far larger than the data it was derived from, and the resulting processing and memory pressure exhausts the resources of the Kibana instance.
- Product
- Kibana
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Aug 13, 2026Incorrect Authorization (CWE-863) in Kibana can lead to unauthorized deletion of Synthetics private locations via Accessing Functionality Not Properly ConstrainCVE-2026-72673 · Other software · Elastic · reported by security@elastic.coMedium 5.4
Incorrect Authorization (CWE-863) in Kibana can lead to unauthorized deletion of Synthetics private locations via Accessing Functionality Not Properly Constrained by ACLs (CAPEC-1). Synthetics private locations can be shared with more than one space, and deleting one removes it from every space it is shared with. The safeguard that prevented the deletion of a private location still in use evaluated only the monitors visible in the requesting user's own space, so monitors that depend on the private location in other spaces were not taken into account. As a result, an authenticated Kibana user holding the Synthetics write privilege in a single space could delete a private location that other spaces still depend on, even where the user has no access to those spaces. Deleting the private location removes the shared configuration and stops the monitors in the other spaces from running, which suppresses the availability monitoring those spaces rely on.
- Product
- Kibana
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Aug 13, 2026Allocation of Resources Without Limits or Throttling (CWE-770) in Kibana can lead to a denial of service via Excessive Allocation (CAPEC-130).CVE-2026-72667 · Other software · Elastic · reported by security@elastic.coMedium 6.5
Allocation of Resources Without Limits or Throttling (CWE-770) in Kibana can lead to a denial of service via Excessive Allocation (CAPEC-130). A specially crafted request submitted by an authenticated user with minimal privileges to a validation capability of the Observability log analysis feature causes Kibana to perform an unbounded amount of concurrent work. This can exhaust the memory available to the Kibana process and make Kibana unavailable to all users until it is restarted. The severity of the outcome depends on the resources allocated to the deployment; on well-provisioned deployments a single request may cause degraded performance and elevated memory pressure rather than a full outage, but the request is inexpensive to repeat.
- Product
- Kibana
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Aug 13, 2026Allocation of Resources Without Limits or Throttling (CWE-770) in Kibana can lead to denial of service via Excessive Allocation (CAPEC-130).CVE-2026-72659 · Other software · Elastic · reported by security@elastic.coMedium 6.5
Allocation of Resources Without Limits or Throttling (CWE-770) in Kibana can lead to denial of service via Excessive Allocation (CAPEC-130). A specially crafted, malformed payload submitted to a Kibana visualization feature by an authenticated user holding only low-privileged access is not correctly validated before use. Processing the request causes unbounded memory growth in the Kibana process, which is terminated by the host once available memory is exhausted. Kibana then becomes unavailable to all users until the service is restarted.
- Product
- Kibana
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Aug 13, 2026Memory Allocation with Excessive Size Value (CWE-789) in the ES|QL query processing of Elasticsearch can lead to denial of service via Excessive Allocation (CAPCVE-2026-72656 · Other software · Elastic · reported by security@elastic.coMedium 6.5
Memory Allocation with Excessive Size Value (CWE-789) in the ES|QL query processing of Elasticsearch can lead to denial of service via Excessive Allocation (CAPEC-130). An authenticated user able to submit ES|QL queries could send a specially crafted query whose evaluation allocates an unbounded amount of heap memory, exhausting the available heap on the receiving node and causing the node to become unavailable.
- Product
- Elasticsearch
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Aug 13, 2026Allocation of Resources Without Limits or Throttling (CWE-770) in Kibana can lead to denial of service via Excessive Allocation (CAPEC-130).CVE-2026-72653 · Other software · Elastic · reported by security@elastic.coMedium 6.5
Allocation of Resources Without Limits or Throttling (CWE-770) in Kibana can lead to denial of service via Excessive Allocation (CAPEC-130). An authenticated user who is authorized to manage maintenance windows could submit a specially crafted, malformed payload that causes the Kibana process to consume excessive resources. Kibana becomes unresponsive for all users and does not recover without manual intervention.
- Product
- Kibana
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Aug 13, 2026Allocation of Resources Without Limits or Throttling (CWE-770) in Kibana can lead to denial of service via Excessive Allocation (CAPEC-130).CVE-2026-72651 · Other software · Elastic · reported by security@elastic.coMedium 6.5
Allocation of Resources Without Limits or Throttling (CWE-770) in Kibana can lead to denial of service via Excessive Allocation (CAPEC-130). An authenticated user with read-only privileges to the alerting feature could submit a specially crafted, malformed payload that causes the Kibana process to consume excessive resources. A single request is sufficient to leave Kibana unable to serve requests for all users until the process is restarted.
- Product
- Kibana
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Aug 13, 2026Memory Allocation with Excessive Size Value (CWE-789) in Elasticsearch can lead to denial of service via Excessive Allocation (CAPEC-130).CVE-2026-72645 · Other software · Elastic · reported by security@elastic.coMedium 6.5
Memory Allocation with Excessive Size Value (CWE-789) in Elasticsearch can lead to denial of service via Excessive Allocation (CAPEC-130). An authenticated user holding only read privileges on a single index can submit one small, specially crafted search request that causes an excessively large memory allocation, exhausting the JVM heap and terminating the affected node.
- Product
- Elasticsearch
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Aug 13, 2026Elasticsearch does not enforce an upper bound on a user-supplied count accepted by a search highlighting option, and the allocation derived from that count is nCVE-2026-72639 · Other software · Elastic · reported by security@elastic.coMedium 6.5
Elasticsearch does not enforce an upper bound on a user-supplied count accepted by a search highlighting option, and the allocation derived from that count is not accounted against any circuit breaker. An authenticated user holding only read privileges on a single searchable index can submit one small search request that causes the node to reserve an excessively large internal data structure. The allocation occurs before the existing highlighting safety limits are evaluated, so memory exhaustion raises a fatal error that terminates the Elasticsearch node process. This results in a denial of service for the affected node and degrades cluster routing and health. The defect is not volumetric and does not depend on the size of the indexed data, so a single request is sufficient.
- Product
- Elasticsearch
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Aug 13, 2026Uncontrolled Recursion (CWE-674) in the Elasticsearch wildcard matching helper can lead to a denial of service via Excessive Allocation (CAPEC-130).CVE-2026-72636 · Other software · Elastic · reported by security@elastic.coMedium 6.5
Uncontrolled Recursion (CWE-674) in the Elasticsearch wildcard matching helper can lead to a denial of service via Excessive Allocation (CAPEC-130). The matcher used to resolve wildcard patterns against names is implemented recursively and had no bound on recursion depth or on the total number of match operations performed. A search request containing a wildcard pattern with a large number of wildcard groups, evaluated against a sufficiently long name, exhausts the thread stack. Elasticsearch treats a stack overflow as an unrecoverable condition and shuts the node down, so the request terminates the affected node rather than failing gracefully.
- Product
- Elasticsearch
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Aug 13, 2026Allocation of Resources Without Limits or Throttling (CWE-770) in Kibana can lead to denial of service via Excessive Allocation (CAPEC-130).CVE-2026-49089 · Other software · Elastic · reported by security@elastic.coMedium 6.5
Allocation of Resources Without Limits or Throttling (CWE-770) in Kibana can lead to denial of service via Excessive Allocation (CAPEC-130). A query expression accepted by a connector reporting operation was processed without any limit on its size, and an oversized expression caused the Kibana process to spend an unbounded amount of time evaluating it. An authenticated user with read-only privileges was able to send a single request that left Kibana unable to serve any user until the process was restarted.
- Product
- Kibana
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Aug 13, 2026IBM i 7.6, 7.5, 7.4, and 7.3 could allow a remote attacker to cause a denial of service due to unbounded resource allocation.CVE-2026-17199 · Other software · IBM · reported by psirt@us.ibm.comHigh 7.5
IBM i 7.6, 7.5, 7.4, and 7.3 could allow a remote attacker to cause a denial of service due to unbounded resource allocation.
- Product
- i
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Aug 13, 2026rsync before 3.5.0 contains a logic error in --max-alloc handling that allows a sender or configuration setting --max-alloc=0 to disable allocation sanity checkCVE-2026-53794 · Other software · RsyncProject · reported by VulnCheckMedium 6.9
rsync before 3.5.0 contains a logic error in --max-alloc handling that allows a sender or configuration setting --max-alloc=0 to disable allocation sanity checks entirely rather than enforcing a zero-byte cap. Attackers can exploit this flaw to cause the receiver to attempt unbounded memory allocations for file list and data structures, potentially exhausting available memory and causing a denial of service.
- Product
- rsync
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Aug 13, 2026Buffer over-read in PostgreSQL ascii() SQL function allows a user to disclose up to 3 bytes after the end of a specific allocation, via a crafted text value.CVE-2026-18024 · Other software · Postgresql · reported by f86ef6dc-4d3a-42ad-8f28-e6d5547a5007Medium 4.3
Buffer over-read in PostgreSQL ascii() SQL function allows a user to disclose up to 3 bytes after the end of a specific allocation, via a crafted text value. This is the same class of defect that CVE-2026-2006 fixed, though this instance has less impact. Versions before PostgreSQL 18.6, 17.11, 16.15, 15.19, and 14.24 are affected.
- Product
- Postgresql
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Aug 13, 2026Integer wraparound in PostgreSQL 32-bit builds of pltcl and plperl allows an object creator to cause the server to undersize an allocation and write out-of-bounCVE-2026-14677 · Other software · Postgresql · reported by f86ef6dc-4d3a-42ad-8f28-e6d5547a5007High 8.8
Integer wraparound in PostgreSQL 32-bit builds of pltcl and plperl allows an object creator to cause the server to undersize an allocation and write out-of-bounds via crafted function bodies. This may execute arbitrary code as the operating system user running the database. CVE-2026-6473 had fixed similar problems. Versions before PostgreSQL 18.6, 17.11, 16.15, 15.19, and 14.24 are affected.
- Product
- Postgresql
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Aug 13, 2026Integer wraparound in PostgreSQL tsvector and tsquery data type functions allows an unprivileged database user to cause the server to undersize an allocation anCVE-2026-14662 · Other software · Postgresql · reported by f86ef6dc-4d3a-42ad-8f28-e6d5547a5007High 8.8
Integer wraparound in PostgreSQL tsvector and tsquery data type functions allows an unprivileged database user to cause the server to undersize an allocation and write out-of-bounds, via crafted large inputs. This may execute arbitrary code as the operating system user running the database. These types are typically sourced from application logic, not taken from the application's user. Hence, application users attacking the database, through the application as a conduit, are unlikely. CVE-2026-6473 had fixed similar problems. Versions before PostgreSQL 18.6, 17.11, 16.15, 15.19, and 14.24 are affected.
- Product
- Postgresql
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Aug 12, 2026In WhatsUp Gold versions released before 2026.0.2, a privileged attacker can write arbitrary files to a web-accessible location on the host server.CVE-2026-65940 · Other software · Progress Software Corporation · reported by security@progress.comMedium 6.8
In WhatsUp Gold versions released before 2026.0.2, a privileged attacker can write arbitrary files to a web-accessible location on the host server.
- Product
- WhatsUp Gold
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordcommunity.progress.comdocs.progress.com
Aug 12, 2026A allocation of resources without limits or throttling vulnerability in Fortinet FortiOS 7.6.0 through 7.6.6, FortiOS 7.4 all versions, FortiOS 7.2 all versionsCVE-2026-71408 · Network & remote access · Fortinet · reported by psirt@fortinet.comMedium 5.3
A allocation of resources without limits or throttling vulnerability in Fortinet FortiOS 7.6.0 through 7.6.6, FortiOS 7.4 all versions, FortiOS 7.2 all versions, FortiOS 7.0 all versions, FortiOS 6.4 all versions may allow an unauthenticated attacker to perform a slow HTTP DoS attack on the web interface via crafted HTTP requests.
- Product
- FortiOS
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordfortiguard.fortinet.comcert-portal.siemens.com
Aug 12, 2026Cookie Consent: Does not correctly enforce its intended administrator-only capability check on the REST route that stores its geolocation service license keyCVE-2026-18046 · WordPress plugins & themes · reported by WPScanMedium 4.3
The Cookie Consent WordPress plugin before 0.0.10 does not correctly enforce its intended administrator-only capability check on the REST route that stores its geolocation service license key, so the route falls back to an authentication-only gate, allowing any authenticated user such as a subscriber to overwrite the stored key and disrupt the Cookie Consent WordPress plugin before 0.0.10's geolocation-based consent banner targeting.
- Product
- Cookie Consent
- Fixed in
- 0.0.10
- What to do
- Update Cookie Consent to 0.0.10 or newer.
Aug 12, 2026The Linkable Loadable Extensions (llext) subsystem mis-handles PLT/RELA relocation entries when linking a relocatable (partially-linked) ELF extension.CVE-2026-12235 · Other software · zephyrproject · reported by vulnerabilities@zephyrproject.orgMedium 6.3
The Linkable Loadable Extensions (llext) subsystem mis-handles PLT/RELA relocation entries when linking a relocatable (partially-linked) ELF extension. In llext_link_plt() (subsys/llext/llext_link.c), the relocatable branch (tgt != NULL, the path used for Xtensa relocatable objects) computed the patch address as ext->mem[LLEXT_MEM_TEXT] - text.sh_offset + rela.r_offset + tgt->sh_offset and then performed the relocation write there without validating rela.r_offset. Its sibling shared/dynamic branch already rejected out-of-range offsets via llext_file_offset(). rela.r_offset is read directly from the ELF's RELA table, so a crafted entry with an offset larger than the target section makes the write land arbitrarily far outside the extension's text buffer. The result is an attacker-influenced out-of-bounds write (the location via r_offset, the written value being the resolved symbol address) performed in supervisor context at link time, before any extension code runs. The path is reached from llext_load() whenever an application loads an attacker-influenced ELF extension on Xtensa with writable storage; llext is documented to accept extensions of untrusted origin. Impact is superviso
- Product
- zephyr
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Aug 11, 2026Uncontrolled Resource Consumption vulnerability in Samsung Open Source rlottie allows Excessive Allocation.CVE-2026-19587 · Computers, phones & browsers · Samsung Open Source · reported by PSIRT@samsung.comMedium 6.5
Uncontrolled Resource Consumption vulnerability in Samsung Open Source rlottie allows Excessive Allocation.
- Product
- rlottie
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Aug 11, 2026DB-GPT v0.8.1 contains an unauthenticated path traversal vulnerability that allows remote attackers to write arbitrary files to any location on the server by inCVE-2026-73034 · Other software · eosphoros-ai · reported by VulnCheckCritical 9.3
DB-GPT v0.8.1 contains an unauthenticated path traversal vulnerability that allows remote attackers to write arbitrary files to any location on the server by injecting directory traversal sequences into the user_id HTTP header of the Python file-upload endpoint. Attackers can send a crafted multipart upload request with a traversal-poisoned user_id header to escape the intended upload directory and write attacker-controlled content to locations such as Python startup hooks, cron directories, or agent scripts, resulting in remote code execution.
- Product
- DB-GPT
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Aug 11, 2026Allocation of resources without limits or throttling in Windows Kernel allows an unauthorized attacker to deny service over a network.CVE-2026-54113 · Computers, phones & browsers · Microsoft · reported by secure@microsoft.comHigh 7.5
Allocation of resources without limits or throttling in Windows Kernel allows an unauthorized attacker to deny service over a network.
- Product
- Windows 10 Version 1607
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Aug 11, 2026Improper Validation of Specified Quantity in Input and Allocation of Resources Without Limits or Throttling vulnerability in Samsung Open Source rlottie allows CVE-2026-19517 · Computers, phones & browsers · Samsung Open Source · reported by PSIRT@samsung.comMedium 6.5
Improper Validation of Specified Quantity in Input and Allocation of Resources Without Limits or Throttling vulnerability in Samsung Open Source rlottie allows Excessive Allocation.
- Product
- rlottie
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Aug 10, 2026In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Fix IRQ unsafe locking in gdom allocation Lockdep complains: [ 259.410489] CVE-2026-68347 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Fix IRQ unsafe locking in gdom allocation Lockdep complains: [ 259.410489] ===================================================== [ 259.417287] WARNING: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected [ 259.424667] 7.0.0-g51db1d8d2113 #54 Not tainted [ 259.429718] ----------------------------------------------------- [ 259.436516] qemu-system-x86/10143 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire: [ 259.444670] ff3b2b1c60305170 (&xa->xa_lock#25){+.+.}-{3:3}, at: __domain_flush_pages+0x17c/0x4b0 [ 259.454485] and this task is already holding: [ 259.460991] ff3b2b1c98504cc0 (&domain->lock){-.-.}-{3:3}, at: amd_iommu_iotlb_sync+0x25/0x60 [ 259.470408] which would create a new lock dependency: [ 259.476041] (&domain->lock){-.-.}-{3:3} -> (&xa->xa_lock#25){+.+.}-{3:3} [ 259.483615] but this new dependency connects a HARDIRQ-irq-safe lock: [ 259.492447] (&domain->lock){-.-.}-{3:3} [ 259.492449] ... which became HARDIRQ-irq-safe at: [ 259.503705] lock_acquire+0xb6/0x2e0 [ 259.507790] _raw_spin_lock_irqsave
- Product
- Linux
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgit.kernel.orggit.kernel.org
Aug 10, 2026In the Linux kernel, the following vulnerability has been resolved: nfp: Check resource mutex allocation nfp_cpp_resource_find() allocates a CPP mutex handle CVE-2026-68328 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: nfp: Check resource mutex allocation nfp_cpp_resource_find() allocates a CPP mutex handle for the matching resource-table entry and then reports success. nfp_resource_try_acquire() immediately passes that handle to nfp_cpp_mutex_trylock(). However, nfp_cpp_mutex_alloc() returns NULL on failure. If that happens for a matching table entry, the resource lookup still returns success and the following trylock dereferences a NULL mutex pointer while opening the resource. nfp_resource_acquire() already treats failure to allocate the table mutex as -ENOMEM. Do the same for the resource mutex and fail the lookup before publishing the rest of the resource handle. This issue was found by a static analysis checker and confirmed by manual source review.
- Product
- Linux
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgit.kernel.orggit.kernel.org
Aug 10, 2026In the Linux kernel, the following vulnerability has been resolved: ice: prevent tstamp ring allocation for non-PF VSI types The pf->txtime_txqs bitmap tracksCVE-2026-68292 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: ice: prevent tstamp ring allocation for non-PF VSI types The pf->txtime_txqs bitmap tracks which Tx queues have ETF (Earliest TxTime First) offload enabled. This bitmap is indexed by queue number and is set by ice_offload_txtime(), which only operates on PF VSI queues. However, ice_is_txtime_ena() does not check the VSI type before consulting the bitmap. When ETF offload is enabled on PF Tx queue 0, bit 0 is set in pf->txtime_txqs. During a subsequent PCI reset rebuild, the CTRL VSI's Tx queue 0 is reconfigured and ice_is_txtime_ena() is called for that ring. Since it only checks pf->txtime_txqs by queue index without distinguishing VSI type, it finds bit 0 set and returns true, matching the PF VSI's ETF queue, not the CTRL VSI's. This causes ice_vsi_cfg_txq() to spuriously allocate a tstamp_ring for the CTRL VSI ring. Since CTRL VSI rings have no associated netdev, ice_clean_tx_ring() takes an early return at the !netdev check before reaching ice_free_tx_tstamp_ring(), leaking the allocation. Each PCI reset leaks one 64-byte tstamp_ring. Fix this by restricting ice_is_txtime_ena() to return true only for PF V
- Product
- Linux
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgit.kernel.orggit.kernel.org
Aug 10, 2026In the Linux kernel, the following vulnerability has been resolved: idpf: fix max_vport related crash on allocation error during init Set adapter->max_vports CVE-2026-68291 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: idpf: fix max_vport related crash on allocation error during init Set adapter->max_vports only after successful allocation of vports, netdevs and vport_config buffers. This fixes possible crashes on reset or rmmod, following failed allocation on init [ 305.981402] idpf 0000:83:00.0: enabling device (0100 -> 0102) [ 305.994464] idpf 0000:83:00.0: Device HW Reset initiated [ 320.416872] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 320.416918] #PF: supervisor read access in kernel mode [ 320.416942] #PF: error_code(0x0000) - not-present page [ 320.416963] PGD 2099657067 P4D 0 [ 320.416983] Oops: Oops: 0000 [#1] SMP NOPTI ... [ 320.417093] RIP: 0010:idpf_remove+0x118/0x200 [idpf] [ 320.417130] Code: 8b bb 98 09 00 00 e8 17 0f 5b e5 48 8b bb e8 08 00 00 e8 0b 0f 5b e5 66 83 bb 28 06 00 00 00 48 8b bb 20 06 00 00 74 49 31 ed <48> 8b 04 ef 48 85 c0 74 2f 48 8b 78 20 e8 66 58 91 e5 48 8b 83 20 [ 320.417183] RSP: 0018:ff7322212903fdb8 EFLAGS: 00010246 [ 320.417205] RAX: 0000000000000000 RBX: ff4463de40300000 RCX: ff7322212903fd4c [ 320.417228] RDX: 0000000000000001 RSI: ffffffffa7f7d100
- Product
- Linux
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgit.kernel.orggit.kernel.org
Aug 10, 2026In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc: Fix buffer overflow in steered register list allocation The size calculation fCVE-2026-68274 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8
In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc: Fix buffer overflow in steered register list allocation The size calculation for the steered register extarray uses only the geometry DSS mask (g_dss_mask) to determine the number of entries to allocate: total = bitmap_weight(gt->fuse_topo.g_dss_mask, ...) * steer_reg_num; However, the filling loop uses for_each_dss_steering(), which iterates over for_each_dss(), defined as the union of g_dss_mask and c_dss_mask (geometry + compute DSS). On platforms with compute-only DSS bits, the loop writes past the allocated buffer, corrupting adjacent slab objects. This manifests as list_del corruption and SLUB redzone overwrites during drm_managed_release on device unbind, since the overflow corrupts the drmres list_head of neighboring allocations. Fix by computing the allocation size using the union of both DSS masks, matching the iteration pattern of for_each_dss_steering(). -- v2: - use bitmap_weighted_or() (Zhanjun) (cherry picked from commit 0a78a44f4901aa6c9263e66be7fce02282f1109f)
- Product
- Linux
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgit.kernel.orggit.kernel.org
Aug 10, 2026In the Linux kernel, the following vulnerability has been resolved: fscrypt: Avoid dynamic allocation in fscrypt_get_devices() When a blk_crypto_key starts beCVE-2026-68147 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8
In the Linux kernel, the following vulnerability has been resolved: fscrypt: Avoid dynamic allocation in fscrypt_get_devices() When a blk_crypto_key starts being used or is evicted, fs/crypto/ calls fscrypt_get_devices() to get the filesystem's list of block devices, then iterates over them and calls blk_crypto_config_supported(), blk_crypto_start_using_key(), or blk_crypto_evict_key() on each one. Currently, the block device pointers are placed in a dynamically allocated array. This dynamic allocation is problematic because: - It can fail, especially at the fscrypt_destroy_inline_crypt_key() call site when it's invoked for inode eviction under direct reclaim. - fscrypt_destroy_inline_crypt_key() doesn't handle the failure. It just zeroizes and frees the blk_crypto_key without calling blk_crypto_evict_key(). That causes a use-after-free. For now, let's fix this in the straightforward and easily-backportable way by switching to an on-stack array. Currently the fscrypt multi-device functionality is used only by f2fs, which has a hardcoded limit of 8 block devices. An on-stack array works fine for that. (Of course, this solution won't scale up to large number of bloc
- Product
- Linux
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgit.kernel.orggit.kernel.org
Aug 10, 2026In the Linux kernel, the following vulnerability has been resolved: net: slip: serialize receive against buffer reallocation sl_realloc_bufs() replaces rbuff CVE-2026-68143 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67High 7.8
In the Linux kernel, the following vulnerability has been resolved: net: slip: serialize receive against buffer reallocation sl_realloc_bufs() replaces rbuff and updates buffsize while holding sl->lock. slip_receive_buf() reads those fields and writes through rbuff without holding the lock. An MTU change can therefore race with receive processing. An MTU shrink can expose the new smaller rbuff with the old larger bound, causing an out-of-bounds write. A receive callback which already loaded the old rbuff can instead continue writing after that buffer has been freed. Serialize receive processing with sl_realloc_bufs() by holding sl->lock while consuming each receive batch.
- Product
- Linux
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgit.kernel.orggit.kernel.org
Aug 10, 2026In the Linux kernel, the following vulnerability has been resolved: staging: vme_user: fix location monitor leak in tsi148 bridge tsi148_probe() allocates a lCVE-2026-68084 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: staging: vme_user: fix location monitor leak in tsi148 bridge tsi148_probe() allocates a location monitor resource and links it into tsi148_bridge->lm_resources. The probe error path frees this list, but tsi148_remove() only frees the dma, slave and master resource lists, so the location monitor resource is leaked on device unbind or module unload. Free the lm_resources list in tsi148_remove() as well, before tsi148_bridge is freed.
- Product
- Linux
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordgit.kernel.orggit.kernel.org
Aug 10, 2026GNU cpio is vulnerable to an uncontrolled memory allocation in the make_path function at src/makepath.c.CVE-2026-66485 · Other software · GNU · reported by cvd@cert.plMedium 4.6
GNU cpio is vulnerable to an uncontrolled memory allocation in the make_path function at src/makepath.c. The function uses alloca to allocate stack memory based on the length of argpath, which is derived from an archive-controlled pathname during extraction. A malicious cpio archive containing a sufficiently long nested pathname causes an unbounded stack allocation, resulting in a stack overflow and crash of the cpio process. An attacker who can supply a crafted cpio archive to a victim who extracts it can cause a denial of service. This issue has been fixed in commit 3cd514031371d8aeeaf2048aa10103e02831aaa9
- Product
- cpio
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordcert.plgit.savannah.gnu.org
Aug 7, 2026Injection of false emergency or status messages over CPDLC may lead to misallocation of resources, operational confusion, and improper response actions by flighCVE-2025-71412 · Other software · ATN-B1 · reported by ics-cert@hq.dhs.govHigh 7.1
Injection of false emergency or status messages over CPDLC may lead to misallocation of resources, operational confusion, and improper response actions by flight crews, traffic controllers, and ground operations. This type of attack can be carried out remotely over radio frequency.
- Product
- CPDLC
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Aug 7, 2026Allocation of Resources Without Limits or Throttling vulnerability in DivvyPayHQ absinthe_federation allows an unauthenticated remote attacker to abort the ErlaCVE-2026-67585 · Other software · DivvyPayHQ · reported by 6b3ad84c-e1a6-4bf7-a703-f496b71e49dbHigh 8.7
Allocation of Resources Without Limits or Throttling vulnerability in DivvyPayHQ absinthe_federation allows an unauthenticated remote attacker to abort the Erlang VM via crafted _entities representation keys. Every key of every object in the representations argument of the federation-mandated _entities field is converted with String.to_atom/1 by convert_key/2 in lib/absinthe/federation/schema/entities_field.ex. representations is typed as the open-ended _Any scalar, so its keys bypass schema coercion and the attacker names them freely. Atoms are never garbage collected and the BEAM atom table is hard-capped (about 1,048,576 entries by default), so one request carrying tens of thousands of unique keys creates that many permanent atoms and a handful of such requests exhausts the table and aborts the node. The impact is confined to availability: no data is read or altered, and recovery requires restarting the application. This issue affects absinthe_federation: from 0.1.0 before 0.9.3.
- Product
- absinthe_federation
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordcna.erlef.orggithub.com
Aug 7, 2026Tobit Laboratories AG TeamDavid's Webbox 's move archive functionality (“!ArcEntryMove”) accepts an arbitrary path, which can be set to network locations usingCVE-2026-54207 · Other software · Tobit Laboratories AG · reported by vulnerability@ncsc.chMedium 6.3
Tobit Laboratories AG TeamDavid's Webbox 's move archive functionality (“!ArcEntryMove”) accepts an arbitrary path, which can be set to network locations using UNC paths (e.g., “\\Server\Share”). The server processes these paths without validation, resulting in outbound connection attempts to attacker-controlled SMB servers. This enables au-thenticated attackers to trigger the server to authenticate to arbitrary SMB endpoints, potentially exposing NTLM authentication information (such as NTLM hashes). If outbound connections to port 445 (SMB) are permitted, attackers can use this to conduct SMB relay or credential theft attacks. Exploitation of the “pathname” parameter is possible without authentication. This issue affects TeamDavid before Rollout 528. Starting with Rollout 528 (June 30, 2026), the affected functionality is disabled by default and the vulnerabilities are therefore no longer exposed through this functionality.
- Product
- TeamDavid
- What to do
- Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD recordchayns.netlabs.infoguard.ch
Where this comes from: the exploited list is CISA’s Known Exploited Vulnerabilities catalog. Everything else is the whole National Vulnerability Database, where each record is published by the team that found the bug (Wordfence, Patchstack, WPScan, the vendors themselves and others); we show who. Exploit odds are FIRST’s EPSS, updated daily. Titles and categories are ours, so check the linked record before acting on a detail. For a write-up of the big ones, see our advisories. Every vendor, and every WordPress plugin and theme with a recorded flaw, also has its own page. All of it is free to reuse as JSON, CSV or RSS.
Weekly security brief
The flaws that hit local websites, every Friday.
One short email: what got exploited this week, which WordPress plugins broke, and what to check. Unsubscribe in one click.
Tell us what you're building.
A website, your marketing, a security check, an app, or the thing you've been running out of a spreadsheet for three years. A few lines is plenty.
Not ready to talk yet? Run the free website check and see what Google sees.