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-2024-3333

Publication date:
17/04/2024
The Essential Addons for Elementor plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the URL attributes of widgets in all versions up to, and including, 5.9.14 due to insufficient input sanitization and output escaping on user supplied attributes. This makes it possible for authenticated attackers, with contributor-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page.
Severity CVSS v4.0: Pending analysis
Last modification:
08/04/2026

CVE-2024-3907

Publication date:
17/04/2024
A vulnerability was found in Tenda AC500 2.0.1.9(1307). It has been rated as critical. This issue affects the function formSetCfm of the file /goform/setcfm. The manipulation of the argument funcpara1 leads to stack-based buffer overflow. The attack may be initiated remotely. The exploit has been disclosed to the public and may be used. The associated identifier of this vulnerability is VDB-261143. NOTE: The vendor was contacted early about this disclosure but did not respond in any way.
Severity CVSS v4.0: Pending analysis
Last modification:
17/01/2025

CVE-2024-26902

Publication date:
17/04/2024
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> perf: RISCV: Fix panic on pmu overflow handler<br /> <br /> (1
Severity CVSS v4.0: Pending analysis
Last modification:
29/04/2024

CVE-2024-26903

Publication date:
17/04/2024
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: rfcomm: Fix null-ptr-deref in rfcomm_check_security<br /> <br /> During our fuzz testing of the connection and disconnection process at the<br /> RFCOMM layer, we discovered this bug. By comparing the packets from a<br /> normal connection and disconnection process with the testcase that<br /> triggered a KASAN report. We analyzed the cause of this bug as follows:<br /> <br /> 1. In the packets captured during a normal connection, the host sends a<br /> `Read Encryption Key Size` type of `HCI_CMD` packet<br /> (Command Opcode: 0x1408) to the controller to inquire the length of<br /> encryption key.After receiving this packet, the controller immediately<br /> replies with a Command Completepacket (Event Code: 0x0e) to return the<br /> Encryption Key Size.<br /> <br /> 2. In our fuzz test case, the timing of the controller&amp;#39;s response to this<br /> packet was delayed to an unexpected point: after the RFCOMM and L2CAP<br /> layers had disconnected but before the HCI layer had disconnected.<br /> <br /> 3. After receiving the Encryption Key Size Response at the time described<br /> in point 2, the host still called the rfcomm_check_security function.<br /> However, by this time `struct l2cap_conn *conn = l2cap_pi(sk)-&gt;chan-&gt;conn;`<br /> had already been released, and when the function executed<br /> `return hci_conn_security(conn-&gt;hcon, d-&gt;sec_level, auth_type, d-&gt;out);`,<br /> specifically when accessing `conn-&gt;hcon`, a null-ptr-deref error occurred.<br /> <br /> To fix this bug, check if `sk-&gt;sk_state` is BT_CLOSED before calling<br /> rfcomm_recv_frame in rfcomm_process_rx.
Severity CVSS v4.0: Pending analysis
Last modification:
05/11/2024

CVE-2024-26904

Publication date:
17/04/2024
Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Severity CVSS v4.0: Pending analysis
Last modification:
21/05/2024

CVE-2024-26905

Publication date:
17/04/2024
Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Severity CVSS v4.0: Pending analysis
Last modification:
29/07/2024

CVE-2024-26906

Publication date:
17/04/2024
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/mm: Disallow vsyscall page read for copy_from_kernel_nofault()<br /> <br /> When trying to use copy_from_kernel_nofault() to read vsyscall page<br /> through a bpf program, the following oops was reported:<br /> <br /> BUG: unable to handle page fault for address: ffffffffff600000<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> PGD 3231067 P4D 3231067 PUD 3233067 PMD 3235067 PTE 0<br /> Oops: 0000 [#1] PREEMPT SMP PTI<br /> CPU: 1 PID: 20390 Comm: test_progs ...... 6.7.0+ #58<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) ......<br /> RIP: 0010:copy_from_kernel_nofault+0x6f/0x110<br /> ......<br /> Call Trace:<br /> <br /> ? copy_from_kernel_nofault+0x6f/0x110<br /> bpf_probe_read_kernel+0x1d/0x50<br /> bpf_prog_2061065e56845f08_do_probe_read+0x51/0x8d<br /> trace_call_bpf+0xc5/0x1c0<br /> perf_call_bpf_enter.isra.0+0x69/0xb0<br /> perf_syscall_enter+0x13e/0x200<br /> syscall_trace_enter+0x188/0x1c0<br /> do_syscall_64+0xb5/0xe0<br /> entry_SYSCALL_64_after_hwframe+0x6e/0x76<br /> <br /> ......<br /> ---[ end trace 0000000000000000 ]---<br /> <br /> The oops is triggered when:<br /> <br /> 1) A bpf program uses bpf_probe_read_kernel() to read from the vsyscall<br /> page and invokes copy_from_kernel_nofault() which in turn calls<br /> __get_user_asm().<br /> <br /> 2) Because the vsyscall page address is not readable from kernel space,<br /> a page fault exception is triggered accordingly.<br /> <br /> 3) handle_page_fault() considers the vsyscall page address as a user<br /> space address instead of a kernel space address. This results in the<br /> fix-up setup by bpf not being applied and a page_fault_oops() is invoked<br /> due to SMAP.<br /> <br /> Considering handle_page_fault() has already considered the vsyscall page<br /> address as a userspace address, fix the problem by disallowing vsyscall<br /> page read for copy_from_kernel_nofault().
Severity CVSS v4.0: Pending analysis
Last modification:
16/09/2025

CVE-2024-26907

Publication date:
17/04/2024
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/mlx5: Fix fortify source warning while accessing Eth segment<br /> <br /> ------------[ cut here ]------------<br /> memcpy: detected field-spanning write (size 56) of single field "eseg-&gt;inline_hdr.start" at /var/lib/dkms/mlnx-ofed-kernel/5.8/build/drivers/infiniband/hw/mlx5/wr.c:131 (size 2)<br /> WARNING: CPU: 0 PID: 293779 at /var/lib/dkms/mlnx-ofed-kernel/5.8/build/drivers/infiniband/hw/mlx5/wr.c:131 mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib]<br /> Modules linked in: 8021q garp mrp stp llc rdma_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_umad(OE) mlx5_ib(OE) ib_uverbs(OE) ib_core(OE) mlx5_core(OE) pci_hyperv_intf mlxdevm(OE) mlx_compat(OE) tls mlxfw(OE) psample nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables libcrc32c nfnetlink mst_pciconf(OE) knem(OE) vfio_pci vfio_pci_core vfio_iommu_type1 vfio iommufd irqbypass cuse nfsv3 nfs fscache netfs xfrm_user xfrm_algo ipmi_devintf ipmi_msghandler binfmt_misc crct10dif_pclmul crc32_pclmul polyval_clmulni polyval_generic ghash_clmulni_intel sha512_ssse3 snd_pcsp aesni_intel crypto_simd cryptd snd_pcm snd_timer joydev snd soundcore input_leds serio_raw evbug nfsd auth_rpcgss nfs_acl lockd grace sch_fq_codel sunrpc drm efi_pstore ip_tables x_tables autofs4 psmouse virtio_net net_failover failover floppy<br /> [last unloaded: mlx_compat(OE)]<br /> CPU: 0 PID: 293779 Comm: ssh Tainted: G OE 6.2.0-32-generic #32~22.04.1-Ubuntu<br /> Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011<br /> RIP: 0010:mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib]<br /> Code: 0c 01 00 a8 01 75 25 48 8b 75 a0 b9 02 00 00 00 48 c7 c2 10 5b fd c0 48 c7 c7 80 5b fd c0 c6 05 57 0c 03 00 01 e8 95 4d 93 da 0b 44 8b 4d b0 4c 8b 45 c8 48 8b 4d c0 e9 49 fb ff ff 41 0f b7<br /> RSP: 0018:ffffb5b48478b570 EFLAGS: 00010046<br /> RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000000<br /> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000<br /> RBP: ffffb5b48478b628 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000000 R12: ffffb5b48478b5e8<br /> R13: ffff963a3c609b5e R14: ffff9639c3fbd800 R15: ffffb5b480475a80<br /> FS: 00007fc03b444c80(0000) GS:ffff963a3dc00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000556f46bdf000 CR3: 0000000006ac6003 CR4: 00000000003706f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> ? show_regs+0x72/0x90<br /> ? mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib]<br /> ? __warn+0x8d/0x160<br /> ? mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib]<br /> ? report_bug+0x1bb/0x1d0<br /> ? handle_bug+0x46/0x90<br /> ? exc_invalid_op+0x19/0x80<br /> ? asm_exc_invalid_op+0x1b/0x20<br /> ? mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib]<br /> mlx5_ib_post_send_nodrain+0xb/0x20 [mlx5_ib]<br /> ipoib_send+0x2ec/0x770 [ib_ipoib]<br /> ipoib_start_xmit+0x5a0/0x770 [ib_ipoib]<br /> dev_hard_start_xmit+0x8e/0x1e0<br /> ? validate_xmit_skb_list+0x4d/0x80<br /> sch_direct_xmit+0x116/0x3a0<br /> __dev_xmit_skb+0x1fd/0x580<br /> __dev_queue_xmit+0x284/0x6b0<br /> ? _raw_spin_unlock_irq+0xe/0x50<br /> ? __flush_work.isra.0+0x20d/0x370<br /> ? push_pseudo_header+0x17/0x40 [ib_ipoib]<br /> neigh_connected_output+0xcd/0x110<br /> ip_finish_output2+0x179/0x480<br /> ? __smp_call_single_queue+0x61/0xa0<br /> __ip_finish_output+0xc3/0x190<br /> ip_finish_output+0x2e/0xf0<br /> ip_output+0x78/0x110<br /> ? __pfx_ip_finish_output+0x10/0x10<br /> ip_local_out+0x64/0x70<br /> __ip_queue_xmit+0x18a/0x460<br /> ip_queue_xmit+0x15/0x30<br /> __tcp_transmit_skb+0x914/0x9c0<br /> tcp_write_xmit+0x334/0x8d0<br /> tcp_push_one+0x3c/0x60<br /> tcp_sendmsg_locked+0x2e1/0xac0<br /> tcp_sendmsg+0x2d/0x50<br /> inet_sendmsg+0x43/0x90<br /> sock_sendmsg+0x68/0x80<br /> sock_write_iter+0x93/0x100<br /> vfs_write+0x326/0x3c0<br /> ksys_write+0xbd/0xf0<br /> ? do_syscall_64+0x69/0x90<br /> __x64_sys_write+0x19/0x30<br /> do_syscall_<br /> ---truncated---
Severity CVSS v4.0: Pending analysis
Last modification:
05/11/2024

CVE-2024-26908

Publication date:
17/04/2024
Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
Severity CVSS v4.0: Pending analysis
Last modification:
30/04/2024

CVE-2024-26909

Publication date:
17/04/2024
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> soc: qcom: pmic_glink_altmode: fix drm bridge use-after-free<br /> <br /> A recent DRM series purporting to simplify support for "transparent<br /> bridges" and handling of probe deferrals ironically exposed a<br /> use-after-free issue on pmic_glink_altmode probe deferral.<br /> <br /> This has manifested itself as the display subsystem occasionally failing<br /> to initialise and NULL-pointer dereferences during boot of machines like<br /> the Lenovo ThinkPad X13s.<br /> <br /> Specifically, the dp-hpd bridge is currently registered before all<br /> resources have been acquired which means that it can also be<br /> deregistered on probe deferrals.<br /> <br /> In the meantime there is a race window where the new aux bridge driver<br /> (or PHY driver previously) may have looked up the dp-hpd bridge and<br /> stored a (non-reference-counted) pointer to the bridge which is about to<br /> be deallocated.<br /> <br /> When the display controller is later initialised, this triggers a<br /> use-after-free when attaching the bridges:<br /> <br /> dp -&gt; aux -&gt; dp-hpd (freed)<br /> <br /> which may, for example, result in the freed bridge failing to attach:<br /> <br /> [drm:drm_bridge_attach [drm]] *ERROR* failed to attach bridge /soc@0/phy@88eb000 to encoder TMDS-31: -16<br /> <br /> or a NULL-pointer dereference:<br /> <br /> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000<br /> ...<br /> Call trace:<br /> drm_bridge_attach+0x70/0x1a8 [drm]<br /> drm_aux_bridge_attach+0x24/0x38 [aux_bridge]<br /> drm_bridge_attach+0x80/0x1a8 [drm]<br /> dp_bridge_init+0xa8/0x15c [msm]<br /> msm_dp_modeset_init+0x28/0xc4 [msm]<br /> <br /> The DRM bridge implementation is clearly fragile and implicitly built on<br /> the assumption that bridges may never go away. In this case, the fix is<br /> to move the bridge registration in the pmic_glink_altmode driver to<br /> after all resources have been looked up.<br /> <br /> Incidentally, with the new dp-hpd bridge implementation, which registers<br /> child devices, this is also a requirement due to a long-standing issue<br /> in driver core that can otherwise lead to a probe deferral loop (see<br /> commit fbc35b45f9f6 ("Add documentation on meaning of -EPROBE_DEFER")).<br /> <br /> [DB: slightly fixed commit message by adding the word &amp;#39;commit&amp;#39;]
Severity CVSS v4.0: Pending analysis
Last modification:
29/04/2024

CVE-2024-3905

Publication date:
17/04/2024
A vulnerability was found in Tenda AC500 2.0.1.9(1307). It has been classified as critical. This affects the function R7WebsSecurityHandler of the file /goform/execCommand. The manipulation of the argument password leads to stack-based buffer overflow. It is possible to initiate the attack remotely. The exploit has been disclosed to the public and may be used. The identifier VDB-261141 was assigned to this vulnerability. NOTE: The vendor was contacted early about this disclosure but did not respond in any way.
Severity CVSS v4.0: Pending analysis
Last modification:
21/01/2025

CVE-2024-3906

Publication date:
17/04/2024
A vulnerability was found in Tenda AC500 2.0.1.9(1307). It has been declared as critical. This vulnerability affects the function formQuickIndex of the file /goform/QuickIndex. The manipulation of the argument PPPOEPassword leads to stack-based buffer overflow. The attack can be initiated remotely. The exploit has been disclosed to the public and may be used. VDB-261142 is the identifier assigned to this vulnerability. NOTE: The vendor was contacted early about this disclosure but did not respond in any way.
Severity CVSS v4.0: Pending analysis
Last modification:
21/01/2025