Суть в чём: любой анонимный чел может отправить POST-запрос на /wp-json/batch/v1, и если сайт не пропатчен, туда залетает PHP-файл. Причём пофиг на плагины и тему дефолтная установка WordPress тоже уязвима. Затронуты версии 6.9.0–6.9.4, 7.0.0–7.0.1, а также 6.8.x (там только SQL-инъекция без RCE). Фикс вышел в 6.9.5 и 7.0.2 ещё в июле, но, как обычно, куча народу забила на обновление.

Уже есть подтверждения, что это не просто теория. CISA добавила оба CVE в каталог известных эксплуатируемых уязвимостей (KEV) ещё в конце июля. По логам видны массовые сканы, а на скомпрометированных сайтах находили веб-шеллы в /wp-content/cache/ и левых админов в базе. По сути, сейчас это автопалилка для ботов: если у тебя старая версия и открыт REST API тебя сольют.

По защите: вариант номер один обновиться до 6.9.5 или 7.0.2. Если не можешь сразу, закрой батч-эндпоинт на уровне WAF или реверс-прокси: блокируй и /wp-json/batch/v1, и вариант через query string rest_route=/batch/v1, иначе толку ноль. Ну и проверь логи на POST-запросы к этому пути, если там уже кто-то наследил простая установка патча не уберёт чужой бэкдор.

Что меня больше всего пробивает: модель сама зарегистрировала аккаунт на почтовом сервисе. Поняла, что публикация пакета это реальная атака («NOT okay»), но решила, что всё ещё в симуляции (её смутил 2026 год в тестах). Она не изобрела ничего нового просто использовала слабые пароли, открытые эндпоинты и типовые SQL-инъекции. То есть даже ИИ не нужны 0-day, чтобы натворить дел. 

Это звоночек или просто глюк тестового стенда? Может, в следующий раз модель вообще в продакшен полезет, а мы и не заметим?)))

В самой Meta проблему уже устранили, но сколько людей реально пострадало молчат, и вот теперь вопрос: если даже собственный ИИ-бот поддержки Meta сливает аккаунты направо и налево, то насколько вообще можно доверять этим платформам?

Пост признанение что я лох)

Всем привет. Сегодня хочу поделиться историей, которая заставила меня задуматься о том, как легко мы, разработчики, сами себе роем ямы, а потом героически из них выбираемся, вооружившись дизассемблером и чувством глубокого самобичевания. История такая: год назад писал один pet-проект на бэке, запилил авторизацию через JWT, хеширование bcrypt, соль, перец, всё как у людей. Админку защитил настолько хорошо, что сам же и не залезу потому что пароль от учётной записи администратора благополучно потерял, базу данных при переезде на новый сервер подчистил (да, бекапы это для слабаков), а метод восстановления, как назло, не реализовал, потому что «кто ж будет терять пароль от собственного проекта, это же не production».

И вот сижу я, автор системы, которая должна была быть неприступной, и понимаю, что моя же собственная защита теперь держит меня снаружи лучше, чем любого злоумышленника. Пришлось вспомнить молодость, поднять IDA Pro, залезть в собственный бинарник, найти место, где происходит сравнение хешей, пропатчить условный переход на месте, собрать обратно и зайти в админку с любым паролем, чувствуя себя одновременно гением и идиотом. Мораль тут двоякая: с одной стороны, если ты защищаешь систему, защищай её и от себя, делай запасные входы, потому что ты самый вероятный нарушитель собственного спокойствия.

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

P.S. Бекапы теперь делаю, пароли храню в менеджере, а в коде админки оставил закладку, о которой знаю только я и теперь весь этот форум)))