Oh man - failure to use a framework or they worked around it - either way this was a big programming no no - direct use of SQL with NO sanitizing. Very bad.
I can't even call this a vulnerability - it's an open door.
I can't even call this a vulnerability - it's an open door.
It is only in the last couple of years that the PHP community has begun properly getting it's shit together (composer, PSR, unit testing (not a universal panacea but a useful tool)).
The problem is as always the good programmers will continually seek out better ways to do things (or at least explore the available options) while the "bad" programmers will continue to program like it's 2001 and PHP4 is the new kid on the block.
This is mostly the result of PHP's origins and is unlikely to improve in the short term.
If you follow best-practices, use modern tools (as mention composer, psr autoloading) and a decent framework (Symfony 2, Zend or my favourite Laravel) then you can turn out a good, secure and well engineered product.
If somebody is inclined to stick raw POST data into an SQL query, a framework isn't going to save him. Maybe an ORM will, but ORMs are only a small part of what we call frameworks nowadays, and any ORM that allows custom SQL still leaves plenty of room for a lazy developer to shoot himself in the foot. Similarly, a framework won't prevent you from sticking raw POST data into an exec() call. Most frameworks don't even care about those shell functions, they're so heavily focused on providing a smooth CRUD experience.
On the other hand, if the argument is that someone who knows how to use a proper framework is likely to be a better programmer than someone who doesn't, I agree and I'm sure that such a correlation can be easily proven.