Root cause

В админ-панели emlog pro есть ИИ-ассистент, который может выполнять SQL от имени администратора через POST /admin/ai.php?action=execute_tool. В этой единственной конечной точке сходится несколько проблем:

1. Нет CSRF-токена. Все остальные файлы деструктивных действий в admin/ сначала вызывают LoginAuth::checkToken() (например, admin/media.php:140). admin/ai.php — никогда.
2. Аутентификация только по session-cookie (admin/ai.php:152, User::isAdmin()) — никакой проверки Origin/Referer.
3. Ворота подтверждения записи — жёстко заданная публичная строка. include/service/ai.php:594: if (trim($confirm_code) !== 'confirm'). Любой поддельный запрос просто отправляет confirm_code=confirm.
4. Для SQL только на чтение подтверждение вообще не требуется (include/service/ai.php:578,589) — голый аутентифицированный запрос может выполнить SELECT из любой таблицы.
5. От записи защищена только таблица blog (include/service/ai.php:591) — user и все остальные таблицы полностью доступны для записи.
6. Маскирование паролей обходится через алиасы. Маскирование сопоставляется только с буквальным именем выходного столбца password (include/service/ai.php:822-828) — SELECT password AS pwd_hash FROM user возвращает исходный хеш.
7. У auth-cookie нет атрибута SameSite (include/lib/loginauth.php:99), поэтому между этой уязвимостью и надёжной межсайтовой доставкой остаётся лишь стандартное окно Chrome "Lax+POST" (примерно первые две минуты после входа).

Совместно: один поддельный запрос из браузера администратора читает все таблицы (включая хеши паролей) и пишет во все таблицы, кроме blog, включая прямую перезапись user.password.

PoC

Part 1 — raw impact chain (poc_raw_impact.sh)

Изолирует примитив SQL/обхода аутентификации от вопроса доставки CSRF. Запускайте на локальном экземпляре, которым управляете:

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

Part 2 — real cross-site CSRF delivery (poc_csrf.html)

Решает вопрос SameSite с помощью живого браузера, а не предположений. Разместите poc_csrf.html в любом origin, отличном от целевого (достаточно другого IP — Chrome считает разные буквальные IP отдельными сайтами), и добейтесь, чтобы вошедший администратор открыл его в течение примерно двух минут после входа:

Форма автоматически отправляется при загрузке, выполняя межсайтовый POST-запрос поддельного вызова query_database с confirm_code=confirm.

Проверено вживую: поддельный межсайтовый POST-запрос передал настоящий auth-cookie администратора (sec-fetch-site: cross-site, cookie прикреплён), вернул 200 {"code":0,"msg":"ok",...}, а наличие внедрённой строки было подтверждено последующим аутентифицированным чтением. Повторение того же запроса примерно через 48 минут с тем же, уже состарившимся cookie-хранилищем не удалось — cookie не был прикреплён, и сервер вернул редирект на аутентификацию, что подтверждает: примерно двухминутное окно Lax+POST — это реальное ограничение (отражено в AC:H).

Impact

• Полное чтение базы данных: каждая таблица/столбец, включая хеши паролей и любые секреты в emlog_options (учётные данные SMTP, ключи API и т.д.).
• Полная запись в базу данных во все таблицы, кроме blog, включая user — перезапись роли/пароля/email, продемонстрированная целиком как захват учётной записи.
• Ограничено учётными записями с role=admin; writer/editor блокируются User::checkRolePermission(). Это не повышение привилегий с более низкой роли — один вредоносный клик по ссылке вошедшим администратором превращается в полную и незаметную компрометацию сайта.

Fix

Добавьте вызов LoginAuth::checkToken() в execute_tool, установите SameSite=Strict для auth-cookie и замените статическую строку confirm_code на настоящий одноразовый токен, действующий для конкретной сессии. Полные детали устранения — в рекомендации.

Disclosure timeline

• 2026-07-31 — Сообщено через GitHub Security Advisories в соответствии с собственным SECURITY.md проекта emlog.
• 2026-08-01 — Мейнтейнер опубликовал рекомендацию и запросил CVE.
• 2026-08-16 — CVE-2026-73847 присвоен GitHub (CNA).

Примечание об авторстве: GitHub как CNA опубликовал запись CVE без поля credits, несмотря на то что сам GHSA указывает автора и принял отчёт. Запрос на исправление был отправлен на [email protected] 16.08.2026; этот README будет обновлён, если запись исправят.

Disclaimer

Опубликовано после того, как рекомендация стала публичной и был присвоен CVE, для защитных/образовательных целей. Не запускайте это против экземпляра emlog, которым вы не владеете или на тестирование которого у вас нет явного разрешения.