Tu web puede verse sólida por fuera y funcionar como una escalera de naipes por dentro. Una campaña, un formulario y una tienda dependen de piezas que el cliente nunca ve. Cuando una de esas piezas tiene una vulnerabilidad crítica, el problema llega al negocio: hay que decidir quién corrige, cómo verificarlo y qué comunicar.

La noticia sobre PHP que compartió BBC Mundo abre esa conversación. Para dueños de negocios y equipos de marketing en Latinoamérica, la pregunta útil es concreta: ¿quién puede demostrar que el servidor de nuestra web recibió la corrección? Esta guía reúne fuentes oficiales consultadas el 27 de octubre de 2026 y propone una forma de coordinar la respuesta.

Qué pasó con PHP y por qué importa a tu web

PHP es una de las tecnologías sobre las que funciona WordPress. El aviso oficial de WordPress aclara que estas fallas pertenecen a PHP: actualizar únicamente WordPress no las corrige. Puedes consultar la versión desde Herramientas > Salud del sitio > Información > Servidor; la actualización del entorno se coordina con el hosting.

Las vulnerabilidades CVE-2026-109618 y CVE-2026-109619 pueden permitir ejecutar código en el servidor sin autenticación. CERT-EU identifica como versiones corregidas PHP 8.2.35, 8.3.36, 8.4.27 y 8.5.12. Si el proveedor distribuye paquetes con correcciones incorporadas, pide la referencia del paquete y del aviso que acredita el arreglo.

Para dirigir un negocio, conviene distinguir tres cosas: estar expuesto, haber sido atacado y haber confirmado un incidente. Una noticia o un número de versión no resuelven por sí solos las tres preguntas. Pide al equipo técnico una evaluación de tu instalación y evita comunicar un robo de datos sin evidencia.

La IA cambia la velocidad; la responsabilidad sigue siendo humana

Wiz Research explica que utilizó IA para investigar las fallas y construir demostraciones de explotación. También señala que adaptar los ataques exige considerar versiones, configuraciones y memoria del servidor. La aportación de la IA fue reducir ese trabajo especializado; no significa que todos los sitios sufran el mismo ataque ni que todos hayan sido comprometidos.

La lectura para una empresa es organizativa: recomendamos acortar la distancia entre una alerta y una decisión. Si el desarrollador espera al hosting, el hosting espera al cliente y marketing desconoce el cambio, nadie puede explicar cuándo terminó la exposición. Nombra a una persona que coordine el caso, reúna evidencias y confirme el cierre con quienes operan el servidor.

También conviene separar herramientas y responsabilidad. Un asistente puede ayudar a ordenar avisos y redactar preguntas. La decisión de intervenir un sistema debe apoyarse en la revisión técnica de su configuración y su operación. El entregable que necesitas es una respuesta comprobable sobre tu web, con un responsable que la firme.

Qué pedir hoy al hosting o al equipo técnico

La guía de actualización de WordPress recomienda respaldar el sitio y revisar la compatibilidad de temas y plugins antes de cambiar PHP. Propón una intervención urgente con verificación, para que la coordinación acompañe al parche y no lo retrase.

1. Inventario y alcance. Pide qué sitios, subdominios, tiendas e integraciones ejecutan PHP, quién los administra y cuáles se revisaron. Incluye páginas antiguas que todavía reciben tráfico o formularios.
2. Corrección acreditada. Solicita versión o paquete instalado, vulnerabilidades cubiertas, fecha de aplicación y confirmación de que el entorno que atiende las peticiones ya utiliza el cambio.
3. Continuidad y recuperación. Acuerda un respaldo recuperable y una respuesta si aparecen errores. Pide que cualquier reversión contemple la seguridad, para evitar volver a dejar expuesta la instalación.
4. Prueba del recorrido comercial. Verifica una solicitud de contacto o una compra de prueba, la llegada al equipo comercial y las integraciones necesarias. Documenta el resultado esperado y el observado.
5. Revisión de exposición previa. Pregunta si corresponde investigar registros y señales de compromiso. Instalar una corrección resuelve la vulnerabilidad cubierta; no demuestra por sí mismo qué ocurrió antes.

Puedes enviar este mensaje: Necesitamos confirmar si nuestros sitios usan PHP y si tienen aplicadas las correcciones de PHP2Shell. Compartan alcance, paquete o versión corregida, fecha de aplicación, pruebas de funcionamiento y cualquier medida pendiente. Indiquen quién coordina la revisión y cuándo recibiremos la confirmación.

Qué hacer con campañas, formularios y atención al cliente

Imagina una tienda que anuncia una promoción mientras su proveedor interviene el servidor. Recomendamos que marketing tenga una persona de contacto y un criterio acordado para pausar o reactivar tráfico. Si el destino falla o debe aislarse, revisa las campañas que lo utilizan y prepara un canal alternativo de atención. La decisión debe responder al estado real del servicio.

Si la corrección inmediata no es posible, CERT-EU recomienda considerar el aislamiento de las aplicaciones expuestas a internet hasta aplicar y verificar el arreglo. Coordina esa decisión con el equipo técnico. Las mitigaciones parciales de las fallas iniciales no equivalen a una actualización completa.

Antes de reactivar una campaña, proponemos recorrer su destino como cliente: abrir la página, completar el formulario, confirmar que se recibió la solicitud y revisar la medición necesaria. Comprueba también enlaces de correos y perfiles sociales. Un registro sencillo de estas pruebas ayuda a decidir con evidencia y a detectar tareas que quedaron pendientes.

Si hay una interrupción, comunica lo que puedas confirmar: qué servicio está disponible, cómo contactar al negocio y cuándo habrá otra actualización. Asigna también quién responderá consultas. Mantener a ventas y atención al cliente informados forma parte de la respuesta, aunque no administren el servidor.

Del parche urgente a un mantenimiento que se pueda demostrar

La revisión debe contemplar novedades posteriores al primer aviso. El proyecto PHP añadió el 23 de octubre una recomendación sobre desactivar el progreso de carga de sesiones para un vector adicional poco habitual. El 26 publicó paquetes de Windows reconstruidos con una corrección de Brotli. Pide al proveedor revisar ambos avisos según tu entorno; no son la misma falla.

Para las siguientes alertas, recomendamos dejar por escrito quién vigila avisos, quién puede aprobar una intervención, cómo se prueba la recuperación y dónde se guarda la evidencia. Incluye estos compromisos en la conversación con tus proveedores y revisa qué tareas cubre realmente el mantenimiento contratado.

La curita de nuestra imagen representa la tentación de resolver una urgencia y seguir adelante. Un parche de seguridad debe aplicarse; sostener el negocio requiere además una operación capaz de revisar lo que cambia y comprobar que funciona. La tarea que proponemos hoy es cerrar esta alerta con evidencia y convertir lo aprendido en un proceso que el equipo pueda repetir.