¡Vaya! Un error de inyección SQL acaba de forzar un parche de emergencia en el core de WordPress la semana pasada.
El 17 de julio, WordPress lanzó una versión de emergencia para corregir una vulnerabilidad de ejecución remota de código no autenticada en el core, accesible a través de una inyección SQL que un atacante anónimo puede explotar en una instalación estándar. WordPress.org incluso activó las actualizaciones automáticas forzadas debido a su gravedad. Searchlight Cyber, quienes lo reportaron, estiman que más de 500 millones de sitios utilizan WordPress. Si estás afectado, actualiza a la Versión 7.0.2 y a la 6.9.5 para la rama anterior.
La inyección SQL, también estilizada como SQLi, es una vulnerabilidad antigua con una solución sencilla, por lo que la gente asume que ha muerto. Pero como acabamos de recordar, no es así.
Inyección SQL: Desde sus humildes comienzos hasta la actualidad
La inyección SQL y sus soluciones forman parte de las clases básicas de Informática. Recuerdo haber aprendido sobre la inyección de prompts en la universidad hace más de una década y, sinceramente, es la única vulnerabilidad basada en aplicaciones que recuerdo que enseñaran (creo que pasaron a otros temas después de cubrirlo, o quizás no presté atención después de eso).
La inyección SQL fue documentada públicamente en 1998 por el investigador conocido como rainforest puppy. La solución que resuelve la mayoría de los problemas de SQLi, las prepared statements, se descubrió aproximadamente un año después. La solución es más antigua que muchos ingenieros de la empresa. Utilice consultas parametrizadas y mantenga la entrada del usuario como datos. Pero incluso con una solución disponible, las inyecciones SQL siguen ocurriendo.
Según los datos de la base de datos de avisos de GitHub, filtrando los avisos por CWE y contando por año:
El número de avisos de inyección SQL aumentó cada año completo de 2023 a 2025, pasando de 2.096 a 2.850. Las tres clases de inyección más antiguas juntas, inyección SQL, inyección de comandos y path traversal, todavía representan más de una de cada diez de todas las vulnerabilidades reportadas.
OWASP movió la inyección del tercer al quinto puesto en su Top 10 de 2025, pero no porque las cosas estén solucionadas. La categoría general de inyección sigue acumulando más CVEs reportados que cualquier otra, con más de 60.000 registrados. De estos, solo la inyección SQL sumó más de 14.000. En los escaneos de Mackenzie de repositorios de código cerrado, el 20% de los proyectos presentaban al menos una vulnerabilidad de inyección SQL en su primer análisis.
¿Por qué la inyección SQL se niega a desaparecer?
Primero, para dejarlo claro, la gente comete errores al escribir código. Sucede. Así que, de vez en cuando, una SQLi se colará. Pero los sistemas modernos que deberían ayudarnos no lo hacen al cien por cien de las veces, e incluso pueden llevarnos a cometer errores diferentes.
Por ejemplo, los frameworks más recientes disponen de métodos para ayudar a prevenir la inyección SQL. Los ORM como Django, Hibernate y ActiveRecord parametrizan por defecto, lo que convence a muchos equipos de que el problema está resuelto. Pero si alguien recurre a una consulta raw o utiliza un método inseguro, la protección desaparece.
El CVE-2024-42005 de Django es un ejemplo. Dos de los propios métodos de consulta de Django, utilizados para leer campos de una columna JSON, insertaban los nombres de campo que se pasaban directamente en el SQL sin limpiarlos, de modo que un atacante que controlara un nombre podía controlar parte de la consulta, a través de un método que los equipos asumían como seguro.
Por otro lado, el código realmente antiguo también es un problema, ya que el código heredado arrastra estas vulnerabilidades durante décadas. Los equipos se apoyan en un WAF y asumen (rezan) que lo detecta todo. Aunque la solución existe desde hace más de 25 años, aplicarla en cada consulta, cada endpoint y cada rincón heredado, cada vez, es un trabajo tedioso que nunca se ha completado por completo en todas las bases de código. Tal como lo enmarca Mackenzie Jackson, nuestro CTO de campo, esto dejó de ser un problema técnico para convertirse en uno cultural, de proceso y de educación.
Y, por supuesto, la IA.
La IA también escribe SQLi
La esperanza obvia es que los asistentes de codificación de IA, entrenados con décadas de ejemplos, dejaran de reproducir un error de 1998. Pero como sabemos, la IA no escribe código perfecto.
Podemos analizar esto cuantitativamente. El estudio de 2021 Asleep at the Keyboard de NYU y Cornell generó 1.689 programas a partir de GitHub Copilot en escenarios de debilidades comunes y encontró que aproximadamente el 40% eran vulnerables, siendo la inyección SQL y la inyección de comandos las más frecuentes. La propia prueba de Mackenzie arroja resultados similares. Al ejecutar un mismo prompt en ChatGPT varios cientos de veces, aproximadamente el 12% de los resultados eran inyectables, una cifra cercana a la tasa en código abierto.
¿Pero por qué? Los modelos aprenden del código público que contiene estas vulnerabilidades, por lo que las reproducen con una frecuencia similar. La IA gestiona la inyección SQL mejor que los errores dependientes del contexto, como el cross-site scripting, donde el mismo informe encontró que la mayoría de las salidas eran inseguras. La IA sigue mejorando, por lo que estas cifras quedarán desactualizadas en seis meses, pero podemos esperar que la IA siga escribiendo esto accidentalmente, al igual que nosotros.
Y ahora, más "vibe-coders" y personas con menos formación técnica están escribiendo código. Es menos probable que reconozcan las inyecciones SQL (si es que saben buscarlas), por lo que más código puede entrar en la base de código de la empresa sin que ojos expertos se aseguren de que este problema se tenga en cuenta.
Por eso hay que tener un respaldo
Incluso si haces todo correctamente, como consultas parametrizadas en todas partes, listas blancas en cada entrada, lo que sea... Aun así, querrás protección en tiempo de ejecución. Una sanitización perfecta en cada endpoint, para siempre, no es algo real. La SQLi podría incluso ocurrir en una dependencia vulnerable que no controlas (o, por ejemplo, en el sitio por defecto de un proveedor de hosting), lo cual está más allá de lo que puedes gestionar razonablemente.
Aikido Zen es un firewall integrado en la aplicación que se ejecuta dentro de tu aplicación y monitoriza la entrada del usuario a medida que se dirige hacia un sumidero de datos, como una consulta de base de datos o una lectura de archivo.
Cuando una carga útil de ataque está a punto de alcanzar uno de estos lugares, Zen la bloquea al instante, con suficiente contexto de la aplicación para distinguir un ataque de una cadena de búsqueda que casualmente se le parece.
También cubre vulnerabilidades que llegan a través de dependencias, donde tus propios estándares de codificación no alcanzan. Trátalo como un respaldo en tiempo de ejecución para cuando la codificación segura se queda corta, lo cual en la práctica siempre ocurre. Zen es RASP, que entiende las entradas peligrosas a nivel de código. Esto es diferente de un WAF que bloquea las entradas sospechosas a nivel de red, lo cual es menos preciso y, por lo tanto, tiende a bloquear demasiado. Profundizo en esto con mucho más detalle en nuestra publicación sobre WAF vs RASP vs ADR.
Un firewall integrado en la aplicación como Zen se interpone entre wp2shell y un sitio WordPress sin parchear. Zen está diseñado para bloquear la inyección SQL en la que se basa esta vulnerabilidad, de modo que un sitio que esperaba la actualización aún tenía una defensa mientras se implementaba el parche.
Detecta inyecciones SQL en tu rama de desarrollo
El runtime es la red de seguridad, pero la prevención es, por supuesto, el estándar de oro. Idealmente, encontramos y eliminamos todas las inyecciones SQL en el código.
El análisis estático como SAST detecta muchas inyecciones SQL, las de tipo simple donde la entrada se introduce en una consulta sin una sentencia parametrizada. No habría detectado esta. El núcleo de WordPress está tan escaneado como cualquier software, y este error no fue detectado. En este caso, la inyección solo se vuelve explotable cuando una solicitud por lotes malformada desajusta la contabilidad interna de WordPress, de modo que el valor llega a la base de datos a través de una ruta que omite la limpieza. Esa es una interacción entre solicitudes que un escáner estático no puede seguir. Encontrar esta vulnerabilidad requirió un modelo de frontera ejecutando cuatro agentes durante seis horas.
La inyección cotidiana es trabajo de tu escáner. El tipo de inyección oculta y dependiente de la lógica requiere cada vez más una IA para encontrarla antes de que lo haga otra persona, como es el caso de Aikido AI pentesting y dirigirla a tu propio código de la misma manera que este investigador la dirigió a WordPress. Aikido ofrece pentesting continuo con Aikido Infinite, lo que puede ayudarte a verificar regularmente cualquier nueva SQLi que pueda intentar pasar por la revisión de código.
Little Bobby Tables sigue vivo y sano. Tómalo en serio y protege tu código, incluso lo más trivial.
