Glosario: PHP y seguridad informática

125 términos técnicos en lenguaje claro, cada uno con enlace a la página técnica correspondiente.

#A B C D E F G H I J L M N O P R S T U V W X Z

#

2FA: 2FA (autenticación en dos factores) exige, además de la contraseña, una segunda prueba al iniciar sesión, por ejemplo un código de una aplicación o una llave de seguridad. Una contraseña robada ya no basta por sí sola. La 2FA debería ser el estándar en todos los accesos de administración a CMS, paneles de hosting y servidores. Configurar la autenticación de dos factores para accesos de administración →

A

Análisis forense: El análisis forense informático investiga de forma metódica, tras un incidente, qué ha ocurrido: cómo entró el atacante, qué hizo y qué datos se han visto afectados. La base son copias aseguradas de soportes de datos, de la memoria y de los registros. Los resultados son importantes para las obligaciones de notificación, el seguro y la denuncia penal. Análisis forense informático tras un ataque a un servidor web →
Apache: Apache HTTP Server es uno de los servidores web más antiguos y extendidos. PHP se ejecuta en él como módulo (mod_php) o mediante PHP-FPM a través de FastCGI. Con archivos .htaccess se puede adaptar la configuración por directorios. Proteger Apache con mod_php →

B

Backport: Un backport traslada una corrección de seguridad a una versión anterior de un programa, sin pasar a la versión nueva. Las distribuciones de Linux y los proveedores de hosting lo hacen con frecuencia; el número de versión mostrado sigue siendo el mismo. Que un backport esté instalado lo demuestran el changelog del paquete y la confirmación del proveedor, no el número. ¿Actualizar PHP o backport? La decisión para sistemas antiguos →
BSI: El BSI (Bundesamt für Sicherheit in der Informationstechnik, Oficina Federal alemana para la Seguridad de la Información) es la autoridad federal alemana de ciberseguridad. Publica avisos, recomendaciones y estándares como el IT-Grundschutz. Sobre PHP2Shell, el BSI ha declarado el nivel de alerta 3 (naranja) y ha recomendado actualizar de inmediato. Qué recomienda el BSI sobre PHP2Shell →

C

Cabeceras de seguridad: Las cabeceras de seguridad son líneas de cabecera de las respuestas HTTP que dan al navegador reglas de protección, por ejemplo Content-Security-Policy, Strict-Transport-Security o X-Content-Type-Options. Protegen a los visitantes frente a determinados ataques en el navegador. No ayudan frente a vulnerabilidades del servidor como PHP2Shell. Cabeceras de seguridad para sitios web: cómo configurarlas bien →
Cadena de custodia: La cadena de custodia (chain of custody) documenta sin lagunas quién ha asegurado, entregado y tratado una prueba, y cuándo. Complementada con sumas de verificación, demuestra que los datos no han sido modificados. Sin esta documentación, los rastros pierden valor ante los tribunales o frente a las aseguradoras. Análisis forense informático tras un ataque a un servidor web →
CDN: Un CDN (Content Delivery Network) entrega contenidos a través de muchos servidores distribuidos y se sitúa por delante del propio sitio web. Muchos CDN ofrecen además reglas de WAF, como Cloudflare frente a PHP2Shell. La protección solo actúa para el tráfico que pasa por el CDN y no sustituye a una actualización de PHP. Reglas de protección de Cloudflare contra PHP2Shell: qué logran y qué no →
CERT-Bund: CERT-Bund es el Computer Emergency Response Team de la administración federal alemana, integrado en el BSI. Publica servicios de aviso e información sobre vulnerabilidades y notifica a los operadores de red los sistemas vulnerables. CERT-Bund también ha emitido avisos sobre PHP2Shell. Qué aconsejan CERT-EU y CERT-Bund sobre PHP2Shell →
CERT-EU: CERT-EU es el equipo de ciberseguridad de las instituciones, órganos y agencias de la Unión Europea. Según informes, CERT-EU considera posible que en PHP2Shell estén afectadas versiones a partir de PHP 5. Aconseja aislar las aplicaciones accesibles públicamente si no pueden parchearse con prontitud. Qué aconsejan CERT-EU y CERT-Bund sobre PHP2Shell →
CGI: CGI (Common Gateway Interface) es una interfaz antigua en la que el servidor web inicia un programa externo para cada petición y devuelve su salida. Es sencilla pero lenta, y en PHP ha sido sustituida en gran medida por FastCGI. Aún se encuentran configuraciones CGI antiguas en algunos sistemas de hosting y de Windows. CGI y FastCGI: los fundamentos →
cgroups: Los cgroups (Control Groups) son una función del kernel de Linux con la que se pueden limitar la memoria, la CPU y otros recursos de grupos de procesos. Los contenedores y systemd los utilizan, por ejemplo con MemoryMax. Como medida provisional frente a PHP2Shell, php.net recomienda un límite de memoria mediante contenedor o cgroup en lugar de RLIMIT_AS o RLIMIT_DATA. Fijar límites de memoria con systemd y cgroups →
Changelog: Un changelog enumera los cambios de una versión de programa o de paquete; en las correcciones de seguridad suele incluir el número CVE. En Debian y Ubuntu, apt-get changelog muestra el changelog del paquete; en la familia RHEL, rpm -q --changelog. Así se puede demostrar un backport incluso con el mismo número de versión. Acreditar números CVE en el registro de cambios del paquete →
Ciberseguro: Un ciberseguro cubre, según el contrato, los costes tras un ataque, por ejemplo de análisis forense, restauración o interrupción de la actividad. Muchos contratos incluyen obligaciones como las actualizaciones con prontitud y la comunicación inmediata del siniestro. Lo que se aplica en cada caso debe aclararlo con su aseguradora. Ciberseguro: qué cuenta en caso de siniestro →
Ciclo de versiones: Cada versión de PHP recibe primero correcciones de errores y, después, durante un tiempo, solo correcciones de seguridad. El proyecto PHP publica en php.net, en las versiones con soporte, cuándo termina cada versión. Según php.net, PHP 8.2 alcanza el fin del soporte el 31/12/2026. Versiones de PHP y ciclo de versiones →
CLI: CLI (Command Line Interface) es PHP en la línea de comandos, por ejemplo para tareas cron, comandos de consola de los CMS y Composer. El PHP de la CLI puede ser una versión distinta de la que sirve las páginas web. Por eso, el comando php -v solo muestra la versión de la línea de comandos; ambas vías deben estar parcheadas. PHP en la línea de comandos (CLI) →
CloudLinux: CloudLinux es una distribución de Linux para hosting compartido que separa a los clientes en entornos limitados. Con alt-php ofrece en paralelo muchas versiones de PHP, también antiguas. Cada una de estas versiones debe estar parcheada por separado. CloudLinux y alt-php: lo que deben saber los clientes de alojamiento →
Composer: Composer es el gestor de paquetes de PHP. Instala bibliotecas según lo indicado en composer.json y registra las versiones exactas en composer.lock. Con composer audit se pueden comprobar los paquetes instalados en busca de vulnerabilidades conocidas; las vulnerabilidades del propio PHP no las detecta este comando. Composer: el gestor de paquetes de PHP →
Comprobación de integridad: En una comprobación de integridad se comparan los archivos con un estado original conocido, normalmente mediante sumas de verificación. Muchos CMS ofrecen comandos propios para ello, por ejemplo WordPress, Nextcloud o Matomo. Una comparación así no cubre los archivos modificados a propósito, las cargas ni los contenidos de la base de datos. Comparar los archivos del núcleo del CMS con el original →
Conservación de pruebas: La conservación de pruebas consiste en asegurar los rastros de un incidente antes de que se pierdan por la limpieza, el reinicio o la reinstalación. Incluye archivos de registro, imágenes de soportes de datos y, según el caso, la memoria. Tras PHP2Shell, la prensa especializada aconseja conservar los registros del servidor desde el 20/10/2026. Conservar las pruebas antes de reinstalar el servidor →
Contenedor: Un contenedor es un entorno de ejecución aislado que inicia una aplicación con todas sus dependencias a partir de una imagen, por ejemplo con Docker. El PHP del contenedor procede de la imagen, no del sistema anfitrión. Por eso, una actualización en el host no lo parchea; hay que reconstruir la imagen y reiniciar el contenedor. Operar PHP en contenedores →
Contrato de encargado del tratamiento: Un contrato de encargado del tratamiento (en alemán, AVV) conforme al art. 28 del RGPD es necesario cuando un prestador de servicios trata datos personales por encargo o puede acceder a ellos. A menudo es el caso también de proveedores de hosting, agencias y prestadores de servicios informáticos con acceso al servidor. El contrato regula, entre otras cosas, las instrucciones, las medidas de protección y las vías de notificación. Encargo del tratamiento cuando los proveedores acceden a servidores →
Copia de seguridad 3-2-1: La regla 3-2-1 recomienda tres copias de los datos en dos soportes de almacenamiento distintos, una de ellas en otra ubicación. Al menos una copia no debería poder modificarse desde el servidor, para que los atacantes no puedan borrarla ni cifrarla. Una copia de seguridad solo cuenta cuando se ha probado la restauración. Estrategia de copias de seguridad para servidores: la regla 3-2-1 →
cPanel: cPanel es un panel de administración para hosting web, con WHM como interfaz para el administrador del servidor. Las versiones de PHP se suelen ofrecer allí mediante paquetes propios (EasyApache). Qué compilaciones están parcheadas lo confirman el estado del paquete y el proveedor de hosting. cPanel y WHM: proteger PHP →
Credential Stuffing: En el credential stuffing, los atacantes prueban en otros servicios credenciales procedentes de filtraciones de datos anteriores. Funciona porque muchas personas reutilizan las contraseñas. La protección la ofrecen una contraseña única para cada servicio y la autenticación en dos factores. Configurar la autenticación de dos factores para accesos de administración →
Criptominero: Un criptominero es un software malicioso que calcula criptomonedas en servidores ajenos. Los indicios típicos son una carga de CPU alta de forma permanente y procesos desconocidos. Un minero demuestra que un atacante puede ejecutar código; el servidor debe considerarse entonces comprometido. Criptominero en el servidor web: indicios y cómo proceder →
Cronología: Una cronología (timeline) ordena cronológicamente todos los rastros de un incidente: entradas de registro, cambios en archivos, inicios de sesión, procesos. Muestra cuándo empezó el ataque y qué ocurrió en qué orden. Es importante usar una zona horaria uniforme, preferiblemente UTC. Elaborar la cronología de un incidente →
CSP: CSP (Content Security Policy) es una cabecera que define desde qué orígenes puede una página cargar scripts, imágenes y otros contenidos. Dificulta el XSS y la introducción de scripts ajenos, por ejemplo en el skimming. Una CSP estricta debe probarse con cuidado para que el sitio web siga funcionando. Cabeceras de seguridad para sitios web: cómo configurarlas bien →
CSRF: CSRF (Cross-Site Request Forgery) hace que el navegador de un usuario autenticado desencadene sin querer una acción en otro sitio web. Son típicos los cambios en las áreas de administración. La protección la ofrecen los tokens aleatorios en los formularios y las cookies con el atributo SameSite. Protección CSRF en aplicaciones PHP →
CVE: CVE (Common Vulnerabilities and Exposures) es un catálogo de uso mundial que asigna un número único a cada vulnerabilidad de seguridad conocida, por ejemplo CVE-2026-109618. El número permite comparar los avisos de fabricantes, autoridades y distribuciones. Mediante el número CVE también se puede comprobar en el changelog del paquete si la corrección está instalada. Acreditar números CVE en el registro de cambios del paquete →
CVSS: CVSS (Common Vulnerability Scoring System) valora la gravedad de una vulnerabilidad en una escala de 0 a 10. La valoración tiene en cuenta, por ejemplo, si es posible un ataque a través de la red y sin autenticación. Las vulnerabilidades de PHP2Shell tienen CVSS v4.0 de 9.2 cada una; el valor por sí solo no dice nada sobre el riesgo concreto en su entorno.

D

DDoS: Un ataque DDoS (Distributed Denial of Service) sobrecarga un servicio con peticiones desde muchos orígenes hasta que deja de estar accesible. Por lo general, no se roban datos. Un DDoS debe distinguirse de un exploit, que aprovecha de forma dirigida una vulnerabilidad. ¿DDoS o ataque de hackers? Cómo clasificar bien los ataques →
Defacement: En un defacement, los atacantes modifican de forma visible la página de inicio o los contenidos de un sitio web, por ejemplo con mensajes o imágenes. Llama la atención, pero a menudo es solo la señal visible de una intrusión más profunda. Hasta aclarar el caso, el sitio web debe tratarse como comprometido. Sitio web hackeado, ¿qué hacer? Ayuda de emergencia remota →
Deserialización: La deserialización convierte datos almacenados de nuevo en objetos; en PHP, por ejemplo, con unserialize(). Si los datos proceden de usuarios, los atacantes pueden construir objetos de modo que al cargarlos se ejecute código no deseado. Para los datos de usuarios, JSON es la opción más segura. Deserialización insegura en PHP: unserialize y seguridad →
disable_functions: disable_functions es un ajuste de php.ini con el que se desactivan funciones concretas de PHP, normalmente las que ejecutan comandos del sistema. Solo puede fijarse en php.ini, no en el código de la aplicación. Dificulta la vida a los atacantes, pero no sustituye ni a las actualizaciones ni a unos permisos correctos. Usar disable_functions de PHP correctamente →
display_errors: display_errors determina si PHP muestra los mensajes de error directamente en el navegador. En producción el valor debe ser Off; los errores se escriben en su lugar en un registro con log_errors. Si no, los mensajes visibles revelan rutas, versiones y fragmentos de código. display_errors off: desactivar la salida de errores en producción →

E

EDR: EDR (Endpoint Detection and Response) es un software en servidores y puestos de trabajo que observa procesos, accesos a archivos y conexiones de red, y avisa o detiene los comportamientos sospechosos. En servidores web puede detectar, por ejemplo, que PHP-FPM inicia una shell. Como para PHP2Shell no hay IOC confirmados, este análisis del comportamiento es especialmente importante. Señal de alerta: el servidor web inicia una shell →
Embargo: Un embargo es el plazo acordado durante el cual los detalles de una vulnerabilidad permanecen confidenciales hasta que los parches están listos. Así, fabricantes y distribuciones pueden preparar las actualizaciones. En PHP2Shell, según varios informes, los detalles se hicieron públicos antes de que terminara el embargo; por eso php.net anunció los parches el 20/10/2026. Por qué se conoció la vulnerabilidad de PHP antes del parche →
End of Life: End of Life (EOL) significa que el fabricante ya no ofrece actualizaciones de una versión de software, tampoco correcciones de seguridad. PHP 8.1 y anteriores ya no reciben actualizaciones oficiales del proyecto PHP; para 7.4, 8.0 y 8.1 solo hay backports mínimos de código fuente. Los sistemas con software EOL necesitan un plan de actualización. PHP End of Life: riesgos de las versiones obsoletas →
Exploit: Un exploit es código o un procedimiento que aprovecha realmente una vulnerabilidad concreta. En cuanto aparece un parche, los atacantes pueden analizarlo y derivar exploits. Por eso, tras la publicación de un parche, el tiempo hasta los ataques suele acortarse de forma notable. La ventana de tiempo entre el parche y el ataque →
expose_php: expose_php controla si PHP revela su versión en la cabecera HTTP X-Powered-By. En producción este ajuste debe estar en Off, para que los atacantes no vean a primera vista qué versión de PHP se ejecuta. Es protección de la información, no un sustituto de la actualización. expose_php y cabecera Server: ocultar los datos de versión →
Extensión: Una extensión añade funciones a PHP, por ejemplo para bases de datos, imágenes o cifrado. Las extensiones se ejecutan en el mismo proceso que PHP y tienen los mismos permisos. Desactivar las extensiones que no se necesitan reduce la superficie de ataque. Entender las extensiones de PHP (Extensions) →

F

Fail2ban: Fail2ban lee archivos de registro y bloquea temporalmente en el cortafuegos las direcciones IP tras intentos fallidos repetidos. Sus usos típicos son SSH, el correo y los accesos de administración de sitios web. Frente a ataques distribuidos desde muchas direcciones, ayuda solo de forma limitada. Configurar Fail2ban para servidores web →
FastCGI: FastCGI es un protocolo mediante el cual un servidor web transmite las peticiones a procesos de programa que se mantienen en ejecución, por ejemplo a PHP-FPM. A diferencia del CGI clásico, no se inicia un proceso nuevo para cada petición. Como los procesos atienden varias peticiones seguidas, es importante reiniciarlos correctamente tras las actualizaciones. CGI y FastCGI: los fundamentos →
FrankenPHP: FrankenPHP es un servidor de aplicaciones moderno para PHP basado en el servidor web Caddy. PHP está integrado directamente en él y, en el modo worker, la aplicación permanece en memoria entre peticiones. Según el equipo de PHP, FrankenPHP se cuenta entre los modos de ejecución afectados; tras la actualización hay que reiniciar el servidor con el nuevo PHP. Proteger FrankenPHP →
Fuerza bruta: En un ataque de fuerza bruta, un atacante prueba de forma automatizada muchas contraseñas para una cuenta. Suelen ser objetivo los accesos de administración de CMS, SSH o FTP. La protección la ofrecen las contraseñas seguras, la autenticación en dos factores y los bloqueos automáticos como Fail2ban. Proteger los inicios de sesión de administración contra la fuerza bruta: protección para cada login →

G

GHSA: GHSA es el identificador de un GitHub Security Advisory, es decir, de un aviso de seguridad en la base de datos de GitHub. Muchos proyectos de código abierto, también PHP, publican allí sus avisos además del número CVE. En PHP2Shell son GHSA-w8hw-w9fx-j79w y GHSA-6wmf-4rv5-p3rp.

H

Hosting compartido: En el hosting compartido, muchos clientes comparten un servidor que gestiona el proveedor de hosting. El proveedor se ocupa de PHP, el sistema operativo y el servidor web; el cliente, de su aplicación. En PHP2Shell esto significa: preguntar al proveedor por el estado del parche y revisar el propio sitio web en busca de rastros. Hosting compartido: qué hace el proveedor y qué debe hacer usted →
HSTS: HSTS (HTTP Strict Transport Security) es una cabecera con la que un sitio web indica al navegador que, durante un tiempo determinado, solo debe accederse a él mediante HTTPS. Esto impide que las conexiones se degraden a HTTP sin cifrar. Antes de activarlo, HTTPS debe funcionar de forma fiable en todos los dominios afectados. Cabeceras de seguridad para sitios web: cómo configurarlas bien →
.htaccess: Los archivos .htaccess son archivos de configuración por directorio para Apache y servidores compatibles como LiteSpeed. Los CMS los usan para redirecciones y protección de acceso; los atacantes, para redirecciones ocultas. Nginx no evalúa .htaccess; allí las reglas de protección deben ir en la configuración del servidor. Configurar Apache para PHP de forma segura →

I

Image digest: Un image digest es un valor hash (sha256) que determina de forma inequívoca el contenido de una imagen de contenedor. A diferencia de una etiqueta como php:8.3-fpm, que puede desplazarse a compilaciones nuevas, un digest no cambia nunca. Quien fija las imágenes por digest debe actualizarlo de forma consciente tras una actualización de seguridad. Imágenes Docker oficiales de PHP: tags, digests y reconstrucción →
ini_set(): ini_set() es una función de PHP con la que un script modifica ajustes en tiempo de ejecución. Lo que un script puede cambiar depende del modo de modificación del ajuste. Como el código malicioso también puede llamar a ini_set(), los ajustes de protección pertenecen a la configuración del servidor o del pool, no al código de la aplicación. El php.ini explicado: estructura, niveles y prioridad →
Inyección de comandos: En una inyección de comandos, las entradas llegan sin comprobar a un comando del sistema que ejecuta la aplicación. Así, el atacante puede iniciar sus propios comandos con los permisos del servidor web. La protección consiste en evitar, cuando sea posible, las llamadas a la shell y en escapar de forma sistemática con escapeshellarg(). Evitar la inyección de comandos (command injection) en PHP →
Inyección SQL: En una inyección SQL, un atacante introduce en una aplicación, a través de entradas, comandos de base de datos propios. Así se pueden leer o modificar datos. La protección la ofrecen las sentencias preparadas (prepared statements) con marcadores de posición en lugar de textos SQL concatenados. Evitar la inyección SQL en PHP →
IOC: Los IOC (Indicator of Compromise) son rastros concretos de un ataque, como nombres de archivo, valores hash, direcciones IP o dominios. Con ellos se pueden revisar los sistemas de forma específica frente a un ataque conocido. Para PHP2Shell no hay IOC confirmados publicados; la detección se basa en el análisis del comportamiento. ¿Ya estoy comprometido? Indicios tras PHP2Shell →
ISO 27001: ISO/IEC 27001 es el estándar internacional para los sistemas de gestión de la seguridad de la información (SGSI). Exige una gestión ordenada de los riesgos, las medidas y las mejoras, incluida la gestión de vulnerabilidades e incidentes. Las empresas pueden certificarse conforme a esta norma. ISO 27001 y TISAX: qué afecta a los servidores web →
IT-Grundschutz: El IT-Grundschutz del BSI es una metodología con módulos y requisitos para la seguridad de la información en empresas y autoridades. Hay módulos propios, por ejemplo, para servidores web y aplicaciones web. Puede utilizarse como base para un SGSI o una certificación. Benchmarks CIS y módulos de la BSI para servidores web →

J

JIT: JIT (compilador Just-in-Time) traduce en tiempo de ejecución a código máquina el código PHP que se ejecuta con frecuencia. Llegó con PHP 8.0 y forma parte de OPcache. En los sitios web habituales la mejora de rendimiento suele ser pequeña; en tareas que requieren mucho cálculo es mayor. JIT y rendimiento en PHP 8 →

L

Lessons Learned: Lessons learned (lecciones aprendidas) es la evaluación posterior de un incidente: qué ocurrió, qué funcionó bien, qué debe cambiar. El objetivo son medidas concretas con responsables y plazos, no la búsqueda de culpables. Los resultados se incorporan al plan de emergencia, al proceso de parcheo y a la formación. Lessons learned: mejorar después del incidente →
LFI: LFI (Local File Inclusion) se da cuando una aplicación incluye un archivo local cuya ruta puede influir el atacante. Así se pueden leer archivos de configuración o, en determinadas circunstancias, ejecutar código introducido. La protección la ofrecen listas de permitidos fijas en lugar de nombres de archivo procedentes de entradas del usuario. Evitar Local File Inclusion en PHP: LFI y RFI →
LiteSpeed: LiteSpeed es un servidor web en gran medida compatible con las configuraciones de Apache como .htaccess, que conecta PHP mediante su propia interfaz LSAPI. Está extendido entre los proveedores de hosting; OpenLiteSpeed es la variante libre. Según el equipo de PHP, LiteSpeed se cuenta entre los modos de ejecución afectados por PHP2Shell. LiteSpeed y LSAPI: actualizar PHP →

M

memory_limit: memory_limit limita cuánta memoria RAM puede ocupar un único script PHP; por defecto son 128 MB. Al alcanzar el límite, PHP se interrumpe con un error de falta de memoria. Frente a CVE-2026-109618, php.net aconseja con carácter provisional memory_limit=-1, fijado de forma definitiva, junto con un límite de memoria mediante contenedor o cgroup. Fijar bien memory_limit →
mod_php: mod_php es el módulo de PHP para el servidor web Apache. PHP se ejecuta directamente dentro del proceso de Apache y, por lo general, con los permisos de su usuario. El equipo de PHP considera que el riesgo por PHP2Shell es mayor en mod_php; allí se demostró un exploit antes de que se ejecute siquiera el código de la aplicación. mod_php explicado: PHP dentro del proceso de Apache →
ModSecurity: ModSecurity es un WAF de código abierto muy extendido que se ejecuta como módulo en Apache, Nginx u otros servidores web. Evalúa las peticiones según reglas y puede registrarlas o bloquearlas. Normalmente se utiliza junto con el OWASP Core Rule Set. Usar ModSecurity y el OWASP Core Rule Set →
Monitorización: La monitorización es la vigilancia continua de los sistemas, por ejemplo de su disponibilidad, carga, archivos de registro y cambios en archivos. La monitorización de seguridad busca de forma específica anomalías como archivos PHP nuevos o shells iniciadas por el servidor web. Solo sirve si alguien valora los avisos con prontitud. Monitorización de seguridad para servidores web →
Mínimo privilegio: El principio de mínimo privilegio (least privilege) significa que cada usuario y cada proceso recibe solo los permisos que realmente necesita. Si PHP se ejecuta con permisos ajustados, un atacante puede causar menos daño tras una intrusión. Afecta a usuarios del sistema, permisos de archivos, cuentas de base de datos y accesos de administración. Mínimo privilegio: los permisos del usuario del servidor web →

N

Nginx: Nginx es un servidor web y proxy inverso muy extendido. No ejecuta PHP por sí mismo, sino que transmite las peticiones a PHP-FPM mediante FastCGI. Es importante una configuración que solo pase a PHP los archivos PHP auténticos y excluya las carpetas de cargas. Proteger Nginx con PHP-FPM →
NIS2: NIS2 es una directiva de la UE que establece, para muchas empresas y entidades, obligaciones de gestión de riesgos y de notificación de incidentes de seguridad. Afecta a bastantes más sectores y tamaños de empresa que la normativa anterior. Si su empresa está incluida debe aclararlo a partir de la transposición nacional y con asesoramiento jurídico. NIS2 y seguridad de los servidores web →
Nivel de alerta: El BSI clasifica la situación de amenaza en los avisos de seguridad en niveles que también se identifican por colores. El nivel 3 (naranja) corresponde a una situación crítica para el negocio, con posible afectación grave del funcionamiento normal. Para PHP2Shell rige el nivel de alerta 3 / naranja. Nivel de alerta naranja del BSI: qué significa esta clasificación →

O

OPcache: OPcache es la caché de bytecode que se incluye con PHP. Guarda en memoria compartida el código ya traducido para que los archivos PHP no se compilen de nuevo en cada petición. Tras una actualización o una limpieza hay que vaciar la caché o reiniciar PHP; de lo contrario, puede seguir ejecutándose código antiguo. OPcache explicado: la caché de bytecode de PHP →
open_basedir: open_basedir restringe a qué directorios pueden acceder los scripts PHP con las funciones de archivos. En servidores con varios sitios web impide que un sitio lea sin más los archivos de otro. No es un aislamiento completo; también hacen falta usuarios de sistema y pools de FPM independientes. open_basedir y aislamiento por sitio web →
Out of Memory: Out of Memory (falta de memoria) designa el estado en el que un programa no obtiene más memoria y debe interrumpirse. En PHP ocurre cuando se supera memory_limit. En CVE-2026-109618, una interrupción así puede detener PHP mientras los datos de la petición están inicializados solo en parte. memory_limit y Out-of-Memory: lo que ocurre por dentro →
OWASP CRS: El OWASP Core Rule Set (CRS) es un conjunto de reglas de libre acceso para ModSecurity y WAF compatibles. Detecta clases de ataque típicas como la inyección SQL o la inyección de comandos. Las reglas deben adaptarse a la aplicación; de lo contrario, también bloquean peticiones legítimas. Usar ModSecurity y el OWASP Core Rule Set →
OWASP Top 10: El OWASP Top 10 es una lista, actualizada con regularidad, de los principales riesgos para las aplicaciones web, publicada por la fundación sin ánimo de lucro OWASP Foundation. Sirve de base para el desarrollo, las auditorías y la formación. Como complemento, OWASP ofrece las Cheat Sheets con contramedidas concretas.

P

Parche: Un parche es una corrección del fabricante que cierra una vulnerabilidad en el código del programa. Solo surte efecto cuando está instalado y se han reiniciado todos los procesos en ejecución. Un parche no elimina el software malicioso ya introducido y no demuestra que antes no hubiera pasado nada. Servicio de parcheo de PHP: actualización por encargo, con reinicio y justificante →
Parcheo virtual: El parcheo virtual bloquea los ataques contra una vulnerabilidad conocida antes de que lleguen a la aplicación, normalmente con un WAF, sin modificar el código vulnerable. Gana tiempo hasta que sea posible la actualización real. En PHP2Shell, Cloudflare advierte, por ejemplo, de que no bastan las reglas basadas solo en los datos de la petición; la actualización sigue siendo obligatoria. WAF y parcheo virtual para PHP →
PECL: PECL (PHP Extension Community Library) es el repositorio de extensiones de PHP escritas en C que no forman parte del paquete estándar. Estas extensiones deben ser compatibles con la versión de PHP instalada. Tras un cambio de versión principal de PHP, a menudo hay que recompilarlas o sustituirlas. Entender las extensiones de PHP (Extensions) →
PHP: PHP es un lenguaje de scripts que se ejecuta sobre todo en servidores web y genera allí las páginas. Muchos CMS y sistemas de tienda muy extendidos, como WordPress, TYPO3 o Shopware, están escritos en PHP. Por eso, una vulnerabilidad en el intérprete de PHP afecta a todas las aplicaciones que se ejecutan sobre él, con independencia de su propio nivel de actualización. ¿Qué es PHP? El lenguaje de programación explicado →
php-cgi: php-cgi es el programa de PHP para el funcionamiento mediante CGI o FastCGI. Según el equipo de PHP, se cuenta entre los modos de ejecución afectados por PHP2Shell. Donde todavía se usa php-cgi, conviene comprobar si es posible pasar a PHP-FPM. php-cgi: una herencia con riesgo →
PHP-FPM: PHP-FPM (FastCGI Process Manager) es un servicio independiente que gestiona los procesos de PHP en pools y recibe las peticiones del servidor web mediante FastCGI. Hoy es el modo de ejecución habitual con Nginx y en muchos servidores Apache. Tras una actualización de PHP hay que reiniciar PHP-FPM para que no sigan activos procesos antiguos. PHP-FPM explicado: gestor de procesos, pools y workers →
php.ini: El archivo php.ini es el archivo central de configuración de PHP. Define límites y ajustes de seguridad y de errores, por ejemplo memory_limit o display_errors. A menudo hay un php.ini distinto para cada SAPI (FPM, CLI, Apache), que debe mantenerse por separado. El php.ini explicado: estructura, niveles y prioridad →
PHP2Shell: PHP2Shell es el nombre de dos vulnerabilidades críticas en el propio PHP, CVE-2026-109618 y CVE-2026-109619, ambas con CVSS v4.0 de 9.2. Permiten ejecutar código malicioso de forma remota sin autenticación. Están corregidas en PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35, publicadas el 21/10/2026. ¿Qué es PHP2Shell? La vulnerabilidad explicada →
php_admin_value: php_admin_value fija un ajuste de PHP en el pool de FPM o en la configuración de Apache de modo que las aplicaciones no puedan sobrescribirlo con ini_set() ni con .htaccess. Para los interruptores existe php_admin_flag. php.net recomienda esta vía para las medidas provisionales frente a PHP2Shell, por ejemplo para memory_limit. php_admin_value: bloquear ajustes frente a la sobrescritura →
Plan de emergencia: Un plan de emergencia informática define quién hace qué en caso de incidente: contactos, vías de decisión, primeros pasos, reanudación. Debe estar disponible también sin conexión, por si los sistemas fallan. Los simulacros periódicos muestran si funciona en un caso real. Crear un plan de emergencia informática para servidores web →
Plesk: Plesk es un panel de administración de servidores web muy extendido, con el que se pueden configurar dominios, versiones de PHP y handlers para cada sitio web. Incluye sus propios paquetes de PHP, pero también puede usar los paquetes de PHP de la distribución. Con backports, Plesk puede seguir mostrando un número anterior como 8.2.34 aunque esté parcheado. Servidor Plesk: comprobar y parchear las versiones de PHP →
Pool de FPM: Un pool es un grupo de procesos de PHP-FPM con configuración propia, socket propio e, idealmente, usuario de sistema propio. Un pool distinto por cada sitio web separa los sitios entre sí, de modo que una intrusión en uno no alcance directamente los archivos de los demás. En el pool se pueden fijar ajustes de forma definitiva con php_admin_value. Aislar los pools de PHP-FPM por sitio web →
post_max_size: post_max_size establece el tamaño total máximo del contenido de una petición POST; por defecto son 8 MB. Como medida provisional frente a PHP2Shell, php.net indica 8M para sitios web sin cargas de archivos y 32M con cargas. upload_max_filesize debe ser inferior. Limitar con criterio post_max_size y upload_max_filesize →
Proof of Concept: Una prueba de concepto (Proof of Concept, PoC) es una demostración de que una vulnerabilidad es explotable, a menudo en forma de un código de demostración sencillo. Sirve a fabricantes e investigadores para valorar el caso, pero también puede servir de modelo a los atacantes. Por eso, un PoC publicado suele aumentar la urgencia de aplicar el parche.
Proxy inverso: Un proxy inverso recibe las peticiones desde Internet y las reenvía a uno o varios servidores situados detrás. Puede encargarse de TLS, repartir la carga y servir de lugar para reglas de filtrado o un WAF. Solo ofrece protección si los servidores de detrás no son además accesibles directamente. Filtrar peticiones de subida en el borde: oportunidades y riesgos →
Puerta trasera: Una puerta trasera (backdoor) es un acceso oculto por el que los atacantes pueden volver después de una intrusión. Puede ser un archivo, una cuenta de administrador, una tarea cron o una clave SSH. Por eso, toda limpieza debe incluir la búsqueda de todo tipo de accesos, no solo de archivos. Encontrar una puerta trasera en WordPress: cómo localizar accesos ocultos →

R

Ransomware: El ransomware cifra datos y exige un rescate por el descifrado, a menudo junto con la amenaza de publicar los datos robados. Un servidor web comprometido puede ser el punto de entrada. La protección más eficaz son las copias de seguridad separadas y probadas y un plan de emergencia. Estrategia de copias de seguridad para servidores: la regla 3-2-1 →
RCE: RCE (Remote Code Execution) significa que un atacante puede ejecutar su propio código de forma remota en un sistema ajeno. Si para ello no hace falta autenticación, se habla de unauthenticated RCE, la clase más grave de vulnerabilidades de servidores web. Con RCE, un atacante puede leer datos, crear puertas traseras y seguir abusando del servidor. ¿Qué es PHP2Shell? La vulnerabilidad explicada →
Refuerzo: El refuerzo (hardening) consiste en configurar un sistema de modo que ofrezca la menor superficie de ataque posible: solo los servicios necesarios, permisos ajustados, valores predeterminados seguros. En los servidores PHP incluye, por ejemplo, pools separados, funciones bloqueadas y ninguna ejecución de PHP en las carpetas de cargas. El refuerzo limita los daños, pero no sustituye a las actualizaciones. Refuerzo de servidores web con PHP →
Respuesta a incidentes: La respuesta a incidentes (incident response) es la gestión ordenada de un incidente de seguridad: detectar, contener, conservar los rastros, limpiar, restaurar y evaluar a posteriori. Un procedimiento establecido evita que, con las prisas, se destruyan pruebas o se pasen por alto puertas traseras. Son importantes unas responsabilidades claras y una documentación sin lagunas. Respuesta a incidentes ante ataques a servidores →
RFI: RFI (Remote File Inclusion) es la variante en la que una aplicación descarga y ejecuta código desde una dirección ajena. En PHP, el ajuste allow_url_include=Off, que desde hace tiempo es el valor por defecto, impide incluir archivos remotos. Conviene comprobar este punto en aplicaciones y configuraciones antiguas. Evitar Local File Inclusion en PHP: LFI y RFI →
RGPD art. 33: El art. 33 del RGPD obliga a los responsables a notificar a la autoridad de control competente una violación de la seguridad de los datos personales, si es posible en un plazo de 72 horas desde que se tiene conocimiento de ella. La obligación solo decae si es improbable que haya un riesgo para los afectados. En cada caso concreto asesoran los delegados de protección de datos o los abogados. Obligación de notificación del RGPD: 72 horas tras el incidente →
RGPD art. 34: El art. 34 del RGPD regula la comunicación a las propias personas afectadas. Es necesaria cuando es probable que una brecha de datos entrañe un alto riesgo para sus derechos y libertades. Si esto se cumple debería valorarse con los delegados de protección de datos o con abogados. Obligación de notificación del RGPD: 72 horas tras el incidente →

S

SAPI: SAPI (Server Application Programming Interface) es la interfaz mediante la cual PHP se comunica con su entorno, por ejemplo con Apache, PHP-FPM o la línea de comandos. La SAPI en uso determina cómo se inician, reutilizan y reinician los procesos de PHP. En PHP2Shell, según el equipo de PHP, hay varios modos de ejecución afectados, y mod_php es el de mayor riesgo. SAPI explicada: cómo habla PHP con el servidor web →
SEO spam: El SEO spam consiste en páginas, enlaces o redirecciones introducidos con los que los atacantes posicionan ofertas ajenas en los buscadores. A menudo solo los buscadores o los visitantes que llegan desde Google ven los contenidos manipulados. Además de la limpieza, después es necesaria una revisión en Google Search Console. Spam SEO y páginas ajenas en el índice de Google →
serialize_handler: session.serialize_handler determina en qué formato guarda PHP los datos de sesión, por ejemplo php, php_binary o php_serialize. La indicación sobre CVE-2026-115560 afecta solo a una configuración poco habitual en la que este formato se cambia en tiempo de ejecución y Session-Upload-Progress está activo. La solución hasta la próxima versión de corrección de errores es session.upload_progress.enabled=0. CVE-2026-115560: aviso sobre Session-Upload-Progress →
Servidor de origen: El servidor de origen (origin server) es el servidor web propiamente dicho que está detrás de un CDN o de un proxy inverso. Si también es accesible directamente por su dirección IP, los atacantes pueden eludir la protección situada por delante. Por eso, el origen solo debería aceptar conexiones del CDN o del proxy. Reglas de protección de Cloudflare contra PHP2Shell: qué logran y qué no →
Servidor gestionado: En un servidor gestionado, el proveedor pone a disposición un servidor propio y asume por contrato partes determinadas de la operación, a menudo las actualizaciones del sistema operativo y de PHP. Qué incluye exactamente consta en el contrato y varía mucho entre proveedores. En caso de duda, debería confirmarse por escrito la responsabilidad de los parches. Servidor gestionado: aclarar la responsabilidad →
Servidor root: Un servidor root es un servidor alquilado en el que el cliente tiene plenos derechos de administrador. Con ello, la responsabilidad total de las actualizaciones, el refuerzo y la vigilancia recae en el cliente. El proveedor solo pone a disposición el hardware y la red. Proteger por su cuenta un servidor root y un vServer →
Sesión: Una sesión vincula varias peticiones del mismo visitante, por ejemplo para el inicio de sesión o el carrito de la compra. PHP guarda los datos en el servidor y entrega al navegador un identificador de sesión, por defecto en la cookie PHPSESSID. Quien conoce el identificador de sesión de otra persona puede, en determinadas circunstancias, hacerse pasar por ese usuario. Sesiones y cookies en PHP →
session.upload_progress: Session-Upload-Progress es una función de PHP que guarda en la sesión el progreso de las cargas de archivos en curso; está activada por defecto. php.net aconseja con carácter provisional session.upload_progress.enabled=0 en php.ini, en el pool de FPM o en la configuración del servidor, y reiniciar después todos los workers. Según informes técnicos, este ajuste por sí solo no cierra las dos vulnerabilidades de PHP2Shell; la actualización sigue siendo obligatoria. Desactivar session.upload_progress: bien y de forma permanente →
SIEM: Un SIEM (Security Information and Event Management) recoge de forma centralizada los datos de registro de muchos sistemas y los evalúa en busca de eventos de seguridad. Así se detectan relaciones que se pierden en registros aislados. Un SIEM necesita reglas mantenidas y personas que atiendan los avisos. Monitorización de seguridad para servidores web →
Skimming: En el skimming en tiendas online, los atacantes introducen en el proceso de pago JavaScript que lee y envía datos de pago y de clientes. El código suele estar en archivos del tema, en scripts de seguimiento o en registros de la base de datos. Los clientes no se dan cuenta y el comerciante, a menudo, solo lo averigua por avisos de los proveedores de pago. ¿Tienda online hackeada? Seguridad informática para comercios →
SSRF: SSRF (Server-Side Request Forgery) hace que una aplicación envíe, por encargo del atacante, peticiones a otras direcciones, también a sistemas internos. Así se vuelven accesibles servicios que desde fuera deberían estar protegidos. La protección la ofrecen las listas de destinos permitidos y el bloqueo de los rangos de direcciones internos. Evitar el Server-Side Request Forgery (SSRF) en PHP →
Superglobales: Los superglobales son variables que PHP pone a disposición en cada script, como $_GET, $_POST, $_COOKIE, $_FILES, $_SERVER y $_SESSION. Contienen los datos de la petición actual, que en gran parte proceden del visitante. Todo lo que contienen debe tratarse como no fiable y comprobarse. Superglobales: $_GET, $_POST, $_FILES y otros →
sury.org: sury.org es un repositorio de paquetes de Ondřej Surý con versiones actuales y antiguas de PHP para Debian y Ubuntu. Es una oferta de un tercero y no el archivo de seguridad de Debian. Según informes, allí se proporcionaron compilaciones para todas las ramas, de la 5.6 a la 8.5. El repositorio sury.org: paquetes de PHP de una fuente de terceros →

T

Threat Hunting: El threat hunting es la búsqueda activa de atacantes en la propia red sin que exista un aviso. El punto de partida son hipótesis, por ejemplo: ¿ha iniciado un proceso del servidor web una shell desde el 20/10? Así se encuentran intrusiones que las herramientas automáticas pasan por alto. Señal de alerta: el servidor web inicia una shell →
TISAX: TISAX es un procedimiento de evaluación e intercambio para la seguridad de la información en la industria del automóvil. Se basa en un catálogo de requisitos de la asociación alemana de la industria del automóvil (VDA) y lo gestiona la ENX Association. Los proveedores deben acreditar con él su nivel de seguridad ante los fabricantes. ISO 27001 y TISAX: qué afecta a los servidores web →
TLS: TLS (Transport Layer Security) cifra la conexión entre el navegador y el servidor; se reconoce por HTTPS. Actualmente se recomiendan TLS 1.2 y 1.3, y las versiones anteriores del protocolo deberían estar desactivadas. TLS protege los datos en tránsito, no frente a vulnerabilidades del propio servidor. Configurar TLS y HTTPS correctamente →
Type Juggling: Type juggling es la conversión automática de tipos en PHP, por ejemplo en la comparación laxa con ==. Así pueden considerarse iguales valores que no lo son, lo que resulta peligroso en comprobaciones de contraseñas o tokens. La protección la ofrecen las comparaciones estrictas con === y hash_equals() para los secretos. Type juggling en PHP: las comparaciones laxas como riesgo de seguridad →

U

upload_max_filesize: upload_max_filesize limita el tamaño de cada archivo subido; por defecto son 2 MB. El valor debe ser menor que post_max_size, porque el archivo forma parte de la petición POST. Los valores demasiado generosos amplían la superficie de ataque sin ningún beneficio. Limitar con criterio post_max_size y upload_max_filesize →
.user.ini: Los archivos .user.ini son ajustes de PHP por directorio que evalúan PHP-FPM y CGI. Permiten a los responsables de un sitio web modificar valores concretos sin acceso al servidor, pero solo aquellos que PHP habilita para ello. Según php.net, los ajustes relevantes para la seguridad, como session.upload_progress.enabled=0 frente a PHP2Shell, no deben fijarse mediante .user.ini. El php.ini explicado: estructura, niveles y prioridad →

V

VdS 10000: VdS 10000 es una directriz de VdS Schadenverhütung (organismo alemán de prevención de daños) para la seguridad de la información en pequeñas y medianas empresas. Es más ligera que ISO 27001 y está adaptada a las posibilidades de las pymes. Es posible certificarse conforme a ella. VdS 10000: seguridad de la información para pequeñas y medianas empresas →
VPS: Un VPS (servidor virtual, en alemán vServer) es un ordenador virtual sobre hardware compartido, con sistema operativo propio y normalmente con acceso root. En cuanto a la seguridad se aplica lo mismo que en el servidor root: las actualizaciones y el refuerzo son cosa del cliente. Muchos VPS funcionan con paneles preinstalados como Plesk. Proteger por su cuenta un servidor root y un vServer →

W

WAF: Un WAF (Web Application Firewall) examina las peticiones HTTP antes de que lleguen a la aplicación y bloquea los patrones de ataque conocidos. Puede funcionar como servicio en la nube, como proxy o como módulo del servidor web. Gana tiempo, pero no sustituye a una actualización, y se elude si el servidor también es accesible directamente. WAF y parcheo virtual para PHP →
Webshell: Una webshell es un script que los atacantes depositan en un servidor web para controlarlo de forma remota desde el navegador. Suele ser pequeña, estar ofuscada y escondida en carpetas de cargas o de caché. Una webshell sigue existiendo tras una actualización de PHP o del CMS y hay que buscarla de forma específica. Detectar y eliminar una webshell →

X

XSS: XSS (Cross-Site Scripting) significa que JavaScript ajeno se ejecuta, a través de un sitio web, en el navegador de otros visitantes. Con ello se pueden secuestrar sesiones o leer lo que se escribe en formularios. La protección la ofrecen la codificación sistemática de todas las salidas y una Content Security Policy. Evitar XSS en PHP: defenderse con seguridad del cross-site scripting →
XXE: XXE (XML External Entities) aprovecha que los analizadores XML pueden cargar referencias externas incluidas en los documentos. Con ello, en determinadas circunstancias, se pueden leer archivos del servidor o desencadenar peticiones internas. La protección consiste en desactivar la carga de entidades externas al procesar datos XML no fiables. Evitar las entidades externas XML (XXE) en PHP →

Z

ZAC: Las Zentrale Ansprechstellen Cybercrime (ZAC, puntos de contacto centrales contra la ciberdelincuencia) de la policía alemana son oficinas especializadas para empresas y autoridades que han sido víctimas de un ciberataque. Existen en todos los estados federados alemanes y en la BKA. Recogen denuncias y asesoran sobre cómo proceder. Presentar una denuncia: Puntos Centrales de Contacto contra la Cibercriminalidad →
Zend Engine: La Zend Engine es el núcleo del intérprete de PHP. Traduce el código PHP a instrucciones internas (opcodes), las ejecuta y gestiona la memoria. Los fallos de la Zend Engine afectan a cualquier aplicación PHP y solo se corrigen con una actualización de PHP. La Zend Engine: el corazón de PHP →
Zero-Day: Un zero-day es una vulnerabilidad que se explota o es de conocimiento público antes de que el fabricante ofrezca un parche. Los operadores no disponen entonces de ni un solo día de margen. Hasta el parche solo ayudan las medidas provisionales, el aislamiento y la vigilancia. La ventana de tiempo entre el parche y el ataque →

Contacto inmediato

Cada hora cuenta. Escríbanos ahora.

Describa brevemente el sistema, la versión de PHP y lo que ha observado. Nos pondremos en contacto, aclararemos la situación y trabajaremos en remoto hasta que el incidente quede cerrado y documentado.

Emergencia por WhatsApp Llamar