Un investigador de Searchlight Cyber utilizó el modelo de OpenAI para construir en poco más de diez horas una cadena de ataque contra una instalación estándar de WordPress.
Una prueba de poco más de diez horas con GPT-5.6 Sol permitió descubrir y desarrollar una vulnerabilidad crítica en el núcleo de WordPress. Según el investigador que condujo el trabajo, el uso del modelo de OpenAI tuvo un costo proporcional estimado de apenas 25 dólares.
La vulnerabilidad, conocida como wp2shell, permite encadenar dos fallas para pasar de una solicitud anónima a la ejecución de código en el servidor. WordPress publicó las correcciones el 17 de julio de 2026, pero los atacantes comenzaron a explotar el problema poco después.
La gravedad del episodio es doble. Por un lado, afecta directamente al núcleo de WordPress y no depende de un complemento vulnerable. Por otro, muestra que un modelo avanzado puede encontrar y combinar errores dispersos en una base de código madura, construyendo en horas una cadena de ataque que habría exigido un trabajo humano considerable.
Cuatro agentes y una copia del código de WordPress
Adam Kues, investigador de Assetnote y Searchlight Cyber, relató en un análisis técnico publicado el 20 de julio cómo utilizó GPT-5.6 Sol Ultra para examinar una copia de la versión estable de WordPress.
Kues adaptó una estrategia de instrucciones publicada previamente por OpenAI y pidió al modelo que organizara cuatro agentes, explorara enfoques diferentes y trabajara durante al menos seis horas. El objetivo explícito era identificar, desde el código fuente y sin consultar el historial de cambios, una cadena que permitiera pasar de una solicitud sin autenticar a la ejecución remota de código en una instalación habitual de WordPress con MySQL.
Para impedir que el modelo encontrara pistas comparando versiones, el investigador eliminó el historial de Git y restringió el acceso a Internet. También le exigió comprobar sus hallazgos con agentes adversariales y evitar configuraciones improbables que solo sirvieran para satisfacer formalmente la prueba.
Cuando Kues regresó, el sistema afirmaba haber encontrado una inyección SQL accesible sin autenticación. El investigador instaló entonces una copia estándar de WordPress en un servidor remoto y pidió al modelo que recuperara la dirección de correo electrónico del administrador. La prueba funcionó en pocos minutos.
El acceso inicial a la base de datos todavía no equivalía a tomar el control del sitio. Kues preguntó entonces si la falla podía ampliarse hasta lograr ejecución remota de código. Unas cuatro horas después, GPT-5.6 Sol había desarrollado una cadena que permitía elevar privilegios, crear una cuenta administrativa y utilizarla para instalar un complemento con código controlado por el atacante.
El proceso completo tomó algo más de diez horas. Kues calculó que consumió aproximadamente la mitad de la cuota semanal de su suscripción de 200 dólares, lo que representa un costo proporcional cercano a 25 dólares. No se trata de una factura independiente por la investigación, sino de una estimación basada en la fracción de la suscripción utilizada.
Un mérito técnico para OpenAI, con dirección humana
El investigador diseñó el experimento, redactó las instrucciones, proporcionó el entorno, verificó el resultado y realizó la divulgación responsable. Pero el hallazgo no fue simplemente una sugerencia superficial producida por una herramienta de autocompletado: según su descripción, GPT-5.6 Sol identificó los errores y construyó la cadena técnica que los convertía en un compromiso completo.
Kues sostiene que un investigador humano no habría podido encontrar y completar la misma cadena en diez horas sin ayuda de inteligencia artificial.
La comunicación oficial de WordPress acredita a Adam Kues, de Assetnote y Searchlight Cyber, como responsable de reportar la falla que conduce a ejecución remota de código. WordPress no atribuye formalmente el descubrimiento al modelo ni verifica el costo y el tiempo declarados por el investigador.
Con esa precisión, el episodio representa un mérito técnico importante para OpenAI. Su modelo no solo encontró un error aislado: relacionó distintos comportamientos internos de WordPress hasta formar una cadena de explotación funcional. El costo reducido muestra, además, que esta capacidad comienza a estar al alcance de equipos que no disponen de grandes laboratorios ni presupuestos extraordinarios.
Dos fallas encadenadas
Wp2shell combina dos vulnerabilidades del núcleo de WordPress.
La primera, identificada como CVE-2026-63030, afecta al mecanismo que procesa varias solicitudes de la API REST en un mismo lote. Una confusión en la asociación entre rutas y controles de validación permite que determinados parámetros lleguen a funciones internas sin la revisión esperada.
La segunda, CVE-2026-60137, es una inyección SQL relacionada con el parámetro author_not_in de WP_Query. Al combinar ambas fallas, un atacante puede consultar información arbitraria de la base de datos sin iniciar sesión.
GPT-5.6 Sol encontró además una vía para transformar ese acceso de lectura en control administrativo. La cadena utiliza el sistema interno de caché, las funciones de contenido incrustado y un tipo especial de entrada empleado para guardar cambios de personalización. Al manipular la interacción entre esos componentes, el sistema consigue que WordPress ejecute temporalmente determinadas operaciones con la autoridad de un administrador.
Ese privilegio permite crear una cuenta administrativa. Desde allí, el atacante puede instalar un complemento malicioso y ejecutar código en el servidor.
La explotación comenzó después del parche
WordPress corrigió las fallas en las versiones 7.0.2, 6.9.5 y 6.8.6. La rama 6.8 solo está afectada por la inyección SQL y no por la cadena completa de ejecución remota. Las versiones anteriores a 6.8 no están afectadas, según el proyecto.
Debido a la gravedad del problema, WordPress activó actualizaciones forzadas mediante su sistema automático para las instalaciones vulnerables compatibles con ese mecanismo.
La existencia del parche no cerró inmediatamente la ventana de riesgo. Aparecieron pruebas de concepto públicas y los primeros sondeos relacionados con la explotación fueron observados durante la noche del mismo 17 de julio.
El 21 de julio, la Agencia de Ciberseguridad y Seguridad de las Infraestructuras de Estados Unidos incorporó CVE-2026-63030 al catálogo de vulnerabilidades explotadas. El registro la clasifica como una falla explotable a través de la red, sin privilegios ni intervención del usuario, con impacto potencial sobre la confidencialidad, integridad y disponibilidad del sistema.
Investigadores citados por BleepingComputer han observado búsquedas masivas de instalaciones vulnerables, creación de cuentas administrativas, instalación de complementos maliciosos y despliegue de webshells: archivos PHP que proporcionan acceso persistente al servidor.
Actualizar y revisar
Los administradores deben comprobar que sus instalaciones ejecutan WordPress 7.0.2 o una versión posterior. Quienes todavía permanezcan en ramas anteriores deben instalar las correcciones correspondientes y planificar la migración hacia una versión que continúe recibiendo soporte.
Actualizar cierra la vulnerabilidad, pero no elimina una cuenta, complemento o puerta trasera que haya sido instalada antes del parche. Si el sitio estuvo expuesto con una versión vulnerable, corresponde revisar las cuentas administrativas, los complementos instalados recientemente, los archivos PHP inesperados -especialmente en directorios de caché- y los registros de acceso.
Los servicios de alojamiento administrado pueden haber distribuido la corrección automáticamente, pero conviene verificar la versión directamente en el panel de WordPress.
La misma capacidad, dos resultados opuestos
Como informó Diario TI en el artículo sobre el incidente que afectó a Hugging Face, modelos de OpenAI configurados para una evaluación de ciberseguridad encontraron una salida del entorno previsto y terminaron accediendo sin autorización a infraestructura real de un tercero.
En wp2shell aparece la otra cara de la misma capacidad. Un investigador humano fijó el objetivo, limitó el entorno, supervisó las comprobaciones y comunicó el problema responsablemente a WordPress. El modelo permitió descubrir la vulnerabilidad antes de que fuera conocida públicamente y dio al proyecto la oportunidad de distribuir una corrección.
La diferencia no está en que una inteligencia artificial sea intrínsecamente ofensiva o defensiva. Está en el objetivo que recibe, el entorno técnico dentro del cual opera, los controles que limitan sus acciones y la supervisión humana que acompaña el proceso.
El resultado también modifica la economía de la ciberseguridad. Una investigación que produjo una vulnerabilidad crítica en uno de los sistemas de publicación más utilizados del mundo consumió diez horas de ejecución y unos 25 dólares de capacidad contratada. Esa reducción de tiempo y costo puede fortalecer a los defensores, pero también obliga a acelerar la instalación de parches: una vez publicada una corrección, otros agentes pueden analizarla y reproducir la falla con rapidez.
Fuentes: WordPress 7.0.2; investigación de Adam Kues; registro de CVE-2026-63030; alerta técnica de NHS England.
Ilustración: captura del sitio de SearchLight Cyber.
📬 Newsletter gratuito
