Skip to main content

Para WordPress, WooCommerce, Laravel, Symfony, Shopware, PrestaShop y otras aplicaciones PHP

PHP actualizado y seguro, sin reescribir su aplicación

PHP solo recibe correcciones de seguridad en las versiones con soporte, pero muchas aplicaciones siguen funcionando con versiones que ya no las reciben. Vulnerabilidades críticas como PHP2Shell (CVE-2026-109618, CVE-2026-109619) ponen de manifiesto ese riesgo. Evalúo dónde se ejecuta PHP en su empresa, migro la aplicación a contenedores que usan una versión de PHP con soporte, le proporciono un entorno de desarrollo reproducible y, si lo desea, me encargo de alojar y gestionar la aplicación. Sus desarrolladores siguen trabajando en el código; yo me ocupo del entorno en el que se ejecuta.

Por qué una versión de PHP desactualizada es un riesgo


Cada versión de PHP recibe correcciones de seguridad durante un periodo limitado. Una vez que llega al fin de su soporte, las vulnerabilidades que se descubren en ella quedan sin corregir, y actualizar es la única solución duradera. El proyecto PHP publica el periodo de soporte de cada versión.

El caso de PHP2Shell, dado a conocer en octubre de 2026, es un ejemplo. Dos vulnerabilidades críticas en el propio motor de PHP (CVE-2026-109618, CVE-2026-109619) permitían la ejecución remota de código sin autenticación, antes de que llegara a ejecutarse ningún código de la aplicación. El proyecto PHP solo publicó versiones corregidas para sus ramas con soporte; los cambios de configuración reducían la exposición, pero no bastaban para que una instalación fuera segura.

A menudo el punto débil no es la propia aplicación: un sitio WordPress o una aplicación Laravel bien mantenidos pueden estar igualmente expuestos porque la versión de PHP sobre la que funcionan está desactualizada. Pasar a una versión con soporte a veces exige cambios en el código de la aplicación. Esos cambios corresponden a sus desarrolladores o a su agencia; yo proporciono el entorno en el que pueden probarlos y desplegarlos con seguridad.

Tres aspectos a tener en cuenta

  • Solo se publican correcciones de seguridad para las versiones de PHP con soporte. La lista de versiones con soporte y sus fechas de fin de soporte está disponible en php.net.
  • La configuración y las reglas de firewall reducen la exposición, pero no sustituyen a una actualización. En el caso de PHP2Shell, el proyecto PHP lo indicó expresamente.
  • Las vulnerabilidades se descubren más rápido que antes: los investigadores descubrieron PHP2Shell con ayuda de modelos de IA, y esa misma capacidad acorta el tiempo que transcurre entre la divulgación de una vulnerabilidad y la aparición de un exploit funcional.

Referencias


Lista de comprobación


Cinco preguntas para cada sitio web o aplicación que funcione con PHP.

  1. ¿Sabe qué versión de PHP utiliza cada uno de sus sitios web y aplicaciones?

    Incluidos los entornos de pruebas, los micrositios antiguos y las herramientas que su proveedor de hosting o su agencia configuró hace años. La versión suele aparecer en el panel de control del hosting; un inventario de servidores o de imágenes de contenedores permite localizar el resto.

  2. ¿Esa versión sigue teniendo soporte?

    El proyecto PHP publica las versiones con soporte y sus fechas de fin de soporte. Una versión que ha llegado al fin de su soporte no recibe correcciones de seguridad, ni siquiera para vulnerabilidades críticas.

  3. ¿Quién actualiza PHP y con qué frecuencia?

    En un hosting compartido lo decide el proveedor; en servidores propios, es fácil que no se encargue nadie. Si una actualización exige trabajo manual en un servidor, suele aplazarse.

  4. ¿Pueden sus desarrolladores probar una nueva versión de PHP antes de pasarla a producción?

    Sin un entorno de desarrollo y pruebas reproducible, la actualización se prueba directamente en producción, y por eso a menudo se evita.

  5. ¿Se daría cuenta si algo fallara?

    La monitorización de los errores, de la disponibilidad y de los procesos inesperados permite detectar un ataque o una actualización fallida antes de que lo noten sus clientes.

Si alguna respuesta es «no» o «no lo sé», el primer paso que se describe a continuación está pensado precisamente para esos casos.

Cómo puedo ayudarle


Tres pasos. Cada uno termina con un resultado por escrito y puede contratarse por separado. Sus desarrolladores o su agencia siguen trabajando en el código de la aplicación.

  1. Evaluación y asesoramiento

    Dónde se ejecuta PHP, cuál es su exposición y qué hacer primero.

    • Inventario de sus sitios web y aplicaciones PHP, con la versión de PHP y el alojamiento de cada uno
    • Valoración de la exposición y del esfuerzo de actualización, en un lenguaje claro
    • Una recomendación por escrito con prioridades: qué corregir ahora y qué planificar
    • Asesoramiento a sus desarrolladores o a su agencia sobre la ruta de actualización
  2. Contenedores y entorno de desarrollo

    Una configuración reproducible en la que la aplicación funciona con una versión de PHP con soporte.

    • La aplicación empaquetada en contenedores, con un runtime de PHP con soporte y fácil de actualizar
    • Un entorno de desarrollo idéntico al de producción, que sus desarrolladores pueden poner en marcha con un solo comando
    • Un pipeline automatizado que prueba y genera las nuevas versiones, incluidas las actualizaciones de seguridad de PHP
    • Bastionado: mínimo privilegio, aislamiento y límites a las peticiones entrantes
  3. Alojamiento y gestión

    Si lo desea, me encargo de alojar y gestionar la aplicación.

    • Gestión de la aplicación en contenedores dentro de un entorno que administro yo
    • Actualizaciones de PHP y de las imágenes base como trabajo rutinario, no como emergencias
    • Una migración planificada desde su alojamiento actual, incluido el paso al nuevo entorno

Alcance y forma de trabajo


  • Responsabilidad directa

    Soy consultor independiente. Realizo el trabajo personalmente, desde la evaluación hasta la entrega.

  • Pensado para pequeñas y medianas empresas

    El trabajo está diseñado para empresas sin un equipo de operaciones propio: pasos claros, resultados por escrito en un lenguaje sencillo y proyectos acotados en el tiempo. También trabajo con organizaciones de mayor tamaño.

  • Ubicación y horario

    Desde Alicante, colaboro en remoto con equipos de toda Europa, en horario de Europa central. Los proyectos pueden realizarse en inglés o en español.

  • Confidencialidad y acceso

    Antes de cualquier acceso a sus sistemas se firma un acuerdo de confidencialidad. El acceso se limita a los permisos mínimos necesarios y a un periodo determinado, y no se realiza ningún cambio en producción sin su autorización.

Fuera del alcance

  • El desarrollo de software: escribir o reescribir el código de la aplicación, en PHP o en cualquier otro lenguaje. Los cambios en el código corresponden a sus desarrolladores o a su agencia; yo aporto el entorno y el asesoramiento.
  • La investigación forense de una posible intrusión. Recomiendo contar con un proveedor de respuesta a incidentes —a menudo uno de los homologados por su aseguradora de ciberriesgos— y puedo trabajar junto a él.

Trabajo como consultor independiente en infraestructura AWS, CI/CD y controles de cumplimiento automatizados (eIDAS, ISO 27001, NIS2, RGPD) para entornos regulados. Ver experiencia


Preguntas frecuentes


¿Basta con una regla de firewall (WAF)?

No. Un firewall de aplicaciones web puede bloquear patrones de ataque conocidos mientras se lleva a cabo la actualización, pero no corrige una vulnerabilidad del propio PHP, y los atacantes adaptan sus peticiones. En el caso de PHP2Shell, el proyecto PHP indicó que solo la actualización corrige por completo el problema.

Tenemos un hosting compartido. ¿Nos afecta?

Sí: la versión de PHP forma parte de su hosting. Compruebe qué versión utiliza su proveedor y si puede elegir una con soporte. Si el proveedor no ofrece ninguna versión con soporte, trasladar la aplicación a contenedores es la opción más sólida a largo plazo.

Nuestra aplicación funciona con una versión de PHP sin soporte. ¿Qué opciones tenemos?

Actualizar a una versión con soporte es la solución duradera. Mientras tanto, un paquete de una distribución o de un proveedor de soporte extendido que incorpore las correcciones adaptadas a esa versión (backports), junto con un aislamiento estricto de la aplicación, reduce el riesgo. Con la aplicación en contenedores, la actualización puede probarse antes de pasarla a producción.

¿Tenemos que reescribir la aplicación en otro lenguaje?

No. Un problema de seguridad en PHP no es motivo para reescribir una aplicación. Lo que sí sirve es mantener el runtime al día: saber dónde se ejecuta, reconstruir las imágenes cuando se publican correcciones y actualizar antes de que termine su soporte.

¿Puede usted alojar nuestra aplicación?

Sí, si lo desea. Una vez que la aplicación funcione en contenedores, puedo alojarla y gestionarla en un entorno que administro yo, de modo que la versión de PHP y sus dependencias se mantengan al día. También puede conservar su propio alojamiento, siempre que este permita ejecutar contenedores.

¿Nos afecta la Directiva NIS2?

Depende de su sector, de su tamaño y de cómo haya transpuesto la directiva su país. Cuando es aplicable, la gestión de las vulnerabilidades conocidas forma parte de las medidas de gestión de riesgos exigidas (artículo 21), y el órgano de dirección responde de ellas (artículo 20). Su asesor jurídico o de cumplimiento normativo puede confirmar si su empresa está dentro del ámbito de aplicación.

Solicitar una consulta


Describa brevemente su situación: de qué sitios web o aplicaciones se trata, qué versión de PHP utilizan (si lo sabe) y dónde están alojados. Por favor, no envíe contraseñas ni datos de acceso a través de este formulario.

Daniel Toth

Ingeniero AWS DevOps y Cloud Architect

Alicante, España

LinkedIn