Cuando recibes el informe final de un pentest, cada hallazgo viene con una etiqueta que dice qué tipo de problema es. No es solo un detalle de formato: esa etiqueta te dice de entrada qué clase de riesgo estás mirando y qué tan urgente es actuar, incluso antes de leer el detalle técnico completo. Acá te explicamos, en lenguaje simple, los tipos de hallazgo que más aparecen en una evaluación real y qué se espera que hagas con cada uno.
Credenciales expuestas
Es de los hallazgos más directos: contraseñas, llaves de API o algún otro secreto quedaron accesibles en algún punto de la superficie evaluada — un archivo de configuración público, un repositorio de código, el código que le llega al navegador del usuario. El riesgo es concreto: quien encuentre esa credencial no necesita romper ningún control adicional, simplemente entra con ella como si fuera un usuario legítimo.
La recomendación siempre es la misma: rotar de inmediato la credencial afectada, retirarla del lugar donde quedó expuesta, y adoptar un mecanismo serio de gestión de secretos (bóveda de credenciales, variables de entorno protegidas) en vez de dejarlas sueltas en el código o en archivos de configuración.
Vulnerabilidad conocida (CVE)
Acá el hallazgo es un componente de software —un CMS, una librería, el servidor web mismo— con una vulnerabilidad pública ya documentada. En la práctica, casi siempre es la misma historia: un parche que existía y que nunca se aplicó. Es uno de los orígenes más comunes de incidentes reales, precisamente porque no requiere que el atacante descubra nada nuevo: la información ya es pública.
La corrección es actualizar el componente a una versión que resuelva la vulnerabilidad reportada, y confirmar con una nueva verificación que el parche realmente cerró el problema.
Servicio expuesto públicamente
Un puerto o servicio queda accesible desde una red que no debería poder llegar a él. No siempre es explotable por sí solo durante la evaluación, pero amplía la superficie de ataque disponible — es una puerta más que alguien puede intentar forzar, y entre menos puertas expuestas sin necesidad real, mejor.
Lo primero es validar si esa exposición responde a una necesidad de negocio real. Si no la tiene, la corrección es restringir el acceso con controles perimetrales (firewall, VPN) o desactivar el servicio directamente.
Subdomain takeover
Es de los hallazgos que más sorprenden cuando se explican bien. Un subdominio de tu organización tiene un registro DNS apuntando a un recurso de un servicio en la nube que ya no está reclamado por nadie —una cuenta cerrada, un servicio dado de baja. Cualquiera puede registrar ese mismo recurso en el proveedor cloud y empezar a servir contenido propio bajo tu subdominio, sin comprometer ningún sistema tuyo: phishing con apariencia legítima, robo de sesión o cookies del dominio principal, o directamente daño reputacional.
La corrección es simple y urgente: eliminar el registro DNS colgante, o reclamar el recurso en el proveedor correspondiente antes de que alguien más lo haga.
Por qué el tipo no reemplaza al contexto
Ninguno de estos tipos te dice por sí solo qué tan grave es el hallazgo en tu caso particular —para eso está el puntaje CVSS que acompaña a cada uno. Una credencial expuesta puede ser crítica si abre acceso a producción, o menor si era una llave de prueba ya revocada. Un buen informe siempre explica el contexto real detrás de la etiqueta, no se queda solo en el nombre del tipo de hallazgo. Si quieres saber qué otras señales distinguen a un informe que realmente sirve, ya escribimos sobre cómo reconocer uno bueno.
Si te encontraste con alguno de estos tipos en un informe propio y no tienes claro por dónde empezar a priorizar, escríbenos — sin compromiso, revisamos el caso concreto contigo.
ConversemosRecibe los posts nuevos
Un correo cuando publicamos algo nuevo. Sin spam, date de baja cuando quieras.