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 últimas 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 últimas 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 últimas vulnerabilidades incorporadas al repositorio.

CVE-2026-30997

Fecha de publicación:
13/04/2026
Idioma:
Inglés
*** Pendiente de traducción *** An out-of-bounds read in the read_global_param() function (libavcodec/av1dec.c) of FFmpeg v8.0.1 allows attackers to cause a Denial of Service (DoS) via a crafted input.
Gravedad CVSS v3.1: ALTA
Última modificación:
23/04/2026

CVE-2026-29628

Fecha de publicación:
13/04/2026
Idioma:
Inglés
*** Pendiente de traducción *** A stack overflow in the experimental/tinyobj_loader_opt.h file of tinyobjloader commit d56555b allows attackers to cause a Denial of Service (DoS) via supplying a crafted .mtl file.
Gravedad CVSS v3.1: MEDIA
Última modificación:
27/04/2026

CVE-2026-1462

Fecha de publicación:
13/04/2026
Idioma:
Inglés
*** Pendiente de traducción *** A vulnerability in the `TFSMLayer` class of the `keras` package, version 3.13.0, allows attacker-controlled TensorFlow SavedModels to be loaded during deserialization of `.keras` models, even when `safe_mode=True`. This bypasses the security guarantees of `safe_mode` and enables arbitrary attacker-controlled code execution during model inference under the victim's privileges. The issue arises due to the unconditional loading of external SavedModels, serialization of attacker-controlled file paths, and the lack of validation in the `from_config()` method.
Gravedad CVSS v3.1: ALTA
Última modificación:
17/04/2026

CVE-2025-66236

Fecha de publicación:
13/04/2026
Idioma:
Inglés
*** Pendiente de traducción *** Before Airflow 3.2.0, it was unclear that secure Airflow deployments require the Deployment Manager to take appropriate actions and pay attention to security details and security model of Airflow. Some assumptions the Deployment Manager could make were not clear or explicit enough, even though Airflow&amp;#39;s intentions and security model of Airflow did not suggest different assumptions. The overall security model [1], workload isolation [2], and JWT authentication details [3] are now described in more detail. Users concerned with role isolation and following the Airflow security model of Airflow are advised to upgrade to Airflow 3.2, where several security improvements have been implemented. They should also read and follow the relevant documents to make sure that their deployment is secure enough. It also clarifies that the Deployment Manager is ultimately responsible for securing your Airflow deployment. This had also been communicated via Airflow 3.2.0 Blog announcement [4].<br /> <br /> [1] Security Model: https://airflow.apache.org/docs/apache-airflow/stable/security/jwt_token_authentication.html <br /> [2] Workload isolation: https://airflow.apache.org/docs/apache-airflow/stable/security/workload.html <br /> [3] JWT Token authentication: https://airflow.apache.org/docs/apache-airflow/stable/security/jwt_token_authentication.html <br /> [4] Airflow 3.2.0 Blog announcement: https://airflow.apache.org/blog/airflow-3.2.0/ <br /> <br /> <br /> <br /> Users are recommended to upgrade to version 3.2.0, which fixes this issue.
Gravedad CVSS v3.1: ALTA
Última modificación:
17/04/2026

CVE-2026-36947

Fecha de publicación:
13/04/2026
Idioma:
Inglés
*** Pendiente de traducción *** Sourcecodester Computer and Mobile Repair Shop Management System v1.0 is vulnerable to SQL Injection in the file /rsms/admin/services/view_service.php.
Gravedad CVSS v3.1: BAJA
Última modificación:
14/04/2026

CVE-2026-36946

Fecha de publicación:
13/04/2026
Idioma:
Inglés
*** Pendiente de traducción *** Sourcecodester Computer and Mobile Repair Shop Management System v1.0 is vulnerable to SQL injection in the file /rsms/admin/inquiries/view_details.php.
Gravedad CVSS v3.1: BAJA
Última modificación:
10/05/2026

CVE-2026-31423

Fecha de publicación:
13/04/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: sch_hfsc: fix divide-by-zero in rtsc_min()<br /> <br /> m2sm() converts a u32 slope to a u64 scaled value. For large inputs<br /> (e.g. m1=4000000000), the result can reach 2^32. rtsc_min() stores<br /> the difference of two such u64 values in a u32 variable `dsm` and<br /> uses it as a divisor. When the difference is exactly 2^32 the<br /> truncation yields zero, causing a divide-by-zero oops in the<br /> concave-curve intersection path:<br /> <br /> Oops: divide error: 0000<br /> RIP: 0010:rtsc_min (net/sched/sch_hfsc.c:601)<br /> Call Trace:<br /> init_ed (net/sched/sch_hfsc.c:629)<br /> hfsc_enqueue (net/sched/sch_hfsc.c:1569)<br /> [...]<br /> <br /> Widen `dsm` to u64 and replace do_div() with div64_u64() so the full<br /> difference is preserved.
Gravedad: Pendiente de análisis
Última modificación:
18/04/2026

CVE-2026-31424

Fecha de publicación:
13/04/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: x_tables: restrict xt_check_match/xt_check_target extensions for NFPROTO_ARP<br /> <br /> Weiming Shi says:<br /> <br /> xt_match and xt_target structs registered with NFPROTO_UNSPEC can be<br /> loaded by any protocol family through nft_compat. When such a<br /> match/target sets .hooks to restrict which hooks it may run on, the<br /> bitmask uses NF_INET_* constants. This is only correct for families<br /> whose hook layout matches NF_INET_*: IPv4, IPv6, INET, and bridge<br /> all share the same five hooks (PRE_ROUTING ... POST_ROUTING).<br /> <br /> ARP only has three hooks (IN=0, OUT=1, FORWARD=2) with different<br /> semantics. Because NF_ARP_OUT == 1 == NF_INET_LOCAL_IN, the .hooks<br /> validation silently passes for the wrong reasons, allowing matches to<br /> run on ARP chains where the hook assumptions (e.g. state-&gt;in being<br /> set on input hooks) do not hold. This leads to NULL pointer<br /> dereferences; xt_devgroup is one concrete example:<br /> <br /> Oops: general protection fault, probably for non-canonical address 0xdffffc0000000044: 0000 [#1] SMP KASAN NOPTI<br /> KASAN: null-ptr-deref in range [0x0000000000000220-0x0000000000000227]<br /> RIP: 0010:devgroup_mt+0xff/0x350<br /> Call Trace:<br /> <br /> nft_match_eval (net/netfilter/nft_compat.c:407)<br /> nft_do_chain (net/netfilter/nf_tables_core.c:285)<br /> nft_do_chain_arp (net/netfilter/nft_chain_filter.c:61)<br /> nf_hook_slow (net/netfilter/core.c:623)<br /> arp_xmit (net/ipv4/arp.c:666)<br /> <br /> Kernel panic - not syncing: Fatal exception in interrupt<br /> <br /> Fix it by restricting arptables to NFPROTO_ARP extensions only.<br /> Note that arptables-legacy only supports:<br /> <br /> - arpt_CLASSIFY<br /> - arpt_mangle<br /> - arpt_MARK<br /> <br /> that provide explicit NFPROTO_ARP match/target declarations.
Gravedad: Pendiente de análisis
Última modificación:
18/04/2026

CVE-2026-31425

Fecha de publicación:
13/04/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rds: ib: reject FRMR registration before IB connection is established<br /> <br /> rds_ib_get_mr() extracts the rds_ib_connection from conn-&gt;c_transport_data<br /> and passes it to rds_ib_reg_frmr() for FRWR memory registration. On a<br /> fresh outgoing connection, ic is allocated in rds_ib_conn_alloc() with<br /> i_cm_id = NULL because the connection worker has not yet called<br /> rds_ib_conn_path_connect() to create the rdma_cm_id. When sendmsg() with<br /> RDS_CMSG_RDMA_MAP is called on such a connection, the sendmsg path parses<br /> the control message before any connection establishment, allowing<br /> rds_ib_post_reg_frmr() to dereference ic-&gt;i_cm_id-&gt;qp and crash the<br /> kernel.<br /> <br /> The existing guard in rds_ib_reg_frmr() only checks for !ic (added in<br /> commit 9e630bcb7701), which does not catch this case since ic is allocated<br /> early and is always non-NULL once the connection object exists.<br /> <br /> KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]<br /> RIP: 0010:rds_ib_post_reg_frmr+0x50e/0x920<br /> Call Trace:<br /> rds_ib_post_reg_frmr (net/rds/ib_frmr.c:167)<br /> rds_ib_map_frmr (net/rds/ib_frmr.c:252)<br /> rds_ib_reg_frmr (net/rds/ib_frmr.c:430)<br /> rds_ib_get_mr (net/rds/ib_rdma.c:615)<br /> __rds_rdma_map (net/rds/rdma.c:295)<br /> rds_cmsg_rdma_map (net/rds/rdma.c:860)<br /> rds_sendmsg (net/rds/send.c:1363)<br /> ____sys_sendmsg<br /> do_syscall_64<br /> <br /> Add a check in rds_ib_get_mr() that verifies ic, i_cm_id, and qp are all<br /> non-NULL before proceeding with FRMR registration, mirroring the guard<br /> already present in rds_ib_post_inv(). Return -ENODEV when the connection<br /> is not ready, which the existing error handling in rds_cmsg_send() converts<br /> to -EAGAIN for userspace retry and triggers rds_conn_connect_if_down() to<br /> start the connection worker.
Gravedad: Pendiente de análisis
Última modificación:
18/04/2026

CVE-2026-31427

Fecha de publicación:
13/04/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_conntrack_sip: fix use of uninitialized rtp_addr in process_sdp<br /> <br /> process_sdp() declares union nf_inet_addr rtp_addr on the stack and<br /> passes it to the nf_nat_sip sdp_session hook after walking the SDP<br /> media descriptions. However rtp_addr is only initialized inside the<br /> media loop when a recognized media type with a non-zero port is found.<br /> <br /> If the SDP body contains no m= lines, only inactive media sections<br /> (m=audio 0 ...) or only unrecognized media types, rtp_addr is never<br /> assigned. Despite that, the function still calls hooks-&gt;sdp_session()<br /> with &amp;rtp_addr, causing nf_nat_sdp_session() to format the stale stack<br /> value as an IP address and rewrite the SDP session owner and connection<br /> lines with it.<br /> <br /> With CONFIG_INIT_STACK_ALL_ZERO (default on most distributions) this<br /> results in the session-level o= and c= addresses being rewritten to<br /> 0.0.0.0 for inactive SDP sessions. Without stack auto-init the<br /> rewritten address is whatever happened to be on the stack.<br /> <br /> Fix this by pre-initializing rtp_addr from the session-level connection<br /> address (caddr) when available, and tracking via a have_rtp_addr flag<br /> whether any valid address was established. Skip the sdp_session hook<br /> entirely when no valid address exists.
Gravedad: Pendiente de análisis
Última modificación:
18/04/2026

CVE-2026-31428

Fecha de publicación:
13/04/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nfnetlink_log: fix uninitialized padding leak in NFULA_PAYLOAD<br /> <br /> __build_packet_message() manually constructs the NFULA_PAYLOAD netlink<br /> attribute using skb_put() and skb_copy_bits(), bypassing the standard<br /> nla_reserve()/nla_put() helpers. While nla_total_size(data_len) bytes<br /> are allocated (including NLA alignment padding), only data_len bytes<br /> of actual packet data are copied. The trailing nla_padlen(data_len)<br /> bytes (1-3 when data_len is not 4-byte aligned) are never initialized,<br /> leaking stale heap contents to userspace via the NFLOG netlink socket.<br /> <br /> Replace the manual attribute construction with nla_reserve(), which<br /> handles the tailroom check, header setup, and padding zeroing via<br /> __nla_reserve(). The subsequent skb_copy_bits() fills in the payload<br /> data on top of the properly initialized attribute.
Gravedad: Pendiente de análisis
Última modificación:
18/04/2026

CVE-2026-31426

Fecha de publicación:
13/04/2026
Idioma:
Inglés
*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ACPI: EC: clean up handlers on probe failure in acpi_ec_setup()<br /> <br /> When ec_install_handlers() returns -EPROBE_DEFER on reduced-hardware<br /> platforms, it has already started the EC and installed the address<br /> space handler with the struct acpi_ec pointer as handler context.<br /> However, acpi_ec_setup() propagates the error without any cleanup.<br /> <br /> The caller acpi_ec_add() then frees the struct acpi_ec for non-boot<br /> instances, leaving a dangling handler context in ACPICA.<br /> <br /> Any subsequent AML evaluation that accesses an EC OpRegion field<br /> dispatches into acpi_ec_space_handler() with the freed pointer,<br /> causing a use-after-free:<br /> <br /> BUG: KASAN: slab-use-after-free in mutex_lock (kernel/locking/mutex.c:289)<br /> Write of size 8 at addr ffff88800721de38 by task init/1<br /> Call Trace:<br /> <br /> mutex_lock (kernel/locking/mutex.c:289)<br /> acpi_ec_space_handler (drivers/acpi/ec.c:1362)<br /> acpi_ev_address_space_dispatch (drivers/acpi/acpica/evregion.c:293)<br /> acpi_ex_access_region (drivers/acpi/acpica/exfldio.c:246)<br /> acpi_ex_field_datum_io (drivers/acpi/acpica/exfldio.c:509)<br /> acpi_ex_extract_from_field (drivers/acpi/acpica/exfldio.c:700)<br /> acpi_ex_read_data_from_field (drivers/acpi/acpica/exfield.c:327)<br /> acpi_ex_resolve_node_to_value (drivers/acpi/acpica/exresolv.c:392)<br /> <br /> <br /> Allocated by task 1:<br /> acpi_ec_alloc (drivers/acpi/ec.c:1424)<br /> acpi_ec_add (drivers/acpi/ec.c:1692)<br /> <br /> Freed by task 1:<br /> kfree (mm/slub.c:6876)<br /> acpi_ec_add (drivers/acpi/ec.c:1751)<br /> <br /> The bug triggers on reduced-hardware EC platforms (ec-&gt;gpe
Gravedad CVSS v3.1: ALTA
Última modificación:
27/04/2026