Vulnerabilities

With the aim of informing, warning and helping professionals with the latest security vulnerabilities in technology systems, we have made a database available for users interested in this information, which is in Spanish and includes all of the latest documented and recognised vulnerabilities.

This repository, with over 75,000 registers, is based on the information from the NVD (National Vulnerability Database) – by virtue of a partnership agreement – through which INCIBE translates the included information into Spanish.

On occasions this list will show vulnerabilities that have still not been translated, as they are added while the INCIBE team is still carrying out the translation process. The CVE (Common Vulnerabilities and Exposures) Standard for Information Security Vulnerability Names is used with the aim to support the exchange of information between different tools and databases.

All vulnerabilities collected are linked to different information sources, as well as available patches or solutions provided by manufacturers and developers. It is possible to carry out advanced searches, as there is the option to select different criteria to narrow down the results, some examples being vulnerability types, manufacturers and impact levels, among others.

Through RSS feeds or Newsletters we can be informed daily about the latest vulnerabilities added to the repository. Below there is a list, updated daily, where you can discover the latest vulnerabilities.

CVE-2026-46604

Publication date:

26/06/2026

The TIFF decoder can panic when decoding an invalid image with an out-of-bounds strip offset.

Severity CVSS v4.0: Pending analysis

Last modification:

01/07/2026

CVE-2024-23581

Publication date:

26/06/2026

The HCL Traveler for Microsoft Outlook libraries are being flagged as potentially malicious software or an unrecognized application.

Severity CVSS v4.0: Pending analysis

Last modification:

06/07/2026

CVE-2026-55188

Publication date:

26/06/2026

RustFS is a distributed object storage system built in Rust. From 1.0.0-alpha.1 until 1.0.0-beta.9, RustFS contains an authorization bypass in the bucket replication admin API. The ListRemoteTargetHandler handler for listing remote replication targets only checks whether request credentials exist, but does not verify that the caller has replication or administrator permissions. As a result, an authenticated user with no effective bucket or admin permissions can list remote replication target configuration for a bucket. Because the returned BucketTarget objects include remote target credentials, this can disclose replication access keys and secret keys. This vulnerability is fixed in 1.0.0-beta.9.

Severity CVSS v4.0: Pending analysis

Last modification:

27/06/2026

CVE-2026-55838

Publication date:

26/06/2026

RustFS is a distributed object storage system built in Rust. In 1.0.0-beta.7 and earlier, the real-time metrics endpoint at /rustfs/admin/v3/metrics is accessible to any valid IAM user regardless of their assigned policy. Every other admin handler in the codebase calls validate_admin_request to enforce admin-action IAM checks; the MetricsHandler skips this call entirely. A restricted IAM user whose policy grants only access to their own bucket can read server-wide operational metrics including disk I/O statistics, network throughput, scanner cycle timing, and cluster RPC state.

Severity CVSS v4.0: Pending analysis

Last modification:

27/06/2026

CVE-2026-55189

Publication date:

26/06/2026

RustFS is a distributed object storage system built in Rust. From 1.0.0-alpha.1 until 1.0.0-beta.9, when the FTP frontend is enabled, the FTP read and probe handlers dispatch directly to the storage backend without ever calling the IAM authorization function that the FTP write/list handlers (and the entire HTTP S3 path) use. As a result, any user who can authenticate to the FTP listener — including a user whose IAM policy contains an explicit Deny on s3:GetObject — can read (RETR) and stat (SIZE/MDTM) any object in any bucket, and probe any bucket (CWD), completely regardless of their IAM policy. This vulnerability is fixed in 1.0.0-beta.9.

Severity CVSS v4.0: Pending analysis

Last modification:

29/06/2026

CVE-2026-53324

Publication date:

26/06/2026

In the Linux kernel, the following vulnerability has been resolved: net: mana: Use pci_name() for debugfs directory naming Use pci_name(pdev) for the per-device debugfs directory instead of hardcoded "0" for PFs and pci_slot_name(pdev->slot) for VFs. The previous approach had two issues: 1. pci_slot_name() dereferences pdev->slot, which can be NULL for VFs in environments like generic VFIO passthrough or nested KVM, causing a NULL pointer dereference. 2. Multiple PFs would all use "0", and VFs across different PCI domains or buses could share the same slot name, leading to -EEXIST errors from debugfs_create_dir(). pci_name(pdev) returns the unique BDF address, is always valid, and is unique across the system.

Severity CVSS v4.0: Pending analysis

Last modification:

06/07/2026

CVE-2026-53323

Publication date:

26/06/2026

In the Linux kernel, the following vulnerability has been resolved: net: dsa: remove redundant netdev_lock_ops() from conduit ethtool ops DSA replaces the conduit (master) device&#39;s ethtool_ops with its own wrappers that aggregate stats from both the conduit and DSA switch ports. Taking the lock again inside the DSA wrappers causes a deadlock. Stumbled upon this when booting qemu with fbnic and CONFIG_NET_DSA_LOOP=y (which looks like some kind of testing device that auto-populates the ports of eth0). `ethtool -i` is enough to deadlock. This means we have basically zero coverage for DSA stuff with real ops locked devs. Remove the redundant netdev_lock_ops()/netdev_unlock_ops() calls from the DSA conduit ethtool wrappers.

Severity CVSS v4.0: Pending analysis

Last modification:

06/07/2026

CVE-2026-53322

Publication date:

26/06/2026

In the Linux kernel, the following vulnerability has been resolved: vfio/pci: Clean up DMABUFs before disabling function On device shutdown, make vfio_pci_core_close_device() call vfio_pci_dma_buf_cleanup() before the function is disabled via vfio_pci_core_disable(). This ensures that all access via DMABUFs is revoked before the function&#39;s BARs become inaccessible. This fixes an issue where, if the function is disabled first, a tiny window exists in which the function&#39;s MSE is cleared and yet BARs could still be accessed via the DMABUF. The resources would also be freed and up for grabs by a different driver.

Severity CVSS v4.0: Pending analysis

Last modification:

06/07/2026

CVE-2026-53321

Publication date:

26/06/2026

In the Linux kernel, the following vulnerability has been resolved: io_uring/napi: cap busy_poll_to 10 msec Currently there&#39;s no cap on the maximum amount of time that napi is allowed to poll if no events are found, which can lead to kernel complaints on a task being stuck as there&#39;s no conditional rescheduling done within that loop. Just cap it to 10 msec in total, that&#39;s already way above any kind of sane value that will reap any benefits, yet low enough that it&#39;s nowhere near being able to trigger preemption complaints.

Severity CVSS v4.0: Pending analysis

Last modification:

06/07/2026

CVE-2026-53320

Publication date:

26/06/2026

In the Linux kernel, the following vulnerability has been resolved: nilfs2: reject zero bd_oblocknr in nilfs_ioctl_mark_blocks_dirty() nilfs_ioctl_mark_blocks_dirty() uses bd_oblocknr to detect dead blocks by comparing it with the current block number bd_blocknr. If they differ, the block is considered dead and skipped. However, bd_oblocknr should never be 0 since block 0 typically stores the primary superblock and is never a valid GC target block. A corrupted ioctl request with bd_oblocknr set to 0 causes the comparison to incorrectly match when the lookup returns -ENOENT and sets bd_blocknr to 0, bypassing the dead block check and calling nilfs_bmap_mark() on a non-existent block. This causes nilfs_btree_do_lookup() to return -ENOENT, triggering the WARN_ON(ret == -ENOENT). Fix this by rejecting ioctl requests with bd_oblocknr set to 0 at the beginning of each iteration. [ryusuke: slightly modified the commit message and comments for accuracy]

Severity CVSS v4.0: Pending analysis

Last modification:

06/07/2026

CVE-2026-53319

Publication date:

26/06/2026

In the Linux kernel, the following vulnerability has been resolved: blk-wbt: remove WARN_ON_ONCE from wbt_init_enable_default() wbt_init_enable_default() uses WARN_ON_ONCE to check for failures from wbt_alloc() and wbt_init(). However, both are expected failure paths: - wbt_alloc() can return NULL under memory pressure (-ENOMEM) - wbt_init() can fail with -EBUSY if wbt is already registered syzbot triggers this by injecting memory allocation failures during MTD partition creation via ioctl(BLKPG), causing a spurious warning. wbt_init_enable_default() is a best-effort initialization called from blk_register_queue() with a void return type. Failure simply means the disk operates without writeback throttling, which is harmless. Replace WARN_ON_ONCE with plain if-checks, consistent with how wbt_set_lat() in the same file already handles these failures. Add a pr_warn() for the wbt_init() failure to retain diagnostic information without triggering a full stack trace.

Severity CVSS v4.0: Pending analysis

Last modification:

06/07/2026

CVE-2026-53318

Publication date:

26/06/2026

In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7925: prevent NULL pointer dereference in mt7925_tx_check_aggr() Move the NULL check for &#39;sta&#39; before dereferencing it to prevent a possible crash.

Severity CVSS v4.0: Pending analysis

Last modification:

06/07/2026

Subscribe to Vulnerabilities