I also saw this error, and it turned out the url parser in modx was being fed malicious urls.
I added an .htaccess rule to block the various characters they used.
GET /something%e2%c3%af%c2%bf%c2%bd%a6something
I found this by searching through the apache logs for the time stamp of the modx error, and realized really all that was happening was that modx was rejecting the bad input, correctly, and then sending the modx 404 error page back. This generated the warnings in the error log.
http://krypted.com/utilities/html-encoding-reference/ gives a fine list of translating the special html characters into ones you can recognize.
Note that the advice to use the right db and db table character encoding is correct, but in our case, all our users and input match the swedish default which I accidentally made the db with initially, so there's not actually any problem with valid input in our case.
You have to be careful constructing the blocking rules, because there are many valid %xx type characters, %20 for space for example, but you'd want to check all your GET urls with something like this (run on an apache log file in this case, set to cut off everything after the 3rd ", then to refilter it because referers can also have %xx in their urls):
zgrep -Ei '%[0-9a-f]' site.20180621.gz | cut -d '"' -f 1-3 | grep '%'
[ed. note: lizardx last edited this post 5 years, 10 months ago.]