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-2025-23147

Publication date:
01/05/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i3c: Add NULL pointer check in i3c_master_queue_ibi()<br /> <br /> The I3C master driver may receive an IBI from a target device that has not<br /> been probed yet. In such cases, the master calls `i3c_master_queue_ibi()`<br /> to queue an IBI work task, leading to "Unable to handle kernel read from<br /> unreadable memory" and resulting in a kernel panic.<br /> <br /> Typical IBI handling flow:<br /> 1. The I3C master scans target devices and probes their respective drivers.<br /> 2. The target device driver calls `i3c_device_request_ibi()` to enable IBI<br /> and assigns `dev-&gt;ibi = ibi`.<br /> 3. The I3C master receives an IBI from the target device and calls<br /> `i3c_master_queue_ibi()` to queue the target device driver’s IBI<br /> handler task.<br /> <br /> However, since target device events are asynchronous to the I3C probe<br /> sequence, step 3 may occur before step 2, causing `dev-&gt;ibi` to be `NULL`,<br /> leading to a kernel panic.<br /> <br /> Add a NULL pointer check in `i3c_master_queue_ibi()` to prevent accessing<br /> an uninitialized `dev-&gt;ibi`, ensuring stability.
Severity CVSS v4.0: Pending analysis
Last modification:
05/11/2025

CVE-2025-23146

Publication date:
01/05/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mfd: ene-kb3930: Fix a potential NULL pointer dereference<br /> <br /> The off_gpios could be NULL. Add missing check in the kb3930_probe().<br /> This is similar to the issue fixed in commit b1ba8bcb2d1f<br /> ("backlight: hx8357: Fix potential NULL pointer dereference").<br /> <br /> This was detected by our static analysis tool.
Severity CVSS v4.0: Pending analysis
Last modification:
05/11/2025

CVE-2025-23145

Publication date:
01/05/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: fix NULL pointer in can_accept_new_subflow<br /> <br /> When testing valkey benchmark tool with MPTCP, the kernel panics in<br /> &amp;#39;mptcp_can_accept_new_subflow&amp;#39; because subflow_req-&gt;msk is NULL.<br /> <br /> Call trace:<br /> <br /> mptcp_can_accept_new_subflow (./net/mptcp/subflow.c:63 (discriminator 4)) (P)<br /> subflow_syn_recv_sock (./net/mptcp/subflow.c:854)<br /> tcp_check_req (./net/ipv4/tcp_minisocks.c:863)<br /> tcp_v4_rcv (./net/ipv4/tcp_ipv4.c:2268)<br /> ip_protocol_deliver_rcu (./net/ipv4/ip_input.c:207)<br /> ip_local_deliver_finish (./net/ipv4/ip_input.c:234)<br /> ip_local_deliver (./net/ipv4/ip_input.c:254)<br /> ip_rcv_finish (./net/ipv4/ip_input.c:449)<br /> ...<br /> <br /> According to the debug log, the same req received two SYN-ACK in a very<br /> short time, very likely because the client retransmits the syn ack due<br /> to multiple reasons.<br /> <br /> Even if the packets are transmitted with a relevant time interval, they<br /> can be processed by the server on different CPUs concurrently). The<br /> &amp;#39;subflow_req-&gt;msk&amp;#39; ownership is transferred to the subflow the first,<br /> and there will be a risk of a null pointer dereference here.<br /> <br /> This patch fixes this issue by moving the &amp;#39;subflow_req-&gt;msk&amp;#39; under the<br /> `own_req == true` conditional.<br /> <br /> Note that the !msk check in subflow_hmac_valid() can be dropped, because<br /> the same check already exists under the own_req mpj branch where the<br /> code has been moved to.
Severity CVSS v4.0: Pending analysis
Last modification:
05/11/2025

CVE-2025-23149

Publication date:
01/05/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tpm: do not start chip while suspended<br /> <br /> Checking TPM_CHIP_FLAG_SUSPENDED after the call to tpm_find_get_ops() can<br /> lead to a spurious tpm_chip_start() call:<br /> <br /> [35985.503771] i2c i2c-1: Transfer while suspended<br /> [35985.503796] WARNING: CPU: 0 PID: 74 at drivers/i2c/i2c-core.h:56 __i2c_transfer+0xbe/0x810<br /> [35985.503802] Modules linked in:<br /> [35985.503808] CPU: 0 UID: 0 PID: 74 Comm: hwrng Tainted: G W 6.13.0-next-20250203-00005-gfa0cb5642941 #19 9c3d7f78192f2d38e32010ac9c90fdc71109ef6f<br /> [35985.503814] Tainted: [W]=WARN<br /> [35985.503817] Hardware name: Google Morphius/Morphius, BIOS Google_Morphius.13434.858.0 10/26/2023<br /> [35985.503819] RIP: 0010:__i2c_transfer+0xbe/0x810<br /> [35985.503825] Code: 30 01 00 00 4c 89 f7 e8 40 fe d8 ff 48 8b 93 80 01 00 00 48 85 d2 75 03 49 8b 16 48 c7 c7 0a fb 7c a7 48 89 c6 e8 32 ad b0 fe 0b b8 94 ff ff ff e9 33 04 00 00 be 02 00 00 00 83 fd 02 0f 5<br /> [35985.503828] RSP: 0018:ffffa106c0333d30 EFLAGS: 00010246<br /> [35985.503833] RAX: 074ba64aa20f7000 RBX: ffff8aa4c1167120 RCX: 0000000000000000<br /> [35985.503836] RDX: 0000000000000000 RSI: ffffffffa77ab0e4 RDI: 0000000000000001<br /> [35985.503838] RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000000<br /> [35985.503841] R10: 0000000000000004 R11: 00000001000313d5 R12: ffff8aa4c10f1820<br /> [35985.503843] R13: ffff8aa4c0e243c0 R14: ffff8aa4c1167250 R15: ffff8aa4c1167120<br /> [35985.503846] FS: 0000000000000000(0000) GS:ffff8aa4eae00000(0000) knlGS:0000000000000000<br /> [35985.503849] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [35985.503852] CR2: 00007fab0aaf1000 CR3: 0000000105328000 CR4: 00000000003506f0<br /> [35985.503855] Call Trace:<br /> [35985.503859] <br /> [35985.503863] ? __warn+0xd4/0x260<br /> [35985.503868] ? __i2c_transfer+0xbe/0x810<br /> [35985.503874] ? report_bug+0xf3/0x210<br /> [35985.503882] ? handle_bug+0x63/0xb0<br /> [35985.503887] ? exc_invalid_op+0x16/0x50<br /> [35985.503892] ? asm_exc_invalid_op+0x16/0x20<br /> [35985.503904] ? __i2c_transfer+0xbe/0x810<br /> [35985.503913] tpm_cr50_i2c_transfer_message+0x24/0xf0<br /> [35985.503920] tpm_cr50_i2c_read+0x8e/0x120<br /> [35985.503928] tpm_cr50_request_locality+0x75/0x170<br /> [35985.503935] tpm_chip_start+0x116/0x160<br /> [35985.503942] tpm_try_get_ops+0x57/0x90<br /> [35985.503948] tpm_find_get_ops+0x26/0xd0<br /> [35985.503955] tpm_get_random+0x2d/0x80<br /> <br /> Don&amp;#39;t move forward with tpm_chip_start() inside tpm_try_get_ops(), unless<br /> TPM_CHIP_FLAG_SUSPENDED is not set. tpm_find_get_ops() will return NULL in<br /> such a failure case.
Severity CVSS v4.0: Pending analysis
Last modification:
06/11/2025

CVE-2025-23144

Publication date:
01/05/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> backlight: led_bl: Hold led_access lock when calling led_sysfs_disable()<br /> <br /> Lockdep detects the following issue on led-backlight removal:<br /> [ 142.315935] ------------[ cut here ]------------<br /> [ 142.315954] WARNING: CPU: 2 PID: 292 at drivers/leds/led-core.c:455 led_sysfs_enable+0x54/0x80<br /> ...<br /> [ 142.500725] Call trace:<br /> [ 142.503176] led_sysfs_enable+0x54/0x80 (P)<br /> [ 142.507370] led_bl_remove+0x80/0xa8 [led_bl]<br /> [ 142.511742] platform_remove+0x30/0x58<br /> [ 142.515501] device_remove+0x54/0x90<br /> ...<br /> <br /> Indeed, led_sysfs_enable() has to be called with the led_access<br /> lock held.<br /> <br /> Hold the lock when calling led_sysfs_disable().
Severity CVSS v4.0: Pending analysis
Last modification:
06/11/2025

CVE-2025-23142

Publication date:
01/05/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sctp: detect and prevent references to a freed transport in sendmsg<br /> <br /> sctp_sendmsg() re-uses associations and transports when possible by<br /> doing a lookup based on the socket endpoint and the message destination<br /> address, and then sctp_sendmsg_to_asoc() sets the selected transport in<br /> all the message chunks to be sent.<br /> <br /> There&amp;#39;s a possible race condition if another thread triggers the removal<br /> of that selected transport, for instance, by explicitly unbinding an<br /> address with setsockopt(SCTP_SOCKOPT_BINDX_REM), after the chunks have<br /> been set up and before the message is sent. This can happen if the send<br /> buffer is full, during the period when the sender thread temporarily<br /> releases the socket lock in sctp_wait_for_sndbuf().<br /> <br /> This causes the access to the transport data in<br /> sctp_outq_select_transport(), when the association outqueue is flushed,<br /> to result in a use-after-free read.<br /> <br /> This change avoids this scenario by having sctp_transport_free() signal<br /> the freeing of the transport, tagging it as "dead". In order to do this,<br /> the patch restores the "dead" bit in struct sctp_transport, which was<br /> removed in<br /> commit 47faa1e4c50e ("sctp: remove the dead field of sctp_transport").<br /> <br /> Then, in the scenario where the sender thread has released the socket<br /> lock in sctp_wait_for_sndbuf(), the bit is checked again after<br /> re-acquiring the socket lock to detect the deletion. This is done while<br /> holding a reference to the transport to prevent it from being freed in<br /> the process.<br /> <br /> If the transport was deleted while the socket lock was relinquished,<br /> sctp_sendmsg_to_asoc() will return -EAGAIN to let userspace retry the<br /> send.<br /> <br /> The bug was found by a private syzbot instance (see the error report [1]<br /> and the C reproducer that triggers it [2]).
Severity CVSS v4.0: Pending analysis
Last modification:
05/11/2025

CVE-2025-23143

Publication date:
01/05/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: Fix null-ptr-deref by sock_lock_init_class_and_name() and rmmod.<br /> <br /> When I ran the repro [0] and waited a few seconds, I observed two<br /> LOCKDEP splats: a warning immediately followed by a null-ptr-deref. [1]<br /> <br /> Reproduction Steps:<br /> <br /> 1) Mount CIFS<br /> 2) Add an iptables rule to drop incoming FIN packets for CIFS<br /> 3) Unmount CIFS<br /> 4) Unload the CIFS module<br /> 5) Remove the iptables rule<br /> <br /> At step 3), the CIFS module calls sock_release() for the underlying<br /> TCP socket, and it returns quickly. However, the socket remains in<br /> FIN_WAIT_1 because incoming FIN packets are dropped.<br /> <br /> At this point, the module&amp;#39;s refcnt is 0 while the socket is still<br /> alive, so the following rmmod command succeeds.<br /> <br /> # ss -tan<br /> State Recv-Q Send-Q Local Address:Port Peer Address:Port<br /> FIN-WAIT-1 0 477 10.0.2.15:51062 10.0.0.137:445<br /> <br /> # lsmod | grep cifs<br /> cifs 1159168 0<br /> <br /> This highlights a discrepancy between the lifetime of the CIFS module<br /> and the underlying TCP socket. Even after CIFS calls sock_release()<br /> and it returns, the TCP socket does not die immediately in order to<br /> close the connection gracefully.<br /> <br /> While this is generally fine, it causes an issue with LOCKDEP because<br /> CIFS assigns a different lock class to the TCP socket&amp;#39;s sk-&gt;sk_lock<br /> using sock_lock_init_class_and_name().<br /> <br /> Once an incoming packet is processed for the socket or a timer fires,<br /> sk-&gt;sk_lock is acquired.<br /> <br /> Then, LOCKDEP checks the lock context in check_wait_context(), where<br /> hlock_class() is called to retrieve the lock class. However, since<br /> the module has already been unloaded, hlock_class() logs a warning<br /> and returns NULL, triggering the null-ptr-deref.<br /> <br /> If LOCKDEP is enabled, we must ensure that a module calling<br /> sock_lock_init_class_and_name() (CIFS, NFS, etc) cannot be unloaded<br /> while such a socket is still alive to prevent this issue.<br /> <br /> Let&amp;#39;s hold the module reference in sock_lock_init_class_and_name()<br /> and release it when the socket is freed in sk_prot_free().<br /> <br /> Note that sock_lock_init() clears sk-&gt;sk_owner for svc_create_socket()<br /> that calls sock_lock_init_class_and_name() for a listening socket,<br /> which clones a socket by sk_clone_lock() without GFP_ZERO.<br /> <br /> [0]:<br /> CIFS_SERVER="10.0.0.137"<br /> CIFS_PATH="//${CIFS_SERVER}/Users/Administrator/Desktop/CIFS_TEST"<br /> DEV="enp0s3"<br /> CRED="/root/WindowsCredential.txt"<br /> <br /> MNT=$(mktemp -d /tmp/XXXXXX)<br /> mount -t cifs ${CIFS_PATH} ${MNT} -o vers=3.0,credentials=${CRED},cache=none,echo_interval=1<br /> <br /> iptables -A INPUT -s ${CIFS_SERVER} -j DROP<br /> <br /> for i in $(seq 10);<br /> do<br /> umount ${MNT}<br /> rmmod cifs<br /> sleep 1<br /> done<br /> <br /> rm -r ${MNT}<br /> <br /> iptables -D INPUT -s ${CIFS_SERVER} -j DROP<br /> <br /> [1]:<br /> DEBUG_LOCKS_WARN_ON(1)<br /> WARNING: CPU: 10 PID: 0 at kernel/locking/lockdep.c:234 hlock_class (kernel/locking/lockdep.c:234 kernel/locking/lockdep.c:223)<br /> Modules linked in: cifs_arc4 nls_ucs2_utils cifs_md4 [last unloaded: cifs]<br /> CPU: 10 UID: 0 PID: 0 Comm: swapper/10 Not tainted 6.14.0 #36<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:hlock_class (kernel/locking/lockdep.c:234 kernel/locking/lockdep.c:223)<br /> ...<br /> Call Trace:<br /> <br /> __lock_acquire (kernel/locking/lockdep.c:4853 kernel/locking/lockdep.c:5178)<br /> lock_acquire (kernel/locking/lockdep.c:469 kernel/locking/lockdep.c:5853 kernel/locking/lockdep.c:5816)<br /> _raw_spin_lock_nested (kernel/locking/spinlock.c:379)<br /> tcp_v4_rcv (./include/linux/skbuff.h:1678 ./include/net/tcp.h:2547 net/ipv4/tcp_ipv4.c:2350)<br /> ...<br /> <br /> BUG: kernel NULL pointer dereference, address: 00000000000000c4<br /> PF: supervisor read access in kernel mode<br /> PF: error_code(0x0000) - not-present page<br /> PGD 0<br /> Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI<br /> CPU: 10 UID: 0 PID: 0 Comm: swapper/10 Tainted: G W 6.14.0 #36<br /> Tainted: [W]=WARN<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:__lock_acquire (kernel/<br /> ---truncated---
Severity CVSS v4.0: Pending analysis
Last modification:
12/05/2026

CVE-2023-46669

Publication date:
01/05/2025
Exposure of sensitive information to local unauthorized actors in Elastic Agent and Elastic Security Endpoint can lead to loss of confidentiality and impersonation of Endpoint to the Elastic Stack. This issue was identified by Elastic engineers and Elastic has no indication that it is known or has been exploited by malicious actors.
Severity CVSS v4.0: Pending analysis
Last modification:
01/10/2025

CVE-2025-23139

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

CVE-2025-23140

Publication date:
01/05/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> misc: pci_endpoint_test: Avoid issue of interrupts remaining after request_irq error<br /> <br /> After devm_request_irq() fails with error in pci_endpoint_test_request_irq(),<br /> the pci_endpoint_test_free_irq_vectors() is called assuming that all IRQs<br /> have been released.<br /> <br /> However, some requested IRQs remain unreleased, so there are still<br /> /proc/irq/* entries remaining, and this results in WARN() with the<br /> following message:<br /> <br /> remove_proc_entry: removing non-empty directory &amp;#39;irq/30&amp;#39;, leaking at least &amp;#39;pci-endpoint-test.0&amp;#39;<br /> WARNING: CPU: 0 PID: 202 at fs/proc/generic.c:719 remove_proc_entry +0x190/0x19c<br /> <br /> To solve this issue, set the number of remaining IRQs to test-&gt;num_irqs,<br /> and release IRQs in advance by calling pci_endpoint_test_release_irq().<br /> <br /> [kwilczynski: commit log]
Severity CVSS v4.0: Pending analysis
Last modification:
05/11/2025

CVE-2025-23141

Publication date:
01/05/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: x86: Acquire SRCU in KVM_GET_MP_STATE to protect guest memory accesses<br /> <br /> Acquire a lock on kvm-&gt;srcu when userspace is getting MP state to handle a<br /> rather extreme edge case where "accepting" APIC events, i.e. processing<br /> pending INIT or SIPI, can trigger accesses to guest memory. If the vCPU<br /> is in L2 with INIT *and* a TRIPLE_FAULT request pending, then getting MP<br /> state will trigger a nested VM-Exit by way of -&gt;check_nested_events(), and<br /> emuating the nested VM-Exit can access guest memory.<br /> <br /> The splat was originally hit by syzkaller on a Google-internal kernel, and<br /> reproduced on an upstream kernel by hacking the triple_fault_event_test<br /> selftest to stuff a pending INIT, store an MSR on VM-Exit (to generate a<br /> memory access on VMX), and do vcpu_mp_state_get() to trigger the scenario.<br /> <br /> =============================<br /> WARNING: suspicious RCU usage<br /> 6.14.0-rc3-b112d356288b-vmx/pi_lockdep_false_pos-lock #3 Not tainted<br /> -----------------------------<br /> include/linux/kvm_host.h:1058 suspicious rcu_dereference_check() usage!<br /> <br /> other info that might help us debug this:<br /> <br /> rcu_scheduler_active = 2, debug_locks = 1<br /> 1 lock held by triple_fault_ev/1256:<br /> #0: ffff88810df5a330 (&amp;vcpu-&gt;mutex){+.+.}-{4:4}, at: kvm_vcpu_ioctl+0x8b/0x9a0 [kvm]<br /> <br /> stack backtrace:<br /> CPU: 11 UID: 1000 PID: 1256 Comm: triple_fault_ev Not tainted 6.14.0-rc3-b112d356288b-vmx #3<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x7f/0x90<br /> lockdep_rcu_suspicious+0x144/0x190<br /> kvm_vcpu_gfn_to_memslot+0x156/0x180 [kvm]<br /> kvm_vcpu_read_guest+0x3e/0x90 [kvm]<br /> read_and_check_msr_entry+0x2e/0x180 [kvm_intel]<br /> __nested_vmx_vmexit+0x550/0xde0 [kvm_intel]<br /> kvm_check_nested_events+0x1b/0x30 [kvm]<br /> kvm_apic_accept_events+0x33/0x100 [kvm]<br /> kvm_arch_vcpu_ioctl_get_mpstate+0x30/0x1d0 [kvm]<br /> kvm_vcpu_ioctl+0x33e/0x9a0 [kvm]<br /> __x64_sys_ioctl+0x8b/0xb0<br /> do_syscall_64+0x6c/0x170<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br />
Severity CVSS v4.0: Pending analysis
Last modification:
05/11/2025

CVE-2025-4163

Publication date:
01/05/2025
A vulnerability, which was classified as critical, has been found in PHPGurukul Land Record System 1.0. This issue affects some unknown processing of the file /admin/aboutus.php. The manipulation of the argument pagetitle leads to sql injection. The attack may be initiated remotely. The exploit has been disclosed to the public and may be used. Other parameters might be affected as well.
Severity CVSS v4.0: MEDIUM
Last modification:
16/05/2025