Чем закрыть дыры в безопасности до того, как их найдут другие

Представь: ты сидишь на дежурстве, и вдруг прилетает алерт об успешном взломе старой версии CMS, про которую все давно забыли. Неприятный сценарий, правда? На практике безопасность часто проигрывает скорости разработки, и админы просто не успевают следить за потоком новых CVE. К счастью, есть энтузиасты, которые собирают всё «оружие» атакующих в одном месте. Сегодня разберем репозиторий POC от пользователя eeeeeeeeee-code — это огромный архив готовых эксплойтов и сценариев для проверки уязвимостей.

Что это за проект и зачем он нужен

Репозиторий представляет собой живую базу данных Proof of Concept (PoC). Изначально проект был бэкапом известной библиотеки уязвимостей wy876, но автор решил не просто хранить архив, а активно развивать его. Сейчас это одна из самых свежих коллекций сценариев атак на китайское и международное ПО.

Зачем это разработчику или системному администратору? Ответ простой: чтобы проверить свои системы «в бою». Вместо чтения сухих описаний в базах CVE, ты берешь готовый сценарий и смотришь, сработает ли он против твоего сервера. Если сработал — значит, пора срочно обновляться или закрывать порт.

На что стоит взглянуть внутри

В репозитории сотни папок, разбитых по вендорам и типам систем. Здесь есть всё: от дырок в роутерах до критических багов в современных AI-фреймворках вроде Langflow.

Любимый всеми SQL Injection

База буквально забита примерами внедрения SQL-кода. Это касается и CRM-систем, и корпоративных порталов управления энергией. Посмотрев эти примеры, понимаешь, что классические ошибки фильтрации параметров всё еще никуда не делись.

Удаленное выполнение кода (RCE)

Самые опасные штуки. В базе есть свежие сценарии для систем致远OA (Zhiyuan OA) и даже критические баги в Kubernetes Ingress-Nginx. Например, уязвимость CVE-2025-1974 наглядно показывает, как неправильная конфигурация может привести к захвату контроля над кластером.

Произвольное чтение файлов

Часто недооцененная проблема. Сценарии для систем вроде MasterSAM или DeepFlow показывают, как злоумышленник может вытянуть конфигурационные файлы с паролями от базы данных, просто обратившись к определенному эндпоинту.

Практическая польза для команды

Обычно такие репозитории используют пентестеры, но и для обычной команды разработки тут много полезного.

Регрессионное тестирование безопасности. Если ваша компания использует какое-то специфическое ПО (например, системы Dify или Langflow), вы можете добавить проверки из этого репозитория в свои CI/CD пайплайны.
Обучение на чужих ошибках. Файлы внутри — это отличные учебные пособия. Открываешь папку с уязвимостью в WordPress или Grafana и видишь, где именно разработчик допустил промах.
Быстрая проверка инфраструктуры. При появлении новости о новом CVE в очередном фреймворке, скорее всего, рабочий PoC появится здесь в течение пары дней.

Посмотрите на список обновлений за последний месяц — там десятки записей.

Несколько мыслей по безопасности

Работая с такими инструментами, важно помнить две вещи. Во-первых, это «обоюдоострый меч». Используйте его только в своей песочнице или на системах, где у вас есть официальное разрешение на поиск багов. Во-вторых, README проекта на китайском, что может слегка усложнить навигацию, но структура папок wpoc/VendorName/VulnerabilityName.md интуитивно понятна.

Внутри каждого .md файла обычно лежит описание уязвимости, параметры запроса и пример пейлоада. Всё максимально конкретно, без лишней воды.

Стоит ли пробовать

Если ты отвечаешь за безопасность инфраструктуры или пишешь корпоративные сервисы, этот репозиторий стоит держать в закладках. Это не просто «список дырок», а инструмент для активной защиты.

Проект активно наполняется — буквально на днях добавили свежие способы обхода аутентификации в WordPress плагинах и RCE в SSH-серверах на Erlang-OTP. Это хороший повод провести ревизию своих зависимостей и убедиться, что вы не используете софт десятилетней давности, который взламывается одним HTTP-запросом.

Конечно, документация местами скудная, а некоторые ссылки ведут на внешние китайские ресурсы, но для технического специалиста кода и примеров запросов будет более чем достаточно. Помните: лучше найти дырку самому, используя PoC, чем узнать о ней от хакеров.