CVE-2019-1068: CISA puso en su lista de explotadas una falla de SQL Server parcheada en 2019 — y nadie publicó todavía cómo se usa en ataques reales
La agencia de ciberseguridad de Estados Unidos sumó el CVE-2019-1068 a su catálogo de vulnerabilidades explotadas, y el número del principio no es un error de tipeo: la falla de Microsoft SQL Server se publicó en julio de 2019 y el arreglo salió ese mismo mes. Siete años después, CISA dice tener evidencia de que alguien la está usando, y les puso a las agencias federales plazo hasta el sábado 29 de agosto.
Lo que hace rara a esta historia: todavía nadie publicó cómo se está usando en ataques reales, y el análisis técnico que sí encontramos —de 2021— termina diciendo que sus autores no consiguieron ejecutar código, sino colgar el servidor.
Lo que vas a encontrar acá
- Qué dice exactamente el catálogo de CISA
- Qué versiones de SQL Server están en la lista
- El análisis de 2021 que solo consiguió un cuelgue
- El lote entero es de vulnerabilidades viejas
- Lo que la ficha de Microsoft sigue diciendo
- ¿Y esto qué significa para vos?
- Preguntas frecuentes
El CVE-2019-1068 entró al catálogo de CISA con plazo de tres días
El Known Exploited Vulnerabilities Catalog (KEV) de CISA es la lista de las fallas que la agencia considera que se están usando en ataques reales: no es un «esto podría pasar», porque para entrar hace falta evidence of active exploitation. El aviso oficial del 26 de agosto sumó seis, y la tercera es la de SQL Server.
La ficha del catálogo describe el alcance sin adornos: «Microsoft SQL Server contiene una vulnerabilidad de ejecución remota de código que podría permitirle a un atacante ejecutar código en el contexto de la cuenta de servicio del motor de base de datos». Traducido: si funciona, el atacante no queda con permisos de un usuario cualquiera, sino con los de la cuenta que hace correr al motor.
| Dato | Valor |
|---|---|
| Identificador | CVE-2019-1068 |
| Producto | Microsoft SQL Server (motor de base de datos) |
| Publicada | 15 de julio de 2019 (registro en MITRE) |
| Actualizaciones de seguridad | 9 de julio de 2019 (historial de compilaciones de Microsoft) |
| Agregada al KEV | 26 de agosto de 2026 |
| Plazo para agencias federales de EE. UU. | 29 de agosto de 2026 |
| Puntaje CVSS 3.1 | 8.8 (alto) |
| Requiere autenticación | Sí — el atacante ya tiene que poder consultar la base |
| Uso conocido en ransomware | «Unknown», según la propia ficha de CISA |
| Entre la publicación del CVE y la alarma | Siete años y un mes, un récord difícil de celebrar |
Ese plazo de tres días no es el habitual: de las seis del lote, cuatro vencen el 9 de septiembre y solo ésta y la de Citrix el 29 de agosto. La instrucción remite a la directiva BOD 26-04, que prioriza las actualizaciones según el riesgo, y agrega la salida que ya es estándar en CISA: si no hay mitigación, se discontinúa el uso del producto.
Qué versiones de SQL Server están en la lista de afectadas
Acá la noticia deja de ser una curiosidad de archivo. El registro del CVE en MITRE y la ficha del boletín de Microsoft listan los mismos productos, y no son exóticos.
| Versión | ¿La alcanza el CVE-2019-1068? | Situación de soporte |
|---|---|---|
| SQL Server 2014 (SP2 y SP3) | Sí | Soporte extendido terminado. Corre el año 3 de actualizaciones extendidas pagas, hasta el 12 de julio de 2027 |
| SQL Server 2016 (SP1 y SP2) | Sí | Soporte extendido terminado el 14 de julio de 2026. Desde el 15 de julio corre el año 1 de actualizaciones extendidas pagas, y el programa llega hasta 2029 |
| SQL Server 2017 | Sí | Soporte de Microsoft hasta el 12 de octubre de 2027 |
| SQL Server 2019 | No figura entre las afectadas (salió en noviembre de 2019, cuatro meses después del parche) | Soporte de Microsoft hasta el 8 de enero de 2030 |
Las fechas de la columna derecha salen de las páginas de ciclo de vida de Microsoft: la de productos que terminan soporte en 2026 pone a SQL Server 2016 el 14 de julio de este año, la de 2027 ubica a SQL Server 2017 el 12 de octubre del año que viene, y la de 2030 le da a SQL Server 2019 hasta el 8 de enero de ese año.
O sea que de las tres versiones alcanzadas, dos ya se quedaron sin soporte gratuito. Eso no significa que estén desprotegidas frente a esta falla puntual —el parche de 2019 sigue existiendo y se puede instalar—, pero sí que, de acá en adelante, los arreglos solo llegan si los pagás: pasan a depender de las Extended Security Updates. La página de Microsoft sobre las ESU de SQL Server lo dice sin rodeos: «hay ESU disponibles para SQL Server 2014 y SQL Server 2016», y aclara que las de 2016 vienen con un cambio en la estructura de precios. Es la misma película que ya vimos con el fin de soporte de Windows 10 LTSC 2021 y su prórroga paga, ahora en la sala de servidores.
Ese «cambio en la estructura de precios» tiene letra chica. Mover la carga a una máquina virtual de Azure era la vía para conseguir las extendidas sin pagarlas aparte, y ya no aplica igual para todos: «los clientes de SQL Server 2014 reciben ESU gratuitas cuando migran sus cargas de trabajo a SQL Server en máquinas virtuales de Azure. Los clientes de SQL Server 2016 pueden suscribirse para recibir ESU al registrarse con la extensión SQL IaaS Agent, pero no son elegibles para ESU gratuitas». Traducido: el que está en 2016 paga, se mude a Azure o no.
Cómo saber en qué versión estás parado
Microsoft resuelve esto con un número de compilación, no con el nombre comercial. La ficha del boletín cruza rangos de versión con la actualización que corresponde —hay dos ramas, GDR y CU, y el pasaje de GDR a CU es de ida: se puede hacer una sola vez y no hay vuelta atrás— y remite al KB 321185, el historial de compilaciones de SQL Server. Ahí se ve que el paquete que corrige esto en 2016 SP1 es la compilación 13.0.4604.0, del 9 de julio de 2019. Y la advertencia de la ficha sigue vigente siete años después: si tu compilación no aparece en esa tabla, tu SQL Server ya no está soportado.
El análisis técnico que hay en público terminó en un cuelgue, no en un ataque
Y acá viene la parte incómoda: cuando una vulnerabilidad entra al KEV suele haber al menos un informe que cuente quién la usa y para qué. Con ésta, no. The Hacker News lo dice sin vueltas: por ahora no hay información pública sobre cómo se está explotando el CVE-2019-1068.
El silencio se nota por omisión: BleepingComputer cubrió el mismo anuncio y le dedicó la nota entera a Citrix — no menciona a SQL Server ni una vez. Cuando hay campaña que contar, se cuenta.
Que no haya informe no significa que no haya herramienta: desde 2021 hay un código de prueba público, de los propios investigadores, que reproduce el cuelgue. No lo enlazamos porque no le sirve a nadie que administre un servidor, pero conviene saber que existe hace cinco años.
Lo que sí encontramos es un trabajo de ingeniería inversa de febrero de 2021, firmado por Fatih Erdogan, ingeniero de ciberseguridad en Turkish Airlines Technology, junto a otros dos investigadores. Reconstruyeron la falla comparando dos actualizaciones acumulativas hasta dar con la biblioteca parcheada, svl.dll: una función que valida rutas revisaba los dos primeros caracteres de la cadena del usuario, pero no el tercero. Con una consulta armada para ese hueco, el motor entra en recursión infinita y se queda sin pila.
El cierre del informe es el dato que cambia la lectura de todo:
«Según el portal del MSRC, esta vulnerabilidad parece derivar en un impacto de ejecución remota de código. Intentamos lograr ese impacto usando algunos métodos públicamente conocidos. Lamentablemente, parece derivar en una vulnerabilidad de denegación de servicio por agotamiento de pila.»
Fatih Erdogan, ingeniero de ciberseguridad — ver el análisis completo
Conviene ser preciso. Erdogan no dice que la falla sea inofensiva ni que Microsoft exagere: dice que su equipo, con las técnicas públicas de 2021, llegó hasta colgar el servidor y no más allá. Que ellos no lo consiguieran entonces no prueba que sea imposible ahora, y CISA no publica la evidencia con la que decide estas incorporaciones. Pero explica por qué esta entrada se lee distinto: hay un análisis que apunta a denegación de servicio y una agencia federal que la clasifica como ejecución remota de código.
El otro detalle que dejaron anotado: Microsoft parcheó esto en silencio. Hay ficha, boletín y actualización —y la ficha incluso marca la falla como divulgada públicamente—, pero ninguna publicación técnica que explicara qué se estaba arreglando. Ése fue el motivo por el que se pusieron a buscarla.
Cinco de las seis vulnerabilidades del lote son viejas
No es una excepción: es la norma. De las seis incorporaciones del 26 de agosto, cinco tienen más de cuatro años.
| CVE | Producto | Publicada | Antigüedad al entrar al KEV |
|---|---|---|---|
| CVE-2015-3246 | Red Hat libuser | 11 de agosto de 2015 | 11 años |
| CVE-2015-5287 | Red Hat ABRT | 7 de diciembre de 2015 | 10 años y 8 meses |
| CVE-2019-1068 | Microsoft SQL Server | 15 de julio de 2019 | 7 años y 1 mes |
| CVE-2021-23758 | Ajax.NET Professional | 3 de diciembre de 2021 | 4 años y 8 meses |
| CVE-2022-0995 | Kernel de Linux | 25 de marzo de 2022 | 4 años y 5 meses |
| CVE-2026-8452 | Citrix NetScaler ADC / Gateway | 30 de junio de 2026 | Casi 2 meses |
Las fechas salen del registro de cada CVE en MITRE, consultado uno por uno. Y para cuatro de las seis hay explicación publicada: según The Hacker News, las incorporaciones de CVE-2015-3246, CVE-2015-5287, CVE-2021-23758 y CVE-2022-0995 siguen a un informe de Cisco Talos sobre un grupo de cibercrimen chino rastreado como UAT-10147, que apunta a servidores web Windows y Linux en educación, medios, tecnología y videojuegos.
Fijate cuál falta en esa lista. Las dos que no aparecen son la de Citrix —que sí tiene telemetría publicada, con intentos contados y web shells identificados— y la de SQL Server. Las cuatro de Talos tienen campaña con nombre; ésta, no.
La moraleja es vieja y aburrida, que es justamente por qué funciona: las vulnerabilidades no se vencen. Estas fallas no volvieron porque hayan mutado, sino porque quedaron servidores donde nadie las cerró.
Dos organismos que no están midiendo lo mismo
Consultamos hoy, 27 de agosto, el registro del CVE en el sistema del Microsoft Security Response Center. Sigue marcando Exploited: No y clasifica la explotación como «Exploitation Less Likely», tanto para la versión más reciente como para las anteriores; la última revisión de esa ficha es de diciembre de 2019. Es la segunda vez en poco más de una semana: el 18 de agosto CISA sumó al mismo catálogo la falla del servicio IKE de Windows, cuya ficha también decía que la explotación era poco probable, y hoy sigue igual.
La aclaración justa es que no miden lo mismo: Microsoft califica cuán fácil parece explotarla el día del boletín, y CISA registra qué está pasando. Que una ficha de 2019 no se actualice sola no es una mentira — pero al administrador que googlea el CVE antes de priorizar el parche, el primer resultado le dice que se quede tranquilo.
¿Y esto qué significa para vos?
El plazo del 29 de agosto obliga a las agencias federales de Estados Unidos. Si tenés una PyME en Argentina, México o Chile, a vos no te obliga nadie — pero el KEV es el mejor indicador público y gratuito de qué están usando los atacantes esta semana. Traducido a tareas concretas, y en orden:
- Fijate qué versión corrés de verdad. No el nombre comercial: el número de compilación. Dos minutos, y define todo lo demás.
- Si estás en 2014, 2016 o 2017 sin actualizaciones desde hace años, instalá la última actualización disponible de tu línea base — la CU+GDR, no la CU sola. No es una sutileza: para SQL Server 2016 SP1, la última acumulativa pura es de mayo de 2019 y no trae el arreglo; el que lo trae es el paquete CU15+GDR, de julio de 2019.
- Revisá quién puede consultar la base. La falla necesita un atacante autenticado: lo que la vuelve un problema real es una cuenta de servicio con contraseña de 2018, un usuario de app con más permisos de los necesarios o una instancia expuesta a internet.
- Si estás en SQL Server 2016, hacé la cuenta del reemplazo contra la de las ESU. No por este CVE, que tiene parche, sino porque desde el 15 de julio los arreglos para lo que venga te salen plata aparte — y, a diferencia de los de 2014, los de 2016 no acceden a la versión gratuita ni migrando a Azure. Si el salto lo hacés ahora, una licencia de SQL Server 2019 Standard te saca de la lista de versiones afectadas y tiene soporte extendido de Microsoft hasta enero de 2030.
- Probá tus backups. Si el peor escenario documentado es que el motor se cuelgue, lo que duele es cuánto tardás en levantarlo.
Preguntas frecuentes sobre esta vulnerabilidad de SQL Server
¿Qué versiones de SQL Server afecta esta falla?
Microsoft lista SQL Server 2014 (Service Pack 2 y 3), SQL Server 2016 (Service Pack 1 y 2) y SQL Server 2017, en sus ramas GDR y CU. SQL Server 2019, 2022 y posteriores no figuran entre las versiones afectadas en la ficha oficial del boletín ni en el registro del CVE en MITRE.
¿Cómo sé si mi SQL Server ya tiene el parche?
Se comprueba por el número de compilación, no por el nombre de la versión. El KB 321185 de Microsoft mantiene la tabla de compilaciones e historial de versiones, y la ficha del boletín cruza cada rango con la actualización que corresponde. Si tu número no aparece en esa tabla, tu versión ya no tiene soporte.
¿Sirve de algo el parche si mi SQL Server 2016 ya no tiene soporte?
Sí. El soporte extendido de SQL Server 2016 terminó el 14 de julio de 2026, pero la actualización que corrige esta falla se publicó en 2019 y sigue disponible. Lo que cambió es que los arreglos futuros ya no vienen incluidos: dependen de una suscripción de Extended Security Updates, que Microsoft ofrece para 2014 y 2016.
¿El plazo del 29 de agosto también corre para mi empresa?
No. La fecha límite obliga únicamente a las agencias del Poder Ejecutivo civil federal de Estados Unidos, bajo la directiva BOD 26-04. Para el resto del mundo el catálogo es una recomendación, aunque sirve como señal de prioridad: indica qué fallas están siendo explotadas ahora mismo.
🛒 Te puede servir
¿Y vos qué opinás? Dejalo en los comentarios ⬇️
Pasá a una versión que sí tenga soporte →
