AGTI | 21 de octubre de 2026 • Información verificada a las 01:30 UTC (20 de octubre, 22:30 de Brasilia)
Llega un aviso de seguridad, menciona PHP y pide una actualización. Para quien administra una tienda, la duda es práctica: ¿depende del software de la tienda, del alojamiento o de ambos? En este caso, el aviso debe llegar a quien mantiene el servidor, aunque el catálogo, el carrito y la gestión de pedidos parezcan funcionar con normalidad.
El 20 de octubre de 2026, el proyecto PHP anunció dos vulnerabilidades críticas, ambas con una puntuación de 9,2 en CVSS v4.0. Las correcciones están previstas para el 21 de octubre de 2026 a las 14:00 UTC, aunque podrían publicarse antes. Al consultar el aviso a las 01:30 UTC del 21 de octubre, equivalentes a las 22:30 de Brasilia del 20 de octubre, todavía no se habían divulgado las versiones afectadas y corregidas. Ya es posible, sin embargo, preparar la revisión y definir quién realizará la actualización.
1 Comprende qué función cumple PHP en la tienda
PHP es una de las tecnologías que se ejecutan en el servidor para que funcione la aplicación. En una tienda PrestaShop o en un sistema desarrollado con Symfony, forma parte de la infraestructura que atiende las solicitudes de la aplicación. Esta capa es distinta del tema de la tienda, de un módulo instalado o del código de una integración.
Por eso, mantener los módulos actualizados no demuestra que el PHP del servidor también lo esté. La responsabilidad varía: en un alojamiento administrado, el proveedor puede mantener esta parte del entorno; en un servidor gestionado por la propia empresa, el trabajo puede depender del equipo técnico o de un proveedor de servicios.
El primer paso para quien gestiona la tienda es identificar a ese responsable. Si el aviso se envía solo a quien administra el contenido o la apariencia de la tienda, la actualización del servidor puede quedarse sin una persona encargada.
2 Revisa qué entornos utiliza la tienda
La revisión debe identificar la versión de PHP, el origen del paquete instalado y los entornos en los que se ejecuta. La versión que muestra un panel de control sirve como punto de partida, pero no sustituye la comprobación de quien administra el servidor.
Una operación puede utilizar varios servidores, aplicaciones auxiliares y tareas programadas con configuraciones diferentes. También puede haber diferencias entre el PHP que utiliza el sitio web y el que ejecuta comandos o procesos en segundo plano. Actualizar uno de ellos no demuestra que los demás también se hayan corregido.
Pide una respuesta que identifique el entorno revisado y quién mantiene sus paquetes. Así podrás dar seguimiento a la actualización que corresponde a tu tienda, en lugar de recibir únicamente una confirmación genérica de que el servidor está al día.
3 Sigue la corrección específica de este aviso
Antes de que se publiquen los detalles, no hay una lista oficial de versiones corregidas que pueda reproducirse en este artículo. Una versión publicada antes de este aviso no debe presentarse como solución para las dos vulnerabilidades sin confirmación en el boletín correspondiente.
Cuando el paquete esté disponible, el equipo técnico deberá consultar el comunicado de PHP y, según el origen de la instalación, el aviso de la distribución del sistema operativo o del proveedor de alojamiento. Contrastar esa información permite determinar qué actualización corresponde al entorno real.
La publicación prevista para el 21 de octubre de 2026 a las 14:00 UTC sirve para organizar la respuesta, no para posponer los preparativos. Como podría adelantarse, el seguimiento debe comenzar antes de esa hora.
4 Prepara el cambio antes de intervenir en producción
Define quién seguirá el boletín, quién aplicará el paquete y quién probará la tienda después. Comprueba que exista una copia de seguridad reciente y un procedimiento de recuperación, y revisa las dependencias que puedan verse afectadas. Una copia de seguridad ayuda a recuperar la operación, pero no impide que se explote una vulnerabilidad.
Si hay un entorno de pruebas, valida allí la actualización antes de llevarla a producción, manteniendo la prioridad que exige el aviso. La planificación debe considerar tanto la urgencia como el riesgo de incompatibilidad, sin dejar una actualización crítica pendiente de forma indefinida.
Evita cambiar la versión principal de PHP solo para alcanzar el número más alto disponible. La compatibilidad depende de la versión de la tienda, los módulos, las extensiones y las integraciones. Una actualización de seguridad compatible y una migración de versión son decisiones relacionadas, pero pueden requerir trabajos distintos.
5 Comprueba el soporte de las versiones antiguas
En octubre de 2026, las versiones anteriores a PHP 8.2 ya no tienen soporte del propio proyecto PHP. Es un dato que requiere atención, pero no basta por sí solo para evaluar un servidor: algunas distribuciones del sistema operativo mantienen correcciones de seguridad en los paquetes que ofrecen sin adoptar el número de versión más reciente del proyecto original.
Esta práctica, conocida como backport, consiste en aplicar una corrección a una versión mantenida por el proveedor. Debe comprobarse mediante el aviso de seguridad y la revisión del paquete instalado. No se debe suponer que cualquier paquete antiguo recibe este mantenimiento.
Pregunta al proveedor de alojamiento qué soporte cubre el entorno y si habrá un paquete corregido para estas vulnerabilidades. Si no lo habrá, el equipo debe evaluar las alternativas de actualización o migración y las precauciones temporales necesarias. Que una distribución ofrezca soporte no confirma, por sí solo, que este aviso ya se haya resuelto.
6 Confirma la actualización y prueba el proceso de compra
Instalar el paquete es una etapa. Después, hay que confirmar que los servicios en ejecución utilizan la versión corregida y que también se han atendido los demás entornos identificados. Si la actualización requiere reiniciar procesos, el equipo debe comprobar que esos reinicios se hayan completado.
En la tienda, repite los pasos que sostienen la venta: abrir productos, seleccionar variantes, iniciar sesión, añadir artículos al carrito, calcular el envío y completar el proceso de compra con el modo de prueba adecuado. Revisa también el panel de administración, las rutinas de pedidos y las integraciones relevantes, sin generar cobros reales solo para hacer pruebas.
Registra el paquete aplicado, el entorno, la hora y las pruebas realizadas. Así, una respuesta como «actualizamos el servidor» contará con evidencias útiles si aparece un problema después del cambio.
7 Distingue las medidas adicionales de la corrección
Las reglas del firewall, los ajustes de configuración y las herramientas de seguridad pueden formar parte de la evaluación técnica. Sin conocer el alcance completo de las vulnerabilidades y validar esas medidas, no corresponde presentarlas como una garantía de protección ni como sustitutos de la actualización.
El funcionamiento aparente de la tienda tampoco permite sacar conclusiones. Seguir recibiendo pedidos no demuestra que no exista exposición. A la vez, el anuncio de una vulnerabilidad no demuestra que una tienda concreta haya sufrido una intrusión. La respuesta debe basarse en el entorno verificado y en el boletín oficial, sin restar importancia al aviso ni afirmar que ocurrió un incidente sin pruebas.
Si hay dificultades para actualizar dentro del plazo necesario, pide al equipo una evaluación de las medidas temporales y del riesgo que permanecería. Esa decisión debe considerar la infraestructura, en lugar de limitarse a instalar otro módulo en la aplicación.
8 Asigna un responsable al siguiente paso
Para empezar, envía el aviso oficial al proveedor de alojamiento o al equipo que administra el servidor. Confirma quién revisará el entorno, cómo seguirá la publicación de la corrección y quién validará la tienda después. Esas respuestas aportan más que un cambio apresurado o la suposición de que alguien ya se está ocupando del asunto.
Si tu negocio necesita apoyo para entender su entorno y planificar la actualización, AGTI puede ayudar a evaluar la situación. Habla con AGTI sobre la infraestructura de tu tienda.
Referencias técnicas
- Comunicado oficial de PHP del 20 de octubre de 2026
- Versiones con soporte del proyecto PHP
- Política de actualizaciones de seguridad de Ubuntu
- Servicios de AGTI
El artículo refleja el aviso disponible a las 01:30 UTC del 21 de octubre de 2026, equivalentes a las 22:30 de Brasilia del 20 de octubre de 2026. No confirma la exposición de una instalación concreta. Los números de las versiones afectadas y corregidas deben consultarse en el boletín publicado con la actualización.