If you haven’t looked at part 1 and 2 here, I suggest you do before reading on. This is a direct continuation of part 1.
So the original
$wpdb->prepare vulnerability, which, I remind you is based on a potential typo in third-party code, is followed up with a new potential vulnerability based on double preparing a query. So again, bad third-party code.
So here’s one for you. If a developer does
$wpdb->prepare( "SELECT * FROM wp_users where ID = %d OR %d". $_GET['param1'], $_GET['param2'] ); (note the . instead of the ,) do I also get a $500 bounty? How far will this go? Will the method be removed completely because #security? To what extent should WordPress and PHP be blamed for potential developer mistakes?
Shouldn’t these be addressed in the actual third-party code and not in core? I’m at a complete and utter loss now. What’s next?
Shout outs to Slavco for bringing all these issues up both with the codebase and the community, and how things are or should be handled.
Published 6 years ago
with one comment
tagged drama, security in WordPress
drama security WordPress