Vulnerabilidad (seguridad informática)

Las vulnerabilidades pueden verse agravadas por factores de diseño deficientes, como por ejemplo:

• Complejidad: Los sistemas grandes y complejos aumentan la posibilidad de fallos y puntos de acceso no deseados. ^{[ 11 ]}
• Familiaridad: El uso de código, software, sistemas operativos y/o hardware comunes y conocidos aumenta la probabilidad de que un atacante tenga o pueda encontrar el conocimiento y las herramientas para explotar la vulnerabilidad. ^{[ 12 ]} Sin embargo, el uso de software conocido, en particular software libre y de código abierto , ofrece la ventaja de contar con parches de software más frecuentes y confiables para cualquier vulnerabilidad descubierta.
• Conectividad: cualquier sistema conectado a internet puede ser accedido y comprometido. Desconectar los sistemas de internet puede ser extremadamente eficaz para prevenir ataques, pero no siempre es factible. ^{[ 13 ]}
• El software y hardware heredados tienen un mayor riesgo por naturaleza. ^{[ 14 ]} Los administradores de sistemas deberían considerar la actualización de los sistemas heredados, pero esto suele ser prohibitivo en términos de costo y tiempo de inactividad .

Las malas prácticas de desarrollo de software pueden afectar la probabilidad de introducir vulnerabilidades en una base de código. La falta de conocimiento o capacitación en desarrollo de software seguro, la presión excesiva para cumplir con los plazos de entrega o una base de código excesivamente compleja pueden permitir que se introduzcan vulnerabilidades y pasen desapercibidas. Estos factores también pueden agravarse si la seguridad no es una prioridad para la cultura de la empresa . ^{[ 15 ]} Las revisiones de código inadecuadas también pueden llevar a que se pasen por alto errores, pero existen herramientas de análisis de código estático que se pueden usar durante el proceso de revisión de código para ayudar a encontrar algunas vulnerabilidades. ^{[ 16 ]}

DevOps , un flujo de trabajo de desarrollo que enfatiza las pruebas y la implementación automatizadas para acelerar la implementación de nuevas funciones, a menudo requiere que se otorgue a muchos desarrolladores acceso para cambiar configuraciones, lo que puede llevar a la inclusión deliberada o inadvertida de vulnerabilidades. ^{[ 17 ]} La compartimentación de dependencias, que suele ser parte de los flujos de trabajo de DevOps, puede reducir la superficie de ataque al limitar las dependencias a solo lo necesario. ^{[ 18 ]} Si se utiliza software como servicio , en lugar del hardware y software propios de la organización, esta depende del proveedor de servicios en la nube para prevenir vulnerabilidades. ^{[ 19 ]}

La Base de Datos Nacional de Vulnerabilidades clasifica las vulnerabilidades en ocho causas raíz que pueden superponerse, entre ellas: ^{[ 20 ]}

1. Existen vulnerabilidades de validación de entrada cuando la comprobación de la entrada no es suficiente para impedir que el atacante inyecte código malicioso. Los exploits de desbordamiento de búfer , los exploits de subdesbordamiento de búfer y los exploits de condiciones límite suelen aprovechar esta categoría. ^{[ 21 ]}
2. Las vulnerabilidades de control de acceso permiten a un atacante acceder a un sistema que se supone que está restringido para él, o realizar una escalada de privilegios . ^{[ 21 ]}
3. Cuando el sistema no maneja correctamente una condición excepcional o imprevista, un atacante puede explotar la situación para obtener acceso. ^{[ 22 ]}
4. Las vulnerabilidades de configuración surgen cuando los ajustes de configuración generan riesgos para la seguridad del sistema, lo que conlleva fallos como software sin parchear o permisos del sistema de archivos que no restringen suficientemente el acceso. ^{[ 22 ]}
5. Una condición de carrera —cuando el momento u otros factores externos cambian el resultado y conducen a resultados inconsistentes o impredecibles— puede causar una vulnerabilidad. ^{[ 22 ]}

Se pueden introducir fallos de seguridad deliberados durante o después de la fabricación, lo que provoca que el circuito integrado no funcione como se espera en determinadas circunstancias. La detección de fallos de seguridad en el hardware resulta bastante difícil debido al tiempo limitado y a la complejidad de los chips del siglo XXI, ^{[ 23 ]} mientras que la globalización del diseño y la fabricación ha aumentado la probabilidad de que agentes maliciosos introduzcan estos fallos. ^{[ 24 ]}

Aunque las vulnerabilidades de los sistemas operativos varían según el sistema operativo utilizado, un problema común son los errores de escalada de privilegios que permiten al atacante obtener más acceso del que debería tener. Los sistemas operativos de código abierto, como Linux y Android, tienen un código fuente de libre acceso y permiten que cualquiera contribuya, lo que podría facilitar la introducción de vulnerabilidades. Sin embargo, las mismas vulnerabilidades también se presentan en sistemas operativos propietarios como Microsoft Windows y los sistemas operativos de Apple . ^{[ 25 ]} Todos los proveedores de sistemas operativos de renombre proporcionan parches periódicamente. ^{[ 26 ]}

Las aplicaciones cliente-servidor se descargan en los ordenadores del usuario final y, por lo general, se actualizan con menos frecuencia que las aplicaciones web. A diferencia de las aplicaciones web, interactúan directamente con el sistema operativo del usuario. Las vulnerabilidades comunes en estas aplicaciones incluyen: ^{[ 27 ]}

• Los datos no cifrados que se encuentran en almacenamiento permanente o que se envían a través de una red son relativamente fáciles de robar para los atacantes. ^{[ 27 ]}
• El secuestro de procesos ocurre cuando un atacante toma el control de un proceso informático existente . ^{[ 27 ]}

Las aplicaciones web se ejecutan en muchos sitios web. Debido a que son inherentemente menos seguras que otras aplicaciones, son una fuente importante de filtraciones de datos y otros incidentes de seguridad. ^{[ 28 ] [ 29 ]} Pueden incluir:

• Los fallos de autenticación y autorización permiten a los atacantes acceder a datos que deberían estar restringidos a usuarios de confianza. ^{[ 28 ] [ 30 ]}
• La vulnerabilidad de la lógica de negocio se produce cuando los programadores no tienen en cuenta los casos inesperados que surgen en la lógica de negocio .

Los ataques utilizados contra las vulnerabilidades en las aplicaciones web incluyen:

• El cross-site scripting (XSS) permite a los atacantes inyectar y ejecutar malware basado en JavaScript cuando la comprobación de entrada es insuficiente para rechazar el código inyectado. ^{[ 28 ]} El XSS puede ser persistente, cuando los atacantes guardan el malware en un campo de datos y lo ejecutan cuando se cargan los datos; también puede cargarse mediante un enlace URL malicioso (XSS reflejado). ^{[ 28 ]} Los atacantes también pueden insertar código malicioso en el modelo de objetos de dominio . ^{[ 31 ]}
• La inyección SQL y ataques similares manipulan las consultas de la base de datos para obtener acceso no autorizado a los datos. ^{[ 31 ]}
• La inyección de comandos es una forma de inyección de código en la que el atacante coloca el malware en campos de datos o procesos. El atacante podría llegar a tomar el control de todo el servidor. ^{[ 31 ]}
• La falsificación de solicitudes entre sitios (CSRF) consiste en crear solicitudes de cliente que realizan acciones maliciosas, como que un atacante cambie las credenciales de un usuario. ^{[ 31 ]}
• La falsificación de solicitudes del lado del servidor es similar a CSRF, pero la solicitud se falsifica desde el lado del servidor y a menudo explota los privilegios mejorados del servidor. ^{[ 31 ]}
• La vulnerabilidad de la lógica de negocio se produce cuando los programadores no consideran los casos inesperados que surgen en la lógica de negocio. ^{[ 32 ]}

La remediación corrige las vulnerabilidades, por ejemplo, mediante la descarga de un parche de software . ^{[ 40 ]} Los escáneres de vulnerabilidades generalmente no pueden detectar vulnerabilidades de día cero, pero son más eficaces para encontrar vulnerabilidades conocidas basadas en una base de datos. Estos sistemas pueden encontrar algunas vulnerabilidades conocidas y recomendar correcciones, como un parche. ^{[ 41 ] [ 42 ]} Sin embargo, tienen limitaciones, incluidos los falsos positivos . ^{[ 40 ]}

Las vulnerabilidades solo pueden explotarse cuando están activas, es decir, cuando el software en el que están integradas se está ejecutando activamente en el sistema. ^{[ 43 ]} Antes de que el código que contiene la vulnerabilidad se configure para ejecutarse en el sistema, se considera un portador. ^{[ 44 ]} Las vulnerabilidades latentes pueden ejecutarse, pero actualmente no lo están. El software que contiene vulnerabilidades latentes y portadoras a veces puede desinstalarse o deshabilitarse, eliminando el riesgo. ^{[ 45 ]} Las vulnerabilidades activas, si se distinguen de los otros tipos, pueden priorizarse para su parcheo. ^{[ 43 ]}

La mitigación de vulnerabilidades son medidas que no cierran la vulnerabilidad, pero dificultan su explotación o reducen las consecuencias de un ataque. ^{[ 46 ]} Reducir la superficie de ataque , particularmente para las partes del sistema con acceso de root (administrador), y cerrar las oportunidades para que los exploits realicen una explotación de privilegios es una estrategia común para reducir el daño que puede causar un ciberataque. ^{[ 40 ]} Si no hay un parche disponible para el software de terceros, puede ser posible deshabilitar temporalmente el software. ^{[ 47 ]}

Una prueba de penetración intenta acceder al sistema mediante una vulnerabilidad para comprobar si es inseguro. ^{[ 48 ]} Si una prueba de penetración falla, no significa necesariamente que el sistema sea seguro. ^{[ 49 ]} Algunas pruebas de penetración se pueden realizar con software automatizado que prueba vulnerabilidades conocidas con exploits existentes. ^{[ 50 ]} Otras pruebas de penetración las realizan hackers capacitados. Muchas empresas prefieren subcontratar este trabajo, ya que simula un ataque externo. ^{[ 49 ]}

Una escala comúnmente utilizada para evaluar la gravedad de las vulnerabilidades es el Sistema Común de Puntuación de Vulnerabilidades (CVSS), una especificación de código abierto. El CVSS evalúa la posibilidad de explotar la vulnerabilidad y comprometer la confidencialidad, disponibilidad e integridad de los datos. También considera cómo podría utilizarse la vulnerabilidad y la complejidad necesaria para su explotación. El nivel de acceso requerido para la explotación y la posibilidad de que esta se realice sin interacción del usuario también se tienen en cuenta en la puntuación final. ^{[ 63 ] [ 64 ]}

Alguien que descubre una vulnerabilidad puede revelarla inmediatamente ( divulgación completa ) o esperar hasta que se haya desarrollado un parche ( divulgación responsable o divulgación coordinada). El primer enfoque es elogiado por su transparencia, pero el inconveniente es que el riesgo de ataque probablemente aumente después de la divulgación sin un parche disponible. ^{[ 65 ]} Algunos proveedores pagan recompensas por errores a quienes les informan sobre vulnerabilidades. ^{[ 66 ] [ 67 ]} No todas las empresas responden positivamente a las divulgaciones, ya que pueden causar responsabilidad legal y gastos operativos. ^{[ 68 ]} No existe ninguna ley que exija la divulgación de vulnerabilidades. ^{[ 69 ]} Si una vulnerabilidad es descubierta por un tercero que no la divulga al proveedor ni al público, se denomina vulnerabilidad de día cero , a menudo considerada el tipo más peligroso porque existen menos defensas. ^{[ 70 ]}

El conjunto de datos de vulnerabilidades más utilizado es Common Vulnerabilities and Exposures (CVE), mantenido por Mitre Corporation . ^{[ 71 ]} A abril de 2026, cuenta con más de 327 000 entradas. ^{[ 1 ]} Esta información se comparte con otras bases de datos, incluida la Base de Datos Nacional de Vulnerabilidades de Estados Unidos , ^{[ 71 ]} donde a cada vulnerabilidad se le asigna una puntuación de riesgo utilizando el Sistema Común de Puntuación de Vulnerabilidades (CVSS), el esquema de Enumeración de Plataforma Común (CPE) y la Enumeración Común de Debilidades . CVE y otras bases de datos generalmente no registran vulnerabilidades en productos de software como servicio . ^{[ 41 ]} El envío de un CVE es voluntario para las empresas que descubren una vulnerabilidad. ^{[ 69 ]}