WordPress: recorrido de rutas no autenticado que conduce a RCE condicional

Artículo original ↗ Discusión en Hacker News ↗

Una vulnerabilidad recientemente divulgada en WordPress permite recorrido de rutas no autenticado que puede conducir a ejecución remota de código bajo ciertas configuraciones, especialmente al combinarse con estructuras comunes de temas y configuraciones inseguras de PHP como las imágenes oficiales de Docker. Los comentaristas debaten cuán extendido es realmente el riesgo, señalando que muchos temas siguen las recomendaciones de directorios de WordPress y que los parches del núcleo ya se han retroportado a versiones antiguas. El incidente reaviva críticas más amplias sobre el modelo de seguridad de WordPress, su ecosistema de plugins y la dependencia de puntuaciones CVSS base, y algunos argumentan que las organizaciones deberían aislar o reemplazar WordPress por completo, mientras que otros subrayan que una configuración y endurecimiento cuidadosos pueden mantenerlo razonablemente seguro.

Vulnerabilidad e impacto

  • Problema principal: uso no saneado de get_page_template / locate_template, lo que permite recorrido de rutas para incluir archivos PHP arbitrarios que ya estén en el servidor.
  • Condición principal: el tema tiene un directorio page-* de nivel superior (por ejemplo, page-templates/), algo que la documentación de WordPress recomienda explícitamente. Varios comentaristas sostienen que esto hace vulnerables a una gran cantidad de temas, no solo a “un par”.
  • En una instalación nueva, los usuarios aleatorios no pueden subir PHP, pero los atacantes pueden abusar de cualquier “PHP que ejecute comandos” ya existente en el sistema.

Condiciones y cadenas de explotación

  • Cadena de ejemplo: combinar esta falla con uno de los muchos errores de subida de archivos sin autenticación en plugins para llegar a una RCE condicional; los atacantes pueden preferir esto frente a subir un webshell simple para evadir configuraciones endurecidas y registros.
  • La imagen oficial de PHP para Docker históricamente incluía pearcmd.php con register_argc_argv habilitado y sin open_basedir, lo que ofrece un objetivo potente una vez que se logra el recorrido de rutas.
  • Algunos sostienen que esto es, en la práctica, “explotable por drive-by” en sitios que usan temas populares junto con configuraciones predeterminadas de Docker o alojamiento compartido.

Estado del parche y despliegue

  • Corregido en WordPress 7.1.2, con backports “como cortesía” a ramas hasta 4.7 (excepto una versión de autoactualización defectuosa).
  • Un comentarista al principio se pregunta si los temas aún necesitan auditoría después del parche, pero concluye que la corrección del núcleo debería neutralizar el comportamiento del tema.
  • WordPress no tiene un LTS real; las ramas antiguas dependen de backports selectivos, dejando errores desconocidos sin parchear.

Debate sobre la puntuación CVSS

  • Un bando: las puntuaciones CVSS son números “de tabla Ouija”, fáciles de manipular y a menudo desalineados con el riesgo real; usarlas para priorizar qué leer es peligroso.
  • El otro bando: el CVSS base es una medida útil de primera pasada del impacto técnico; las organizaciones deberían reajustarlo por entorno usando calculadoras y controles compensatorios.
  • Contraste de ejemplo: esta RCE de WordPress (9.x) frente a vulnerabilidades de herramientas de Hugo (también 9.3) — misma severidad numérica pero exposición práctica muy distinta.

Valoraciones sobre la seguridad de WordPress

  • Crítica fuerte: “RCE-as-a-Service”, “un montón de basura”, código desordenado y mal tipado, muchas APIs sin documentar, modelo por defecto inseguro (el sitio puede escribir su propio código; las subidas a menudo son ejecutables; los plugins amplían masivamente la superficie de ataque).
  • Contraargumentos: extremadamente popular, incluidos sitios de alto valor; puede ejecutarse de forma segura con experiencia, endurecimiento y uso disciplinado de plugins. Los problemas a menudo provienen de contratistas baratos y no expertos que “ensamblan con Lego” plugins y temas.
  • Algunos sostienen que la popularidad y la extensibilidad inevitablemente atraen atacantes; otros dicen que la popularidad por sí sola no explica la historia de explotación de WordPress.

Alternativas y migraciones

  • Varios participantes informan que migraron desde WordPress a generadores estáticos (Hugo, Astro) o a PHP personalizado en su mayor parte estático, describiendo:
    • Reducción enorme de la complejidad operativa y de la preocupación por seguridad.
    • Libertad frente a la acumulación de plugins, el comportamiento de caja negra y las actualizaciones frágiles.
  • Sin embargo, incluso las herramientas estáticas pueden tener errores con CVSS alto (ejemplo de Hugo); la diferencia es que los sitios generados son HTML estático, por lo que la exposición en tiempo de ejecución es mucho menor.
  • Los sistemas de comentarios siguen siendo un punto conflictivo para los sitios estáticos; se sugieren servicios de terceros y sistemas mínimos autohospedados.

Observaciones de seguridad más amplias

  • El recorrido de rutas se ve como una clase recurrente de errores impulsada por malas abstracciones del sistema de archivos; un comentarista promueve soporte en bibliotecas para mitigarlo.
  • Los registros de servidores públicos muestran escaneo constante de exploits PHP, con rutas de WordPress y archivos .env filtrados como objetivos comunes.
  • Algunos especulan que el análisis de código impulsado por IA podría aumentar enormemente las vulnerabilidades descubiertas en todos los ecosistemas, desafiando suposiciones sobre qué software es “más explotable”.