Dos alertas críticas de WordPress en quince días, y un sitio chileno ya sirviendo phishing
La ANCI publicó dos alertas críticas de WordPress entre el 20 de julio y el 3 de agosto. En medio de ambas, otra alerta mostró un sitio `.cl` legítimo alojando una campaña de fraude. Es el riesgo abstracto y su consecuencia concreta, con dos semanas de diferencia.
- CVE-2026-63030, en el endpoint de procesamiento por lotes de la API REST de WordPress: explotable de forma remota y sin autenticación. Encadenada con CVE-2026-60137 permite manipular consultas a la base de datos y llegar a ejecución remota de código.
- Quince días después, una segunda alerta crítica: inyección SQL por falta de saneamiento del parámetro
author_not_inenWP_Query, cuando un plugin o tema pasa entradas sin validar. - Versiones parchadas: 6.8.6, 6.9.5 o 7.0.2 en adelante. Si tu sitio corre algo anterior y está expuesto a internet, asume que ya fue escaneado.
Qué pasó
La ANCI publicó dos alertas críticas de WordPress en quince días, ambas dirigidas explícitamente a prestadores de servicios esenciales y operadores de importancia vital.
AVC26-00724, 20 de julio. CVE-2026-63030 afecta al endpoint de procesamiento por lotes de la API REST. La falla se explota de forma remota y sin autenticación. Combinada con CVE-2026-60137, permite manipular consultas a la base de datos y llegar a ejecutar código en el servidor. Es la cadena completa: de una petición HTTP anónima a control del servidor.
AVC26-00726, 3 de agosto. Las versiones afectadas no sanitizan el parámetro author_not_in de WP_Query, lo que habilita inyección SQL cuando un plugin o un tema pasa ahí una entrada no confiable. El matiz importa: el agujero está en el núcleo, pero quien lo abre suele ser un plugin de terceros.
La corrección en ambos casos es la misma: actualizar el núcleo a 6.8.6, 6.9.5 o 7.0.2 o posterior, y verificar que las actualizaciones automáticas hayan quedado aplicadas de verdad, cosa que en instalaciones con temas o plugins que las bloquean no siempre ocurre.
Por qué importa acá
WordPress no es solo el motor de los blogs. En Chile sostiene tiendas, medios, portales institucionales, sitios de reservas y las páginas corporativas de buena parte de las empresas medianas. Es infraestructura crítica silenciosa: nadie la inventaria como tal, y casi nadie la parcha con la urgencia con que parcha un firewall.
Los escáneres automatizados no distinguen geografía ni tamaño. Solo ven la huella de una versión vulnerable. Por eso el sitio de una pyme de Ñuñoa es tan atractivo como el de una multinacional: cuesta lo mismo comprometerlo, y sirve igual como plataforma para el ataque siguiente.
Si tu sitio maneja datos personales de clientes —nombres, correos, RUT, información de pago— un compromiso activa además las obligaciones de la Ley 21.719. Y si tu organización es OIV o prestador de servicios esenciales, la Ley 21.663 convierte esto en un asunto de reporte, no solo en un ticket de TI. Confirma el procedimiento vigente en el portal de la ANCI.
Entre las dos alertas de vulnerabilidad ocurrió algo que las conecta y que las convierte en algo más que una recomendación de parcheo.
El 30 de julio, en plena ventana entre ambas, la ANCI publicó ACF26-01130: una campaña de fraude que suplantaba a CorreosChile. El alojamiento del sitio falso era bioredox.cl/wp-content/in/app/index.php.
Esa ruta lo dice todo. wp-content es el directorio de WordPress, y /in/app/ no es una estructura que genere ninguna instalación normal. Es un sitio chileno legítimo, corriendo WordPress, que estaba sirviendo el phishing de otro desde su propio servidor.
Esto es dato verificable en los indicadores publicados. Lo que evaluamos con confianza alta es la lectura: ese sitio fue comprometido, no cedido. Nadie hospeda voluntariamente una página que suplanta a CorreosChile en un subdirectorio oculto de su propio WordPress.
Y ahí está el punto que ninguna alerta de vulnerabilidad transmite bien por sí sola: el costo de no parchar no es que te roben a ti. Es que tu dominio, tu certificado y tu reputación pasen a trabajar para el atacante, contra tus propios compatriotas, mientras tú sigues sin enterarte.
bioredox.cl/wp-content/in/app/index.php — WordPress chileno sirviendo phishing de CorreosChile desde su propio dominio20 jul → 30 jul → 3 ago — Advertencia, consecuencia y segunda advertencia en quince díasMientras el parque de sitios .cl con WordPress desactualizado siga siendo grande, va a seguir siendo la infraestructura gratuita del phishing dirigido a Chile. Para el atacante es el mejor negocio posible: no paga dominio, no paga alojamiento, y hereda un .cl legítimo con certificado válido, que es justo lo que vuelve creíble el engaño.
La consecuencia práctica para tu detección: no basta con vigilar si te atacan. Hay que vigilar si estás siendo usado. Un PHP nuevo en wp-content/uploads no genera ninguna alerta en un antivirus de escritorio y puede llevar meses ahí.
Anatomía del ataque
Mapeo a marcos públicos, para que puedas cruzarlo con tu propia matriz de cobertura.
T1190— CVE-2026-63030 se explota sin credenciales contra el endpoint de lotes de la API REST.T1505.003— Es como se mantiene el acceso después del parche. Si no se busca, sobrevive a la actualización.T1136.001— Alta de un administrador de WordPress que nadie del equipo reconoce.T1584.004— El objetivo final en ACF26-01130: usar el sitio ajeno como alojamiento del fraude.T1608.005— El portal falso montado dentro del WordPress comprometido.
Estructurado sobre las seis funciones del NIST CSF 2.0, según el ciclo de respuesta a incidentes de NIST SP 800-61r3 (abril 2025, reemplaza al r2). Proteger y Detectar vienen abiertas.
GV GobernarQuien decide, que se reporta y a quien
Alguien tiene que ser dueño del sitio web. En muchas organizaciones chilenas el sitio lo hizo una agencia hace tres años, nadie sabe quién tiene las credenciales y no hay presupuesto asignado a mantenerlo. Eso no es un problema técnico, es de gobierno.
Si eres OIV o prestador de servicios esenciales, una plataforma digital comprometida puede activar deberes de reporte bajo la Ley 21.663. Y si maneja datos personales, la Ley 21.719.
- Asignar por escrito un responsable del sitio, con presupuesto de mantención.
- Confirmar quién tiene credenciales de administración hoy, incluida la agencia externa.
- Definir si el sitio entra en el alcance de tus obligaciones regulatorias.
ID IdentificarSi esto me toca, por donde me toca
No puedes parchar lo que no sabes que tienes. El caso típico no es el sitio principal: es el micrositio de una campaña de 2024 que sigue publicado y que nadie recuerda.
Inventaria también los plugins. El agujero suele estar ahí, no en el núcleo.
- Listar todos los WordPress de la organización, incluidos subdominios y micrositios olvidados.
- Registrar versión del núcleo y de cada plugin, con su fecha de última actualización.
- Confirmar que las actualizaciones automáticas están realmente activas, no solo configuradas.
PR ProtegerComo evito que ocurra
Parchar es el piso. Lo que cambia el resultado a mediano plazo es reducir lo que un atacante puede hacer aun si entra: que uploads no ejecute PHP, que el panel de administración no esté abierto a todo internet, y que una credencial robada no baste.
La regla de no ejecutar PHP desde uploads es la de mejor rendimiento de todas: no rompe nada legítimo y anula la forma más común de persistencia.
Controles priorizados
P1: esta semana · P2: este mes · P3: este trimestre
| Prio | Control | Esfuerzo | Mapeo |
|---|---|---|---|
| P1 | Actualizar el núcleo a 6.8.6, 6.9.5 o 7.0.2 o posterior, y verificar que quedó aplicado. Un tema o plugin que bloquea las actualizaciones automáticas es más común de lo que parece. | bajo | MITRE ATT&CK M1051 CIS Controls v8 7.3 ISO 27001 A.8.8 |
| P1 | Impedir la ejecución de PHP dentro de wp-content/uploads desde la configuración del servidor web. No rompe nada legítimo y anula la persistencia más común. |
bajo | MITRE ATT&CK M1042 CIS Controls v8 2.7 ISO 27001 A.8.19 |
| P1 | Ejecutar la verificación de compromiso antes de dar el sitio por seguro: PHP recientes en wp-content, PHP en uploads y administradores no reconocidos. Parchar no limpia un sitio ya comprometido. |
medio | CIS Controls v8 8.11 ISO 27001 A.8.16 |
| P2 | Restringir /wp-admin y /wp-login.php por IP o exigir un segundo factor. El panel de administración no necesita estar abierto a internet completo. |
medio | MITRE ATT&CK M1035 CIS Controls v8 6.5 ISO 27001 A.8.5 |
| P2 | Desplegar un WAF delante del sitio. No reemplaza al parche, pero compra los días que separan la publicación de la vulnerabilidad de tu ventana de mantención. | medio | MITRE ATT&CK M1050 CIS Controls v8 13.10 ISO 27001 A.8.20 |
| P3 | Dejar operando monitoreo de integridad de archivos sobre el directorio del sitio, con alerta ante cualquier PHP nuevo. | medio | CIS Controls v8 3.14 ISO 27001 A.8.16 |
El orden importa: parchar sin verificar compromiso previo deja al atacante dentro con la puerta cerrada por fuera. Y de todos los controles de esta lista, el de no ejecutar PHP en uploads es el que más protección da por menos trabajo.
DE DetectarComo me doy cuenta de que ya ocurrio
Hay dos cosas distintas que detectar, y se suelen confundir. La primera es el intento de explotación, que se ve en los registros del servidor web. La segunda es el compromiso ya ocurrido, que se ve en el sistema de archivos y en la tabla de usuarios.
Actualizar no limpia un sitio ya comprometido. Si había una web shell antes del parche, sigue ahí después. Por eso la verificación de compromiso es un paso aparte, y no opcional.
Qué necesitas tener logueado
- Registros de acceso del servidor web, con URI completa y cabeceras de cookie
- Eventos de archivo del EDR sobre el directorio del sitio, o monitoreo de integridad
- Tabla de usuarios de WordPress, revisada contra el listado real del equipo
- Registros del WAF si existe, para ver intentos bloqueados que indican interés en tu sitio
Indicadores de compromiso
hxxp, [.]) para evitar clics accidentales. El bloque de abajo los trae en crudo, listos para tu lista de bloqueo.| Tipo | Indicador | Confianza | Nota |
|---|---|---|---|
url |
hxxps://bioredox[.]cl/wp-content/in/app/index[.]php |
alta | Sitio chileno comprometido: bloquea la URL, jamás el dominio raíz |
user-agent |
/wp-json/batch/v1 |
media | Patrón de ruta, no indicador atómico: peticiones sin sesión a este endpoint |
https://bioredox.cl/wp-content/in/app/index.php /wp-json/batch/v1
Reglas y consultas de detección
title: Indicios de compromiso en instalaciones WordPress
id: 9d4a2f18-6c73-4b90-a1e5-8f3d7b201c64
status: experimental
description: >
Cubre las dos rutas de abuso descritas en AVC26-00724 y AVC26-00726 de la ANCI:
peticiones sin autenticar al endpoint de lotes de la API REST, y creacion de archivos
PHP dentro de wp-content, que es como se persiste una web shell.
references:
- https://www.anci.gob.cl/alertas/
author: Vantis Chile SpA
date: 2026/08/03
logsource:
category: webserver
detection:
api_lotes:
cs-uri-stem|contains: '/wp-json/batch/v1'
sin_sesion:
cs-cookie|contains: 'wordpress_logged_in'
php_en_uploads:
cs-uri-stem|contains: '/wp-content/uploads/'
cs-uri-stem|endswith: '.php'
condition: (api_lotes and not sin_sesion) or php_en_uploads
falsepositives:
- El endpoint de lotes tiene uso legitimo desde el propio panel de administracion.
Filtrar por origen antes de bloquear; alertar primero, bloquear despues.
- Ningun PHP deberia servirse jamas desde uploads. Ahi no hay falso positivo posible.
level: high
tags:
- attack.initial_access
- attack.t1190
- attack.persistence
- attack.t1505.003
// Ejecucion de PHP desde directorios de subida y altas de administrador en WordPress
let ventana = 45d;
union isfuzzy=true
(DeviceProcessEvents
| where Timestamp > ago(ventana)
| where InitiatingProcessFileName in~ ("php-fpm","php","httpd","apache2","nginx")
| where ProcessCommandLine has "wp-content"
| project Timestamp, DeviceName, Senal="proceso desde wp-content", Detalle=ProcessCommandLine),
(DeviceFileEvents
| where Timestamp > ago(ventana)
| where FolderPath has "wp-content" and FileName endswith ".php"
| where ActionType in ("FileCreated","FileModified")
| project Timestamp, DeviceName, Senal="PHP nuevo en wp-content", Detalle=FolderPath)
| order by Timestamp desc
# Ejecutar en el servidor del sitio. No borra nada: solo enumera para revision. # 1. PHP creado o modificado en los ultimos 45 dias dentro de wp-content find /var/www -path '*/wp-content/*' -name '*.php' -mtime -45 -printf '%TY-%Tm-%Td %p\n' | sort # 2. PHP dentro de uploads: no existe razon legitima para que haya uno find /var/www -path '*/wp-content/uploads/*' -name '*.php' -ls # 3. Administradores dados de alta, ordenados por fecha de registro wp user list --role=administrator --fields=ID,user_login,user_email,user_registered --allow-root # 4. Version instalada frente a las parchadas por la ANCI (6.8.6 / 6.9.5 / 7.0.2) wp core version --allow-root # 5. Plugins con actualizacion pendiente, que es donde suele estar el agujero real wp plugin list --update=available --allow-root
El endpoint /wp-json/batch/v1 tiene uso legítimo desde el propio panel de administración: por eso la regla exige ausencia de cookie de sesión. Filtra además por las IP desde las que administra tu equipo.
La detección de PHP en wp-content/uploads no tiene falso positivo posible: ningún proceso legítimo de WordPress escribe código ejecutable en el directorio de subidas. Si aparece uno, es un hallazgo, no una alerta a calibrar.
RS ResponderContencion y erradicacion
Si encuentras un PHP que nadie creó o un administrador que nadie reconoce, resiste la tentación de borrarlo y seguir. Ese archivo es la única evidencia de cómo entraron y de qué más tocaron.
Aísla el sitio del tráfico público antes de limpiar. Una restauración apresurada sobre un sitio comprometido suele terminar en un segundo compromiso a los pocos días, porque nunca se cerró la puerta original.
- Sacar el sitio de circulación antes de tocar archivos: página de mantenimiento o regla del WAF.
- Copiar el sitio y sus registros completos antes de borrar o restaurar nada.
- Rotar todas las credenciales: administradores, base de datos, FTP/SSH y claves de API.
- Restaurar desde un respaldo anterior al primer archivo sospechoso, no desde el más reciente.
- Revisar si tu dominio quedó marcado en Google Safe Browsing y pedir la revisión.
RC RecuperarVolver a operar y no repetirlo
Volver a publicar no es haber recuperado. La pregunta es si cerraste la puerta por la que entraron, y eso solo lo sabes si identificaste cuál era.
Después del incidente, la métrica útil es sencilla: cuánto tardas hoy en aplicar un parche crítico de WordPress desde que se publica. Si son semanas, el próximo incidente ya está agendado.
- Verificar que el vector original está cerrado, no solo que el sitio volvió a cargar.
- Dejar el monitoreo de integridad de archivos operando de forma permanente.
- Medir el tiempo desde publicación del parche hasta su aplicación. Esa es tu métrica.
Llévatelo
Lo de arriba explica. Esto se ejecuta. Son archivos, no capturas de pantalla: se abren, se pegan y funcionan.
La regla Sigma es la canónica: es el formato neutral del que se derivan las demás. Si tu SIEM no aparece en la lista, esa se convierte con pySigma. Las traducciones a motores concretos van sin validar contra tu modelo de datos — revisa los nombres de tabla y campo antes de subirlas a producción.
Fuentes
- ANCI / CSIRT NacionalAVC26-00724 — WordPress, vulnerabilidad crítica (CVE-2026-63030) · 2026-07-20
- ANCI / CSIRT NacionalAVC26-00726 — WordPress, inyección SQL en WP_Query · 2026-08-03
- ANCI / CSIRT NacionalACF26-01130 — campaña que suplanta a CorreosChile · 2026-07-30
- MITRE ATT&CKT1190 — Exploit Public-Facing Application
- MITRE ATT&CKT1505.003 — Server Software Component: Web Shell
- BCNLey 21.663, Ley Marco de Ciberseguridad
¿Esto te aplica y no sabes por dónde partir?
Revisamos tu exposición real frente a lo que describe este análisis: superficie expuesta, cobertura de detección y brechas frente a la Ley 21.663. Diagnóstico de 15 minutos, sin costo.
Agendar diagnósticoRelacionado
Falla crítica en Hitachi Energy Asset Suite expone servlets sin autenticación
CISA documentó dos CVEs con CVSS 8.1 en el software de gestión de activos que usan generadoras, transmisoras y distribui…
CVE-2026-65660 en SharePoint on-premise ya se explota activamente
CISA la sumó a su catálogo de explotación activa seis semanas después del parche de agosto. En paralelo, el ransomware W…
CISA suma falla crítica de Apple a su catálogo de explotación activa
CVE-2026-86950 afecta iOS, macOS y otros productos Apple; el parche de emergencia ya está disponible. Fuentes técnicas l…