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-38405

Publication date:
25/07/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvmet: fix memory leak of bio integrity<br /> <br /> If nvmet receives commands with metadata there is a continuous memory<br /> leak of kmalloc-128 slab or more precisely bio-&gt;bi_integrity.<br /> <br /> Since commit bf4c89fc8797 ("block: don&amp;#39;t call bio_uninit from bio_endio")<br /> each user of bio_init has to use bio_uninit as well. Otherwise the bio<br /> integrity is not getting free. Nvmet uses bio_init for inline bios.<br /> <br /> Uninit the inline bio to complete deallocation of integrity in bio.
Severity CVSS v4.0: Pending analysis
Last modification:
25/07/2025

CVE-2025-38406

Publication date:
25/07/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath6kl: remove WARN on bad firmware input<br /> <br /> If the firmware gives bad input, that&amp;#39;s nothing to do with<br /> the driver&amp;#39;s stack at this point etc., so the WARN_ON()<br /> doesn&amp;#39;t add any value. Additionally, this is one of the<br /> top syzbot reports now. Just print a message, and as an<br /> added bonus, print the sizes too.
Severity CVSS v4.0: Pending analysis
Last modification:
25/07/2025

CVE-2025-38407

Publication date:
25/07/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> riscv: cpu_ops_sbi: Use static array for boot_data<br /> <br /> Since commit 6b9f29b81b15 ("riscv: Enable pcpu page first chunk<br /> allocator"), if NUMA is enabled, the page percpu allocator may be used<br /> on very sparse configurations, or when requested on boot with<br /> percpu_alloc=page.<br /> <br /> In that case, percpu data gets put in the vmalloc area. However,<br /> sbi_hsm_hart_start() needs the physical address of a sbi_hart_boot_data,<br /> and simply assumes that __pa() would work. This causes the just started<br /> hart to immediately access an invalid address and hang.<br /> <br /> Fortunately, struct sbi_hart_boot_data is not too large, so we can<br /> simply allocate an array for boot_data statically, putting it in the<br /> kernel image.<br /> <br /> This fixes NUMA=y SMP boot on Sophgo SG2042.<br /> <br /> To reproduce on QEMU: Set CONFIG_NUMA=y and CONFIG_DEBUG_VIRTUAL=y, then<br /> run with:<br /> <br /> qemu-system-riscv64 -M virt -smp 2 -nographic \<br /> -kernel arch/riscv/boot/Image \<br /> -append "percpu_alloc=page"<br /> <br /> Kernel output:<br /> <br /> [ 0.000000] Booting Linux on hartid 0<br /> [ 0.000000] Linux version 6.16.0-rc1 (dram@sakuya) (riscv64-unknown-linux-gnu-gcc (GCC) 14.2.1 20250322, GNU ld (GNU Binutils) 2.44) #11 SMP Tue Jun 24 14:56:22 CST 2025<br /> ...<br /> [ 0.000000] percpu: 28 4K pages/cpu s85784 r8192 d20712<br /> ...<br /> [ 0.083192] smp: Bringing up secondary CPUs ...<br /> [ 0.086722] ------------[ cut here ]------------<br /> [ 0.086849] virt_to_phys used for non-linear address: (____ptrval____) (0xff2000000001d080)<br /> [ 0.088001] WARNING: CPU: 0 PID: 1 at arch/riscv/mm/physaddr.c:14 __virt_to_phys+0xae/0xe8<br /> [ 0.088376] Modules linked in:<br /> [ 0.088656] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.16.0-rc1 #11 NONE<br /> [ 0.088833] Hardware name: riscv-virtio,qemu (DT)<br /> [ 0.088948] epc : __virt_to_phys+0xae/0xe8<br /> [ 0.089001] ra : __virt_to_phys+0xae/0xe8<br /> [ 0.089037] epc : ffffffff80021eaa ra : ffffffff80021eaa sp : ff2000000004bbc0<br /> [ 0.089057] gp : ffffffff817f49c0 tp : ff60000001d60000 t0 : 5f6f745f74726976<br /> [ 0.089076] t1 : 0000000000000076 t2 : 705f6f745f747269 s0 : ff2000000004bbe0<br /> [ 0.089095] s1 : ff2000000001d080 a0 : 0000000000000000 a1 : 0000000000000000<br /> [ 0.089113] a2 : 0000000000000000 a3 : 0000000000000000 a4 : 0000000000000000<br /> [ 0.089131] a5 : 0000000000000000 a6 : 0000000000000000 a7 : 0000000000000000<br /> [ 0.089155] s2 : ffffffff8130dc00 s3 : 0000000000000001 s4 : 0000000000000001<br /> [ 0.089174] s5 : ffffffff8185eff8 s6 : ff2000007f1eb000 s7 : ffffffff8002a2ec<br /> [ 0.089193] s8 : 0000000000000001 s9 : 0000000000000001 s10: 0000000000000000<br /> [ 0.089211] s11: 0000000000000000 t3 : ffffffff8180a9f7 t4 : ffffffff8180a9f7<br /> [ 0.089960] t5 : ffffffff8180a9f8 t6 : ff2000000004b9d8<br /> [ 0.089984] status: 0000000200000120 badaddr: ffffffff80021eaa cause: 0000000000000003<br /> [ 0.090101] [] __virt_to_phys+0xae/0xe8<br /> [ 0.090228] [] sbi_cpu_start+0x6e/0xe8<br /> [ 0.090247] [] __cpu_up+0x1e/0x8c<br /> [ 0.090260] [] bringup_cpu+0x42/0x258<br /> [ 0.090277] [] cpuhp_invoke_callback+0xe0/0x40c<br /> [ 0.090292] [] __cpuhp_invoke_callback_range+0x68/0xfc<br /> [ 0.090320] [] _cpu_up+0x11a/0x244<br /> [ 0.090334] [] cpu_up+0x52/0x90<br /> [ 0.090384] [] bringup_nonboot_cpus+0x78/0x118<br /> [ 0.090411] [] smp_init+0x34/0xb8<br /> [ 0.090425] [] kernel_init_freeable+0x148/0x2e4<br /> [ 0.090442] [] kernel_init+0x1e/0x14c<br /> [ 0.090455] [] ret_from_fork_kernel+0xe/0xf0<br /> [ 0.090471] [] ret_from_fork_kernel_asm+0x16/0x18<br /> [ 0.090560] ---[ end trace 0000000000000000 ]---<br /> [ 1.179875] CPU1: failed to come online<br /> [ 1.190324] smp: Brought up 1 node, 1 CPU
Severity CVSS v4.0: Pending analysis
Last modification:
25/07/2025

CVE-2025-38408

Publication date:
25/07/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> genirq/irq_sim: Initialize work context pointers properly<br /> <br /> Initialize `ops` member&amp;#39;s pointers properly by using kzalloc() instead of<br /> kmalloc() when allocating the simulation work context. Otherwise the<br /> pointers contain random content leading to invalid dereferencing.
Severity CVSS v4.0: Pending analysis
Last modification:
25/07/2025

CVE-2025-38409

Publication date:
25/07/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm: Fix another leak in the submit error path<br /> <br /> put_unused_fd() doesn&amp;#39;t free the installed file, if we&amp;#39;ve already done<br /> fd_install(). So we need to also free the sync_file.<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/653583/
Severity CVSS v4.0: Pending analysis
Last modification:
25/07/2025

CVE-2025-38410

Publication date:
25/07/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm: Fix a fence leak in submit error path<br /> <br /> In error paths, we could unref the submit without calling<br /> drm_sched_entity_push_job(), so msm_job_free() will never get<br /> called. Since drm_sched_job_cleanup() will NULL out the<br /> s_fence, we can use that to detect this case.<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/653584/
Severity CVSS v4.0: Pending analysis
Last modification:
25/07/2025

CVE-2025-38411

Publication date:
25/07/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfs: Fix double put of request<br /> <br /> If a netfs request finishes during the pause loop, it will have the ref<br /> that belongs to the IN_PROGRESS flag removed at that point - however, if it<br /> then goes to the final wait loop, that will *also* put the ref because it<br /> sees that the IN_PROGRESS flag is clear and incorrectly assumes that this<br /> happened when it called the collector.<br /> <br /> In fact, since IN_PROGRESS is clear, we shouldn&amp;#39;t call the collector again<br /> since it&amp;#39;s done all the cleanup, such as calling -&gt;ki_complete().<br /> <br /> Fix this by making netfs_collect_in_app() just return, indicating that<br /> we&amp;#39;re done if IN_PROGRESS is removed.
Severity CVSS v4.0: Pending analysis
Last modification:
25/07/2025

CVE-2025-38412

Publication date:
25/07/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> platform/x86: dell-wmi-sysman: Fix WMI data block retrieval in sysfs callbacks<br /> <br /> After retrieving WMI data blocks in sysfs callbacks, check for the<br /> validity of them before dereferencing their content.
Severity CVSS v4.0: Pending analysis
Last modification:
25/07/2025

CVE-2025-38403

Publication date:
25/07/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vsock/vmci: Clear the vmci transport packet properly when initializing it<br /> <br /> In vmci_transport_packet_init memset the vmci_transport_packet before<br /> populating the fields to avoid any uninitialised data being left in the<br /> structure.
Severity CVSS v4.0: Pending analysis
Last modification:
25/07/2025

CVE-2025-38404

Publication date:
25/07/2025
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: typec: displayport: Fix potential deadlock<br /> <br /> The deadlock can occur due to a recursive lock acquisition of<br /> `cros_typec_altmode_data::mutex`.<br /> The call chain is as follows:<br /> 1. cros_typec_altmode_work() acquires the mutex<br /> 2. typec_altmode_vdm() -&gt; dp_altmode_vdm() -&gt;<br /> 3. typec_altmode_exit() -&gt; cros_typec_altmode_exit()<br /> 4. cros_typec_altmode_exit() attempts to acquire the mutex again<br /> <br /> To prevent this, defer the `typec_altmode_exit()` call by scheduling<br /> it rather than calling it directly from within the mutex-protected<br /> context.
Severity CVSS v4.0: Pending analysis
Last modification:
25/07/2025

CVE-2025-51411

Publication date:
25/07/2025
A reflected cross-site scripting (XSS) vulnerability exists in Institute-of-Current-Students v1.0 via the email parameter in the /postquerypublic endpoint. The application fails to properly sanitize user input before reflecting it in the HTML response. This allows unauthenticated attackers to inject and execute arbitrary JavaScript code in the context of the victim&amp;#39;s browser by tricking them into visiting a crafted URL or submitting a malicious form. Successful exploitation may lead to session hijacking, credential theft, or other client-side attacks.
Severity CVSS v4.0: Pending analysis
Last modification:
25/07/2025

CVE-2025-8156

Publication date:
25/07/2025
A vulnerability was found in PHPGurukul User Registration &amp; Login and User Management 3.3 and classified as critical. Affected by this issue is some unknown functionality of the file /admin/lastsevendays-reg-users.php. The manipulation of the argument ID leads to sql injection. The attack may be launched remotely. The exploit has been disclosed to the public and may be used.
Severity CVSS v4.0: MEDIUM
Last modification:
29/07/2025