GitBucket 4.47.0 вышел 9 августа 2026 года с изменениями, которые затрагивают безопасность, автоматизацию и повседневную работу с репозиториями. Самая заметная часть релиза связана с CVE-2026-13540: разработчики закрыли SSRF-сценарий при создании репозитория из внешнего Git-адреса и добавили отдельные средства контроля для такого клонирования.
GitBucket редко попадает в новости из-за громких интерфейсных новинок, и версия 4.47.0 хорошо показывает характер проекта. Здесь интереснее то, что происходит под капотом: сервер получил защиту на одном из чувствительных сетевых путей, GitHub-совместимый API научился работать со стабильными числовыми идентификаторами репозиториев и форками, а несколько давно раздражавших мелочей в редакторе и управлении задачами были исправлены.
GitBucket — самостоятельная Git-платформа на Scala, которую можно разместить на собственном сервере. По смыслу она закрывает знакомый набор задач GitHub и GitLab — хранение репозиториев, issues, pull requests, wiki и API для интеграций. Поэтому изменения в 4.47.0 особенно заметны там, где GitBucket уже встроен во внутреннюю инфраструктуру компании или команды.
GitBucket 4.47.0 закрывает SSRF при создании репозитория из внешнего URL
Ключевое нововведение в этом релизе связано с функцией «Copy existing git repository». Эта функция позволяет создать новый репозиторий в GitBucket, указав URL уже существующего Git-репозитория. До версии 4.47.0 передаваемый пользователем URL напрямую обрабатывался JGit — библиотекой, отвечающей за клонирование.
Проблема получила идентификатор CVE-2026-13540 и относится к классу SSRF, Server-Side Request Forgery. Такой сценарий позволяет заставить сервер отправить сетевой запрос по адресу, который выбрал пользователь. В опубликованном отчёте показано, что запросы могли уходить к внутренним узлам, Docker-host и произвольным портам. Уязвимый путь был доступен аутентифицированным пользователям, у которых разрешено создание репозиториев; в стандартной конфигурации GitBucket такое разрешение доступно всем пользователям.
По данным NVD, CVE-2026-13540 затрагивает GitBucket 4.46.0 и 4.46.1. CNA VulDB оценил уязвимость в 6,3 балла по CVSS 3.1, уровень Medium. Исходный отчёт проекта описывает CWE-918 и отдельно указывает возможность обращений к внутренней сетевой инфраструктуре и облачным metadata-сервисам.
Исправление вошло в 4.47.0 сразу в нескольких формах. GitBucket получил механизм блокировки приватных адресов при клонировании и IP whitelist для разрешённых исключений. В настройках появилась возможность целиком отключить создание репозитория путём копирования внешнего Git-источника. Такой набор настроек разделяет два сценария: публичные внешние репозитории можно обрабатывать через сетевые ограничения, а сам путь клонирования может быть убран из доступных способов создания репозитория.
Официальный changelog GitBucket описывает эту часть релиза как дополнительные параметры безопасности для создания репозиториев через клонирование. Патч для сетевой проверки связан с commit 487a9b980f56aa73b6a044b1e86a92eed5043215, который также указан в записи CVE.
GitHub-совместимый API получил постоянные ID репозиториев и управление форками
Вторая крупная линия GitBucket 4.47.0 касается API. Проект давно старается поддерживать совместимость с GitHub API, чтобы сторонние инструменты могли работать с локальным GitBucket с меньшим количеством специальных адаптеров. В 4.47.0 этот слой стал ближе к поведению GitHub в операциях с репозиториями.
В модель репозитория добавили числовой REPOSITORY_ID. Идентификатор сохраняется при переименовании репозитория и повторно не используется для другого объекта. Через API появился маршрут /api/v3/repositories/:id, а JSON-представление репозитория получило поля id и fork.
Практический эффект хорошо виден на интеграциях. Если внешняя система хранит ссылку на репозиторий по постоянному числовому ID, переименование проекта или изменение его пути больше не обязано ломать такую привязку. Именно такую модель давно используют сервисы, которые ориентируются на GitHub API.
Для форков добавлены два совместимых маршрута:
POST /api/v3/repos/:owner/:repository/forks— создание форка;GET /api/v3/repos/:owner/:repository/forks— получение списка форков.
Изменение потребовало миграции базы данных и дополнительных ограничений для связей между исходным репозиторием и его форками. В тестах проекта отдельно проверяются сохранение ID при переименовании, отсутствие повторного использования идентификаторов и целостность данных после миграции.
Шесть API-маршрутов теперь возвращают корректный JSON
За несколько часов до подготовки релиза разработчики закрыли ещё одну несовместимость API. В ряде маршрутов GitBucket формировал JSON-значение, затем оборачивал его в JSON-строку. Для клиента это выглядело как строка с сериализованным объектом вместо самого объекта.
В 4.47.0 исправлены шесть маршрутов:
POST /api/v3/admin/organizations;POST /api/v3/repos/:owner/:repository/pulls;POST /api/v3/repos/:owner/:repository/releases;PATCH /api/v3/repos/:owner/:repository/releases/:tag;PATCH /api/v3/user;POST /api/v3/admin/users.
Ошибочно сформированный запрос на этих маршрутах теперь получает HTTP 400 Bad Request. Для скриптов и SDK это устраняет отдельное распознавание «JSON внутри строки» и делает ответ ближе к тому, который ожидают клиенты GitHub API.
Ещё одна точечная правка касается авторов коммитов. Если автор или committer отсутствует среди зарегистрированных пользователей GitBucket, API теперь возвращает null в поле пользователя. Раньше GitBucket создавал фиктивный объект. Поведение приведено к модели GitHub, где Git-коммит может существовать с именем и email автора, хотя соответствующей учётной записи на платформе нет.
Ссылка сброса пароля получила настраиваемый срок действия
GitBucket 4.46.1 содержал неприятный сценарий: пользователь запрашивал сброс пароля, открывал присланную ссылку и мог получить страницу Not found. Обсуждение проблемы привело к двум связанным изменениям для версии 4.47.0.
Срок действия reset-токена увеличили до 10 минут, после чего период сделали настраиваемым. Здесь хорошо видно, как небольшая жалоба на вход в систему превратилась в параметр уровня администратора. Фикс убирает жёстко заданное короткое окно и позволяет самой установке GitBucket определять время жизни ссылки.
Для корпоративных инсталляций этот нюанс заметен сильнее, чем кажется. Почта может проходить через фильтры, прокси и внешние шлюзы, а пользователь открывает сообщение спустя несколько минут. При слишком коротком сроке токен успевает стать недействительным ещё до перехода по ссылке.
Переименование репозитория больше не сбрасывает assignee в issues
В 4.47.0 исправлена потеря назначенных исполнителей при переименовании репозитория или смене владельца. Раньше такая операция могла оставить issue без assignee, хотя сама задача и остальные данные продолжали существовать.
Теперь назначения сохраняются. Для проектов, где issues используются как рабочий трекер, это устраняет тихую потерю части контекста: после переноса репозитория задача остаётся связанной с тем же ответственным пользователем.
Это изменение связано и с более крупной переработкой модели репозиториев в API. В одной версии разработчики одновременно закрепили постоянные числовые ID, обновили миграции связей и сохранили назначения при переименовании или переносе проекта.
Markdown-редактор избавился от ложной отправки форм и поправил форматирование кода
Набор пользовательских исправлений в 4.47.0 сосредоточен вокруг панели Markdown. Кнопки форматирования раньше могли вести себя как submit-кнопки формы и случайно отправлять содержимое. Теперь действия панели форматирования отделены от отправки формы.
Разработчики объединили действия для inline-кода и блока кода. При выделении нескольких строк редактор использует формат с тройными обратными кавычками, который соответствует многострочному Markdown-блоку. Для короткого фрагмента остаётся однострочное форматирование.
В том же milestone закрыта ошибка, при которой кнопка отправки комментария могла неожиданно становиться недоступной. Эти правки невелики по объёму кода, зато касаются операций, которые повторяются десятки раз в течение обычного review или обсуждения issue.
Версия 4.47.0 получилась релизом инфраструктурных границ
GitBucket 4.47.0 опубликован 9 августа 2026 года, спустя почти четыре месяца после 4.46.1. По официальному changelog релиз объединяет пять основных направлений: сетевую защиту при клонировании, настройку срока действия reset-токена, расширение GitHub-совместимого API, сохранение assignee и исправления Markdown-редактора.
Самое заметное изменение связано с границей между GitBucket и внутренней сетью. CVE-2026-13540 показала, что удобная функция импорта репозитория одновременно становится серверным сетевым клиентом, если URL полностью контролирует пользователь. В 4.47.0 у этого пути появились отдельные ограничения и возможность полного отключения.
GitBucket всё точнее повторяет модель GitHub для ID репозиториев, форков, JSON-ответов и неизвестных авторов коммитов. Открытым остаётся вопрос о том, насколько быстро сторонние клиенты начнут использовать новые маршруты и постоянные ID в реальных инсталляциях. Сам релиз уже формирует для этого более предсказуемую основу.
