Предположим, мы имеем скрипт users.php, который выводит список пользователей атакуемого веб-сайта. Обычно, подобные скрипты выводят этот список в виде таблицы, содержащей имя пользователя, дату его регистрации, статус на сайте и т.п. информацию. Кроме того данный скрипт позволяет сортировать вывод этой информации по каждому из этих параметров. Например, передав скрипту параметры "?orderby=name&direct=ASC", мы получаем список пользователей отсортированный в нисходящем порядке по параметру name, т.е. по имени пользователей. Обычно, таблица БД к которой обращаются подобные скрипты, помимо выводимых ими данных, содержит также секретные данные: например, пароли или хеши паролей юзерских аккаунтов.

Вот тут разработчиков веб-движков и может подстерегать опасная ошибка. Если передаваемый скрипту параметр "orderby", подставляется в SQL-запрос, без проверки его на "адекватность" его значения, то мы можем передать параметр "orderby" равный, к примеру, 'password' (или равный номеру колонки 'password' в таблице с пользователями), получив таким оразом вывод списка пользователей, отсортированный по полю 'password'. Дело в том, что тут действует одна важная особенность конструкции "ORDER BY" SQL-опертора SELECT: сортировка с помощью нее возможна по любому полю таблицы из которой извлекается информация, а не только по тем полям, по которым производится выборка SELECT'ом. Причем в данном случае никакой роли не сыграют различные защиты от sql-инъекций. Фактически, в случае обнаружения подобной уязвимости, мы имеем хоть и косвенное, но все же раскрытие секретной информации, что уже можно считать дырой в безопасности.

Является ли эта уязвимость распространенной? Нет. В серьезных движках с солидной историей обновлений ее трудно будет повстречать, но вот в разного рода самописных сайтовых движках, "фирменных" двигах всяких мелких веб-студий, вероятность обнаружить подобную багу всегда есть. 

Является ли данная уязвимость действительно опасной? Да, в случае, если атакующий имеет доступ к аккаунту пользователя уязвимого сайта и имеется возможность изменять пароль данного юзера, или же есть возможность создавать некоторое количество новых юзеров, при этом нет возможности менять их пароли. Кроме того необходимое условие для атаки: пароли в БД хранятся либо в plain-text виде, либо в виде хеша, но без соли. Следует отметить, что в случе с хешами возможен подбор только криптографически слабых паролей.

Подробности прочитать можно тут.
О подобной уязвимости в Fireboard
Фикс уязвимости в Seditio и скрипт для атаки на Seditio