WHK102

Eso es problema de WordPress y sucedió porque en la url se pasa como parámetro una colección de textos separados por coma en ves de utilizar diferentes parámetros como arrays por parámetro GET lo cual si es estandard, usar comas no es estandard y crs lo considera como un posible ataque de inyección sql. Eso demuestra que tu hosting es bastante bueno ya que es seguro y pudo detectar una deficiencia de WordPress. Lo mas lógico hubiera sido que wordpress hubiera enviado strings concatenados de esta manera: var[1]=val1&var[2]=val2, pero enviar una colección así: var=val1,val2,val3 es hacer las cosas a lo bruto, no hay secuencia de escape, no hay reglas de codificación, no hay nada. Se nota que hay algunas personas que hicieron comentarios a lo bestia sin saber de lo que hablan. De todas maneras o puedes solucionar creando un directorio «custom_rules» dentro del directorio de reglas y crear un archivo de excepción tal como este: https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/192 y este https://www.kubuntuforums.net/showthread.php?64939-Apache2-ModSecurity-Whitelist-Generartor-Script y es que el problema no es el crs sino que suceden situaciones especiales donde WordPress no utiliza la via estandard para hacer las cosas sino que a veces hacen las cosas como se les venga en gana y este es uno de varios casos, otr ejemplo muy claro es la serialización via php del contenido de la cookie de smf forum saliendo de todo estandard en ves de utilizar una cookie para cada variable/valor y por ende tambien arroja problemas con el mod_security y para cada excepción que haces abres una puerta al atacante porque es un lugar menos donde el crs ya no tendrá control. Saludos.