Actualización de seguridad de WordPress 7.1.2: qué hacer hoy

Tal vez fue un correo de su proveedor de hosting, un aviso rojo en su panel, o un titular que dice que una falla crítica de WordPress deja entrar a los atacantes sin necesidad de iniciar sesión. Ahora usted está revisando su propio sitio, quizás fuera de horario, y se pregunta dos cosas a la vez: ¿ya es demasiado tarde?, y ¿romperá algo si hace clic en Actualizar, algo que le trae clientes? La actualización de seguridad de WordPress 7.1.2, publicada el 22 de septiembre de 2026, cierra esa brecha, y para un sitio configurado de forma normal es una tarea de un solo clic que puede que ya haya ocurrido sola. La falla es real y los atacantes empezaron a sondearla en horas después de la corrección, pero solo llega al peor resultado en sitios con condiciones específicas de servidor y tema. Actualizar cierra la puerta de aquí en adelante. No le puede decir si alguien ya entró antes, y eso requiere una revisión corta y específica. Puede hacer todo usted mismo esta noche, en orden, y saber en qué situación está su sitio antes de cerrar la laptop.

Cierre la brecha hoy con la actualización correcta de WordPress 7.1.2

Actualice WordPress hoy a 7.1.2, o a la versión de seguridad corregida listada para la rama que corre su sitio. WordPress corrigió CVE-2026-87902, una falla de path traversal sin autenticación que puede llevar a ejecución de código cuando existen ciertas condiciones de servidor y tema. El anuncio de lanzamiento de WordPress 7.1.2, fechado el 22 de septiembre, es directo al respecto: «Because this is a security release, it is recommended that you update your sites immediately» (Debido a que es un lanzamiento de seguridad, se recomienda que actualice sus sitios de inmediato). El estado abajo se revisó por última vez el 23 de septiembre de 2026.

En términos prácticos, «path traversal» significa que una solicitud puede engañar a WordPress para que llegue fuera de la carpeta que debería leer. Aquí, el punto débil es el código que decide qué plantilla de página cargar. Según WordPress y el registro de CVE-2026-87902, un atacante sin sesión iniciada puede hacer que WordPress incluya un archivo PHP legible que está fuera de las carpetas del tema activo. «Sin autenticación» es la parte que genera titulares: nadie necesita un nombre de usuario ni una contraseña para intentarlo.

Ayuda saber qué corrigió cada lanzamiento, porque dos lanzamientos de seguridad salieron con una semana de diferencia y los titulares los mezclan.

Si su sitio está en 7.1.1, no está cubierto. El lanzamiento de mantenimiento y seguridad 7.1.1 fue una lista de correcciones separada, con fallas como la vulnerabilidad Click2Shell de WordPress, y salió antes de que se corrigiera esta falla. La documentación de la versión 7.1.2 lista el lanzamiento corregido para cada rama compatible, así que si está en una línea más antigua como la 6.x, busque su rama ahí en lugar de adivinar el número. Las versiones 4.6 y anteriores ya no reciben correcciones de seguridad de ningún tipo.

Sepa si su sitio de verdad está expuesto

El peor resultado en los titulares, un desconocido corriendo código en su servidor, no es automático. Tanto WordPress como la descripción de la CVE dicen que la ejecución remota de código depende de condiciones relevantes de servidor y del tema activo. Un sitio que no cumple esas condiciones sigue corriendo una versión con falla y sigue necesitando el parche, pero no está en la misma situación que uno que sí las cumple. No es fácil saber desde el panel en cuál grupo está usted, que es la mejor razón para aplicar el parche ahora en lugar de intentar averiguarlo.

También puede ver dos números de severidad distintos. El registro de la CVE, publicado el 22 de septiembre por la organización que asigna el identificador, lo puntúa en 8.1, Alta. Patchstack, una firma de seguridad de WordPress, lo califica en 9.2, Crítica, en su propio aviso. Ambos son reales, pero solo el 8.1 es la puntuación oficial en la CVE. Cualquiera de los dos números apunta a la misma acción: actualizar hoy.

La explotación es donde la historia se movió más rápido, así que las fechas importan aquí.

Lea esa línea de tiempo por lo que muestra. Los atacantes están escaneando activamente e intentando plantar archivos, según Patchstack. Eso es evidencia de intentos en todo internet. No es un conteo de sitios vulnerados, y no significa que su sitio fue comprometido. El catálogo de vulnerabilidades explotadas conocidas del gobierno de Estados Unidos no tenía entrada para esta CVE el 23 de septiembre, y eso podría cambiar, así que revíselo otra vez si está leyendo esto más adelante. Lo que la línea de tiempo sí deja claro es el ritmo: esperar unos días por más titulares no es una opción más segura que actualizar ahora.

Averigüe si la actualización automática ya lo protegió

Hay una buena probabilidad de que su sitio se haya parchado solo. WordPress introdujo las actualizaciones automáticas en segundo plano en la versión 3.7, y las instalaciones existentes reciben actualizaciones menores del núcleo, como la 7.1.2, por defecto. Las instalaciones nuevas desde la 5.6 en adelante reciben actualizaciones tanto menores como mayores del núcleo por defecto, a menos que WordPress detecte una instalación con control de versiones. El anuncio del lanzamiento dice que los sitios que admiten actualizaciones en segundo plano empezarán a actualizarse solos.

«Empezarán» no es lo mismo que «ya lo hicieron», sin embargo. La guía de WordPress para configurar actualizaciones automáticas en segundo plano documenta las formas en que se desactiva o se bloquea:

• Un actualizador desactivado: Una línea en la configuración del sitio que fija `AUTOMATIC_UPDATER_DISABLED`, o `WP_AUTO_UPDATE_CORE` en `false`, detiene las actualizaciones del núcleo.
• Un filtro de actualización: Un plugin o código personalizado puede filtrar las actualizaciones sin que se muestre nada en el frente del sitio.
• Límites de permisos de archivo o FTP: Si WordPress no puede escribir sus propios archivos sin credenciales, no puede actualizarse solo en segundo plano.
• Despliegues con control de versiones: Los sitios desplegados desde un repositorio de código se dejan intactos a propósito, así que un desarrollador tiene que enviar la actualización.
• Gestión a nivel de proveedor de hosting: Algunos proveedores de hosting desactivan el actualizador propio de WordPress y manejan las actualizaciones con su propio calendario.

Un correo del proveedor de hosting que dice «nosotros manejamos las actualizaciones» es una buena señal, pero no es prueba de que este sitio en particular esté en la 7.1.2. La única prueba es el número de versión en su propio panel, que la siguiente sección recorre paso a paso. Y si su sitio corre la 4.6 o anterior, no viene ningún parche automático. Ese sitio necesita una actualización planeada a una rama compatible, no una espera.

Actualice con seguridad en cuatro pasos sin romper el sitio

El miedo a que una actualización rompa el sitio es razonable, y la forma de manejarlo es el orden, no la demora. La propia guía de WordPress para actualizar WordPress recomienda hacer un respaldo primero y dice que un respaldo se puede restaurar si surge un problema después de la actualización. Los cuatro pasos siguientes llevan a un sitio normal de expuesto a confirmado en mucho menos de una hora. Si el sitio tiene cambios de código personalizados al núcleo de WordPress o un plugin o tema desactualizado, el paso del respaldo importa todavía más.

Haga un respaldo que de verdad pueda restaurar

Antes de tocar nada, confirme que tiene un respaldo completo de los archivos y de la base de datos, y sepa tres cosas de él: cuándo se hizo, dónde está guardado y cómo lo restauraría. Un respaldo hecho por su proveedor de hosting cuenta si usted sabe cómo activar una restauración. Si no tiene ningún respaldo, hágalo ahora. No puede retroceder a un momento antes de que la falla fuera pública, pero le da una forma de volver atrás si la actualización sale mal.

Corra la actualización desde Escritorio > Actualizaciones

Inicie sesión en su dirección real `/wp-admin`, escrita por usted mismo en lugar de desde un enlace en un correo, y abra Escritorio > Actualizaciones. La documentación de la pantalla de actualizaciones muestra dónde lista WordPress las actualizaciones del núcleo disponibles, y el anuncio del lanzamiento les dice a los propietarios que hagan clic en Actualizar ahora. En un sitio normal toma uno o dos minutos.

Confirme que el número de versión cambió

Cuando termine, vuelva a Escritorio > Actualizaciones y lea la versión que reporta WordPress. Debe decir 7.1.2, o el lanzamiento corregido para su rama listado en WordPress.org. Si la actualización falló, la pantalla suele mostrar un mensaje de error; anótelo, porque le dice a quien lo ayude por dónde empezar.

Pruebe lo que le genera dinero

Abra el sitio público en una ventana privada del navegador y revise las páginas y acciones que le importan a su negocio: la página de inicio, una página de servicio, el formulario de contacto, una reserva o un pago, y el inicio de sesión. Envíese usted mismo un formulario de prueba. Si algo se rompió, tiene un punto de restauración, y tiene una descripción precisa de qué falló.

Confirme que nadie entró antes del parche

Actualizar cierra la ruta vulnerable, pero no elimina un archivo o una cuenta que un atacante ya haya creado. Estas revisiones toman unos minutos cada una y son la diferencia entre saber que su sitio está limpio y solo esperar que lo esté. Si ya manejó una alerta de plugin antes, el patrón le resultará familiar por nuestra publicación sobre qué hacer ante una alerta de vulnerabilidad de plugin de WordPress, con la diferencia de que esta vez la falla estaba en el propio WordPress.

Empiece dentro del panel, donde no se necesita ninguna habilidad técnica:

• Usuarios: Abra Usuarios > Todos los usuarios, filtre a Administradores, y compare cada nombre, correo, rol y fecha de creación con las personas que deberían tener acceso. Busque editores con permisos extra sin explicación y contraseñas de aplicación cambiadas recientemente.
• Plugins y temas: Busque cualquier cosa instalada o cambiada que nadie de su lado pueda explicar, incluidos los plugins de uso obligatorio, que no aparecen en la lista normal de plugins.
• Tareas programadas: Las tareas programadas desconocidas pueden ser una forma de mantener el acceso después de cerrada la brecha.

Después, si usted o su proveedor de hosting pueden acceder a los registros de acceso, busque desde el 22 de septiembre en adelante los patrones que describe Patchstack: `pagename` con caracteres de traversal codificados, `page_id` junto con `pagename`, y las cadenas `pearcmd`, `+config-show` o `+config-create`. Patchstack también dice que archivos PHP inesperados en `/tmp` o `/var/tmp`, incluidos archivos llamados `wp-pear-rce-flag.php` o `poc87902.php`, o nombres que empiezan con `luci_` o `zeta_`, son señales de que un intento de plantar archivos tuvo éxito.

Por último, revise los archivos agregados o cambiados recientemente. La guía de fortalecimiento de WordPress recomienda monitorear archivos cambiados y agregados, y la guía de Wordfence para limpiar un sitio de WordPress hackeado señala que los archivos nuevos en `wp-admin` y `wp-includes` son muy inusuales. El administrador de archivos de su proveedor de hosting suele poder ordenar los archivos por fecha.

Un resultado limpio en todo esto es tranquilizador. No es una garantía sobre el pasado, porque los registros pueden estar incompletos y algunos rastros son difíciles de detectar, así que conserve sus respaldos y registros en lugar de borrarlos.

Sepa exactamente cuándo detenerse y pedir ayuda

Si alguna revisión encuentra algo real, como un administrador que nadie reconoce, uno de los archivos con nombre, o líneas de registro que coinciden con los patrones de arriba, deje de tratar esto como una actualización de rutina. Preserve los registros y haga un respaldo del sitio tal como está ahora, antes de limpiar nada, para que haya evidencia con la cual trabajar. Después cambie contraseñas, restrinja el acceso donde pueda, y consiga ayuda de respuesta a incidentes. Las preguntas frecuentes de WordPress para sitios hackeados cubren los pasos de recuperación, y nuestra publicación sobre las primeras 24 horas después de que hackean un sitio web recorre el orden.

Lo que no debe hacer es igual de útil saberlo. No desactive las actualizaciones, no apague funciones de seguridad, no edite archivos del núcleo, ni instale plugins «de arreglo» desconocidos. Un plugin de firewall puede sumar una capa, pero no sustituye el lanzamiento parchado de WordPress. Y no pase la primera hora cambiando permalinks o apagando plugins legítimos por pánico.

El tamaño de la tarea depende de lo que encuentre:

Por el otro lado de esa línea: si su sitio está en 7.1.2 o el lanzamiento corregido de su rama, tiene un respaldo reciente que puede restaurar, el sitio funciona, la lista de administradores es familiar, y ninguno de los indicadores con nombre aparece, puede que no necesite ayuda pagada en absoluto. Una actualización cuidadosa y una prueba corta pueden ser toda la tarea. Un correo de advertencia por sí solo no es una razón para comprar una limpieza.

Corra la revisión de diez minutos antes de cerrar la laptop

Si quiere todo en una sola pasada, este es el orden.

Si cada línea sale limpia, hizo lo que WordPress les pidió a los propietarios de sitios el 22 de septiembre. Si alguna línea no sale limpia, ahora sabe exactamente cuál, y eso es lo que la persona que lo ayude necesitará primero.

Preguntas frecuentes sobre la actualización de seguridad de WordPress 7.1.2

¿Qué corrige la actualización de seguridad de WordPress 7.1.2?

Corrige CVE-2026-87902, una falla de path traversal sin autenticación en cómo WordPress resuelve las plantillas de página. Puede permitir que un atacante incluya un archivo PHP legible fuera del tema activo, y puede llevar a ejecución remota de código solo cuando se cumplen ciertas condiciones de servidor y tema.

¿Necesito instalar WordPress 7.1.2 hoy?

Sí. El anuncio de WordPress del 22 de septiembre recomienda actualizar de inmediato. Si su sitio está en una rama compatible más antigua, instale el lanzamiento corregido para esa rama listado en WordPress.org.

¿Se está explotando CVE-2026-87902?

Patchstack reportó sondeos a partir del 22 de septiembre e intentos de escribir archivos en disco el 23 de septiembre. Eso muestra intentos activos, no que un sitio en particular fue vulnerado. El catálogo de vulnerabilidades explotadas de CISA no lo listaba al 23 de septiembre.

¿WordPress se actualizará a la 7.1.2 automáticamente?

Por lo general sí, en sitios con las actualizaciones en segundo plano activadas. La configuración, los filtros de actualización, los permisos de archivo, los despliegues con control de versiones o la gestión del proveedor de hosting pueden impedirlo, así que revise usted mismo la versión en Escritorio > Actualizaciones.

¿Qué pasa si mi sitio corre una versión más antigua de WordPress?

La corrección se adaptó a cada rama hasta la 4.7, así que instale el lanzamiento corregido de su rama. Los sitios en 4.6 o anteriores no reciben corrección de seguridad y necesitan una actualización planeada.

¿Cómo reviso si mi sitio fue hackeado a través de esta falla?

Revise las cuentas de administrador, los cambios recientes de plugin, tema y archivos, y los registros de acceso desde el 22 de septiembre en adelante en busca de los patrones que nombra Patchstack, y busque los archivos PHP con nombre en carpetas temporales. Si encuentra alguno, preserve la evidencia y consiga ayuda de respuesta a incidentes.

Qué significa esto para usted

WordPress 7.1.2 cierra una falla real que los atacantes empezaron a sondear en horas después de la corrección, y para un sitio configurado de forma normal el remedio es una sola actualización que puede que ya haya corrido. El peor resultado depende de condiciones de servidor y tema, la puntuación oficial es 8.1 Alta, y los reportes de Patchstack muestran intentos, no una lista de víctimas. Confirme usted mismo la versión, mantenga un respaldo que pueda restaurar, y corra la revisión corta de usuarios, cambios, registros y archivos.

Una vez hecho eso, ya no depende de un titular o de un correo del proveedor de hosting para saber si su sitio está a salvo. Tiene el número de versión, un punto de restauración y una lista de administradores limpia, y el próximo lanzamiento de seguridad se vuelve una rutina de cinco minutos en lugar de un apuro de madrugada.

Si algún paso de la revisión no salió limpio, o prefiere que alguien más lo confirme, Web Leveling puede ayudar. Nuestra auditoría de seguridad web revisa la versión, los respaldos, la lista de usuarios, los registros y los archivos, y le dice claramente si hay algo que limpiar o nada de qué preocuparse. Trabajamos con pequeñas y medianas empresas en todo el país y en el extranjero. Envíenos lo que muestran su panel y su proveedor de hosting, y le diremos qué vemos y qué, si algo, hay que hacer después.

Términos