Read Time:2 Minute
Si administras un sitio en WordPress, hoy conviene hacer algo bastante menos entretenido que publicar contenido: revisar qué versión estás usando.
WordPress lanzó la versión 7.1.2 para corregir una vulnerabilidad crítica identificada como CVE-2026-87902. El problema puede permitir que un atacante no autenticado fuerce la carga de archivos PHP locales fuera de las carpetas normales del tema y, bajo ciertas condiciones del servidor, llegar a ejecutar código remoto.
La situación es especialmente relevante porque empresas de seguridad ya reportan intentos de explotación contra sitios reales pocas horas después de que el fallo se hiciera público.
¿Qué versiones de WordPress están afectadas?
La vulnerabilidad afecta a versiones anteriores a WordPress 7.1.2. El proyecto también está distribuyendo correcciones retroactivas para ramas antiguas que todavía reciben parches de seguridad.
WordPress recomienda actualizar inmediatamente a la versión más reciente disponible para cada rama.
En una instalación normal, la revisión puede hacerse desde Escritorio → Actualizaciones. Si las actualizaciones automáticas de seguridad están habilitadas, el parche puede haberse instalado sin intervención manual, pero igual conviene verificarlo.
¿Qué hace CVE-2026-87902?
El fallo está en la resolución de plantillas de página.
En determinadas configuraciones, un atacante remoto puede manipular qué archivo PHP local intenta cargar WordPress y escapar de los directorios esperados del tema activo.
Eso no significa que cualquier sitio vulnerable pueda ser tomado automáticamente. Para llegar a ejecución remota de código tienen que cumplirse condiciones específicas del tema y del entorno del servidor.
Pero cuando esas condiciones existen, el impacto potencial es alto: el atacante podría conseguir que el servidor ejecute PHP con los permisos de la cuenta utilizada por el servicio web.
Ya hay intentos de explotación en internet
SecurityWeek, The Hacker News y firmas como Patchstack y Previdian reportan actividad de explotación poco después de la publicación del parche.
Los primeros intentos comenzaron como reconocimiento para verificar si un sitio podía ser vulnerable. Después aparecieron solicitudes que intentaban utilizar archivos PHP presentes en algunos servidores para escribir contenido malicioso y conseguir ejecución de código.
Eso cambia la prioridad del problema: ya no estamos hablando solo de una vulnerabilidad teórica con una prueba de concepto pública.
¿Qué debería hacer un administrador de WordPress?
Lo primero es actualizar WordPress Core a la versión corregida disponible para la rama instalada.
Después conviene revisar registros del servidor, archivos modificados recientemente y cualquier comportamiento extraño, especialmente si el sitio permaneció expuesto desde el 22 de septiembre.
También es buena práctica mantener temas y plugins actualizados, eliminar componentes que ya no se utilizan y contar con una copia de seguridad reciente.
Si el sitio está alojado en un proveedor administrado, vale la pena confirmar si el parche ya fue desplegado automáticamente.
¿Hay que entrar en pánico?
No.
La vulnerabilidad es seria, pero la explotación depende de ciertas condiciones y WordPress ya publicó el parche.
El problema real aparece cuando una corrección crítica queda disponible y el sitio sigue funcionando varios días o semanas sin actualizarse.
En seguridad web, muchas veces la diferencia entre un incidente y un susto no está en descubrir antes que todos una vulnerabilidad, sino en instalar el parche antes de que los escaneos automatizados encuentren tu servidor.
Te puede interesar
Nueva técnica permite forjar firmas RSA sin factorizar la clave: qué tan preocupado deberías estar
Investigadores demostraron que ciertas implementaciones de RSA pueden atacarse con muchos menos recursos de lo que se estimaba. El hallazgo es importante para la criptografía, pero no significa que las conexiones y firmas RSA más comunes estén hoy rotas.
El 46% de las pymes chilenas aún no tiene un plan de ciberseguridad pese a su rápida digitalización
Un estudio regional de Mastercard muestra una brecha llamativa en Chile: 85% de las pymes encuestadas ya acepta pagos digitales, pero casi la mitad todavía no cuenta con un plan de ciberseguridad y solo 50% confía en su capacidad para proteger el negocio.
De una sala eléctrica a un incendio forestal: el emprendimiento chileno que entrena emergencias en realidad virtual
Digital Dreams Studio desarrolla simuladores en realidad virtual y entornos 3D para practicar procedimientos de riesgo eléctrico, incendios forestales y operación de ROV sin exponer personas ni equipos reales. La apuesta es llevar al entrenamiento industrial una lógica conocida en aviación: equivocarse primero en el simulador.
Los agentes de IA necesitan identidad y permisos propios: el nuevo problema que NTT DATA y Palo Alto quieren resolver
NTT DATA y Palo Alto Networks ampliaron su alianza para proteger entornos donde agentes de IA pueden acceder a datos y ejecutar acciones. La seguridad empieza a tratar a estos sistemas como nuevas identidades digitales con privilegios, registros y límites propios.
¿Bodegas que operan a oscuras? La automatización con robots empieza a redibujar los centros de distribución en Chile
STG y Mushiny proyectan centros logísticos más densos y automatizados, con robots móviles y sistemas Goods-to-Person. La idea de bodegas “oscuras” no significa eliminar personas, sino automatizar zonas donde la iluminación deja de ser necesaria.
Gemini hackeó tres empresas reales por error: el problema no fue que la IA “escapara”
Una prueba de ciberseguridad dejó a Gemini con acceso a Internet y el agente terminó entrando a sistemas de tres compañías reales. No descubrió una vulnerabilidad desconocida: el caso muestra qué puede pasar cuando una IA recibe autonomía sin suficientes barreras.
Average Rating