Hola amigos, desde Mangas Verdes, Manuel A. Almeida ha tenido a bien (menos mal :D) coger mi parche y ordenar los archivos según directorios para que el parcheo os resulte más sencillo.

Recordar que estos parches no plantean problemas de funcionamiento pero que ni Manuel ni yo podemos hacernos responsables del comportamiento de la aplicación al 100%. El código reorganizado en directorios desde aquí.
Había quedado también en escribiros algo sobre como solucionar este Bug que se genera al ejecutar uno de los 17 archivos vía web desde el servidor, concrétamente, la clave está en la configuración del PHP.

Comentar primeramente que mucha gente no tiene acceso a la configuración de su servidor Apache o del PHP y en mi opinión es muy fácil para la gente del WordPress solucionarlo a nivel de código porque son 2 líneas únicamente.

Dicho esto, vamos a hablar del Bug y de como hacer que no se haga presente. Mi colega Rául Naveiras me dice que sería bueno explicarlo, está aquí conmigo y os pone unas líneas. «En un sistema en producción en el que estén alojadas ya unas webs funcionando correctamente, lo normal es que la variable en el «php.ini» debería estar de este modo «display_errors» con el valor Off».

Esto que comentaba Raúl, suele ser lo recomendable pero no vayáis a pensar que todos los administradores lo tienen así configurado, se puede también paliarlo a nivel de Apache para la configuración de ese host de este modo; php_admin_value display_errors Off.

Para que el administrador pueda ver que error da alguna aplicación en concreto ya que no se visualizan vía web en pantalla, se puede habilitar un registro interno de log para consultarlo cuando se necesite.

Básicamente es eso, el «full path disclosure» o adivinación de la ruta del WordPress , no es algo que se pueda catalogar como de «muy grave» pero sabiendo la ruta «maestra» de donde se alojan las webs, en el caso de un ataque o de ejecución de un exploit contra la web/servidor, puede ser más efectivo porqué irá «directo».

Saludos