En resumen: una webshell se reconoce por archivos PHP nuevos o modificados en lugares atípicos, por procesos ajenos del usuario del servidor web y por conexiones inusuales. Conserve las pruebas antes de borrar nada y restaure el código desde una fuente limpia. Un parche por sí solo no elimina una puerta trasera.
Por qué las webshells son un tema tras PHP2Shell
Las vulnerabilidades CVE-2026-109618 y CVE-2026-109619 en el propio PHP permiten ejecutar código malicioso de forma remota y sin autenticación. Un objetivo evidente tras un ataque exitoso es una puerta trasera persistente, es decir, una webshell. Permanece incluso si PHP ya se ha actualizado entretanto.
Según informes de los medios, un primer intento de ataque se observó ya el 17/10/2026; los parches llegaron el 21/10. Quien fue vulnerable en ese periodo debería comprobarlo de forma específica. Hasta ahora no se han publicado Indicators of Compromise confirmados. Por eso la búsqueda se apoya en anomalías de comportamiento y no en una lista ya preparada.
Si encuentra una webshell en un servidor con datos de clientes: no borre nada con precipitación. Primero conserve las pruebas, después aísle el servidor y planifique los pasos siguientes.
Cómo detectar una webshell: revisar los archivos
La mayoría de las webshells son archivos PHP en el directorio web. Llaman la atención los archivos creados o modificados después del 17/10, los archivos PHP en carpetas de subidas y de caché y los archivos con código ofuscado. Los comandos siguientes no modifican nada, solo listan:
# Archivos PHP modificados desde el 17/10/2026
find /var/www -type f -name "*.php*" -newermt "2026-10-17" -ls
# Archivos PHP en carpetas de subidas, caché o tmp
find /var/www -type f -name "*.php*" \( -path "*upload*" -o -path "*cache*" -o -path "*tmp*" \) -ls
# Ofuscación típica: eval combinado con decodificación
grep -rlE "eval\s*\(\s*(base64_decode|gzinflate|str_rot13|gzuncompress)" /var/www --include="*.php"
# Las líneas muy largas suelen indicar código empaquetado
grep -rlE ".{3000,}" /var/www --include="*.php"
Las coincidencias son indicios, no pruebas. Algunos plugins usan código codificado de forma legítima. Compare los archivos sospechosos con el paquete original del fabricante. Lo más fiable es contrastar con sumas de comprobación o con un sistema de control de versiones como Git:
# Diferencias respecto al último estado conocido en el repositorio Git
git -C /var/www/projekt status --porcelain
Una marca de tiempo puede estar falsificada. Por eso no se fíe únicamente de la fecha de modificación de un archivo.
Qué características hacen sospechoso a un archivo
| Característica | Por qué llama la atención |
|---|---|
| Archivo PHP en una carpeta de subidas o de imágenes | Allí solo debería haber medios |
Doble extensión como .jpg.php o .php.png |
Camuflaje como archivo inofensivo |
| Líneas muy largas sin salto | Típico de código empaquetado o cifrado |
| Nombre de archivo parecido al de un archivo del núcleo, pero que no está en el paquete original | Camuflaje en un entorno conocido |
| El propietario o los permisos difieren de los de los archivos vecinos | El archivo se creó por otra vía |
Cuantas más características coinciden, mayor es la probabilidad de un hallazgo. Abra los archivos sospechosos solo como texto, nunca a través del navegador, porque acceder mediante el sitio web ejecutaría el código.
Revisar procesos, conexiones y tareas cron
Una webshell activa suele dejar rastros fuera del sistema de archivos. El usuario del servidor web, por ejemplo www-data, apache o nginx, normalmente no inicia shells, herramientas de red ni compiladores.
# Procesos de los usuarios típicos del servidor web
ps -eo user,pid,ppid,lstart,cmd | grep -E "^(www-data|apache|nginx)"
# Conexiones de red abiertas con su proceso correspondiente
sudo ss -tunap | grep -E "php|www-data|apache|nginx"
# Tareas programadas del usuario del servidor web
sudo crontab -u www-data -l
ls -la /etc/cron.d /var/spool/cron 2>/dev/null
Llaman la atención las conexiones salientes persistentes hacia destinos desconocidos, los procesos con nombres crípticos y las tareas cron que descargan archivos de Internet. Revise además los registros de acceso en busca de peticiones a archivos que antes no existían. Cómo hacerlo se describe en la guía Analizar los registros del servidor web tras un ataque.
Conservar las pruebas antes de eliminar
Quien borra primero pierde la respuesta a las preguntas más importantes: cómo entró el atacante, qué vio, qué datos están afectados. Necesita esas respuestas para una posible notificación según el RGPD, para las aseguradoras y para decidir si hay otros sistemas en peligro.
Orden recomendable:
- Documentar el estado: lista de procesos, conexiones de red, usuarios conectados.
- Copiar los archivos sospechosos y los registros con suma de comprobación, sin abrirlos ni ejecutarlos.
- Si es posible, crear una imagen del sistema o una instantánea de la máquina virtual.
- Desconectar el servidor de la red o restringir con fuerza el acceso.
En sistemas con datos sensibles o con posible litigio, la conservación debería hacerse con rigor forense. Encontrará más información en Análisis forense informático tras un ataque a un servidor web.
Eliminar webshells correctamente
Borrar un solo archivo rara vez es el final. Los atacantes suelen crear varios accesos: otros archivos en lugares ocultos, entradas en archivos de configuración como .htaccess o .user.ini, nuevas cuentas de administrador en la aplicación o tareas cron. Una limpieza fiable sigue estos pasos:
- Llevar PHP a una versión corregida (8.5.12, 8.4.27, 8.3.36, 8.2.35 o un backport confirmado) y reiniciar todos los procesos de PHP.
- Reinstalar el código de la aplicación desde una fuente limpia en lugar de reparar archivos sueltos.
- Conservar solo contenidos verificados, como las subidas y la base de datos, y buscar allí de forma específica código introducido.
- Cambiar todas las credenciales: base de datos, SSH, FTP, cuentas de administrador, claves de API.
- Limitar al mínimo necesario los permisos de escritura del servidor web e impedir la ejecución de PHP en las carpetas de subidas.
Para WordPress hay escondites típicos propios, que describe la guía Encontrar puertas traseras en WordPress. Después, conviene vigilar el sitio web más de cerca durante un tiempo para detectar pronto un nuevo acceso.
¿Cómo ayuda PHP SOS en concreto?
- Conservamos registros, archivos y estado del sistema de forma trazable antes de modificar nada.
- Buscamos puertas traseras en archivos, base de datos, tareas cron y configuración, y clasificamos los hallazgos.
- Reinstalamos la aplicación desde una fuente limpia, cambiamos los accesos y reforzamos el servidor.
- Documentamos el incidente hasta su cierre, como base para notificaciones y aseguradoras.
El desarrollo de una limpieza lo describe el servicio Eliminación de malware y webshells.
Preguntas frecuentes
¿Qué es una webshell?
Una webshell es un archivo introducido a escondidas, normalmente en PHP, mediante el cual los atacantes pueden controlar el servidor de forma remota. A menudo se camufla como un archivo inofensivo con un nombre discreto y sigue activa incluso después de una actualización.
¿Un antivirus encuentra todas las webshells?
No. Los escáneres reconocen patrones conocidos; las variantes nuevas o muy ofuscadas se les escapan. Además, sobre PHP2Shell no hay Indicators of Compromise confirmados y publicados, por lo que el análisis de comportamiento es más importante que una lista de firmas.
¿Basta con borrar el archivo encontrado?
Normalmente no. Los atacantes suelen crear varios accesos, por ejemplo otros archivos, tareas cron o nuevas cuentas de administrador. Sin un análisis de la causa y sin cambiar todas las credenciales, un nuevo acceso es probable.
¿Debo notificar algo si encuentro una webshell?
Si pueden estar afectados datos personales, puede existir una obligación de notificación según el RGPD, por lo general en un plazo de 72 horas. Acláralo con su delegado de protección de datos o con un abogado; esto no es asesoramiento jurídico.