Instituto Nacional de ciberseguridad. Sección Incibe
Instituto Nacional de Ciberseguridad. Sección INCIBE-CERT

Go to Calendar     Go to Press Room     Go to Newsletters subscription

Search

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-53138
Publication date:
25/06/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Bound VBIOS record-chain walk loops<br /> <br /> [Why &amp; How]<br /> All record-chain walk loops in bios_parser.c and bios_parser2.c use<br /> for(;;) and only terminate on a 0xFF record_type sentinel or zero<br /> record_size. A malformed VBIOS image missing the terminator record<br /> causes unbounded iteration at probe time, potentially hundreds of<br /> thousands of iterations with record_size=1. In the final iterations<br /> near the BIOS image boundary, struct casts beyond the 2-byte header<br /> validated by GET_IMAGE can also read out of bounds.<br /> <br /> Cap all 14 record-chain walk loops to BIOS_MAX_NUM_RECORD (256)<br /> iterations. The atombios.h defines up to 22 distinct record types<br /> and atomfirmware.h has 13. Assuming an average of less than 10<br /> records per type (which is reasonable since most are connector-<br /> based) 256 is a generous upper bound.<br /> <br /> (cherry picked from commit 95700a3d660287ed657d6892f7be9ffc0e294a93)
Severity CVSS v4.0: Pending analysis
Last modification:
07/07/2026

CVE-2026-53137
Publication date:
25/06/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Clamp HDMI HDCP2 rx_id_list read to buffer size<br /> <br /> [Why &amp; How]<br /> During HDCP 2.x repeater authentication over HDMI, the driver reads the<br /> sink&amp;#39;s RxStatus register and extracts a 10-bit message size field (max<br /> value 1023). This value is used as the read length for the ReceiverID<br /> list without being clamped to the size of the destination buffer<br /> rx_id_list[177]. A malicious HDMI repeater could advertise a message<br /> size larger than the buffer, causing an out-of-bounds write during the<br /> I2C read.<br /> <br /> Clamp the read length in mod_hdcp_read_rx_id_list() to the size of the<br /> rx_id_list buffer, matching the approach already used in the DP branch.<br /> <br /> (cherry picked from commit 229212219e4247d9486f8ba41ef087358490be09)
Severity CVSS v4.0: Pending analysis
Last modification:
07/07/2026

CVE-2026-46751
Publication date:
25/06/2026
A vulnerability in Apache Kvrocks.<br /> <br /> This issue affects Apache Kvrocks: from 2.2.0 through 2.15.0.<br /> <br /> Users are recommended to upgrade to version 2.16.0, which fixes the issue.
Severity CVSS v4.0: MEDIUM
Last modification:
25/06/2026

CVE-2026-46752
Publication date:
25/06/2026
Redis Lua HEAP overflow in cjson library vulnerability in Apache Kvrocks.<br /> <br /> This issue affects Apache Kvrocks: from 2.0.4 through 2.15.0.<br /> <br /> Users are recommended to upgrade to version 2.16.0, which fixes the issue.
Severity CVSS v4.0: CRITICAL
Last modification:
25/06/2026

CVE-2026-53132
Publication date:
25/06/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vsock/virtio: fix potential unbounded skb queue<br /> <br /> virtio_transport_inc_rx_pkt() checks vvs-&gt;rx_bytes + len &gt; vvs-&gt;buf_alloc.<br /> <br /> virtio_transport_recv_enqueue() skips coalescing for packets<br /> with VIRTIO_VSOCK_SEQ_EOM.<br /> <br /> If fed with packets with len == 0 and VIRTIO_VSOCK_SEQ_EOM,<br /> a very large number of packets can be queued<br /> because vvs-&gt;rx_bytes stays at 0.<br /> <br /> Fix this by estimating the skb metadata size:<br /> <br /> (Number of skbs in the queue) * SKB_TRUESIZE(0)
Severity CVSS v4.0: Pending analysis
Last modification:
06/07/2026

CVE-2026-53131
Publication date:
25/06/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: require Ethernet MAC header before using eth_hdr()<br /> <br /> `ip6t_eui64`, `xt_mac`, the `bitmap:ip,mac`, `hash:ip,mac`, and<br /> `hash:mac` ipset types, and `nf_log_syslog` access `eth_hdr(skb)`<br /> after either assuming that the skb is associated with an Ethernet<br /> device or checking only that the `ETH_HLEN` bytes at<br /> `skb_mac_header(skb)` lie between `skb-&gt;head` and `skb-&gt;data`.<br /> <br /> Make these paths first verify that the skb is associated with an<br /> Ethernet device, that the MAC header was set, and that it spans at<br /> least a full Ethernet header before accessing `eth_hdr(skb)`.
Severity CVSS v4.0: Pending analysis
Last modification:
06/07/2026

CVE-2026-53136
Publication date:
25/06/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Clamp VBIOS HDMI retimer register count to array size<br /> <br /> [Why &amp; How]<br /> The VBIOS integrated info tables (v1_11 and v2_1) contain HdmiRegNum and<br /> Hdmi6GRegNum fields that are used as loop bounds when copying retimer I2C<br /> register settings into fixed-size arrays (dp*_ext_hdmi_reg_settings[9]<br /> and dp*_ext_hdmi_6g_reg_settings[3]). These u8 fields are not validated<br /> before use, so a malformed VBIOS can specify values up to 255, causing an<br /> out-of-bounds heap write during driver probe.<br /> <br /> Clamp each register count to the destination array size using min_t()<br /> before the copy loops, in both get_integrated_info_v11() and<br /> get_integrated_info_v2_1().<br /> <br /> (cherry picked from commit 5a7f0ef90195940c54b0f5bb85b87da55f038c69)
Severity CVSS v4.0: Pending analysis
Last modification:
07/07/2026

CVE-2026-53135
Publication date:
25/06/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Fix NULL deref and buffer over-read in SDP debugfs<br /> <br /> [Why &amp; How]<br /> dp_sdp_message_debugfs_write() dereferences connector-&gt;base.state-&gt;crtc<br /> without checking for NULL. A connector can be connected but not bound to<br /> any CRTC (e.g. after hot-plug before the next atomic commit), causing a<br /> kernel crash when writing to the sdp_message debugfs node.<br /> <br /> The function also ignores the user-provided size argument and always<br /> passes 36 bytes to copy_from_user(), reading past the user buffer when<br /> size base.state or state-&gt;crtc is NULL<br /> - Clamping write_size to min(size, sizeof(data))<br /> <br /> (cherry picked from commit 6ab4c36a522842ff70474a1c0af2e40e50fc8300)
Severity CVSS v4.0: Pending analysis
Last modification:
07/07/2026

CVE-2026-53134
Publication date:
25/06/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nft_fib: fix stale stack leak via the OIFNAME register<br /> <br /> For NFT_FIB_RESULT_OIFNAME the destination register is declared with<br /> len = IFNAMSIZ (four 32-bit registers), but on the lookup-fail,<br /> RTN_LOCAL and oif-mismatch paths nft_fib{4,6}_eval() only writes one<br /> register via "*dest = 0". The remaining three registers are left as<br /> whatever was on the stack in nft_do_chain()&amp;#39;s struct nft_regs, and a<br /> downstream expression that loads the register span can leak that<br /> uninitialised kernel stack to userspace.<br /> <br /> The NFTA_FIB_F_PRESENT existence check has the same shape: it is only<br /> meaningful for NFT_FIB_RESULT_OIF, yet it was accepted for any result type<br /> while the eval stores a single byte via nft_reg_store8(), leaving the rest<br /> of the declared span stale.<br /> <br /> Fix both:<br /> <br /> - replace the bare "*dest = 0" in the eval with nft_fib_store_result(),<br /> which strscpy_pad()s the whole IFNAMSIZ for OIFNAME (and is already<br /> used on the other early-return path), and<br /> <br /> - restrict NFTA_FIB_F_PRESENT to NFT_FIB_RESULT_OIF and declare its<br /> destination as a single u8, so the marked span matches the one byte<br /> the eval writes.
Severity CVSS v4.0: Pending analysis
Last modification:
07/07/2026

CVE-2026-53133
Publication date:
25/06/2026
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/umem: Fix truncation for block sizes &gt;= 4G<br /> <br /> When the iommu is used the linearization of the mapping can give a single<br /> block that is very large split across multiple SG entries.<br /> <br /> When __rdma_block_iter_next() reassembles the split SG entries it is<br /> overflowing the 32 bit stack values and computed the wrong DMA addresses<br /> for blocks after the truncation.<br /> <br /> Use the right types to hold DMA addresses.
Severity CVSS v4.0: Pending analysis
Last modification:
07/07/2026

CVE-2026-41566
Publication date:
25/06/2026
Improper Handling of Insufficient Permissions or Privileges vulnerability in Apache Kvrocks.<br /> <br /> This issue affects Apache Kvrocks: 2.8.0.<br /> <br /> Users are recommended to upgrade to version 2.16.0, which fixes the issue.
Severity CVSS v4.0: CRITICAL
Last modification:
25/06/2026

CVE-2026-45188
Publication date:
25/06/2026
Relative Path Traversal vulnerability in Apache Kvrocks.<br /> <br /> This issue affects Apache Kvrocks: from 1.0.0 through 2.15.0.<br /> <br /> Users are recommended to upgrade to version 2.16.0, which fixes the issue.
Severity CVSS v4.0: LOW
Last modification:
25/06/2026
Subscribe to Vulnerabilities