Para aquellos que desconocen, WordPress utiliza (desde la versión 2 si mal no recuerdo) las funciones wp_create_nonce y wp_verify_nonce como sistema de protección para ataques de tipo CSRF. Más allá de algunos problemas no relacionados con la implementación de estas funciones, ha funcionado bastante bien a lo largo del tiempo.
Entrando un poco más en detalle sobre esta funcionalidad, lo que parecería que se usa es algo que se conoce como nonce en el mundo de la seguridad informática. Un nonce viene de la abreviación en inglés number used once, un número pseudo-aleatorio que normalmente se usa para evitar ataques de repetición (mala traducción para replay attacks) cuando se definen y verifican protocolos criptográficos. Volviendo al principio, lo que se usa en WordPress no son estrictamente nonces puesto que estos valores tienen una duración de 24 horas más o menos y que naturalmente puede ser usado para realizar las mismas acciones múltiples veces.
En circunstancias normales, si ese valor generado es seguro y un atacante no tiene la posibilidad de generarlo o interceptarlo, pues todavía es en cierta forma aceptable. El protocolo de manera simplificada es el siguiente.
WP -> B : nonce( time.action.user_id ) B -> WP : pair( nonce( time.action.user_id ), action )
WP representa a WordPress, que envía al navegador B un valor encriptado conteniendo el timestamp, la acción relacionada y el identificador del usuario. Por su lado el navegador debe enviar el valor generado por WP y la acción que desea realizar. WP al recibir el mensaje comprueba que el numero enviado por B no ha sido modificado y corresponde exactamente a la acción a realizar. Sin embargo, una vez más, esto no se cumple siempre debido a que el valor que puede tomar action, puede ser modificado por B. ¿Las consecuencias? pues simplemente que este mecanismo puede actualmente ser evadido bajo ciertas condiciones. En el caso de un blog, puede que no sea importante, pero para otro tipo de aplicaciones hay que tener bastante más cuidado.