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 общей базы.

Затем, не отправляя xc-auth, я использовал только:

xc-shared-base-id: <sharedBaseUuid>

Используя только этот заголовок, я вызвал:

GET /api/v2/meta/bases/<baseId>/users

Это вернуло 200 OK и раскрыло реальных участников базы, включая адреса электронной почты.

Всё ещё используя только xc-shared-base-id, я вызвал:

POST /api/v2/meta/bases/<baseId>/users
Content-Type: application/json

{
  "email": "[email protected]",
  "roles": "viewer"
}

Это также вернуло 200 OK.

Для локальной проверки в лаборатории без доставки почты я подтвердил напрямую в мета-базе SQLite, что:

• nc_users_v2 содержал приглашённого пользователя с непустым invite_token
• nc_base_users_v2 содержал реальную строку членства для целевой базы
• invited_by был NULL

Затем я активировал приглашение через обычный процесс регистрации:

POST /api/v2/auth/user/signup
Content-Type: application/json

{
  "email": "[email protected]",
  "password": "Password123.",
  "token": "<invite_token>"
}

Используя возвращённый xc-auth, я вызвал:

GET /api/v2/meta/bases/<baseId>/tables

Это вернуло 200 OK.

Наконец, как владелец, я отключил общую ссылку:

DELETE /api/v2/meta/bases/<baseId>/shared

После этого:

• доступ по общей ссылке с xc-shared-base-id завершился с ошибкой 401
• приглашённая учётная запись, использующая обычный xc-auth, всё ещё успешно получала 200

Наблюдаемые результаты

• список пользователей общих ссылок: 200
• приглашение общих ссылок: 200
• регистрация: 200
• доступ к таблицам приглашённого аутентифицированного пользователя до отключения общей ссылки: 200
• отключение общей ссылки: 200
• доступ к таблицам по общей ссылке после отключения: 401
• доступ к таблицам приглашённого аутентифицированного пользователя после отключения: 200

Это подтвердило центральное утверждение безопасности:

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

Почему воспроизведение имеет значение

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

Но полная цепочка проверки была важна по двум причинам.

Первая

Она показала, что это не просто раскрытие конечной точки.

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

• перечислить участников
• пригласить нового субъекта
• активировать приглашение
• получить обычный аутентифицированный доступ

Вторая

Она доказала, что это не является самоотзываемым.

Более серьёзное воздействие проявилось после отключения общей ссылки:

• исходная ссылка перестала работать
• учётная запись, созданная злоумышленником, — нет

Именно это превратило временный доступ по ссылке в долговременное сохранение доступа.

Воздействие

Эта уязвимость позволяет любому, у кого есть ссылка на общую базу:

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

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

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

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

Серьёзность и классификация

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

CVSS:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N

Этот вектор соответствует основному поведению:

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

Предлагаемые меры по смягчению

Направление исправления очевидно.

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

Как минимум:

• удалить baseUserList и userInvite из любых прав, доступных через xc-shared-base-id
• явно заблокировать доступ субъектов общего/публичного доступа к конечным точкам членства базы, таким как GET и POST /api/v2/meta/bases/:baseId/users
• рассматривать доступ к общей базе как отдельный тип субъекта вместо прямого отображения на обычные права читателя базы
• добавить регрессионные тесты, проверяющие, что запросы от общих баз не могут перечислять участников, приглашать пользователей и создавать долговременный доступ, который переживает отзыв общей ссылки

Раскрытие информации

Эта проблема была проверена локально на NocoDB 0.301.3 на коммите dac49b0122c5ee655fb8f46a1b6e42dfeec1f3ad.

Отчёт демонстрировал:

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

Проблеме был присвоен идентификатор:

CVE-2026-46552

Чему на самом деле учит эта ошибка

Ключевой урок прост:

доступ по общей ссылке — это не то же самое, что доверенное членство.

Многие системы попадают в неприятности, когда объединяют эти две концепции в одной ролевой модели.

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

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

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

Вот настоящий вывод.

Ключевые моменты

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

Заключительные слова

Эта уязвимость заключалась не в полном обходе аутентификации.

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

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

Вот почему это стало CVE-2026-46552.