Parche crítico de PHP: qué le pasa a tu empresa si no lo aplica
Por Sebastián Zapateiro6 min de lectura
El 21 de octubre de 2026, PHP publicó las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35 para corregir dos vulnerabilidades críticas: CVE-2026-109618 y CVE-2026-109619, ambas con puntaje CVSS 9,2 sobre 10. Si el servidor de tu empresa ejecuta una versión anterior, el parche ya existe y, según el propio equipo de PHP, actualizar es la única solución completa.
Esta guía no busca asustarte; busca que decidas con información. Te explicamos qué puede pasar en tu empresa si el parche no se aplica, qué cuesta de verdad esperar y cómo hacerlo sin tumbar tu sitio.
Qué corrige el parche, en palabras simples
Son dos fallas en la forma en que PHP maneja la memoria entre una petición y otra. En ciertas configuraciones, un atacante puede enviar peticiones preparadas a tu sitio y terminar ejecutando código en el servidor sin usuario ni contraseña. Los detalles técnicos están en nuestro aviso sobre la vulnerabilidad crítica de PHP y la historia de cómo se descubrió, en PHP2Shell: la IA que encontró la falla.
Importa también para empresas pequeñas. Los ataques automáticos no distinguen tamaños: recorren internet buscando servidores con versiones sin actualizar y prueban la misma técnica en miles de ellos. Una pyme con una tienda en línea o un portal de clientes es un objetivo tan válido como una gran empresa, y suele tener menos defensas alrededor.
Qué le pasa a tu empresa si no aplica el parche
Nadie puede asegurarte que un sitio sin parche será atacado mañana. Lo que sí se sabe es que los detalles de las fallas ya son públicos y que Cloudflare y watchTowr reportaron intentos de explotación desde el 21 de octubre. Con ese contexto, estos son los escenarios que conviene tener presentes.
1. Datos de clientes y de la operación expuestos
Si un atacante ejecuta código en tu servidor, puede leer lo que ese servidor puede leer: bases de clientes, pedidos, correos, archivos y credenciales guardadas en la configuración. Para una empresa, no se trata solo de un problema técnico: son datos de personas que confiaron en ti.
2. Caídas o sitio modificado
Un sitio comprometido puede quedar fuera de línea, mostrar páginas que tú no publicaste o redirigir a tus visitantes a sitios falsos. Mientras tanto, tu tienda no vende, tu formulario no recibe contactos y tu equipo se ocupa de apagar incendios en lugar de trabajar.
3. Pérdida de tráfico y de confianza
Los navegadores y buscadores pueden advertir a los usuarios cuando un sitio distribuye contenido peligroso. Recuperar la reputación toma más tiempo que aplicar el parche, y los clientes que ven una advertencia rara vez vuelven a intentarlo.
4. Un servidor que trabaja para otros
Los servidores comprometidos se usan para enviar spam o minar criptomonedas. El resultado es una factura de nube más alta, correos tuyos que caen en spam y, a veces, inclusión en listas negras que son difíciles de limpiar.
5. Obligaciones legales
En Colombia, la Ley 1581 de 2012 exige a quien trata datos personales adoptar medidas de seguridad para protegerlos. No aplicar un parche crítico disponible puede ser difícil de justificar ante un incidente. Cómo se aplica a tu empresa conviene confirmarlo con tu asesor legal.
| Qué está en juego | Si no se aplica el parche | Si se aplica a tiempo |
|---|---|---|
| Datos de clientes | Pueden quedar al alcance de un atacante | Se cierra la puerta conocida |
| Disponibilidad | Riesgo de caídas o de sitio modificado | Cambio planificado, con respaldo |
| Reputación y tráfico | Advertencias y pérdida de confianza | Sin impacto visible |
| Costos | Limpieza, soporte urgente y servidor usado por terceros | Horas de trabajo planificado |
Un escenario para ponerle rostro al riesgo
Imagina una empresa con una tienda en línea sobre WooCommerce, alojada en un servidor que nadie ha actualizado en años. El equipo se entera del aviso, lo deja «para el próximo mantenimiento» y sigue vendiendo. Es un ejemplo hipotético, no un caso real, pero describe bien la decisión: cada semana de espera es una semana en la que la puerta conocida sigue abierta, mientras que el costo de cerrarla hoy es un cambio planificado.
La comparación es sencilla. Actualizar a tiempo implica un respaldo, una prueba y una ventana corta de trabajo. Esperar implica apostar a que nadie encuentre tu servidor antes de que lo hagas tú, y si pierdes esa apuesta, el costo ya no lo decides tú.
Quién debe actuar primero
| Configuración | Nivel de riesgo | Detalle |
|---|---|---|
| Apache con mod_php | Muy alto | Ejecución remota de código confirmada en ambas fallas |
| PHP-FPM (Nginx o Apache) | Alto | Expuesto en ciertas configuraciones |
| FrankenPHP y LiteSpeed | Probable | Susceptibles según el análisis del código |
| PHP 8.1 o anterior | Crítico | Sin parches oficiales: hay que migrar de versión |
WordPress, Drupal, WooCommerce, Laravel y Moodle corren sobre PHP. La falla está en PHP, no en el CMS, así que actualizar plugins o temas no basta: hay que actualizar el motor.
Versiones de PHP corregidas
| Rama de PHP | Protegida desde | Nota |
|---|---|---|
| PHP 8.5 | 8.5.12 | Con soporte |
| PHP 8.4 | 8.4.27 | Con soporte |
| PHP 8.3 | 8.3.36 | Con soporte |
| PHP 8.2 | 8.2.35 | Fin de soporte el 31 de diciembre de 2026 |
| PHP 8.1 o anterior | Sin parche | Sin actualizaciones oficiales |
Por qué tanta gente demora en aplicarlo
- No saben qué versión de PHP usan: el hosting la eligió hace años y nadie la revisó.
- Temen que la actualización rompa el sitio, la tienda o un plugin clave.
- Creen que el proveedor de hosting lo hace solo; muchos dejan que cada cliente elija su versión.
- Su distribución (Ubuntu, Debian, Red Hat) corrige la falla sin cambiar el número de versión, y la verificación confunde.
Actualizar PHP en un sitio en producción exige método. Los problemas aparecen cuando se hace a la carrera: plugins o módulos que dejan de funcionar, servicios que no se reinician bien o un error sin plan de reversa que deja el sitio caído mientras alguien busca cómo arreglarlo.
Cómo aplicar el parche sin tumbar tu sitio
- Confirmar la versión actual
- Respaldo del sitio y la base de datos
- Actualizar en una copia de pruebas
- Probar inicio de sesión, formularios y pagos
- Paso a producción
- Monitorear errores
Comprueba tu versión ahora
Escribe tu dominio o la versión de PHP que te indicó tu proveedor y te decimos si está expuesta. Si no logras saberlo, déjanos tus datos y lo revisamos gratis.
Solo revisamos datos públicos de tu sitio. Guardamos tu correo para darte seguimiento.
También puedes usar el verificador de vulnerabilidad de PHP en su propia página y compartirlo con tu equipo o tu proveedor de hosting.
Qué hacer hoy: cinco pasos
- Averigua qué versión de PHP usa cada sitio o aplicación de tu empresa.
- Compárala con la tabla de versiones corregidas.
- Si está desactualizada, pide a tu proveedor o a tu equipo técnico una fecha concreta para el parche.
- Exige respaldo y plan de reversa antes de tocar producción.
- Después de actualizar, revisa que todo funcione y deja un monitoreo básico activo.
Cuándo conviene pedir ayuda
Si no tienes un equipo técnico propio, si tu sitio es crítico para vender o si estás en PHP 8.1 o anterior, conviene apoyarte en ingenieros. En Nextech hacemos el diagnóstico sin costo y, si lo necesitas, aplicamos el parche. Conoce cómo trabajamos en Seguridad Informática o revisa las 7 señales de que los datos de tu empresa pueden estar expuestos.
Esperar tiene costo. Actualizar a tiempo, con respaldo y pruebas, casi siempre cuesta menos que apagar un incendio.
Aplicamos el parche por ti
Déjanos tus datos y te contactamos hoy. Revisamos tu versión de PHP sin costo y, si hace falta, la actualizamos con respaldo, pruebas y plan de reversa.
Sin compromiso · Te respondemos en menos de 24 horas hábiles.
Preguntas frecuentes
¿Qué pasa si no aplico el parche de PHP?
Tu servidor sigue expuesto a dos fallas críticas (CVE-2026-109618 y CVE-2026-109619) que, según el aviso de PHP, pueden permitir la ejecución remota de código sin credenciales. Eso puede traducirse en datos expuestos, sitio caído o modificado y servidor usado por terceros. Que ocurra depende de tu versión y configuración, pero el riesgo es real y los detalles ya son públicos.
¿Qué versión de PHP debo tener para estar protegido?
PHP 8.5.12, 8.4.27, 8.3.36 o 8.2.35 (o superior dentro de su rama). PHP 8.2 recibe soporte hasta el 31 de diciembre de 2026 y PHP 8.1 o anteriores ya no tienen parches oficiales, así que hay que migrar a una rama con soporte.
¿Cuánto tarda aplicar el parche?
Depende del servidor y del sitio. La actualización en sí puede tomar poco tiempo; lo que lleva más es el respaldo, la revisión de compatibilidad de plugins o código y las pruebas. Por eso conviene empezar hoy y no en la próxima ventana de mantenimiento.
¿Puede romperse mi sitio al actualizar PHP?
Puede pasar si se hace sin preparación: plugins, temas o código que no son compatibles con la nueva versión. Se evita probando primero en una copia, con respaldo y con un plan de reversa.
¿Estoy obligado a proteger los datos de mis clientes?
En Colombia, la Ley 1581 de 2012 exige a quien trata datos personales adoptar medidas de seguridad para protegerlos. Cómo se aplica a tu caso concreto conviene confirmarlo con tu asesor legal.
