Glosario
Qué es la RCE (ejecución remota de código): por qué es la peor clase de fallo
La RCE (ejecución remota de código) permite a un atacante ejecutar código en tu servidor a través de la red: directo a la toma de control, la peor clase. En qué se diferencia de XSS y SQLi, qué determina el radio de impacto y cómo defenderse: parcheo rápido, monitorización de CVE, privilegios mínimos.
«Una RCE con CVSS 10.0»: la frase que más tensa a la gente de seguridad. Aquí tienes por qué la RCE es la «peor clase» y en qué se diferencia de otros fallos, desde cero.
En qué se diferencia de otros fallos
La mayoría de las vulnerabilidades tienen un radio de impacto limitado. La RCE ejecuta comandos en el propio servidor, así que es un orden de magnitud peor.
| Vulnerabilidad | Dónde se ejecuta el código | Daño principal | Gravedad típica |
|---|---|---|---|
| XSS | el navegador | robo de sesión, desfiguración | media–alta |
| SQLi | la base de datos | leer/alterar datos | alta |
| RCE | el propio servidor | toma de control, movimiento lateral, todo | la peor (clase 10.0) |
Por qué es la peor clase
Que un atacante ejecute comandos en tu servidor significa que todo lo que ese proceso pueda hacer, lo puede hacer él.
RCE conseguida (ejecución de código arbitrario)
.env y robar secretosEl radio de impacto lo determinan «los privilegios de ese proceso». Por eso exactamente funcionan la contenerización, los privilegios mínimos y el aislamiento (minimizar el radio de impacto). Ejecuta como root y todo se va; ejecuta sin privilegios y aislado y lo contienes.
La mayoría de las RCE vienen de «agujeros conocidos», no de tus propios fallos
La RCE muy a menudo no viene de un fallo que escribiste, sino de un agujero conocido en un framework o librería que usas. Muchos incidentes históricos fueron RCE.
- Log4Shell (CVE-2021-44228): RCE vía un componente de registro; el mundo entró en pánico.
- El CVSS 10.0 descuidado: una RCE publicada dejada sin parchear durante meses.
Qué puedes hacer para defenderte
No descuides las CVE publicadas (la mayor defensa)
Monitoriza las CVE con máquinas (Dependabot / osv-scanner) y actualiza rápido a las versiones corregidas. La mayoría de las RCE vienen de descuidar agujeros conocidos.
Juzga por la versión en ejecución
Mide el riesgo por la versión que realmente se ejecuta, no por el mínimo del manifiesto. Fiarte del texto malinterpreta el peligro.
Minimiza el radio de impacto
Ejecuta como usuario sin privilegios; aísla contenedores y redes. Contén el daño si te alcanzan.
No pases la entrada directamente a la ejecución
Nunca alimentes la entrada externa directamente a comandos de shell, deserialización o evaluación de plantillas. Lo básico para no crear tú mismo una RCE.
Sigue leyendo
- Glosario: Qué es una CVE · Qué es CVSS
- Historia: Log4Shell: RCE a través de una dependencia
- Defensa: Ejecutar Next.js con seguridad (higiene de CVE)
FAQ
Q¿En qué se diferencia la RCE de fallos comunes como el XSS?
El XSS y similares en su mayoría se comportan mal dentro del navegador del usuario; la RCE ejecuta programas arbitrarios en el propio servidor. Como puede alcanzar los privilegios, los datos y otros servicios del servidor, suele ser la clase más grave.
Q¿Hasta dónde se propaga el daño de una RCE?
Hasta donde lleguen los privilegios del proceso que se estaba ejecutando cuando fue atacado. Ejecuta como root o con amplios derechos y el daño es enorme; ejecuta como usuario sin privilegios con aislamiento en contenedor y puedes contenerlo. Por eso importan los privilegios mínimos y el aislamiento.
Q¿Cómo me defiendo (como desarrollador) contra la RCE?
Además de no escribir tú mismo fallos de RCE (no pases la entrada directamente a la ejecución), la mayor defensa es no descuidar las RCE publicadas en los frameworks/librerías que usas. La monitorización de CVE y las actualizaciones rápidas son el núcleo.