revision de seguridad de codigo con IA WordPress 2026

La revision de seguridad de codigo con IA WordPress ha pasado a formar parte de mi flujo estándar antes de entregar cualquier plugin o tema a un cliente. No porque la IA lo detecte todo, sino porque detecta las vulnerabilidades mecánicas más rápido que unos ojos cansados tras una semana intensa de desarrollo. En la práctica, tres herramientas justifican su lugar en ese proceso. Aquí está lo que cada una detecta, lo que todas ellas pasan por alto, y una lista de comprobación de tres pasadas que encaja en una carga de trabajo real.

El vibe coding está generando deuda de seguridad específica en WordPress

La cifra que merece una pausa: investigadores de seguridad emparejaron análisis estático con IA y verificación automatizada, y afloraron más de 300 vulnerabilidades críticas zero-day en el ecosistema de plugins de WordPress en aproximadamente 72 horas. No en plugins marginales con una docena de instalaciones. En plugins con cifras de instalación relevantes, usados en producción por miles de sitios.

¿Qué está detrás de esto? La respuesta corta es el vibe coding: desarrolladores que publican código de plugins generado por modelos de lenguaje sin haberlo leído completamente. El modelo produce lógica funcional con rapidez. El desarrollador lo confirma sin auditar la sanitización de entradas, las comprobaciones de nonce ni la verificación de capacidades. El resultado es un problema de doble confianza: el desarrollador confía en la salida de la IA, y esa salida confía en la entrada del usuario sin validación suficiente.

En un sitio de presentación sin datos de usuario, las consecuencias son limitadas. En una instalación de WooCommerce que gestiona transacciones reales, o en una red multisitio con subsitios de clientes, una llamada ausente a esc_html() o la falta de current_user_can() es una exposición con implicaciones reales. Una auditoría de agencia sobre un plugin desarrollado con vibe coding encontró más de 100 problemas de seguridad distintos en un único código fuente.

No es un argumento contra el desarrollo asistido por IA. Es un argumento para tratar el paso de revisión de seguridad como no negociable, no como un añadido cuando queda tiempo al final del sprint.

Lo que los revisores de IA detectan realmente en PHP de WordPress

Las herramientas de revisión de seguridad con IA escanean estructura de código, no comportamiento en tiempo de ejecución. Esa distinción es lo primero que hay que interiorizar antes de incorporar estas herramientas a un flujo de entrega.

Donde funcionan con fiabilidad en PHP de WordPress: llamadas ausentes a esc_html, esc_url o wp_kses; manejadores AJAX sin protección mediante check_ajax_referer o verificación de capacidades; llamadas brutas a $wpdb->query con variables interpoladas; operaciones de archivo inseguras con rutas suministradas por el usuario; llamadas no protegidas a update_option. Estos son patrones mecánicos que los modelos reconocen bien.

Donde son sistemáticamente poco fiables: errores de lógica de negocio en el procesamiento de pedidos de WooCommerce, condiciones de carrera en la gestión de inventario, vulnerabilidades del flujo de autenticación dependientes del orden de ejecución, problemas específicos del contexto como el multisitio o las restricciones del alojamiento.

El modelo mental correcto: la revisión de seguridad con IA es un filtro de primera pasada. Eleva el suelo, no el techo. La herramienta detecta lo que un desarrollador cansado pasaría por alto en una revisión rutinaria. Lo que requiere criterio sobre intención de negocio sigue siendo trabajo humano.

Tres herramientas que se ganan un lugar en una revisión de seguridad de WordPress

SonarQube Community Edition es análisis estático de PHP alojado en local y sin coste de licencia, con un motor de reglas bien orientado a los patrones de vulnerabilidad habituales en WordPress y puertas de calidad integrables en CI. La limitación práctica: la sobrecarga de configuración inicial lo hace poco operativo para revisiones puntuales si no existe ya una instancia compartida en el equipo. Para un freelance que trabaja en solitario, el coste de puesta en marcha no se amortiza en un único proyecto.

Cursor integra la revisión de seguridad dentro del entorno de desarrollo a través del modo agente. Se puede indicar que revise un directorio completo de plugin con un enfoque explícito en vulnerabilidades. El nivel gratuito es funcional para empezar; Pro a 20 $/mes para trabajo de revisión regular. La ventaja real de Cursor frente a las herramientas independientes es la proximidad al código: no hay que exportar ni mover archivos, y la iteración sobre los hallazgos ocurre en el mismo entorno donde se escribe.

Tabnine ofrece despliegue en local o en entorno aislado (air-gapped), lo que lo convierte en la opción adecuada cuando los NDAs o la sensibilidad de los datos del cliente impiden usar herramientas de IA alojadas en la nube. En proyectos del sector financiero, sanitario o de administración pública, donde el código fuente no puede procesarse en servidores de terceros, esta capacidad no es un detalle menor sino el criterio de selección.

Claude Code permite la revisión agéntica de directorios completos de plugins, con una salida estructurada suficientemente limpia para compartir directamente con clientes como parte del informe de entrega. La tasa de falsos positivos en PHP de WordPress no es trivial, lo que significa que cada hallazgo necesita verificación manual antes de incluirlo en un informe final.

Lo que la IA no detecta, y la responsabilidad que esto genera

Los errores de lógica de negocio, como el apilamiento indebido de cupones en WooCommerce o los descuentos mal calculados en escenarios de precios por rol de usuario, son invisibles para el análisis estático. Requieren criterio humano sobre la intención del negocio y el contexto de ejecución. Las vulnerabilidades del flujo de autenticación que dependen del orden de ejecución están igualmente fuera del alcance de estas herramientas.

El dato que cambia la perspectiva: el tiempo medio desde la divulgación pública de una vulnerabilidad hasta su explotación activa es de aproximadamente cinco horas. Esto convierte la revisión de seguridad antes de la entrega en un requisito operativo, no en una respuesta reactiva a un incidente. El 52% de los desarrolladores de plugins no publican parches antes de la divulgación pública, lo que agrava considerablemente el problema para los sitios que dependen de plugins de terceros.

La revisión con IA no resuelve ese problema estructural. Lo que sí hace es reducir la superficie de los fallos mecánicos antes de que el código entre en producción.

Una lista de comprobación antes de la entrega que funciona en la práctica

Pasada 1 (15 min): PHP_CodeSniffer con el conjunto de reglas WordPress-VIP-Go, o SonarQube si hay una instancia disponible. Corregir todos los hallazgos críticos antes de pasar a la siguiente pasada. Los hallazgos de severidad baja se registran pero no bloquean el avance.

Pasada 2 (20 min): Cursor o Claude Code, con un prompt dirigido al manejo de entradas, protección AJAX, consultas a la base de datos, operaciones de archivo y gestión de opciones. Registrar todos los hallazgos, incluidos los falsos positivos descartados, con la razón del descarte. Este registro tiene valor tanto técnico como contractual.

Pasada 3 (25 min): Revisión manual de cada endpoint AJAX, endpoint REST y hook de acción de administrador. Verificar que la comprobación de nonce esté presente y bien posicionada, que la verificación de capacidad use la capacidad apropiada, que la entrada se sanitice antes del procesamiento y se escape antes de la salida. Esta pasada no se puede delegar a ninguna herramienta. Se hace a mano, siempre.

El total es aproximadamente una hora por plugin de tamaño estándar. Es tiempo que se recupera con creces en la primera incidencia de seguridad que no ocurre.

El plazo de la UE de septiembre de 2026 que la mayoría de los freelances no ha planificado

Septiembre de 2026: la Unión Europea exige programas de divulgación de vulnerabilidades para desarrolladores de plugins y temas que distribuyan a usuarios de la UE. El requisito incluye un proceso documentado, una ventana de respuesta definida y un contacto de seguridad específico. Se aplica también a plugins privados o de cliente único distribuidos en mercados europeos.

Para las agencias y los freelances que trabajan en España, esto no es una abstracción regulatoria lejana. Es un requisito que afecta a los contratos actuales con clientes con presencia digital en la UE. Una revisión de tres pasadas registrada, con hallazgos documentados y decisiones razonadas, forma parte de un proceso de diligencia debida defendible en caso de auditoría o incidente.

La preparación práctica no es compleja: establecer un flujo de registro de revisiones, designar un contacto de seguridad aunque sea el propio desarrollador, y definir en los contratos la política de respuesta a vulnerabilidades notificadas. Lo que no se puede hacer es tratar esto como algo a resolver en septiembre.

Cuándo la revisión de tres pasadas es suficiente y cuándo no lo es

Un sitio de presentación o un tema de bloques sin AJAX personalizado ni procesamiento de datos: el proceso de tres pasadas es suficiente y proporcionado al riesgo real.

Un plugin personalizado con autenticación, procesamiento de pedidos, subidas de archivos o acceso a datos privilegiados: la revisión formal con hallazgos documentados es el alcance correcto. El proceso de tres pasadas es el punto de partida de esa revisión, no su sustituto.

El criterio práctico: si un fallo de seguridad en el plugin podría exponer datos de clientes finales o transacciones económicas, la revisión formal está justificada. En muchos contratos con clientes del sector comercio electrónico, es contractualmente exigible y, a partir de septiembre de 2026, puede ser legalmente relevante.