Abril 2026CríticaCVSS 9.8Objetivo: Aplicación web corporativa

Inyección SQL ciega en cabecera HTTP con ruta abierta a ejecución de comandos del sistema

Inyección SQL ciega basada en tiempo en una cabecera HTTP no estándar. El usuario de la base de datos tenía privilegios de administrador, lo que abría la vía a la ejecución de comandos del sistema mediante procedimientos almacenados.

CWE-89
CWE-78
SQLi
RCE
Header Injection

Resumen

El valor de la cabecera llegaba a la base de datos desde el registro de la aplicación, concatenado en la consulta. Esa cabecera atraviesa proxies y balanceadores, así que cualquiera podía alcanzar el punto de entrada.

La inyección admitía stacked queries: la consulta original podía encadenarse con instrucciones nuevas. Con ese nivel de acceso, los procedimientos almacenados del sistema quedaban al alcance.

Detalles técnicos

Vector de inyección

La aplicación registraba en base de datos el valor de ciertas cabeceras HTTP:

Petición HTTP: punto de inyección

GET /[REDACTED]/errors.aspx HTTP/2
Host: [REDACTED]
Cookie: [REDACTED]
X-Forwarded-For: [PAYLOAD]
User-Agent: Mozilla/5.0 ...

Confirmación de la inyección

Lo confirmamos con cargas basadas en tiempo, que retrasaban la respuesta cuando la condición evaluada era verdadera:

Carga: inyección ciega basada en tiempo

X-Forwarded-For: [PREFIX]'); IF ([CONDITION]) WAITFOR DELAY '0:0:5'--
 
[+] Retardo de 5 segundos detectado -> condición TRUE

Privilegios elevados

Verificamos que el usuario de la aplicación tenía privilegios de administrador en la base de datos:

Resultado

[+] El usuario de la aplicación tiene privilegios de administrador de base de datos
[+] Stacked queries soportadas
[+] Múltiples bases de datos accesibles en el servidor

Camino hasta la ejecución de comandos

Con privilegios de administrador, probamos los procedimientos almacenados que ejecutan comandos del sistema:

Indicios de RCE

X-Forwarded-For: [PREFIX]'); EXEC [stored_procedure] 'echo test';--
 
[!] Comportamiento compatible con un procedimiento de ejecución de comandos habilitado

Detuvimos la explotación en este punto: el sistema estaba en producción. No ejecutamos ningún comando más allá de la comprobación inocua ni extrajimos datos reales.

Reportamos el hallazgo al cliente de inmediato, con severidad crítica. El caso se publica anonimizado: no se identifican el cliente, sus sistemas ni sus datos.

El desglose de la clasificación CVSS, con su vector, consta en el informe entregado al cliente.

Impacto

Ejecución de comandos en el servidor de base de datos: la cadena quedó verificada hasta el paso previo al impacto
Acceso a las múltiples bases de datos alojadas en ese servidor
Exfiltración de los datos sensibles al alcance de la cuenta de base de datos comprometida
Movimiento lateral potencial dentro de la red interna
Compromiso del servidor y, potencialmente, del dominio

Remediación

Parametrizar todas las consultas SQL. Nunca concatenar valores de cabeceras HTTP en una consulta: usar sentencias preparadas.
Reducir los privilegios del usuario de la aplicación. La conexión a base de datos no debe ejecutarse con una cuenta administradora.
Deshabilitar los procedimientos de ejecución de comandos. Mantenerlos activos solo cuando un proceso concreto los necesite.
Tratar las cabeceras HTTP como entrada no confiable. Validar longitud y formato antes de almacenarlas, sin que esa validación sustituya a la consulta parametrizada.
Revisar la configuración del WAF. Las reglas deben cubrir inyecciones en cabeceras no estándar.