An old (2.x) version of WordPress I worked on included an eval() statement that amounted to basically just doing variable assignment. I am sure there was some reason for this (probably not a good one), but it turned me off to the WordPress core. The fact that every WP release is quickly followed up with a patch for some critical remote code execution vulnerability tells me that there is something systematically wrong with its handling of user input and security.

Because of that, I moved off WordPress for personal blogging and onto Pelican [1]. You can't compromise static content.

[1] http://docs.getpelican.com/en/3.2/

Cool research. I like how you "connect-the-dots" from the benign-looking MySQL's behaviour to the bad code in Wordpress. This reminds me of http://www.suspekt.org/2008/08/18/mysql-and-sql-column-trunc....

I'm surprised that the fix in Wordpress wasn't explicitly marking fields that need to be serialized/unserialized, instead of second-guessing based on the broken promise by MySQL.

> MySQL replaces characters it doesn’t recognize (for the given character set), with a placeholder. MySQL will sometimes replace byte sequences with “?” or “�” (U+FFFD). Such replacements would not be harmful.

This is so wrong. A database must never change any data that it's asked to stored. Wordpress, and other applications, always make that assumption, and when it isn't true anymore all hell breaks loose.

PS: it blows my mind that it looks like strpos in PHP could return either boolean or integer [1].

[1] http://core.trac.wordpress.org/browser/tags/3.6.1/wp-include...

WordPress is the PHP of web frameworks....

I'll be in the corner.