Inyección de comandos (command injection): guía 2026

La inyección de comandos, conocida en inglés como command injection u OS command injection, es una vulnerabilidad que permite a un atacante ejecutar comandos arbitrarios del sistema operativo en el servidor que aloja una aplicación. Ocurre cuando el código construye una llamada a la shell del sistema concatenando entrada del usuario sin control, de modo que datos que deberían ser tratados como texto acaban interpretándose como instrucciones. El resultado suele ser directo y devastador: ejecución remota de código (RCE) con los privilegios del proceso vulnerable y, en muchos casos, la toma completa del servidor.

Lo esencial: la inyección de comandos aparece cuando una aplicación pasa entrada no confiable a un intérprete de shell (/bin/sh, cmd.exe, PowerShell). Los metacaracteres de shell permiten encadenar comandos propios a un comando legítimo. La defensa correcta no es escapar caracteres, sino evitar la shell por completo y usar APIs que reciban los argumentos como una lista, junto con validación por allowlist y mínimo privilegio.

Qué es la inyección de comandos (OS command injection)

Muchas aplicaciones necesitan invocar utilidades del sistema: hacer un ping para comprobar conectividad, convertir una imagen con ImageMagick, comprimir un fichero o consultar un DNS. El problema surge cuando el desarrollador delega esa tarea en la shell del sistema y compone la orden mezclando una plantilla fija con datos que vienen del usuario. La shell no distingue entre lo que el programador quiso decir y lo que el atacante introduce: interpreta toda la cadena como una línea de comandos.

Esta clase de fallo está catalogada como CWE-78 (Improper Neutralization of Special Elements used in an OS Command) y forma parte de la categoría A03:2021 Injection del OWASP Top 10, la misma familia que la inyección SQL. Conviene no confundirla con la inyección de código (donde se inyecta código del propio lenguaje, por ejemplo mediante eval): en la inyección de comandos el destino es el intérprete de comandos del sistema operativo, no el runtime de la aplicación.

Cómo funciona el ataque: metacaracteres de shell

La clave del ataque son los metacaracteres, símbolos que la shell interpreta con un significado especial en lugar de tratarlos como texto literal. Los más útiles para un atacante son:

• ; ejecuta un comando tras otro de forma incondicional.
• | canaliza la salida de un comando hacia otro.
• && y || ejecutan el segundo comando según el éxito o el fracaso del primero.
• ` y $( ) sustitución de comandos: ejecutan lo que hay dentro y colocan su salida en la línea.
• & lanza el comando en segundo plano.
• Un salto de línea, que separa instrucciones igual que en un script.

Código vulnerable frente a código seguro

Consideremos una funcionalidad clásica: un panel que hace ping a una dirección facilitada por el usuario. En Python, la versión insegura invoca la shell concatenando la entrada:

# VULNERABLE: la entrada se interpreta por la shell
import os
ip = request.form["host"]
os.system("ping -c 1 " + ip)

Si el atacante envía como host el valor 127.0.0.1; cat /etc/passwd, la shell ejecuta primero el ping y a continuación su comando. Con 127.0.0.1 && id o $(whoami) obtiene información del sistema. A partir de ahí, descargar una reverse shell o un binario de post-explotación es trivial.

La versión segura no usa la shell y pasa los argumentos como una lista, de forma que la entrada del usuario nunca se interpreta como sintaxis:

# SEGURO: sin shell, argumentos como lista, con validación previa
import subprocess, ipaddress
ip = ipaddress.ip_address(request.form["host"])  # lanza excepción si no es una IP válida
subprocess.run(["ping", "-c", "1", str(ip)], shell=False, timeout=5)

En Node.js el mismo patrón se traduce en evitar child_process.exec (que abre una shell) y usar execFile o spawn pasando los argumentos por separado. En Java, la clave es ProcessBuilder con la lista de argumentos y sin construir una cadena para /bin/sh -c. La regla general es sencilla: nunca dejes que la entrada del usuario alcance un intérprete de shell.

Variantes: inyección ciega y basada en tiempo (blind)

No siempre la aplicación devuelve la salida del comando en la respuesta. Cuando no hay eco visible se habla de inyección de comandos ciega (blind), y el atacante recurre a canales indirectos para confirmar la ejecución.

• Basada en tiempo: inyecta un retardo controlado, por ejemplo ; sleep 10 en Linux o & timeout 10 en Windows. Si la respuesta tarda diez segundos más, la ejecución está confirmada. Es la misma lógica que la inyección SQL basada en tiempo.
• Fuera de banda (OAST): fuerza al servidor a generar tráfico saliente hacia un dominio controlado, con nslookup atacante.oast.example, curl o ping. La consulta DNS o HTTP que llega al servidor colaborador demuestra la ejecución incluso sin ningún cambio en la respuesta. Herramientas como Burp Collaborator o interactsh automatizan esta técnica, y esta lógica de exfiltración fuera de banda es la misma que se explota en un ataque SSRF, otra vulnerabilidad de la familia de inyección.
• Redirección a un fichero legible: escribir la salida en la raíz web con > /var/www/html/out.txt y leerla después por HTTP.

Para automatizar la detección y explotación existe commix, una herramienta open source especializada en command injection que prueba de forma sistemática metacaracteres, técnicas ciegas y basadas en tiempo. En una auditoría manual, Burp Suite sigue siendo el pivote para interceptar y modificar los parámetros sospechosos.

Impacto real: de la ejecución a la toma del servidor

La inyección de comandos no es una vulnerabilidad de bajo perfil. Al lograr ejecución de código con los privilegios del servicio web, el atacante puede leer ficheros de configuración con credenciales, moverse lateralmente por la red interna, cifrar datos o desplegar un implante persistente. Si el proceso corre como root o como un usuario con privilegios amplios, el compromiso del servidor es total.

Los ejemplos recientes ilustran la gravedad. La CVE-2024-3400 en PAN-OS de Palo Alto Networks fue una inyección de comandos no autenticada en el componente GlobalProtect, con CVSS 10.0 y explotada activamente en la campaña Operation MidnightEclipse. La CVE-2024-21887 en Ivanti Connect Secure permitía inyección de comandos y, encadenada con un bypass de autenticación, dio lugar a compromisos masivos de VPN corporativas. Y la histórica CVE-2014-6271 (Shellshock) demostró cómo una debilidad de Bash al procesar variables de entorno abría RCE en miles de servidores. Estos casos no son teóricos: son incidentes que obligaron a parches de emergencia a escala global.

Cómo prevenir la inyección de comandos

La prevención eficaz se apoya en varias capas que se refuerzan entre sí, siguiendo el principio de defensa en profundidad.

Evitar la shell y usar APIs parametrizadas

La medida más importante es no invocar la shell del sistema. Siempre que sea posible, resuelve la tarea con la librería nativa del lenguaje: para leer un fichero no lances cat, para resolver un DNS usa la API de resolución, para manipular imágenes usa un binding de la biblioteca. Cuando sea imprescindible ejecutar un programa externo, usa APIs que reciban el ejecutable y sus argumentos como elementos separados de un array (execFile, subprocess.run con shell=False, ProcessBuilder), de modo que la entrada nunca se interprete como sintaxis de shell.

Validación de entrada por allowlist

Valida toda entrada contra una lista blanca de valores o formatos esperados y rechaza el resto. Si un campo debe ser una dirección IP, verifícalo con un parser estricto; si debe ser un identificador, aplica una expresión regular anclada como ^[a-zA-Z0-9_-]+$. La lista negra de metacaracteres es frágil: siempre aparece una codificación o un separador olvidado. Esta validación estricta de entrada es una defensa transversal a toda la familia de inyección, como detallamos en las 5 vulnerabilidades web más comunes.

Mínimo privilegio y defensa en profundidad

Ejecuta el servicio con el usuario menos privilegiado posible, dentro de un contenedor con capabilities reducidas, seccomp y sistema de ficheros de solo lectura donde proceda. Así, aunque el atacante logre ejecutar un comando, el radio de daño queda contenido. Complementa con filtrado de egress para detectar el tráfico OAST y con monitorización de procesos hijos anómalos lanzados por el servicio web. Este razonamiento por capas es el mismo que aplicamos frente a la inyección de prompts en LLM, donde tampoco basta con filtrar palabras clave.

Dónde encaja en OWASP y en una auditoría

La inyección de comandos es un objetivo prioritario en cualquier prueba de intrusión de aplicación web. La guía OWASP Web Security Testing Guide dedica pruebas específicas a la inyección de comandos, y la categoría Injection lidera año tras año el OWASP Top 10. El enfoque de la auditoría varía según el nivel de acceso a código, un aspecto que tratamos en la comparativa entre auditoría de caja blanca, negra y gris: en caja blanca se rastrean las llamadas a system, exec o Runtime en el código fuente, mientras que en caja negra se fuzzean los parámetros con metacaracteres y payloads ciegos. Si necesitas verificar la exposición de tus aplicaciones a este vector, nuestro servicio de auditoría web y móvil incluye pruebas dirigidas de inyección de comandos.

Preguntas frecuentes

¿Cuál es la diferencia entre inyección de comandos e inyección SQL?

Ambas son inyecciones y comparten la causa raíz (mezclar datos y código), pero el destino es distinto. La inyección SQL abusa del intérprete de la base de datos; la inyección de comandos abusa del intérprete de comandos del sistema operativo. La inyección de comandos suele tener un impacto más directo, porque conduce a ejecución de código en el servidor.

¿Escapar los caracteres especiales es suficiente para protegerse?

No como defensa principal. El escapado es propenso a errores porque cada shell tiene reglas distintas y siempre queda algún caso sin cubrir. La estrategia robusta es evitar la shell y pasar los argumentos como una lista a una API parametrizada, reservando la validación por allowlist como capa adicional.

¿Qué es la inyección de comandos ciega?

Es la variante en la que la aplicación no devuelve la salida del comando en la respuesta. El atacante confirma la ejecución por canales indirectos: introduciendo un retardo con sleep (basada en tiempo) o forzando una petición DNS o HTTP hacia un servidor que controla (fuera de banda).

¿Puede darse inyección de comandos en Windows?

Sí. Cambia la sintaxis (se usan cmd.exe o PowerShell, y separadores como &, | o &&), pero el fallo es idéntico: entrada no confiable que llega a un intérprete de comandos. Utilidades como timeout cumplen el papel de sleep para las pruebas basadas en tiempo.

¿Qué herramientas ayudan a detectar esta vulnerabilidad?

En pruebas manuales, Burp Suite para interceptar y modificar parámetros, complementado con servidores OAST como Burp Collaborator o interactsh para las variantes ciegas. Para automatizar, commix está especializada en inyección de comandos. En análisis estático, las reglas SAST señalan llamadas peligrosas a system, exec o Runtime.

Recursos relacionados

• OWASP Top 10 2025: vulnerabilidades para empresas
• Las 5 vulnerabilidades web más comunes
• Qué es SSRF: server-side request forgery
• Qué es prompt injection: ataques a LLM
• Auditoría de caja blanca, negra y gris

Auditoría de inyección de comandos con Secra

En Secra tratamos la inyección de comandos como un hallazgo de máxima prioridad en nuestras auditorías de aplicación web. Combinamos análisis de las rutas de código que invocan la shell, fuzzing dirigido de parámetros con payloads clásicos, ciegos y basados en tiempo, y validación de la explotabilidad real mediante técnicas fuera de banda controladas. Entregamos hallazgos priorizados por impacto, con prueba de concepto reproducible y recomendaciones de remediación concretas: eliminación de la shell, adopción de APIs parametrizadas, validación por allowlist y hardening de privilegios. Si quiere confirmar que sus aplicaciones no exponen este vector antes de que lo descubra un atacante, escríbanos desde nuestra página de contacto.