# Blog: PHP2Shell, seguridad de servidores y ayuda de emergencia

> Blog sobre PHP2Shell y seguridad de servidores: situación, hosting, detección, refuerzo, desarrollo seguro, dirección y ayudas para decidir.

Fuente: https://phpsos.de/es/blog/  
Actualizado: 25/10/2026  
Proveedor: PHP SOS, Ayuda de emergencia para PHP y seguridad de servidores. Ayuda inmediata por WhatsApp: https://wa.me/491736494914?text=Hola%20PHP%20SOS%2C%20necesitamos%20ayuda%20con%20nuestro%20servidor%20PHP.%20Empresa%3A%20%E2%80%A6%20Sitio%20web%3A%20%E2%80%A6

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.

- [PHP2Shell: qué está comprobado y qué no](https://phpsos.de/es/blog/php2shell-was-belegt-ist/): 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.
- [Por qué se conoció la vulnerabilidad de PHP antes del parche](https://phpsos.de/es/blog/php-luecke-vorzeitig-bekannt/): 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.
- [Las autoridades desconectan sus webs: qué pueden aprender las empresas](https://phpsos.de/es/blog/behoerden-webseiten-offline/): Maguncia, el Gobierno regional de Hesse y la BKA desconectaron webs como medida preventiva. Qué pueden aprender las empresas para su propia decisión.
- [Nivel de alerta naranja del BSI: qué significa esta clasificación](https://phpsos.de/es/blog/bsi-warnstufe-orange-erklaert/): 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.
- [Qué aconsejan CERT-EU y CERT-Bund sobre PHP2Shell](https://phpsos.de/es/blog/cert-eu-empfehlungen-php/): 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.
- [Reglas de protección de Cloudflare contra PHP2Shell: qué logran y qué no](https://phpsos.de/es/blog/cloudflare-waf-php2shell/): 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.
- [22,6 millones de instancias expuestas: cómo interpretar las cifras](https://phpsos.de/es/blog/exponierte-instanzen-einordnen/): Unit 42, CybelAngel y otros citan cifras muy distintas sobre PHP2Shell. Explicamos qué se contó y qué cifra cuenta de verdad para usted.
- [PHP2Shell en cinco minutos: informe para la dirección](https://phpsos.de/es/blog/php2shell-briefing-geschaeftsfuehrung/): La vulnerabilidad de PHP PHP2Shell en una página para quien decide: situación, riesgo, cinco preguntas a TI y las decisiones para hoy.
- [La vulnerabilidad de seguridad de PHP explicada de forma sencilla](https://phpsos.de/es/blog/php-luecke-einfach-erklaert/): 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.
- [PHP2Shell: 15 preguntas de clientes de alojamiento web](https://phpsos.de/es/blog/fragen-von-hosting-kunden/): ¿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.
- [Por qué actualizar WordPress no ayuda contra PHP2Shell](https://phpsos.de/es/blog/warum-wordpress-update-nicht-hilft/): Tras los titulares, muchos administradores actualizaron WordPress y se sienten seguros. Por qué eso no sirve con PHP2Shell y qué cuenta en su lugar.
- [PHP2Shell y Log4Shell: qué tienen en común las vulnerabilidades](https://phpsos.de/es/blog/php2shell-und-log4shell/): Muchos comparan PHP2Shell con Log4Shell de 2021. Qué aporta la comparación, dónde cojea y qué lecciones de entonces ayudan hoy.
- [Escaneos masivos en busca de PHP sin parchear: así funcionan los ataques automatizados](https://phpsos.de/es/blog/automatisierte-massenscans/): 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.
- [La ventana de tiempo entre el parche y el ataque](https://phpsos.de/es/blog/zeitfenster-patch-angriff/): 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.
- [Tras PHP2Shell: por qué son probables más avisos](https://phpsos.de/es/blog/weitere-php-meldungen/): 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.
- [PHP2Shell: el panorama de la primera semana](https://phpsos.de/es/blog/lagebild-erste-woche/): 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.
- [Consejos erróneos y peligrosos sobre PHP2Shell que circulan ahora](https://phpsos.de/es/blog/gefaehrliche-falschtipps/): 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.
- [Cambiar la versión de PHP en el área de cliente del alojamiento](https://phpsos.de/es/blog/php-version-hosting-aendern/): 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.
- [Debian y Ubuntu: ¿está parcheado mi paquete de PHP?](https://phpsos.de/es/blog/debian-ubuntu-paket-gepatcht/): 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.
- [RHEL, AlmaLinux y Rocky Linux: comprobar el parche de PHP](https://phpsos.de/es/blog/rhel-almalinux-rocky-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.
- [El repositorio sury.org: paquetes de PHP de una fuente de terceros](https://phpsos.de/es/blog/sury-repository-php/): 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.
- [El repositorio Remi: mantener PHP al día en sistemas RHEL](https://phpsos.de/es/blog/remi-repository-php/): 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.
- [Por qué php -v muestra el mismo número tras la actualización](https://phpsos.de/es/blog/php-v-zeigt-alte-nummer/): 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.
- [Acreditar números CVE en el registro de cambios del paquete](https://phpsos.de/es/blog/cve-im-changelog-nachweisen/): 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.
- [Cambiar de hoster tras un incidente de seguridad: ¿en qué fijarse?](https://phpsos.de/es/blog/hoster-wechseln-nach-vorfall/): 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.
- [Varias versiones de PHP en un servidor: parchear cada una por separado](https://phpsos.de/es/blog/mehrere-php-versionen-server/): En muchos servidores conviven tres, cuatro o más instalaciones de PHP. Tras PHP2Shell hay que localizar, actualizar y reiniciar cada una.
- [Desactivar versiones antiguas de PHP en el panel de alojamiento](https://phpsos.de/es/blog/alte-php-versionen-abschalten/): 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.
- [Plesk: entender los handlers de PHP (FPM, FastCGI, módulo de Apache)](https://phpsos.de/es/blog/plesk-php-handler/): 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.
- [CloudLinux y alt-php: lo que deben saber los clientes de alojamiento](https://phpsos.de/es/blog/cloudlinux-alt-php/): 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.
- [PHP en NAS, cortafuegos y appliances: los sistemas olvidados](https://phpsos.de/es/blog/php-auf-nas-und-appliances/): 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.
- [PHP en proveedores cloud y PaaS: ¿quién parchea el entorno de ejecución?](https://phpsos.de/es/blog/paas-php-laufzeit/): 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.
- [Imágenes Docker oficiales de PHP: tags, digests y reconstrucción](https://phpsos.de/es/blog/offizielle-php-docker-images/): 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.
- [CI/CD: reconstruir automáticamente las imágenes de PHP](https://phpsos.de/es/blog/php-images-in-ci-neu-bauen/): 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.
- [Soporte a largo plazo para versiones antiguas de PHP: opciones y límites](https://phpsos.de/es/blog/langzeitsupport-alte-php-versionen/): 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.
- [Actualizar PHP en Windows](https://phpsos.de/es/blog/php-unter-windows-aktualisieren/): 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.
- [Señal de alerta: el servidor web inicia una shell](https://phpsos.de/es/blog/webserver-startet-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.
- [Encontrar procesos sospechosos en servidores Linux](https://phpsos.de/es/blog/verdaechtige-prozesse-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.
- [Reconocer tareas cron ocultas como puerta trasera](https://phpsos.de/es/blog/cronjobs-als-hintertuer/): 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.
- [Encontrar archivos modificados recientemente en el servidor web](https://phpsos.de/es/blog/geaenderte-dateien-finden/): 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.
- [Archivos PHP en la carpeta de subida: interpretar bien los hallazgos](https://phpsos.de/es/blog/php-dateien-im-upload-ordner/): 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.
- [Reconocer código PHP ofuscado](https://phpsos.de/es/blog/verschleierter-php-code/): 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.
- [Comprobar las conexiones salientes de un servidor](https://phpsos.de/es/blog/ausgehende-verbindungen-pruefen/): 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.
- [Encontrar cuentas de administrador ajenas en el CMS y el servidor](https://phpsos.de/es/blog/fremde-admin-konten-finden/): 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.
- [Encontrar y eliminar claves SSH desconocidas](https://phpsos.de/es/blog/ssh-schluessel-pruefen/): 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.
- [Criptominero en el servidor web: indicios y cómo proceder](https://phpsos.de/es/blog/kryptominer-auf-dem-server/): 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.
- [El servidor envía spam: encontrar las causas](https://phpsos.de/es/blog/server-verschickt-spam/): 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.
- [Spam SEO y páginas ajenas en el índice de Google](https://phpsos.de/es/blog/seo-spam-im-google-index/): 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.
- [El sitio web redirige a páginas ajenas](https://phpsos.de/es/blog/website-leitet-um/): ¿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.
- [Conservar las pruebas antes de reinstalar el servidor](https://phpsos.de/es/blog/beweise-sichern-vor-neuinstallation/): 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ó.
- [Elaborar la cronología de un incidente](https://phpsos.de/es/blog/zeitleiste-eines-vorfalls/): ¿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.
- [Comparar los archivos del núcleo del CMS con el original](https://phpsos.de/es/blog/cms-kerndateien-vergleichen/): 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.
- [Revisar la base de datos en busca de código inyectado](https://phpsos.de/es/blog/datenbank-auf-schadcode-pruefen/): 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.
- [Escáneres de malware para sitios web: qué encuentran y qué no](https://phpsos.de/es/blog/grenzen-von-malware-scannern/): ¿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.
- [Aislar los pools de PHP-FPM por sitio web](https://phpsos.de/es/blog/php-fpm-pools-isolieren/): 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.
- [Fijar bien memory_limit](https://phpsos.de/es/blog/memory-limit-richtig-setzen/): 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.
- [Limitar con criterio post_max_size y upload_max_filesize](https://phpsos.de/es/blog/post-max-size-upload-limits/): 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.
- [Desactivar session.upload_progress: bien y de forma permanente](https://phpsos.de/es/blog/session-upload-progress-abschalten/): 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.
- [expose_php y cabecera Server: ocultar los datos de versión](https://phpsos.de/es/blog/expose-php-versionsangaben/): 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.
- [display_errors off: desactivar la salida de errores en producción](https://phpsos.de/es/blog/display-errors-produktion/): 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.
- [php_admin_value: bloquear ajustes frente a la sobrescritura](https://phpsos.de/es/blog/php-admin-value-sperren/): 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.
- [Fijar límites de memoria con systemd y cgroups](https://phpsos.de/es/blog/speichergrenzen-systemd-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.
- [Configurar Nginx para PHP de forma segura](https://phpsos.de/es/blog/nginx-fuer-php-absichern/): 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.
- [Configurar Apache para PHP de forma segura](https://phpsos.de/es/blog/apache-fuer-php-absichern/): 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.
- [Prohibir la ejecución de PHP en las carpetas de subidas](https://phpsos.de/es/blog/php-in-uploads-verbieten/): 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.
- [Filtrar peticiones de subida en el borde: oportunidades y riesgos](https://phpsos.de/es/blog/upload-anfragen-am-rand-filtern/): 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.
- [Usar ModSecurity y el OWASP Core Rule Set](https://phpsos.de/es/blog/modsecurity-owasp-crs/): 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.
- [Configurar Fail2ban para servidores web](https://phpsos.de/es/blog/fail2ban-fuer-webserver/): 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.
- [Cortafuegos para servidores web: abrir solo los puertos necesarios](https://phpsos.de/es/blog/firewall-fuer-webserver/): 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.
- [Actualizaciones de seguridad automáticas en servidores Linux](https://phpsos.de/es/blog/automatische-sicherheitsupdates/): 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.
- [Mínimo privilegio: los permisos del usuario del servidor web](https://phpsos.de/es/blog/rechte-des-webserver-benutzers/): 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.
- [Blindar las áreas de administración con IP, VPN o protección adicional](https://phpsos.de/es/blog/admin-bereiche-abschirmen/): 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.
- [Configurar TLS y HTTPS correctamente](https://phpsos.de/es/blog/tls-https-richtig-konfigurieren/): 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.
- [Benchmarks CIS y módulos de la BSI para servidores web](https://phpsos.de/es/blog/cis-benchmarks-bsi-bausteine/): 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.
- [Guardar contraseñas en PHP con seguridad: usar bien password_hash](https://phpsos.de/es/blog/passwoerter-in-php-speichern/): 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.
- [Protección CSRF en aplicaciones PHP](https://phpsos.de/es/blog/csrf-schutz-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.
- [Validar y filtrar entradas en PHP con filter_var](https://phpsos.de/es/blog/eingaben-validieren-php/): 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.
- [Evitar la inyección de comandos (command injection) en PHP](https://phpsos.de/es/blog/command-injection-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.
- [Evitar el Server-Side Request Forgery (SSRF) en PHP](https://phpsos.de/es/blog/ssrf-in-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.
- [Evitar las entidades externas XML (XXE) en PHP](https://phpsos.de/es/blog/xxe-in-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.
- [Type juggling en PHP: las comparaciones laxas como riesgo de seguridad](https://phpsos.de/es/blog/type-juggling-php/): 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.
- [Números aleatorios y tokens seguros en PHP con random_bytes](https://phpsos.de/es/blog/sichere-tokens-php/): 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.
- [Proteger correctamente las credenciales y los archivos .env](https://phpsos.de/es/blog/env-dateien-schuetzen/): 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.
- [Carpeta .git pública: una fuga de datos subestimada](https://phpsos.de/es/blog/git-ordner-oeffentlich/): 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.
- [Archivos de copia de seguridad en el webroot: .zip, .sql y .bak](https://phpsos.de/es/blog/backup-dateien-im-webroot/): 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.
- [Archivos phpinfo(): por qué deben desaparecer](https://phpsos.de/es/blog/phpinfo-dateien-entfernen/): 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.
- [Mantener al día las dependencias: Composer, npm y plugins](https://phpsos.de/es/blog/abhaengigkeiten-aktuell-halten/): 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.
- [Revisión de código de seguridad para proyectos PHP](https://phpsos.de/es/blog/sicherheits-code-review-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.
- [Registrar con seguridad: anotar errores sin fuga de datos](https://phpsos.de/es/blog/sicher-loggen-php/): 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.
- [Proteger las API REST en PHP](https://phpsos.de/es/blog/rest-api-php-absichern/): 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.
- [Contratos con proveedores de TI: regular con claridad las obligaciones de seguridad](https://phpsos.de/es/blog/dienstleistervertrag-sicherheit/): 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.
- [Encargo del tratamiento cuando los proveedores acceden a servidores](https://phpsos.de/es/blog/auftragsverarbeitung-serverzugriff/): 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.
- [Gestión de vulnerabilidades para la pyme](https://phpsos.de/es/blog/schwachstellenmanagement-mittelstand/): 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.
- [Saber qué se ejecuta: inventario de todos los sitios web y servidores](https://phpsos.de/es/blog/inventar-websites-server/): 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.
- [Gestión de parches como proceso en lugar de bomberos](https://phpsos.de/es/blog/patch-management-prozess/): 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.
- [Contactos de emergencia: ¿a quién hay que avisar y cuándo?](https://phpsos.de/es/blog/notfallkontakte-liste/): 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.
- [Lo que cuesta un servidor hackeado: las partidas de coste](https://phpsos.de/es/blog/kostenposten-eines-hacks/): 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.
- [Informar a los clientes tras un incidente](https://phpsos.de/es/blog/kunden-nach-vorfall-informieren/): 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.
- [La cadena de suministro web: agencia, proveedor de alojamiento, proveedores de plugins](https://phpsos.de/es/blog/lieferkette-agentur-hoster/): 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.
- [Concienciación en seguridad para administradores y redactores en el equipo web](https://phpsos.de/es/blog/sicherheitsbewusstsein-redaktion/): 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.
- [Ejercicio de emergencia sobre la mesa: simular un incidente de servidor web](https://phpsos.de/es/blog/notfalluebung-am-tisch/): 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.
- [ISO 27001 y TISAX: qué afecta a los servidores web](https://phpsos.de/es/blog/iso-27001-tisax-webserver/): 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.
- [VdS 10000: seguridad de la información para pequeñas y medianas empresas](https://phpsos.de/es/blog/vds-10000-kmu/): 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.
- [Lessons learned: mejorar después del incidente](https://phpsos.de/es/blog/lessons-learned-nach-vorfall/): Después del incidente viene el próximo. Una reunión posterior estructurada y sin culpables convierte una mala semana en un avance medible.
- [¿Parchear, apagar o esperar? Una ayuda para decidir ante la vulnerabilidad de PHP](https://phpsos.de/es/blog/patchen-abschalten-abwarten/): 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.
- [WAF o actualización: por qué necesita ambas](https://phpsos.de/es/blog/waf-oder-update/): 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.
- [¿Reinstalar o limpiar el servidor? La decisión tras una infección](https://phpsos.de/es/blog/neu-aufsetzen-oder-bereinigen/): 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.
- [¿Resolverlo uno mismo o buscar un proveedor? Una ponderación honesta](https://phpsos.de/es/blog/selbst-beheben-oder-dienstleister/): 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.
- [Elegir un proveedor de seguridad TI: 12 preguntas antes del encargo](https://phpsos.de/es/blog/sicherheitsdienstleister-auswaehlen/): 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.
- [Hosting gestionado o servidor propio: la comparativa de seguridad](https://phpsos.de/es/blog/managed-oder-eigener-server/): 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.
- [¿Actualizar PHP o backport? La decisión para sistemas antiguos](https://phpsos.de/es/blog/php-upgrade-oder-backport/): 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.
- [¿Cambiar de CMS tras el hackeo? Cuándo ayuda y cuándo no](https://phpsos.de/es/blog/cms-wechsel-nach-hack/): 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.
- [Sitios web estáticos: menos PHP, menos superficie de ataque](https://phpsos.de/es/blog/statische-website-alternative/): 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.
- [¿Pentest, bug bounty o escaneo de vulnerabilidades? Elegir el método de auditoría adecuado](https://phpsos.de/es/blog/pentest-bugbounty-scan/): 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.