{"id":842426,"date":"2026-10-22T11:49:18","date_gmt":"2026-10-22T11:49:18","guid":{"rendered":"https:\/\/www.knowband.com\/blog\/?p=842411\/"},"modified":"2026-10-22T11:58:28","modified_gmt":"2026-10-22T11:58:28","slug":"vulnerabilidades-cr%c3%adticas-de-php-octubre-de-2026-lo-que-todo-propietario-de-una-tienda-prestashop-debe-hacer-ahora","status":"publish","type":"post","link":"https:\/\/www.knowband.com\/blog\/es\/comercio-electronico\/vulnerabilidades-cr%c3%adticas-de-php-octubre-de-2026-lo-que-todo-propietario-de-una-tienda-prestashop-debe-hacer-ahora\/","title":{"rendered":"Vulnerabilidades cr\u00edticas de PHP (octubre de 2026): Lo que todo propietario de una tienda PrestaShop debe hacer ahora"},"content":{"rendered":"

Lea esto primero. PHP lanz\u00f3 correcciones el 21 de octubre para dos vulnerabilidades cr\u00edticas. Si su tienda utiliza una versi\u00f3n de PHP sin parchear, un atacante podr\u00eda ejecutar c\u00f3digo en el servidor sin necesidad de iniciar sesi\u00f3n. Ninguna de estas vulnerabilidades afecta a PrestaShop. Hoy necesita saber tres cosas: qu\u00e9 versi\u00f3n de PHP est\u00e1 utilizando, si su proveedor de alojamiento web ha aplicado la correcci\u00f3n (cons\u00edgala por escrito) y si PHP se ha reiniciado desde entonces.<\/p>\n

La mayor\u00eda de las noticias sobre seguridad tratan sobre un plugin o un tema, y \u200b\u200bla soluci\u00f3n se reduce a un bot\u00f3n de “Actualizar”. Este caso es diferente. El problema reside en el motor subyacente de tu tienda, y la soluci\u00f3n est\u00e1 en el servidor, fuera del alcance del panel de administraci\u00f3n. Por eso es f\u00e1cil pasarlo por alto, y por eso necesitas dedicar una tarde a solucionarlo con calma y de forma sistem\u00e1tica.<\/span><\/p>\n

C\u00f3mo se desarrollaron los acontecimientos<\/b><\/h2>\n

El equipo de PHP advirti\u00f3 el 20 de octubre sobre la pr\u00f3xima publicaci\u00f3n de actualizaciones de seguridad. Estas vulnerabilidades fueron descubiertas el 21 de octubre y se les asignaron los n\u00fameros CVE CVE-2026-109618 y CVE-2026-109619. Ambas vulnerabilidades obtienen una puntuaci\u00f3n de 9.2 en la escala CVSS v4.0, son bastante cr\u00edticas y se las conoce como “php2shell”. La Comisi\u00f3n Europea (DG CNECT), ENISA, CERT-EU, Europol EC3 y la Red CSIRT emitieron un aviso conjunto.<\/span><\/p>\n

La Comisi\u00f3n Europea (DG CNECT), ENISA, CERT-EU, Europol EC3 y la Red CSIRT emitieron entonces un comunicado conjunto en el que instaban a las organizaciones a trasladarse. <\/span><\/p>\n

Versiones corregidas: PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35.<\/span><\/p>\n

Lo que realmente est\u00e1 roto<\/b><\/h2>\n

\"\"<\/a><\/p>\n

Ambas vulnerabilidades pueden provocar la ejecuci\u00f3n remota de c\u00f3digo sin autenticaci\u00f3n. En otras palabras: un desconocido en internet podr\u00eda lograr que tu servidor ejecute sus instrucciones.<\/span><\/p>\n

La vulnerabilidad CVE-2026-109618 es un problema de gesti\u00f3n de memoria. Imaginemos que PHP est\u00e1 creando el espacio de trabajo para una solicitud entrante y el servidor se queda sin memoria a mitad del proceso. PHP se detiene, pero la rutina de limpieza posterior asume que el espacio de trabajo parcialmente terminado est\u00e1 completo y act\u00faa sobre \u00e9l.<\/span><\/p>\n

CVE-2026-109619 se asemeja m\u00e1s a una resaca. Algo que pertenec\u00eda a una solicitud permanece all\u00ed despu\u00e9s de que se liber\u00f3 su memoria, y una solicitud posterior en el mismo proceso puede recuperarlo y confiar en \u00e9l.<\/span><\/p>\n

F\u00edjese d\u00f3nde residen ambos: dentro de PHP. PrestaShop no tiene la culpa, y PrestaShop no puede defenderse, ya que el ataque puede producirse antes de que se ejecute una sola l\u00ednea de c\u00f3digo de PrestaShop. Por lo tanto, una actualizaci\u00f3n de m\u00f3dulo o del n\u00facleo no cambia nada en este caso. <\/span>La actualizaci\u00f3n de PHP es la soluci\u00f3n.<\/b><\/p>\n

\u00bfDe qui\u00e9n es el problema?<\/b><\/h2>\n

Todas las formas de ejecutar PHP para la web est\u00e1n incluidas: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP y LiteSpeed. Apache con mod_php es el peor caso, ya que el ataque puede ejecutarse antes que cualquier c\u00f3digo de la aplicaci\u00f3n.<\/span><\/p>\n

Lo que debes hacer depende de tu entorno de alojamiento y de qui\u00e9n gestione tu instalaci\u00f3n de PHP:<\/p>\n\n\n\n\n\n\n\n\n
Entorno de alojamiento<\/th>\n\u00bfQui\u00e9n gestiona PHP?<\/th>\nAcci\u00f3n sugerida<\/th>\n<\/tr>\n<\/thead>\n
Alojamiento web<\/td>\nTu proveedor de alojamiento<\/td>\nP\u00f3ngase en contacto con su proveedor de alojamiento y solicite confirmaci\u00f3n de que se han aplicado las correcciones de seguridad de PHP pertinentes a su entorno.<\/td>\n<\/tr>\n
VPS o Servidor Dedicado<\/td>\nUsted o su administrador del sistema<\/td>\nInstale las actualizaciones de seguridad adecuadas para su versi\u00f3n de PHP o paquete del sistema operativo y, si es necesario, reinicie los servicios de PHP pertinentes.<\/td>\n<\/tr>\n
Docker o alojamiento en contenedores<\/td>\nEl equipo responsable de la imagen del contenedor<\/td>\nReconstruya la imagen utilizando una imagen base de PHP con las correcciones de seguridad aplicables, luego vuelva a implementarla y verifique el entorno de ejecuci\u00f3n.<\/td>\n<\/tr>\n
Versiones de PHP antiguas o no compatibles<\/td>\nSu proveedor de alojamiento o administrador del servidor<\/td>\nComprueba si existe una versi\u00f3n de seguridad para el proveedor. De no ser as\u00ed, planifica la migraci\u00f3n a una versi\u00f3n de PHP compatible tras verificar la compatibilidad con tu tienda, tema y m\u00f3dulos.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Tu lista de tareas para hoy<\/b><\/h2>\n
    \n
  1. Consulta la versi\u00f3n de PHP.<\/b> Oficina administrativa, par\u00e1metros avanzados, informaci\u00f3n.<\/span><\/li>\n
  2. Escribe a tu anfitri\u00f3n.<\/b> Pregunte directamente: “\u00bfSe han aplicado los parches a nuestros servidores para las vulnerabilidades CVE-2026-109618 y CVE-2026-109619, y se han reiniciado todos nuestros procesos PHP?”. Guarde la respuesta. Consejo: Algunas distribuciones aplican el parche de forma silenciosa, sin modificar el n\u00famero de versi\u00f3n; por lo tanto, la antig\u00fcedad de la versi\u00f3n no permite determinar si el servidor es vulnerable o no.<\/span><\/li>\n
  3. Actualiza y luego reinicia.<\/b> Utilice una versi\u00f3n corregida o un paquete con parches del proveedor. Reinicie todos los procesos PHP. El reinicio es un paso que a menudo se olvida. En Docker, vuelva a construir las im\u00e1genes.<\/span><\/li>\n
  4. \u00bfUtiliza PHP 8.1 o una versi\u00f3n anterior?<\/b> El proyecto PHP public\u00f3 algunas actualizaciones para las versiones 7.4, 8.0 y 8.1, y muchas distribuciones de Linux y proveedores de soporte a largo plazo (LTS) incluyen paquetes parcheados. Averigua si la tuya lo hace. En cualquier caso, empieza a planificar la migraci\u00f3n a una versi\u00f3n compatible.<\/span><\/li>\n
  5. Piensa en PrestaShop a continuaci\u00f3n.<\/b> Seleccione una versi\u00f3n que sea compatible con su versi\u00f3n de PHP (consulte la tabla a continuaci\u00f3n). Esta versi\u00f3n se aplica despu\u00e9s del parche, no antes.<\/span><\/li>\n<\/ol>\n

    \u00bfA\u00fan no se puede aplicar el parche? La gu\u00eda de la UE plantea una opci\u00f3n: aislar la aplicaci\u00f3n afectada de la red p\u00fablica hasta que se solucione el problema. Una medida dr\u00e1stica para una tienda, s\u00ed. Aun as\u00ed, conviene tenerla en cuenta.<\/span><\/p>\n

    Soluciones provisionales mientras espera<\/b><\/h2>\n

    La postura de PHP es que ninguna mitigaci\u00f3n es completa y que la actualizaci\u00f3n es la \u00fanica v\u00eda segura. Considere todo lo que se menciona en esta secci\u00f3n como una forma de reducir la exposici\u00f3n durante unos d\u00edas, nada m\u00e1s.<\/span><\/p>\n