Blog: PHP2Shell, seguridad de servidores y ayuda de emergencia
Valoración de la situación, tutoriales para administradores y ayudas para decidir dirigidas a la dirección. Ordenado por tema, cada artículo con fuentes.
Situación y valoración
17 artículos
PHP2Shell: qué está comprobado y qué no
Una verificación de hechos sobre PHP2Shell: qué afirmaciones proceden de fuentes primarias, cuáles de informes de prensa y qué afirmaciones no se sostienen.
Seguir leyendo →002Por qué se conoció la vulnerabilidad de PHP antes del parche
Según los informes, los detalles de PHP2Shell se hicieron públicos antes de que terminara el embargo. Explicamos el desarrollo y qué significa para su planificación de parches.
Seguir leyendo →003Las autoridades desconectan sus webs: qué pueden aprender las empresas
Maguncia, el Gobierno regional de Hesse y la BKA desconectaron webs como medida preventiva. Qué pueden aprender las empresas para su propia decisión.
Seguir leyendo →004Nivel de alerta naranja del BSI: qué significa esta clasificación
El BSI clasifica PHP2Shell con 3 / naranja. Qué dice la escala, qué no dice y cómo traducen las empresas la clasificación en decisiones.
Seguir leyendo →005Qué aconsejan CERT-EU y CERT-Bund sobre PHP2Shell
Los organismos oficiales coinciden: parchear de inmediato y, si no, aislar. Comparamos las recomendaciones y mostramos cómo es el aislamiento en la práctica.
Seguir leyendo →006Reglas de protección de Cloudflare contra PHP2Shell: qué logran y qué no
Cloudflare desplegó pronto reglas de protección contra PHP2Shell. Por qué ayudan, por qué aun así no sustituyen la actualización de PHP y qué ajustes debe revisar.
Seguir leyendo →00722,6 millones de instancias expuestas: cómo interpretar las cifras
Unit 42, CybelAngel y otros citan cifras muy distintas sobre PHP2Shell. Explicamos qué se contó y qué cifra cuenta de verdad para usted.
Seguir leyendo →008PHP2Shell en cinco minutos: informe para la dirección
La vulnerabilidad de PHP PHP2Shell en una página para quien decide: situación, riesgo, cinco preguntas a TI y las decisiones para hoy.
Seguir leyendo →009La vulnerabilidad de seguridad de PHP explicada de forma sencilla
PHP2Shell para quien no es técnico: con imágenes cotidianas, un pequeño glosario y tres situaciones de partida típicas sobre qué debe hacer como responsable de un sitio web.
Seguir leyendo →010PHP2Shell: 15 preguntas de clientes de alojamiento web
¿Su sitio web está en un proveedor de alojamiento y quiere saber qué debe hacer usted mismo ante PHP2Shell? Aquí van las 15 preguntas más frecuentes con respuestas breves.
Seguir leyendo →011Por qué actualizar WordPress no ayuda contra PHP2Shell
Tras los titulares, muchos administradores actualizaron WordPress y se sienten seguros. Por qué eso no sirve con PHP2Shell y qué cuenta en su lugar.
Seguir leyendo →012PHP2Shell y Log4Shell: qué tienen en común las vulnerabilidades
Muchos comparan PHP2Shell con Log4Shell de 2021. Qué aporta la comparación, dónde cojea y qué lecciones de entonces ayudan hoy.
Seguir leyendo →013Escaneos masivos en busca de PHP sin parchear: así funcionan los ataques automatizados
Tras PHP2Shell, los atacantes rastrean internet de forma automatizada en busca de servidores vulnerables. Cómo funciona, por qué el tamaño no importa y qué le protege.
Seguir leyendo →014La ventana de tiempo entre el parche y el ataque
En PHP2Shell hubo intentos de ataque ya antes del parche. Explicamos las fases de la ventana de tiempo, cómo medir la suya propia y cómo acortarla.
Seguir leyendo →015Tras PHP2Shell: por qué son probables más avisos
PHP2Shell no queda cerrado con el parche del 21 de octubre. Por qué cabe esperar más avisos y cómo preparar a su equipo.
Seguir leyendo →016PHP2Shell: el panorama de la primera semana
Una semana después del primer intento de ataque observado: el estado de los parches, las alertas de las autoridades, los ataques y las desconexiones, separado con claridad por fuentes.
Seguir leyendo →017Consejos erróneos y peligrosos sobre PHP2Shell que circulan ahora
Bloquear cookies, ocultar mensajes de error, actualizar solo el CMS: nueve consejos sobre PHP2Shell que dan una falsa seguridad y lo que cuenta de verdad.
Seguir leyendo →Hosting y distribuciones
18 artículos
Cambiar la versión de PHP en el área de cliente del alojamiento
Cómo cambiar la versión de PHP en el área de cliente de su proveedor de alojamiento, qué versión elegir y qué comprobar antes y después.
Seguir leyendo →019Debian y Ubuntu: ¿está parcheado mi paquete de PHP?
Qué paquetes de PHP han corregido Debian y Ubuntu frente a PHP2Shell, cómo comparar con exactitud el estado instalado y en qué falla el justificante.
Seguir leyendo →020RHEL, AlmaLinux y Rocky Linux: comprobar el parche de PHP
Qué ha publicado Red Hat sobre PHP2Shell, cómo acreditar el nivel del paquete en RHEL y sus derivados y por qué una recarga no basta.
Seguir leyendo →021El repositorio sury.org: paquetes de PHP de una fuente de terceros
Muchos servidores Debian y Ubuntu obtienen PHP del repositorio sury. Qué significa eso para las actualizaciones, los justificantes y las versiones antiguas de PHP tras PHP2Shell.
Seguir leyendo →022El repositorio Remi: mantener PHP al día en sistemas RHEL
Remi ofrece versiones actuales de PHP para la familia RHEL, como módulo o instalables en paralelo. Así comprueba el estado tras PHP2Shell y evita ramas olvidadas.
Seguir leyendo →023Por qué php -v muestra el mismo número tras la actualización
La actualización se hizo, pero php -v indica la versión antigua. Casi siempre es un backport y no un fallo. Así distingue lo inofensivo de los problemas reales.
Seguir leyendo →024Acreditar números CVE en el registro de cambios del paquete
Quien debe acreditar un parche de PHP ante la dirección, auditores o aseguradoras necesita algo más que un número de versión. Así se convierte la entrada del registro de cambios en un justificante.
Seguir leyendo →025Cambiar de hoster tras un incidente de seguridad: ¿en qué fijarse?
Tras un incidente se entiende el deseo de un hoster nuevo. Para que el cambio no se lleve consigo al atacante, importan el orden y la elección.
Seguir leyendo →026Varias versiones de PHP en un servidor: parchear cada una por separado
En muchos servidores conviven tres, cuatro o más instalaciones de PHP. Tras PHP2Shell hay que localizar, actualizar y reiniciar cada una.
Seguir leyendo →027Desactivar versiones antiguas de PHP en el panel de alojamiento
PHP2Shell es una buena ocasión para deshacerse de versiones antiguas de PHP. Así se procede en tres fases, para que ningún sitio web ni tarea cron deje de funcionar sin que nadie lo note.
Seguir leyendo →028Plesk: entender los handlers de PHP (FPM, FastCGI, módulo de Apache)
El handler de PHP que Plesk usa para un sitio web decide el aislamiento, la configuración y el riesgo. Una comparación pensando en PHP2Shell.
Seguir leyendo →029CloudLinux y alt-php: lo que deben saber los clientes de alojamiento
En servidores CloudLinux, los sitios web suelen funcionar con paquetes alt-php propios. Cada una de estas versiones necesita su propio parche, y solo el operador del servidor puede aplicarlo.
Seguir leyendo →030PHP en NAS, cortafuegos y appliances: los sistemas olvidados
No solo los servidores web usan PHP. También pueden verse afectados los sistemas NAS, los cortafuegos y los equipos especializados con interfaz web. Allí normalmente solo puede parchear el fabricante; la accesibilidad la regula usted.
Seguir leyendo →031PHP en proveedores cloud y PaaS: ¿quién parchea el entorno de ejecución?
En los servicios de plataforma, el parche de PHP depende del modelo de explotación. Lo decisivo es el entorno de ejecución que realmente sirve las peticiones, no el entorno local ni el código de la aplicación.
Seguir leyendo →032Imágenes Docker oficiales de PHP: tags, digests y reconstrucción
Un tag de la imagen oficial de PHP es un puntero que, con el tiempo, se mueve a niveles nuevos. Quien sabe qué significan tag, variante y digest elige la imagen correcta y puede acreditar el nivel de parcheo.
Seguir leyendo →033CI/CD: reconstruir automáticamente las imágenes de PHP
Una imagen se queda obsoleta aunque no cambie el código. Con builds programados, una comprobación de versión y un despliegue por digest, los parches de PHP llegan a producción de forma fiable.
Seguir leyendo →034Soporte a largo plazo para versiones antiguas de PHP: opciones y límites
Quien no puede abandonar de inmediato PHP 8.1 o anteriores encuentra soporte a largo plazo en distribuciones, terceros y servicios comerciales. Qué ofrecen estos caminos, qué necesita por escrito y dónde están los límites.
Seguir leyendo →035Actualizar PHP en Windows
En Windows no hay actualización automática de PHP. Quien elige la variante correcta, verifica la descarga y reinicia todos los procesos lleva el parche de PHP2Shell limpiamente a cada equipo.
Seguir leyendo →Detección y análisis forense
18 artículos
Señal de alerta: el servidor web inicia una shell
Si un proceso de PHP-FPM o del servidor web inicia una shell, es una de las señales de alerta más fuertes de una intrusión. Cómo revisar el árbol de procesos, valorar las excepciones y vigilar el patrón de forma permanente.
Seguir leyendo →037Encontrar procesos sospechosos en servidores Linux
Los procesos maliciosos se camuflan con nombres inofensivos, se ejecutan desde carpetas temporales o desde archivos borrados. Con pocos comandos de lectura encuentra anomalías y las valora.
Seguir leyendo →038Reconocer tareas cron ocultas como puerta trasera
Los atacantes usan tareas programadas para volver tras una limpieza. Cómo revisar por completo crontabs, directorios cron, temporizadores de systemd y trabajos at, y reconocer entradas sospechosas.
Seguir leyendo →039Encontrar archivos modificados recientemente en el servidor web
Tras una posible intrusión importa lo que ha cambiado en el servidor. Cómo buscar por ventanas temporales, usar bien mtime y ctime y contrastar con paquetes, Git y copias de seguridad.
Seguir leyendo →040Archivos PHP en la carpeta de subida: interpretar bien los hallazgos
Un archivo PHP en la carpeta de subida es casi siempre una señal de alarma, pero no todos son código malicioso. Cómo valorar el hallazgo sin destruir huellas y aclarar si alguien lo ha llamado.
Seguir leyendo →041Reconocer código PHP ofuscado
El código PHP ilegible con eval y base64_decode es una señal clásica de código malicioso inyectado. Qué patrones buscar, cómo encontrarlos sin riesgo y cuándo la ofuscación es legítima.
Seguir leyendo →042Comprobar las conexiones salientes de un servidor
Un servidor web responde sobre todo a peticiones. Si él mismo establece conexiones con destinos desconocidos, puede significar control por atacantes o fuga de datos. Cómo comprobar y limitar el tráfico saliente.
Seguir leyendo →043Encontrar cuentas de administrador ajenas en el CMS y el servidor
Un administrador desconocido es a menudo la puerta trasera más sencilla. Cómo buscar nivel por nivel cuentas ajenas, también las que la interfaz oculta.
Seguir leyendo →044Encontrar y eliminar claves SSH desconocidas
Una clave SSH inyectada abre la puerta a los atacantes aunque se hayan cambiado todas las contraseñas. Cómo encontrar cada archivo authorized_keys y revisar cada entrada.
Seguir leyendo →045Criptominero en el servidor web: indicios y cómo proceder
CPU permanentemente a tope sin que lleguen más visitantes: puede ser un criptominero. Cómo revisar la carga, encontrar el proceso y sus mecanismos de reinicio y proceder con orden.
Seguir leyendo →046El servidor envía spam: encontrar las causas
Correos no entregables, listas de bloqueo, quejas: cuando su propio servidor envía spam, casi siempre hay detrás un script o un buzón secuestrado. Cómo encontrar el origen.
Seguir leyendo →047Spam SEO y páginas ajenas en el índice de Google
De pronto, bajo su dominio se posicionan páginas sobre medicamentos o productos de marca. Cómo averiguar de dónde viene el spam SEO y sacarlo del índice.
Seguir leyendo →048El sitio web redirige a páginas ajenas
¿Los visitantes acaban en sorteos o tiendas dudosas y usted no ve nada? Cómo encontrar la capa donde se oculta la redirección y eliminarla.
Seguir leyendo →049Conservar las pruebas antes de reinstalar el servidor
Reconstruir el servidor elimina al atacante, pero también todos los rastros. Quien dedica antes una hora a conservar las pruebas podrá explicar después qué ocurrió.
Seguir leyendo →050Elaborar la cronología de un incidente
¿Cuándo llegó el atacante, qué hizo, cuándo se notó? Una cronología limpia responde a estas preguntas y es la base de las notificaciones, del seguro y del informe.
Seguir leyendo →051Comparar los archivos del núcleo del CMS con el original
La comparación con un original limpio muestra cada archivo modificado, lo conozca o no un escáner. Así se monta la comparación para WordPress, proyectos Composer y paquetes del sistema.
Seguir leyendo →052Revisar la base de datos en busca de código inyectado
Quien solo revisa archivos pasa por alto la mitad. Cómo buscar código inyectado en contenidos, ajustes, triggers y cuentas de la base de datos, en modo lectura y sobre una copia.
Seguir leyendo →053Escáneres de malware para sitios web: qué encuentran y qué no
¿El escáner no avisa de nada, así que todo está bien? No necesariamente. Qué tipos de escáneres de sitios web existen, qué ve cada uno y qué no puede ver por principio.
Seguir leyendo →Refuerzo y configuración
20 artículos
Aislar los pools de PHP-FPM por sitio web
Un pool propio por sitio web es el comienzo, no el final. Cómo revisar los pools existentes y reforzar sockets, extensiones, páginas de estado, recursos y logs.
Seguir leyendo →055Fijar bien memory_limit
memory_limit limita la memoria por petición PHP. Tras PHP2Shell, php.net recomienda temporalmente lo contrario. Qué rige en el funcionamiento normal, en la transición y tras la actualización.
Seguir leyendo →056Limitar con criterio post_max_size y upload_max_filesize
Los límites de subida actúan en tres puntos: el servidor web, PHP y la aplicación. Cómo fijar los valores de forma coherente, también con los valores transitorios de php.net para PHP2Shell.
Seguir leyendo →057Desactivar session.upload_progress: bien y de forma permanente
La contramedida frente a CVE-2026-115560 y una de las medidas transitorias de PHP2Shell se fija rápido. Para que se mantenga, debe estar en el lugar correcto, bloqueada y revisada de nuevo tras cada actualización.
Seguir leyendo →058expose_php y cabecera Server: ocultar los datos de versión
PHP, Nginx y Apache indican por defecto su número de versión en cada respuesta. Eso no protege de ataques, pero da a los escáneres una cómoda lista de objetivos. Cómo desactivarlo sin perder la visión de conjunto.
Seguir leyendo →059display_errors off: desactivar la salida de errores en producción
Los mensajes de error de PHP visibles revelan rutas, nombres de bases de datos y versiones. Cómo desactivarlos en PHP, en el framework y en el servidor web sin perder de vista los errores.
Seguir leyendo →060php_admin_value: bloquear ajustes frente a la sobrescritura
Un ajuste de seguridad sirve de poco si la aplicación lo cambia de nuevo con una línea de código. Con php_admin_value y php_admin_flag fija valores vinculantes para PHP-FPM y Apache.
Seguir leyendo →061Fijar límites de memoria con systemd y cgroups
php.net recomienda como medida transitoria de PHP2Shell memory_limit=-1 y un límite de memoria fuera de PHP. Cómo fijar ese límite con systemd y cgroups sin que un solo worker arrastre a todo el servicio.
Seguir leyendo →062Configurar Nginx para PHP de forma segura
La mayoría de los puntos débiles de las configuraciones de Nginx para PHP no están en Nginx, sino en unas pocas líneas de la location de PHP. Cómo configurar el traspaso a PHP-FPM para que solo se ejecuten los scripts deseados.
Seguir leyendo →063Configurar Apache para PHP de forma segura
Apache es flexible, y precisamente eso lo hace vulnerable a errores de configuración. Cómo conectar PHP mediante PHP-FPM, cerrar .htaccess como puerta trasera y fijar de forma segura las opciones básicas más importantes.
Seguir leyendo →064Prohibir la ejecución de PHP en las carpetas de subidas
Una webshell necesita dos cosas: una carpeta donde pueda escribirse y un servidor que la ejecute. Cómo quitarle lo segundo, y en toda carpeta con permiso de escritura, no solo en uploads.
Seguir leyendo →065Filtrar peticiones de subida en el borde: oportunidades y riesgos
Autores especializados proponen bloquear en el proxy las peticiones de subida fuera de las rutas de subida reales hasta que PHP esté parcheado. Puede ayudar, pero también paralizar formularios y pedidos. Cómo proceder de forma controlada.
Seguir leyendo →066Usar ModSecurity y el OWASP Core Rule Set
Un Web Application Firewall propio con ModSecurity y el OWASP Core Rule Set es gratuito y potente, pero no funciona solo. Cómo elegir el motor, empezar sin interrupciones y afinar las reglas.
Seguir leyendo →067Configurar Fail2ban para servidores web
Fail2ban bloquea las direcciones que llaman la atención de forma repetida en los logs. Para servidores web trae filtros ya hechos, y con pocas líneas se añaden otros propios. Cómo configurarlo sin bloquearse a sí mismo ni a sus clientes.
Seguir leyendo →068Cortafuegos para servidores web: abrir solo los puertos necesarios
Un servidor web suele necesitar hacia fuera solo dos puertos. Aun así, en muchos servidores escuchan en internet bases de datos, PHP-FPM o interfaces de administración. Cómo encontrar los servicios abiertos y cerrar lo que no se necesita.
Seguir leyendo →069Actualizaciones de seguridad automáticas en servidores Linux
Según informes, las distribuciones entregaron backports de PHP en parte el mismo 21 de octubre de 2026, el día de los parches. Quien usa actualizaciones de seguridad automáticas las tuvo pronto en el servidor. Para que además surtan efecto hacen falta reinicios, fuentes de terceros y control.
Seguir leyendo →070Mínimo privilegio: los permisos del usuario del servidor web
El código inyectado se ejecuta con los permisos del usuario del servidor web. Lo que esa cuenta puede hacer decide hasta dónde llega un atacante. Cómo limitar shell, sudo, cron, base de datos y sistema de archivos a lo necesario.
Seguir leyendo →071Blindar las áreas de administración con IP, VPN o protección adicional
Por qué el backend de un sitio web no tiene por qué ser accesible para todo el mundo y cómo blindarlo con una lista de IP, un VPN o un inicio de sesión previo, sin quedarse usted mismo fuera.
Seguir leyendo →072Configurar TLS y HTTPS correctamente
Qué versiones de TLS y cipher suites debería ofrecer hoy un servidor web, en qué se basan las recomendaciones y cómo comprobar Nginx, Apache y las conexiones salientes de PHP.
Seguir leyendo →073Benchmarks CIS y módulos de la BSI para servidores web
Qué estándares de refuerzo existen para servidores web Linux, en qué se diferencian los benchmarks CIS de los módulos del IT-Grundschutz y cómo convertirlos en una norma verificable para sus servidores PHP.
Seguir leyendo →Desarrollo seguro
16 artículos
Guardar contraseñas en PHP con seguridad: usar bien password_hash
Cómo guardan los desarrolladores las contraseñas en PHP con password_hash y password_verify, cómo elegir el algoritmo adecuado y cómo sustituir hashes MD5 o SHA-1 antiguos sin restablecer la contraseña de todos los usuarios.
Seguir leyendo →075Protección CSRF en aplicaciones PHP
Cómo evitan los desarrolladores el Cross-Site Request Forgery en aplicaciones PHP: tokens para cada petición que modifique datos, comprobación del origen en la cabecera y cookies SameSite como capa adicional.
Seguir leyendo →076Validar y filtrar entradas en PHP con filter_var
Cómo comprueban los desarrolladores las entradas en PHP con filter_var, filter_input_array y listas de permitidos, qué filtros están obsoletos y por qué la validación no sustituye a las consultas preparadas ni a la codificación de salida.
Seguir leyendo →077Evitar la inyección de comandos (command injection) en PHP
Cómo evitan los desarrolladores la inyección de comandos en PHP: sustituir comandos del sistema por funciones de PHP, usar proc_open sin shell, comprobar los argumentos y encontrar los puntos peligrosos en el código existente.
Seguir leyendo →078Evitar el Server-Side Request Forgery (SSRF) en PHP
Cómo evitan los desarrolladores que una aplicación PHP consulte sistemas internos por encargo de terceros: listas de permitidos, restricción de protocolos, comprobación de la dirección resuelta y límites en la red.
Seguir leyendo →079Evitar las entidades externas XML (XXE) en PHP
Cómo procesan los desarrolladores XML en PHP con seguridad: comportamiento predeterminado de libxml, opciones arriesgadas como LIBXML_NOENT, protección con cargador de entidades y LIBXML_NO_XXE, y entradas XML ocultas típicas.
Seguir leyendo →080Type juggling en PHP: las comparaciones laxas como riesgo de seguridad
Por qué las comparaciones laxas con == en PHP pueden provocar vulnerabilidades, qué cambió con PHP 8.0 y cómo escribir comparaciones robustas en inicios de sesión, tokens y permisos.
Seguir leyendo →081Números aleatorios y tokens seguros en PHP con random_bytes
Cómo generan los desarrolladores en PHP tokens para enlaces de contraseña, claves de API y códigos de un solo uso: fuentes criptográficamente seguras, longitud suficiente, almacenamiento como hash y validez limitada.
Seguir leyendo →082Proteger correctamente las credenciales y los archivos .env
Cómo proteger contraseñas de bases de datos, claves de API y otros secretos en proyectos PHP: archivos .env fuera del webroot, bloqueos en el servidor web, permisos estrictos y renovación ordenada tras un incidente.
Seguir leyendo →083Carpeta .git pública: una fuga de datos subestimada
Por qué un webroot desplegado con Git puede revelar todo el código fuente con su historial, cómo comprobarlo, bloquearlo de inmediato y montar el despliegue de forma permanente sin carpeta .git.
Seguir leyendo →084Archivos de copia de seguridad en el webroot: .zip, .sql y .bak
Por qué los volcados de bases de datos, los archivos comprimidos y las copias de seguridad en el directorio público figuran entre las fugas de datos más frecuentes, cómo encontrarlos y bloquearlos y cómo aclarar si se descargaron.
Seguir leyendo →085Archivos phpinfo(): por qué deben desaparecer
Tras PHP2Shell, muchos administradores crean deprisa un info.php. Por qué esos archivos son una fuga de datos, cómo encontrarlos y qué vías de comprobación son mejores.
Seguir leyendo →086Mantener al día las dependencias: Composer, npm y plugins
Un proyecto se compone de tres mundos de paquetes: Composer, npm y plugins de CMS. Cómo mantener los tres al día con un ritmo fijo, responsabilidades claras y pruebas.
Seguir leyendo →087Revisión de código de seguridad para proyectos PHP
Cómo revisan los equipos su propio código PHP en busca de vulnerabilidades: tipos de revisión, funciones críticas, herramientas útiles y una lista de comprobación.
Seguir leyendo →088Registrar con seguridad: anotar errores sin fuga de datos
Los logs ayudan en la búsqueda de errores y en el análisis forense, pero enseguida se convierten ellos mismos en una fuga de datos. Qué deben registrar las aplicaciones PHP, qué nunca y cómo proteger los logs.
Seguir leyendo →089Proteger las API REST en PHP
Las interfaces suelen estar peor protegidas que el sitio web que tienen delante. Las reglas más importantes para las API REST en PHP, desde el permiso por objeto hasta la limitación de tasa.
Seguir leyendo →Dirección y aspectos legales
14 artículos
Contratos con proveedores de TI: regular con claridad las obligaciones de seguridad
PHP2Shell ha mostrado con qué frecuencia no está claro quién debe parchear. Qué obligaciones de seguridad deben incluirse en los contratos con agencias, proveedores de hosting y proveedores de TI.
Seguir leyendo →091Encargo del tratamiento cuando los proveedores acceden a servidores
Quien deja que externos accedan a servidores con datos de clientes suele necesitar un contrato de encargo del tratamiento. Qué exige el art. 28 del RGPD y cómo organizar los accesos en una emergencia conforme a la protección de datos.
Seguir leyendo →092Gestión de vulnerabilidades para la pyme
Ninguna pyme puede despachar cada aviso al instante. Un ciclo ligero de registrar, valorar, decidir y documentar hace que lo más importante se haga primero.
Seguir leyendo →093Saber qué se ejecuta: inventario de todos los sitios web y servidores
En PHP2Shell muchos no fallaron por el parche, sino por la pregunta de dónde se ejecuta PHP. Así construye un inventario de todos los sitios web y servidores.
Seguir leyendo →094Gestión de parches como proceso en lugar de bomberos
Quien solo parchea cuando hay fuego pierde tiempo en una emergencia. Cómo un proceso con clases, ventanas y pruebas documentales une la rutina y la emergencia.
Seguir leyendo →095Contactos de emergencia: ¿a quién hay que avisar y cuándo?
En una emergencia cuenta a quién se localiza y cuándo. Cómo crear una lista de contactos de emergencia de TI con detonantes, suplencias y los datos que necesita cada llamada.
Seguir leyendo →096Lo que cuesta un servidor hackeado: las partidas de coste
Un servidor web hackeado genera más costes que la reparación. Qué partidas se producen y cómo justificar con cifras propias un presupuesto de prevención.
Seguir leyendo →097Informar a los clientes tras un incidente
Sea obligatorio o voluntario: cómo decidir tras un incidente a quién informar, qué canales son seguros y cómo preparar su servicio de atención al cliente.
Seguir leyendo →098La cadena de suministro web: agencia, proveedor de alojamiento, proveedores de plugins
PHP2Shell ha mostrado cuántos eslabones hay entre un parche y su sitio web. Cómo conocer y proteger la cadena de suministro de su web y amortiguar el fallo de un eslabón.
Seguir leyendo →099Concienciación en seguridad para administradores y redactores en el equipo web
Quien mantiene sitios web decide cada día sobre seguridad, a menudo sin darse cuenta. Cómo formar a administradores y redactores según su rol y sin maratones de diapositivas.
Seguir leyendo →100Ejercicio de emergencia sobre la mesa: simular un incidente de servidor web
Un ejercicio sobre la mesa cuesta una tarde y muestra si su plan de emergencia resiste. Aquí encontrará un guion listo para un incidente en un servidor web con PHP.
Seguir leyendo →101ISO 27001 y TISAX: qué afecta a los servidores web
Quien opera un SGSI según ISO 27001 o tiene una etiqueta TISAX debe tener en cuenta los servidores web. Qué requisitos afectan y qué pruebas cuentan tras PHP2Shell.
Seguir leyendo →102VdS 10000: seguridad de la información para pequeñas y medianas empresas
La VdS 10000 es un marco ligero de seguridad de la información para la pyme. Qué exige, qué novedades llegaron en 2025 y qué significa para sitios web y servidores web.
Seguir leyendo →103Lessons learned: mejorar después del incidente
Después del incidente viene el próximo. Una reunión posterior estructurada y sin culpables convierte una mala semana en un avance medible.
Seguir leyendo →Ayudas para decidir
10 artículos
¿Parchear, apagar o esperar? Una ayuda para decidir ante la vulnerabilidad de PHP
Ante una vulnerabilidad crítica de PHP, los responsables deben decidir rápido. Esta ayuda ordena las tres opciones, indica criterios y muestra cuándo es defendible esperar.
Seguir leyendo →105WAF o actualización: por qué necesita ambas
Un firewall de aplicaciones web puede frenar ataques, pero no cierra una vulnerabilidad en el intérprete de PHP. Cuándo ayuda un WAF, dónde termina y cómo combinar ambos con sentido.
Seguir leyendo →106¿Reinstalar o limpiar el servidor? La decisión tras una infección
Tras una intrusión hay dos caminos: limpiar el servidor o reconstruirlo. Qué criterios deciden, y por qué el orden importa más que la elección.
Seguir leyendo →107¿Resolverlo uno mismo o buscar un proveedor? Una ponderación honesta
No toda situación de seguridad necesita ayuda externa. Con estos criterios y un breve autotest decide si su equipo afronta PHP2Shell por sí solo o necesita apoyo.
Seguir leyendo →108Elegir un proveedor de seguridad TI: 12 preguntas antes del encargo
Encontrar bajo presión de tiempo un buen proveedor de seguridad es difícil. Estas doce preguntas ayudan a comparar ofertas con objetividad, sin caer en promesas publicitarias.
Seguir leyendo →109Hosting gestionado o servidor propio: la comparativa de seguridad
PHP2Shell fue una prueba de esfuerzo para cada modelo de operación. La comparativa muestra cuándo es más seguro el hosting gestionado, cuándo el servidor propio y qué formas mixtas funcionan.
Seguir leyendo →110¿Actualizar PHP o backport? La decisión para sistemas antiguos
Para las versiones antiguas de PHP hay tras PHP2Shell varios caminos: backport de la distribución, fuente de terceros, parche de código fuente, soporte a largo plazo o actualización. Qué vale cada uno y cuánto dura.
Seguir leyendo →111¿Cambiar de CMS tras el hackeo? Cuándo ayuda y cuándo no
Tras una intrusión, la confianza en el CMS suele perderse. Pero un sistema nuevo rara vez resuelve la causa real. Cuándo tiene sentido el cambio y cómo hacerlo limpiamente.
Seguir leyendo →112Sitios web estáticos: menos PHP, menos superficie de ataque
Un sitio web estático sirve archivos HTML terminados y no necesita PHP en el servidor. Eso reduce mucho la superficie de ataque, pero trae sus propios límites y obligaciones.
Seguir leyendo →113¿Pentest, bug bounty o escaneo de vulnerabilidades? Elegir el método de auditoría adecuado
El escaneo, la prueba de penetración y el bug bounty auditan sitios web de formas muy distintas. Qué logra cada método, dónde falla y qué orden encaja con su empresa.
Seguir leyendo →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.