PHP2Shell: qué pasó con WordPress y por qué Shopify es una opción más segura

El 21 de octubre de 2026, el equipo de PHP publicó una actualización de emergencia para dos fallas críticas en el corazón del lenguaje. Las bautizaron PHP2Shell. Permiten que un atacante ejecute código en el servidor de un sitio sin necesidad de iniciar sesión. Y PHP es el lenguaje sobre el que funciona WordPress, el CMS que mueve cerca del 40% de todos los sitios web del mundo.

Hubo ataques antes de que el parche existiera. Gobiernos y universidades europeas bajaron sus sitios como precaución. Y la mayoría de los dueños de sitios WordPress se enteró por la prensa, sin saber si su sitio estaba expuesto ni a quién preguntarle.

En este artículo te explicamos qué pasó, por qué WordPress queda tan expuesto cuando falla PHP, qué tiene que ver esto con la nueva Ley de Protección de Datos Personales de Chile y por qué Shopify es una alternativa más segura para muchas empresas. Al final te contamos cómo trabajamos en Lattemedia para que nuestros clientes, corporativos y B2C, no queden en esa zona gris.

Contenido

• Qué pasó: PHP2Shell en simple
• Por qué WordPress queda tan expuesto
• El hueco que deja un WordPress sin una agencia detrás
• La Ley 21.719: la seguridad pasa a ser una obligación legal
• Qué hace distinto a Shopify en seguridad
• WordPress vs. Shopify: comparación de seguridad
• ¿Conviene cambiarse a Shopify?
• Cómo lo trabajamos en Lattemedia
• Fuentes

Qué pasó: PHP2Shell en simple

PHP2Shell son dos vulnerabilidades, registradas como CVE-2026-109618 y CVE-2026-109619, con una puntuación de 9,2 sobre 10 en la escala de gravedad CVSS. Las descubrió el equipo de Wiz Research en agosto, usando modelos de inteligencia artificial para encontrar y encadenar los errores, y las reportó al equipo de PHP el 24 de agosto. El parche salió el 21 de octubre (Wiz Research).

Lo grave no es solo el puntaje. Son tres cosas juntas:

• Están en el motor, no en la aplicación. La falla vive en PHP mismo. Un sitio puede tener su código perfecto y aun así estar expuesto. Wiz demostró ejecución remota de código sin autenticación contra las versiones más recientes de WordPress, Drupal y Joomla.
• Afectan casi todas las versiones. Según Wiz, todas las versiones de PHP desde la 5.4 tienen al menos una de las dos fallas. Solo hay parche oficial para PHP 8.2 en adelante (8.5.12, 8.4.27, 8.3.36 y 8.2.35). Las versiones 8.1 y anteriores ya no tienen soporte oficial.
• Los ataques llegaron antes que el parche. Los detalles se filtraron el 20 de octubre. Patchstack reportó que sus partners de hosting detectaron explotación activa en la mañana del 21, horas antes de la publicación del parche, y que circulaba una herramienta de ataque.

La reacción fue inmediata. Según Search Engine Journal y Patchstack, sitios del Parlamento y del Centro Nacional de Ciberseguridad de Países Bajos, servicios del gobierno de Finlandia y sitios de universidades se bajaron de forma preventiva. CERT-EU y el NCSC del Reino Unido recomendaron aislar o apagar temporalmente los servidores que no pudieran protegerse de inmediato.

El mensaje oficial de PHP fue claro: actualizar es la única opción segura y ninguna medida alternativa cubre completamente la falla. Wiz lo resume así: «aplicar la actualización de seguridad de PHP sigue siendo la única remediación completa».

Por qué WordPress queda tan expuesto

PHP2Shell no es un error de WordPress. Pero WordPress depende 100% de PHP, y ahí está el problema. Según W3Techs, PHP es el lenguaje de servidor del 70,8% de los sitios web cuyo lenguaje se conoce, y WordPress funciona sobre PHP en el 100% de los casos.

Esto deja tres puntos débiles que vale la pena entender:

1. El parche no se instala desde WordPress

Actualizar WordPress o sus plugins no actualiza PHP. WordPress.org confirmó que no habrá una actualización de WordPress para esta falla, porque la corrección le corresponde al servidor. Si tu hosting no aplicó el parche, tu sitio sigue expuesto aunque el panel de WordPress diga que todo está al día. Puedes revisar tu versión en Herramientas > Salud del sitio > Información > Servidor.

2. Muchos sitios corren versiones viejas de PHP

Es común encontrar sitios WordPress en PHP 7.4 o 8.0, porque algún plugin o tema antiguo no funciona en versiones nuevas. Esas versiones no recibieron un parche oficial. Patchstack lo dice sin rodeos: si usas PHP 8.1 o anterior, necesitas un parche de tu proveedor o migrar a una versión con soporte.

3. Los plugins ya eran el flanco más débil

PHP2Shell llegó sobre un ecosistema que ya venía con problemas. El informe State of WordPress Security in 2026 de Patchstack registró 11.334 vulnerabilidades nuevas en el ecosistema WordPress durante 2025, un 42% más que el año anterior. El 91% estaba en plugins. Y el 46% no tenía parche disponible al momento de hacerse pública.

Solo en las semanas previas a PHP2Shell, se explotó activamente una falla en el núcleo de WordPress (CVE-2026-87902, corregida en la versión 7.1.2) y otra con puntaje 10 sobre 10 en el plugin Bricksforge, que permitía subir y ejecutar código PHP sin autenticación (The Hacker News).

El hueco que deja un WordPress sin una agencia detrás

WordPress puede ser seguro. Pero solo si alguien se hace cargo de cada capa: el servidor, la versión de PHP, el núcleo, los plugins, el tema, los usuarios administradores, los respaldos y el monitoreo. Cuando nadie tiene esa responsabilidad clara, siempre queda un espacio vulnerable.

PHP2Shell lo dejó en evidencia. Para proteger un WordPress esta semana había que:

• Saber que la falla existía y que no se arreglaba desde el panel de WordPress.
• Confirmar con el hosting que el parche estaba instalado, en producción y también en los sitios de prueba (staging), que suelen quedar olvidados.
• Si el sitio usaba PHP 8.1 o anterior, buscar un parche del proveedor o migrar de versión, revisando antes que los plugins no se rompieran.
• Poner un firewall de aplicaciones (WAF) como medida temporal, entendiendo que no reemplaza el parche.
• Revisar si el sitio ya había sido comprometido: archivos PHP desconocidos, usuarios administradores nuevos, web shells. Un parche no elimina una intrusión que ya ocurrió.
• Cambiar las credenciales guardadas en el servidor si había señales de ataque.

Patchstack además advirtió contra instalar plugins o fragmentos de código que prometían «arreglar» PHP2Shell: no están verificados y pueden romper el sitio o abrir otra puerta.

Una agencia que conoce WordPress a fondo puede hacer todo esto en horas. Un sitio que se hizo hace tres años, en un hosting compartido barato y sin mantenimiento, probablemente sigue expuesto hoy. Y su dueño no lo sabe.

La Ley 21.719: la seguridad pasa a ser una obligación legal

En Chile esto deja de ser solo un problema técnico. La Ley 21.719 de Protección de Datos Personales, publicada el 13 de diciembre de 2024, entra en vigencia el 1 de diciembre de 2026. Crea la Agencia de Protección de Datos Personales y cambia las reglas para cualquier empresa que maneje datos de clientes: nombres, correos, teléfonos, direcciones, RUT o historial de compras.

Los puntos que más importan para un sitio web o una tienda online:

• Deber de seguridad. La empresa responsable de los datos debe adoptar medidas técnicas y organizativas adecuadas para protegerlos. Un servidor con una versión de PHP vulnerable y sin parchar es difícil de defender como «medida adecuada».
• Reporte de brechas. Si hay un incidente que filtre, altere o destruya datos personales, hay que informarlo a la Agencia sin demora injustificada y, en ciertos casos, a los propios afectados.
• Multas. Las fuentes coinciden en tres tramos: hasta 5.000 UTM para infracciones leves, hasta 10.000 UTM para graves y hasta 20.000 UTM para gravísimas. En caso de reincidencia, las multas pueden calcularse como un porcentaje de los ingresos anuales de la empresa.

Una nota importante: el Gobierno ingresó al Senado el boletín 18.623-07, que busca postergar la entrada en vigencia al 1 de diciembre de 2027. A la fecha de este artículo sigue en primer trámite y no está aprobado. Aun si se aprueba, el proyecto no cambia las obligaciones ni las multas, solo la fecha. Como plantea una carta en Diario Constitucional, postergar la ley no es postergar la preparación.

Dicho de otra forma: un formulario de contacto, un newsletter o un carrito de compras en un WordPress mal mantenido es hoy un riesgo técnico, y desde diciembre puede ser también un riesgo legal.

Qué hace distinto a Shopify en seguridad

Shopify no está hecho en PHP. Su plataforma central es una aplicación en Ruby on Rails, con más de 2,8 millones de líneas de código, según el propio equipo de ingeniería de Shopify. Pero la diferencia de fondo no es el lenguaje, es el modelo: Shopify es una plataforma alojada (SaaS). Tú no administras servidores ni versiones de PHP. La infraestructura la mantiene Shopify, de forma centralizada, para todas las tiendas a la vez.

Por eso, frente a PHP2Shell, las tiendas Shopify no tuvieron que hacer nada en su tienda. Shopify no publicó un comunicado específico sobre esta falla, pero el consenso entre especialistas es que la tienda alojada no queda expuesta, porque el comerciante no gestiona ninguna versión de PHP. Sí recomiendan revisar las piezas en PHP que la marca tenga fuera de Shopify, como un blog antiguo en WordPress o una landing alojada aparte.

Los puntos de seguridad que Shopify trae de serie:

• Certificación PCI DSS Nivel 1. Es el nivel más alto del estándar de seguridad de la industria de tarjetas de pago. Shopify declara: «Shopify cuenta con la certificación PCI DSS de Nivel 1».
• Informes SOC 2 Tipo II y SOC 3. Auditorías independientes sobre cómo Shopify protege la información de su servicio.
• Programa de recompensas por errores (bug bounty). Shopify paga a investigadores de seguridad por reportar fallas, con recompensas de hasta 200.000 dólares. Según su página oficial, ha pagado más de 9,5 millones de dólares y resuelto más de 2.400 reportes.
• Checkout gestionado por Shopify. Los datos de pago no pasan por un plugin que tú tengas que mantener.
• SSL incluido y actualizaciones automáticas. No hay versiones de plataforma que actualizar ni plugins de núcleo que parchar.
• Informe de transparencia. Shopify publica datos sobre las solicitudes legales que recibe sobre comerciantes y clientes.

Ojo, Shopify no es invulnerable. Las apps de terceros, los accesos de colaboradores y las contraseñas débiles siguen siendo riesgos, y bajo la Ley 21.719 la empresa sigue siendo responsable de los datos de sus clientes. La diferencia es que la capa más crítica, el servidor y la plataforma, deja de depender de ti o de tu hosting.

WordPress vs. Shopify: comparación de seguridad

¿Conviene cambiarse a Shopify?

Depende del sitio, pero para muchas empresas la respuesta es sí. Estas preguntas te ayudan a decidir:

• ¿Tu sitio vende online o captura datos de clientes? Si tienes un e-commerce en WooCommerce o formularios con datos personales, el costo de un incidente (y desde diciembre, de una multa) suele ser mayor que el de migrar.
• ¿Sabes qué versión de PHP usa tu sitio y quién la actualiza? Si la respuesta es «no sé», ese es el espacio vulnerable del que hablamos.
• ¿Tienes una agencia o un equipo que mantenga WordPress todas las semanas? Si no, cada nueva falla depende de que alguien se entere a tiempo.
• ¿Tu sitio usa muchos plugins o un tema que ya no se actualiza? Cada uno suma riesgo y puede impedir subir de versión de PHP.
• ¿Tu sitio es corporativo y no vende online? Shopify no es solo para tiendas. Un sitio institucional puede montarse sobre Shopify sin carrito de compras, con sus páginas, blog y formularios de contacto, y aprovechar la misma infraestructura protegida que usan las tiendas.
• ¿Necesitas desarrollos muy a medida que solo WordPress permite? En ese caso, WordPress puede seguir siendo la opción correcta, siempre que tenga mantenimiento profesional.

Nuestra visión es simple: Shopify reduce de forma importante la superficie de ataque y la carga de mantenimiento, tanto en un e-commerce como en un sitio corporativo. Para una tienda B2C, porque protege el checkout y los datos de compra. Para una empresa B2B, porque su sitio institucional deja de depender de un servidor, una versión de PHP y una lista de plugins que alguien tiene que vigilar. Lo que no es una opción es un WordPress abandonado.

Cómo lo trabajamos en Lattemedia

En Lattemedia trabajamos con tiendas B2C y con sitios corporativos para empresas B2B, y en ambos casos partimos de la misma idea: la seguridad no es un plugin, es un proceso. Por eso usamos Shopify como base en los dos mundos, aunque uno venda online y el otro no.

En tiendas B2C sobre Shopify

• Migramos tiendas desde WooCommerce y otras plataformas cuidando el SEO, las redirecciones y los datos de clientes.
• Configuramos permisos de colaboradores con acceso mínimo y autenticación en dos pasos para todo el equipo.
• Revisamos cada app antes de instalarla: qué datos pide, quién la desarrolla y si realmente se necesita.
• Dejamos las políticas de privacidad y los formularios alineados con la Ley 21.719. 

En sitios corporativos B2B sobre Shopify

Muchas empresas B2B no necesitan vender por internet. Necesitan un sitio que presente sus servicios, capture contactos y no se caiga ni se vulnere. Para ellas desarrollamos sitios corporativos sobre la estructura de Shopify, sin carrito de compras:

• Usamos Shopify como plataforma del sitio institucional: páginas de servicios, blog, formularios de contacto y secciones a medida, sin activar la venta online.
• El sitio hereda la misma infraestructura que protege a las tiendas: servidores administrados por Shopify, SSL incluido, auditorías SOC 2 y actualizaciones automáticas. No hay un servidor propio, una versión de PHP ni plugins que parchar.
• Los datos que llegan por los formularios quedan en la plataforma de Shopify y no en una base de datos expuesta en un hosting compartido, algo clave frente a la Ley 21.719.
• Cuando una falla como PHP2Shell aparece, nuestros clientes corporativos no tienen que apagar su sitio ni esperar a que su hosting reaccione.
• Migramos sitios corporativos desde WordPress cuidando el SEO, las URLs y las redirecciones, para no perder el posicionamiento ganado. 

Si no sabes qué versión de PHP usa tu sitio, si tu WordPress lleva tiempo sin mantenimiento o si quieres evaluar una migración a Shopify antes de que entre en vigencia la Ley 21.719, conversemos. Revisamos tu caso y te decimos con honestidad qué te conviene.

Fuentes

• Wiz Research. PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet. wiz.io
• Patchstack. Major security alert: PHP vulnerable to critical RCE, attacks ongoing. patchstack.com
• Patchstack. State of WordPress Security in 2026. patchstack.com
• Search Engine Journal. Critical PHP Core Vulnerabilities Affect Websites, Including WordPress. searchenginejournal.com
• Codeable. PHP Security Release on 21 October 2026: What WordPress Site Owners Need to Do. codeable.io
• The Hacker News. Attackers Exploit WordPress CVE-2026-87902 Within Hours of Disclosure. thehackernews.com
• The Hacker News. Attackers Exploit CVSS 10.0 Bricksforge WordPress Flaw Enabling Unauthenticated RCE. thehackernews.com
• W3Techs. Usage statistics of PHP / content management systems. w3techs.com
• Mind The Shop. Is Shopify Affected by PHP2Shell? mindtheshop.co.uk
• Shopify. Security (PCI DSS, SOC 2 y SOC 3). shopify.com/security
• Shopify. Bug Bounty. shopify.com/bugbounty
• Shopify Engineering. Deconstructing the Monolith. shopify.engineering
• Biblioteca del Congreso Nacional. Ley 21.719, que regula la protección y el tratamiento de los datos personales. bcn.cl
• ProtecciónDatosWeb.cl. Postergación de la Ley 21.719 al 2027: qué dice exactamente el proyecto del Ejecutivo. protecciondatosweb.cl
• Diario Constitucional. Datos personales: postergar la ley no es postergar la preparación. diarioconstitucional.cl
• Prey. Multas y sanciones de la Ley 21.719. preyproject.com