CVE-2026-46552

Ссылки совместного доступа к базам NocoDB могут приглашать реальных участников базы и переживать отзыв доступа

Введение

Я нашел эту проблему при аудите NocoDB, задав простой вопрос безопасности:

Может ли публичная ссылка на общую базу пересечь границу от временного общего доступа к реальной аутентифицированной роли участника базы?

В данном случае ответ был «да».

Сессия, аутентифицированная только по xc-shared-base-id, рассматривалась как обычный читатель базы для целей контроля доступа (ACL). Поскольку права читателя всё ещё включали конечные точки управления участниками, пользователь, имеющий только UUID общей базы, мог перечислить существующих участников базы и пригласить произвольный email-адрес в базу как реального участника.

Приглашённый пользователь затем мог активировать приглашение через обычный процесс регистрации, получить стандартную аутентифицированную учётную запись и сохранить доступ к базе даже после того, как владелец отключил общую ссылку.

Эта проблема получила идентификатор CVE-2026-46552.

Проект: NocoDB

Подтверждённая уязвимая версия: 0.301.3

Это затронуло NocoDB. На официальном сайте NocoDB представлен как платформа, которой доверяют более 35 000 организаций, с более 20 миллионами загрузок. На сайте также перечислены такие компании, как Accenture, Western Digital, Hyundai, Walmart, PwC, Bosch и American Express.

---

Цепочка атаки

публичная ссылка на общую базу -> xc-shared-base-id воспринимается как обычный читатель базы -> ACL читателя открывает конечные точки управления участниками -> злоумышленник перечисляет пользователей базы и приглашает произвольный email -> приглашённый пользователь активирует обычный токен регистрации -> долговременный аутентифицированный доступ к базе переживает отзыв общей ссылки

---

Что делает NocoDB

NocoDB — это платформа для совместной работы, ориентированная на базы данных, которая предоставляет браузерный доступ к базам, возможность публикации, управления метаданными и рабочими процессами управления участниками.

Это означает, что модель публикации является реальной границей безопасности.

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

Настоящий вопрос был:

Может ли субъект публичного доступа выполнять действия, которые должны принадлежать только аутентифицированным участникам базы?

В данном случае — мог.

---

Почему эта поверхность заслуживала внимания

Функции публичного доступа легко недооценить.

Это ошибка.

Как только приложение поддерживает:

• анонимный или ссылочный доступ,
• привязку ролей,
• и обычные аутентифицированные API управления, использующие ту же систему ACL,

основной риск заключается не только в раскрытии данных.

Более сильный риск — это коллапс границ:

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

В этом и заключалась реальная проблема.

Это не была ошибка проверки входа. Это не была проблема подделки токенов. Это не был дефект сброса пароля.

Это был классический отказ границы авторизации:

• субъект с общей ссылкой был привязан к обычным ролям базы,
• эти роли всё ещё включали возможности управления участниками,
• и реальное долговременное состояние контроля доступа могло быть изменено из контекста публичного доступа.

---

Граница, на которой я сосредоточился

Я подошёл к этому не путём случайного зондирования конечных точек в надежде, что что-то интересное ответит.

Более эффективным путём было сначала определить границу доверия с наибольшей ценностью.

Для NocoDB это была граница между:

• доступом к общей базе
• и аутентифицированным членством в базе

Эти два состояния не должны быть взаимозаменяемыми.

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

Именно эта граница и была нарушена.

---

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

Уязвимость возникла из-за того, как доступ к общей базе был интегрирован в обычный путь ACL.

В клиентской части для общей базы вставлялся xc-shared-base-id, при этом обычные заголовки аутентификации удалялись.

Затем на серверной стороне BaseViewStrategy принимал xc-shared-base-id и напрямую преобразовывал общую ссылку в обычные roles / base_roles, полученные из конфигурации общей базы.

Это была первая проблема.

Вторая проблема заключалась в том, что права уровня читателя всё ещё включали действия по управлению участниками.

В слое ACL, ProjectRoles.VIEWER имел доступ к:

• baseUserList
• userInvite

Эти права защищали обычные маршруты метаданных:

• GET /api/v2/meta/bases/:baseId/users
• POST /api/v2/meta/bases/:baseId/users

Таким образом, сессия публичного доступа фактически могла обращаться к конечным точкам членства, предназначенным для реальных участников базы.

Последний шаг был в самом потоке приглашений.

BaseUsersService.userInvite() проверял силу роли, а затем создавал:

• реальную строку пользователя с invite_token
• реальную строку членства в базе для целевой базы

А для сессий общей базы:

• invited_by становился null

потому что за запросом не было реальной аутентифицированной личности приглашающего.

Это и есть вся цепочка ошибок.

Почему это эксплуатируемо

Потому что обладания ссылкой на общую базу было достаточно.

Злоумышленнику не требовалось:

• xc-auth
• предварительно созданная учётная запись
• украденные учётные данные
• или предварительное членство в базе

Цепочка эксплуатации была прямолинейной:

• злоумышленник получает UUID общей базы
• UUID принимается как субъект-читатель базы
• ACL читателя открывает конечные точки управления участниками
• злоумышленник перечисляет текущих участников базы
• злоумышленник приглашает произвольный email-адрес
• приглашённый пользователь активирует токен через обычный процесс регистрации
• новая учётная запись становится реальным аутентифицированным участником базы
• владелец позже отключает общую ссылку
• приглашённая учётная запись всё равно сохраняет обычный аутентифицированный доступ

Это преобразует отзываемый общий доступ в постоянное членство.

---

Почему это проблема безопасности, а не просто странное поведение общего доступа

Важное различие — сохранение доступа после отзыва.

Это не было просто:

«читатель мог вызвать конечную точку читателя»

Уязвимым субъектом был не обычный аутентифицированный читатель.

Это была сессия публичного доступа.

Это важно, потому что приложение считало временный субъект, ограниченный ссылкой, достаточно доверенным для того, чтобы:

• перечислять реальных участников,
• изменять состояние контроля доступа,
• и создавать новых долговременных субъектов внутри базы

Настоящий вопрос был не в том:

«Может ли общий пользователь читать общие данные?»

Настоящий вопрос был в том:

«Может ли публичный доступ быть преобразован в постоянный аутентифицированный доступ, который переживёт отзыв общего доступа?»

Ответ был «да».

Вот почему это реальная уязвимость авторизации, а не просто удивительное поведение приложения.

---

PoC

Я проверил это локально на версии:

• продукт: 0.301.3
• коммит: dac49b0122c5ee655fb8f46a1b6e42dfeec1f3ad
• базовый URL: http://127.0.0.1:8080

Воспроизведение было простым.

Сначала я вошёл как обычная учётная запись владельца, создал новую базу, создал таблицу и включил общий доступ к базе с ролью viewer:

PATCH /api/v2/meta/bases/<baseId>/shared
Content-Type: application/json

{
  "roles": "viewer"
}

Это вернуло UUID общей базы.