Skip to content
← Blog

technical

WordPress 6.7 AI Abilities API — Analisis de superficie de ataque por Prompt Injection

· Rekon Security Research

TL;DR

WordPress 6.7 incluye un AI Client con una “Abilities API” que permite a modelos de IA ejecutar funciones PHP en el servidor. Realizamos una auditoria completa del codigo fuente: 146 archivos del SDK, la capa adaptadora, y las 3 abilities core. La implementacion es razonablemente segura — pero el diseno crea una superficie de ataque masiva de prompt injection → ejecucion de codigo que escalara con el ecosistema de plugins.

Que auditamos

WordPress 6.7.2 incluye una nueva capa de integracion con IA:

  • wp-includes/php-ai-client/ — 146 archivos PHP. SDK compatible con PSR para proveedores de IA.
  • wp-includes/ai-client/ — 6 archivos adaptadores. HTTP client, cache, eventos y Abilities.
  • wp-includes/abilities-api/ — El sistema de registro. WP_Ability envuelve un callback PHP con validacion y permisos.
  • 3 abilities core: core/get-site-info, core/get-user-info, core/get-environment-info.

Todo se carga en cada request via wp-settings.php. No esta detras de un feature flag. Es core.

Como la IA ejecuta codigo en el servidor

Plugin activa wp_ai_client_prompt()
    ↓
PromptBuilder arma prompt + herramientas
    ↓
Request HTTP al proveedor de IA
    ↓
Modelo responde con FunctionCall:
  { name: "wpab__core__get_user_info", args: {} }
    ↓
Resolver verifica whitelist + permisos
    ↓
$ability->execute() → codigo PHP real

La IA decide QUE llamar y CON QUE ARGUMENTOS.

Lo que WordPress hizo bien

  1. Permission callbacks obligatorios — sin callback, la ability falla cerrado.
  2. Validacion por JSON Schema — el mismo validador de la REST API.
  3. HTTP seguro — wp_safe_remote_request previene SSRF.
  4. Whitelist por constructor — el modelo no puede llamar abilities fuera de la lista.
  5. Verificacion de clases — class_exists() antes de instanciacion dinamica.

Lo que podria salir mal

Hallazgo 1: get-user-info solo requiere is_user_logged_in()

Cualquier suscriptor puede filtrar user_login, roles y user_id via IA. Compara con get-site-info y get-environment-info que requieren manage_options.

Hallazgo 2: Prompt Injection → Tool Use

El ataque:

  1. Atacante crea contenido con prompt injection (comentario, resena, formulario)
  2. Usuario legitimo activa procesamiento de IA sobre ese contenido
  3. El prompt inyectado manipula al modelo para llamar abilities
  4. Las abilities se ejecutan con los permisos del usuario actual

Ejemplo con WooCommerce: un gerente resume una resena que contiene prompt injection oculto → la IA crea un cupon de 100% descuento. La validacion de schema pasa. Los permisos pasan. El ataque funciona.

Hallazgo 3: Sin rate limiting

execute_abilities() procesa TODAS las function calls en un mensaje. Sin limite. Un modelo manipulado podria invocar docenas de funciones.

Hallazgo 4: Random debil en fallback criptografico

Si AUTH_SALT no esta definido: $salt = (string) rand(); — predecible.

La bomba de tiempo

Los 60,000+ plugins de WordPress van a registrar abilities. Cada ability con permisos debiles = nueva superficie de ataque. Esto es la nueva SQL injection.

Recomendaciones

Plugin devs: traten args de IA como input hostil. Capability minima. Log todo.

Operadores: define('WP_AI_SUPPORT', false); si no lo necesitan.

WordPress core: agregar max_ability_calls_per_response, documentar el riesgo.

Si tu aplicacion usa WordPress y quieres una evaluacion profesional, consulta nuestros planes de pentesting.

Metodologia

Analisis automatizado con nuestro 0-day hunter (1,884 archivos PHP en 6 segundos): 199 hallazgos → 72 POP chains → 81 patrones WP → 4 preocupaciones confirmadas. Seguido de analisis manual profundo del codigo fuente.
Solicitar presupuesto →