cache.lat
El 22 de septiembre de 2026 WordPress publicó la versión 7.1.2, una actualización de seguridad que corrige una vulnerabilidad de severidad crítica. Y dos días después, el 24 de septiembre, el equipo de PHP lanzó versiones de seguridad para todas las ramas soportadas. Si administrás sitios WordPress, esta es una semana para revisar versiones, no para postergar.
Qué corrige WordPress 7.1.2
Según el anuncio oficial, un atacante sin autenticación podría, bajo ciertas condiciones, lograr que la resolución de plantillas de página incluya un archivo PHP local legible fuera de los directorios del tema activo. Eso puede derivar en ejecución remota de código. Está registrado como CVE-2026-87902.
El propio equipo de seguridad aclara que hace falta que se den condiciones previas tanto en el servidor como en el tema activo. No es una excusa para esperar: es una razón más para no tener temas viejos o modificados a mano en producción. El parche se aplicó a todas las ramas elegibles, hacia atrás hasta la 4.7, y los sitios con actualizaciones automáticas en segundo plano lo reciben solos.
Y en PHP: cuatro versiones de seguridad a la vez
El 24 de septiembre salieron PHP 8.2.34, 8.3.35, 8.4.26 y 8.5.11 como versiones de seguridad. Según el resumen publicado por Pantheon, corrigen 11 vulnerabilidades, entre ellas una de severidad alta en la extensión SOAP y problemas en la verificación de certificados de OpenSSL, el wrapper de streams HTTP y PHP-FPM.
En hosting compartido normalmente no elegís cuándo se actualiza PHP, pero sí podés revisar qué versión corre tu sitio y pedírselo al proveedor si quedó atrás.
Checklist práctico para hoy
- Actualizá WordPress a 7.1.2 (o a la última versión de tu rama) desde Escritorio → Actualizaciones. Verificá que de verdad se aplicó.
- Confirmá la versión de PHP en Herramientas → Salud del sitio → Información.
- Hacé un backup antes de actualizar si tenés WooCommerce o personalizaciones en el tema.
- Revisá temas inactivos y borrá los que no uses.
- Probá el sitio después: home, una entrada, el checkout si hay tienda y el formulario de contacto.
Qué pasa con la caché cuando actualizás
Una actualización de core o de PHP no debería romper una caché bien hecha, pero conviene verificar. Después de actualizar, regenerá o purgá lo cacheado y comprobá que las páginas públicas siguen sirviéndose bien y que lo dinámico (carrito, cuenta, formularios) sigue funcionando sin cachear.
cache.lat sirve HTML estático desde el servidor, de modo que las visitas no ejecutan PHP en cada página. Eso reduce carga, pero no reemplaza actualizar: el panel de administración, la API REST y las rutas dinámicas siguen pasando por WordPress. Si querés ver qué se sirve estático y qué no, mirá cómo funciona cache.lat, y los requisitos de PHP y servidor en los datos técnicos.
Cómo organizar las actualizaciones sin sufrir
Activá las automáticas para seguridad
Las actualizaciones menores y de seguridad de core suelen estar activadas por defecto. Verificá que ningún plugin ni constante en wp-config.php las esté desactivando sin que lo recuerdes.
Tené un sitio de pruebas
Si tu sitio vive de las ventas, probá las actualizaciones grandes en staging. Para parches de seguridad críticos, el riesgo de esperar suele ser mayor que el de actualizar con backup reciente.
Mirá los logs después
Tras actualizar PHP, revisá el log de errores unas horas por si algún plugin viejo emite avisos o errores fatales.
Conclusión
Dos paquetes de parches en la misma semana: WordPress 7.1.2 y las versiones de seguridad de PHP. Actualizá, verificá y probá el sitio. Si necesitás una mano con la caché o con la configuración del servidor, podés escribir al soporte de TNL o repasar la documentación.