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

Vulnerabilidades

Con el objetivo de informar, advertir y ayudar a los profesionales sobre las ultimas vulnerabilidades de seguridad en sistemas tecnológicos, ponemos a disposición de los usuarios interesados en esta información una base de datos con información en castellano sobre cada una de las ultimas vulnerabilidades documentadas y conocidas.

Este repositorio con más de 75.000 registros esta basado en la información de NVD (National Vulnerability Database) – en función de un acuerdo de colaboración – por el cual desde INCIBE realizamos la traducción al castellano de la información incluida. En ocasiones este listado mostrará vulnerabilidades que aún no han sido traducidas debido a que se recogen en el transcurso del tiempo en el que el equipo de INCIBE realiza el proceso de traducción.

Se emplea el estándar de nomenclatura de vulnerabilidades CVE (Common Vulnerabilities and Exposures), con el fin de facilitar el intercambio de información entre diferentes bases de datos y herramientas. Cada una de las vulnerabilidades recogidas enlaza a diversas fuentes de información así como a parches disponibles o soluciones aportadas por los fabricantes y desarrolladores. Es posible realizar búsquedas avanzadas teniendo la opción de seleccionar diferentes criterios como el tipo de vulnerabilidad, fabricante, tipo de impacto entre otros, con el fin de acortar los resultados.

Mediante suscripción RSS o Boletines podemos estar informados diariamente de las ultimas vulnerabilidades incorporadas al repositorio.

CVE-2025-39897

Fecha de publicación:
01/10/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: xilinx: axienet: Add error handling for RX metadata pointer retrieval<br /> <br /> Add proper error checking for dmaengine_desc_get_metadata_ptr() which<br /> can return an error pointer and lead to potential crashes or undefined<br /> behaviour if the pointer retrieval fails.<br /> <br /> Properly handle the error by unmapping DMA buffer, freeing the skb and<br /> returning early to prevent further processing with invalid data.
Gravedad CVSS v3.1: MEDIA
Última modificación:
14/01/2026

CVE-2025-39899

Fecha de publicación:
01/10/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/userfaultfd: fix kmap_local LIFO ordering for CONFIG_HIGHPTE<br /> <br /> With CONFIG_HIGHPTE on 32-bit ARM, move_pages_pte() maps PTE pages using<br /> kmap_local_page(), which requires unmapping in Last-In-First-Out order.<br /> <br /> The current code maps dst_pte first, then src_pte, but unmaps them in the<br /> same order (dst_pte, src_pte), violating the LIFO requirement. This<br /> causes the warning in kunmap_local_indexed():<br /> <br /> WARNING: CPU: 0 PID: 604 at mm/highmem.c:622 kunmap_local_indexed+0x178/0x17c<br /> addr \!= __fix_to_virt(FIX_KMAP_BEGIN + idx)<br /> <br /> Fix this by reversing the unmap order to respect LIFO ordering.<br /> <br /> This issue follows the same pattern as similar fixes:<br /> - commit eca6828403b8 ("crypto: skcipher - fix mismatch between mapping and unmapping order")<br /> - commit 8cf57c6df818 ("nilfs2: eliminate staggered calls to kunmap in nilfs_rename")<br /> <br /> Both of which addressed the same fundamental requirement that kmap_local<br /> operations must follow LIFO ordering.
Gravedad CVSS v3.1: MEDIA
Última modificación:
14/01/2026

CVE-2025-39900

Fecha de publicación:
01/10/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net_sched: gen_estimator: fix est_timer() vs CONFIG_PREEMPT_RT=y<br /> <br /> syzbot reported a WARNING in est_timer() [1]<br /> <br /> Problem here is that with CONFIG_PREEMPT_RT=y, timer callbacks<br /> can be preempted.<br /> <br /> Adopt preempt_disable_nested()/preempt_enable_nested() to fix this.<br /> <br /> [1]<br /> WARNING: CPU: 0 PID: 16 at ./include/linux/seqlock.h:221 __seqprop_assert include/linux/seqlock.h:221 [inline]<br /> WARNING: CPU: 0 PID: 16 at ./include/linux/seqlock.h:221 est_timer+0x6dc/0x9f0 net/core/gen_estimator.c:93<br /> Modules linked in:<br /> CPU: 0 UID: 0 PID: 16 Comm: ktimers/0 Not tainted syzkaller #0 PREEMPT_{RT,(full)}<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025<br /> RIP: 0010:__seqprop_assert include/linux/seqlock.h:221 [inline]<br /> RIP: 0010:est_timer+0x6dc/0x9f0 net/core/gen_estimator.c:93<br /> Call Trace:<br /> <br /> call_timer_fn+0x17e/0x5f0 kernel/time/timer.c:1747<br /> expire_timers kernel/time/timer.c:1798 [inline]<br /> __run_timers kernel/time/timer.c:2372 [inline]<br /> __run_timer_base+0x648/0x970 kernel/time/timer.c:2384<br /> run_timer_base kernel/time/timer.c:2393 [inline]<br /> run_timer_softirq+0xb7/0x180 kernel/time/timer.c:2403<br /> handle_softirqs+0x22c/0x710 kernel/softirq.c:579<br /> __do_softirq kernel/softirq.c:613 [inline]<br /> run_ktimerd+0xcf/0x190 kernel/softirq.c:1043<br /> smpboot_thread_fn+0x53f/0xa60 kernel/smpboot.c:160<br /> kthread+0x70e/0x8a0 kernel/kthread.c:463<br /> ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148<br /> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245<br />
Gravedad CVSS v3.1: MEDIA
Última modificación:
14/01/2026

CVE-2025-39901

Fecha de publicación:
01/10/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i40e: remove read access to debugfs files<br /> <br /> The &amp;#39;command&amp;#39; and &amp;#39;netdev_ops&amp;#39; debugfs files are a legacy debugging<br /> interface supported by the i40e driver since its early days by commit<br /> 02e9c290814c ("i40e: debugfs interface").<br /> <br /> Both of these debugfs files provide a read handler which is mostly useless,<br /> and which is implemented with questionable logic. They both use a static<br /> 256 byte buffer which is initialized to the empty string. In the case of<br /> the &amp;#39;command&amp;#39; file this buffer is literally never used and simply wastes<br /> space. In the case of the &amp;#39;netdev_ops&amp;#39; file, the last command written is<br /> saved here.<br /> <br /> On read, the files contents are presented as the name of the device<br /> followed by a colon and then the contents of their respective static<br /> buffer. For &amp;#39;command&amp;#39; this will always be ": ". For &amp;#39;netdev_ops&amp;#39;,<br /> this will be ": ". But note the buffer is<br /> shared between all devices operated by this module. At best, it is mostly<br /> meaningless information, and at worse it could be accessed simultaneously<br /> as there doesn&amp;#39;t appear to be any locking mechanism.<br /> <br /> We have also recently received multiple reports for both read functions<br /> about their use of snprintf and potential overflow that could result in<br /> reading arbitrary kernel memory. For the &amp;#39;command&amp;#39; file, this is definitely<br /> impossible, since the static buffer is always zero and never written to.<br /> For the &amp;#39;netdev_ops&amp;#39; file, it does appear to be possible, if the user<br /> carefully crafts the command input, it will be copied into the buffer,<br /> which could be large enough to cause snprintf to truncate, which then<br /> causes the copy_to_user to read beyond the length of the buffer allocated<br /> by kzalloc.<br /> <br /> A minimal fix would be to replace snprintf() with scnprintf() which would<br /> cap the return to the number of bytes written, preventing an overflow. A<br /> more involved fix would be to drop the mostly useless static buffers,<br /> saving 512 bytes and modifying the read functions to stop needing those as<br /> input.<br /> <br /> Instead, lets just completely drop the read access to these files. These<br /> are debug interfaces exposed as part of debugfs, and I don&amp;#39;t believe that<br /> dropping read access will break any script, as the provided output is<br /> pretty useless. You can find the netdev name through other more standard<br /> interfaces, and the &amp;#39;netdev_ops&amp;#39; interface can easily result in garbage if<br /> you issue simultaneous writes to multiple devices at once.<br /> <br /> In order to properly remove the i40e_dbg_netdev_ops_buf, we need to<br /> refactor its write function to avoid using the static buffer. Instead, use<br /> the same logic as the i40e_dbg_command_write, with an allocated buffer.<br /> Update the code to use this instead of the static buffer, and ensure we<br /> free the buffer on exit. This fixes simultaneous writes to &amp;#39;netdev_ops&amp;#39; on<br /> multiple devices, and allows us to remove the now unused static buffer<br /> along with removing the read access.
Gravedad CVSS v3.1: ALTA
Última modificación:
14/01/2026

CVE-2025-39902

Fecha de publicación:
01/10/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/slub: avoid accessing metadata when pointer is invalid in object_err()<br /> <br /> object_err() reports details of an object for further debugging, such as<br /> the freelist pointer, redzone, etc. However, if the pointer is invalid,<br /> attempting to access object metadata can lead to a crash since it does<br /> not point to a valid object.<br /> <br /> One known path to the crash is when alloc_consistency_checks()<br /> determines the pointer to the allocated object is invalid because of a<br /> freelist corruption, and calls object_err() to report it. The debug code<br /> should report and handle the corruption gracefully and not crash in the<br /> process.<br /> <br /> In case the pointer is NULL or check_valid_pointer() returns false for<br /> the pointer, only print the pointer value and skip accessing metadata.
Gravedad CVSS v3.1: MEDIA
Última modificación:
16/01/2026

CVE-2025-11226

Fecha de publicación:
01/10/2025
Idioma:
Inglés
*** Pendiente de traducción *** ACE vulnerability in conditional configuration file processing by QOS.CH logback-core up to and including version 1.5.18 in Java applications, allows an attacker to execute arbitrary code by compromising an existing logback configuration file or by injecting an environment variable before program execution.<br /> <br /> <br /> <br /> A successful attack requires the presence of Janino library and Spring Framework to be present on the user&amp;#39;s class path. In addition, the attacker must  have write access to a <br /> configuration file. Alternatively, the attacker could inject a malicious <br /> environment variable pointing to a malicious configuration file. In both <br /> cases, the attack requires existing privilege.
Gravedad CVSS v4.0: MEDIA
Última modificación:
31/10/2025

CVE-2025-39892

Fecha de publicación:
01/10/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: soc-core: care NULL dirver name on snd_soc_lookup_component_nolocked()<br /> <br /> soc-generic-dmaengine-pcm.c uses same dev for both CPU and Platform.<br /> In such case, CPU component driver might not have driver-&gt;name, then<br /> snd_soc_lookup_component_nolocked() will be NULL pointer access error.<br /> Care NULL driver name.<br /> <br /> Call trace:<br /> strcmp from snd_soc_lookup_component_nolocked+0x64/0xa4<br /> snd_soc_lookup_component_nolocked from snd_soc_unregister_component_by_driver+0x2c/0x44<br /> snd_soc_unregister_component_by_driver from snd_dmaengine_pcm_unregister+0x28/0x64<br /> snd_dmaengine_pcm_unregister from devres_release_all+0x98/0xfc<br /> devres_release_all from device_unbind_cleanup+0xc/0x60<br /> device_unbind_cleanup from really_probe+0x220/0x2c8<br /> really_probe from __driver_probe_device+0x88/0x1a0<br /> __driver_probe_device from driver_probe_device+0x30/0x110<br /> driver_probe_device from __driver_attach+0x90/0x178<br /> __driver_attach from bus_for_each_dev+0x7c/0xcc<br /> bus_for_each_dev from bus_add_driver+0xcc/0x1ec<br /> bus_add_driver from driver_register+0x80/0x11c<br /> driver_register from do_one_initcall+0x58/0x23c<br /> do_one_initcall from kernel_init_freeable+0x198/0x1f4<br /> kernel_init_freeable from kernel_init+0x1c/0x12c<br /> kernel_init from ret_from_fork+0x14/0x28
Gravedad CVSS v3.1: MEDIA
Última modificación:
14/01/2026

CVE-2025-39893

Fecha de publicación:
01/10/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: spi-qpic-snand: unregister ECC engine on probe error and device remove<br /> <br /> The on-host hardware ECC engine remains registered both when<br /> the spi_register_controller() function returns with an error<br /> and also on device removal.<br /> <br /> Change the qcom_spi_probe() function to unregister the engine<br /> on the error path, and add the missing unregistering call to<br /> qcom_spi_remove() to avoid possible use-after-free issues.
Gravedad CVSS v3.1: MEDIA
Última modificación:
14/01/2026

CVE-2025-39894

Fecha de publicación:
01/10/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: br_netfilter: do not check confirmed bit in br_nf_local_in() after confirm<br /> <br /> When send a broadcast packet to a tap device, which was added to a bridge,<br /> br_nf_local_in() is called to confirm the conntrack. If another conntrack<br /> with the same hash value is added to the hash table, which can be<br /> triggered by a normal packet to a non-bridge device, the below warning<br /> may happen.<br /> <br /> ------------[ cut here ]------------<br /> WARNING: CPU: 1 PID: 96 at net/bridge/br_netfilter_hooks.c:632 br_nf_local_in+0x168/0x200<br /> CPU: 1 UID: 0 PID: 96 Comm: tap_send Not tainted 6.17.0-rc2-dirty #44 PREEMPT(voluntary)<br /> RIP: 0010:br_nf_local_in+0x168/0x200<br /> Call Trace:<br /> <br /> nf_hook_slow+0x3e/0xf0<br /> br_pass_frame_up+0x103/0x180<br /> br_handle_frame_finish+0x2de/0x5b0<br /> br_nf_hook_thresh+0xc0/0x120<br /> br_nf_pre_routing_finish+0x168/0x3a0<br /> br_nf_pre_routing+0x237/0x5e0<br /> br_handle_frame+0x1ec/0x3c0<br /> __netif_receive_skb_core+0x225/0x1210<br /> __netif_receive_skb_one_core+0x37/0xa0<br /> netif_receive_skb+0x36/0x160<br /> tun_get_user+0xa54/0x10c0<br /> tun_chr_write_iter+0x65/0xb0<br /> vfs_write+0x305/0x410<br /> ksys_write+0x60/0xd0<br /> do_syscall_64+0xa4/0x260<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> ---[ end trace 0000000000000000 ]---<br /> <br /> To solve the hash conflict, nf_ct_resolve_clash() try to merge the<br /> conntracks, and update skb-&gt;_nfct. However, br_nf_local_in() still use the<br /> old ct from local variable &amp;#39;nfct&amp;#39; after confirm(), which leads to this<br /> warning.<br /> <br /> If confirm() does not insert the conntrack entry and return NF_DROP, the<br /> warning may also occur. There is no need to reserve the WARN_ON_ONCE, just<br /> remove it.
Gravedad CVSS v3.1: MEDIA
Última modificación:
16/01/2026

CVE-2025-39891

Fecha de publicación:
01/10/2025
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mwifiex: Initialize the chan_stats array to zero<br /> <br /> The adapter-&gt;chan_stats[] array is initialized in<br /> mwifiex_init_channel_scan_gap() with vmalloc(), which doesn&amp;#39;t zero out<br /> memory. The array is filled in mwifiex_update_chan_statistics()<br /> and then the user can query the data in mwifiex_cfg80211_dump_survey().<br /> <br /> There are two potential issues here. What if the user calls<br /> mwifiex_cfg80211_dump_survey() before the data has been filled in.<br /> Also the mwifiex_update_chan_statistics() function doesn&amp;#39;t necessarily<br /> initialize the whole array. Since the array was not initialized at<br /> the start that could result in an information leak.<br /> <br /> Also this array is pretty small. It&amp;#39;s a maximum of 900 bytes so it&amp;#39;s<br /> more appropriate to use kcalloc() instead vmalloc().
Gravedad CVSS v3.1: ALTA
Última modificación:
23/01/2026

CVE-2020-36852

Fecha de publicación:
01/10/2025
Idioma:
Inglés
*** Pendiente de traducción *** The Custom Searchable Data Entry System plugin for WordPress is vulnerable to unauthenticated database wiping in versions up to, and including 1.7.1, due to a missing capability check and lack of sufficient validation on the ghazale_sds_delete_entries_table_row() function. This makes it possible for unauthenticated attackers to completely wipe database tables such as wp_users.
Gravedad CVSS v3.1: CRÍTICA
Última modificación:
02/10/2025

CVE-2025-9512

Fecha de publicación:
01/10/2025
Idioma:
Inglés
*** Pendiente de traducción *** The Schema &amp; Structured Data for WP &amp; AMP WordPress plugin before 1.50 does not properly handles HTML tag attribute modifications, making it possible for unauthenticated attackers to conduct Stored XSS attacks via post comments.
Gravedad CVSS v3.1: MEDIA
Última modificación:
02/10/2025