Una corrección crítica de seguridad de PHP llega el 21 de octubre. ¿Tu sitio web está listo?

El equipo de seguridad de PHP acaba de darle a internet un aviso con un día de anticipación. El miércoles 21 de octubre de 2026 a las 14:00 UTC (9:00 a.m. en Austin, 8:00 a.m. en la Ciudad de México), PHP publicará una actualización de seguridad que corrige dos vulnerabilidades críticas, ambas calificadas con 9.2 en una escala de gravedad de 10 puntos. Su consejo para todos los que usan PHP es corto: prepárate ahora, para que puedas actualizar en cuanto salga la versión.

PHP es el lenguaje detrás de la mayor parte de la web, incluido todo sitio en WordPress, así que esto alcanza a muchos negocios que nunca se han preguntado sobre qué funciona su sitio. Aquí van respuestas claras a las preguntas que los dueños se van a hacer.

¿Qué pasa exactamente el 21 de octubre?

El 20 de octubre, PHP publicó un aviso anticipado de una próxima actualización de seguridad. Corrige dos vulnerabilidades críticas, cada una con 9.2 en CVSS v4.0, la escala estándar que usa la industria de seguridad para medir qué tan peligrosa es una falla. Todo lo que va de 9.0 a 10 está en la banda más alta, la de “crítico”.

Lo que todavía no sabemos importa igual. Los detalles de ambas fallas, qué versiones están afectadas y qué versiones las corrigen solo se publicarán cuando salga la actualización. Cualquiera que hoy te diga exactamente qué está roto está adivinando, y en este artículo tampoco vamos a adivinar.

¿Por qué avisar antes de que exista la corrección?

Para que los responsables de los servidores con PHP puedan despejar su agenda. Las empresas de hosting, los equipos de TI y los desarrolladores tienen un día para preparar respaldos, ventanas de mantenimiento y personal, y así aplicar el parche en horas y no en semanas.

Hay una segunda razón por la que el reloj importa. En cuanto una corrección es pública, los atacantes pueden estudiar exactamente qué cambió y trabajar hacia atrás hasta el hueco que cierra. El tiempo entre “parche publicado” y “parche descifrado” puede ser corto, por eso la ventana que cuenta empieza el miércoles en la mañana, no cuando alguien tenga tiempo. PHP también dice que podría publicar antes de lo planeado si los detalles de alguna de las fallas se hacen públicos, o si hay evidencia de que ya se están explotando.

¿Mi sitio web siquiera usa PHP?

Es muy posible. Según W3Techs, PHP mueve el 69.3% de todos los sitios web cuyo lenguaje de servidor se conoce. WordPress está construido sobre PHP, y también Drupal, Joomla, WooCommerce y Magento. Si entras a tu sitio por una dirección “wp-admin”, administras tu hosting desde cPanel o alguna vez te dijeron que tu sitio necesita actualizar plugins, tu sitio casi seguro funciona con PHP.

Si tu sitio vive en un constructor totalmente alojado como Wix o Squarespace, tú no corres ni actualizas el software del servidor. Parcharlo es trabajo de la plataforma, y no hay nada que tengas que instalar. Lo mismo aplica para un sitio construido y operado por SWATS (más sobre eso abajo).

¿Y si mi sitio usa una versión vieja de PHP?

Esta es la pregunta incómoda, y es la que más probablemente aplica a un sitio de negocio pequeño con algunos años encima. Hoy PHP da soporte oficial a cuatro versiones: 8.2, 8.3, 8.4 y 8.5, y la 8.2 solo recibe correcciones de seguridad hasta el 31 de diciembre de 2026. Todo lo anterior, incluida cualquier versión de PHP 7 y PHP 5, llegó al fin de su vida útil. Eso significa que ya no recibe correcciones oficiales de seguridad, nunca más.

No es un grupo pequeño. W3Techs reporta que el 27% de los sitios con PHP todavía usan PHP 7, y casi el 8% todavía usan PHP 5. Si alguna de las fallas de esta semana llega tan atrás, esos sitios no tendrán parche oficial el miércoles. Algunas empresas de hosting y distribuciones de Linux llevan correcciones a versiones viejas por su cuenta, así que lo honesto es preguntarle directamente a tu hosting si lo hace. Si la respuesta es no, tu solución no es un parche. Es actualizar a una versión con soporte, y en un sitio de WordPress viejo, con plugins viejos y un tema a la medida, eso es un proyecto, no un botón.

¿Qué hago antes del miércoles?

No necesitas convertirte en ingeniero de seguridad esta noche. Necesitas unas cuantas respuestas, un respaldo y un plan para el miércoles en la mañana.

• Averigua tu versión de PHP. Normalmente aparece en el panel de control de tu hosting. En WordPress, ve a Herramientas, luego Salud del sitio, abre la pestaña Información y despliega la sección Servidor. O simplemente escríbele a tu hosting y pregunta.
• Confirma que sea una versión con soporte. Es decir, 8.2, 8.3, 8.4 u 8.5. Si estás en algo más viejo, empieza hoy la conversación para actualizar, no después del miércoles.
• Averigua quién instala la corrección, y cuándo. Hazle una pregunta directa a tu hosting o a tu desarrollador: “¿Cuándo se va a aplicar en mi sitio la actualización de seguridad de PHP del 21 de octubre?” Pide una hora, no un “pronto”.
• Haz un respaldo nuevo hoy. Una actualización de seguridad es justo el momento en que quieres una copia limpia de tu sitio y su base de datos, por si la actualización rompe algo.
• Revisa tu sitio después de la actualización. Abre la página de inicio, envía tu formulario de contacto, prueba una reserva o un pago. Un sitio parchado que dejó de mandarte clientes sin avisar es otro tipo de caída.

Si estás leyendo esto después de la actualización, los pasos son los mismos. Solo hazlos más rápido.

¿Quién es realmente responsable de instalarla?

Aquí es donde la mayoría de los negocios descubre el verdadero hueco. En un hosting compartido típico, la empresa de hosting normalmente actualiza PHP por ti, pero la velocidad varía, y un sitio fijado en una versión vieja puede quedarse ahí hasta que alguien pida actualizarlo. En un servidor privado, la actualización le toca a quien administra ese servidor: tu persona de TI, tu desarrollador o la agencia que construyó el sitio hace años y que ya siguió con otra cosa. A veces la respuesta honesta es nadie.

Esa es la parte que vale la pena pensar. Tu sitio funciona sobre una pila de software que es de otras personas, y cada capa (el servidor, PHP, el CMS, el tema, cada plugin) necesita a alguien pendiente de las correcciones y aplicándolas a tiempo. Ya escribimos sobre cómo se acumula esa deuda de seguridad y sobre la falla del núcleo de WordPress que ninguna disciplina con los plugins habría evitado. Esta semana la capa es PHP mismo. Si no sabes quién es el responsable, acabas de encontrar el punto más importante de tu lista.

¿Los sitios de SWATS están afectados?

No. Los Smart Websites que construye SWATS no funcionan con PHP. No hay PHP que parchar, ni cPanel, ni servidor que cuidar, ni lista de plugins que auditar, y eso es parte del SWATS Standard que sigue cada sitio que construimos. Cuando sale un aviso como este, nuestros clientes no tienen nada que revisar ni nada que agendar para el miércoles en la mañana.

Ese es justo el punto de SWATS. Construimos o rescatamos tu sitio web, y mantenerlo al día, seguro y rápido es nuestro trabajo, no el tuyo. Cuando algo tiene que cambiar, mandas un correo. Hacemos el cambio, apruebas un enlace de vista previa y se publica. Los días de actualizaciones como este se vuelven algo que lees, no algo que administras.

Si tu sitio funciona con PHP y prefieres no volver a tener una semana como esta, vale la pena que lo platiquemos. Y si quieres ver dónde está tu sitio hoy, corre el SWATS Scorecard gratis y descubre si eres visible, o invisible, para la búsqueda con IA.

Este es el camino. 🤖

— Jenaro Diaz, Founder & CEO, SWATS