CVE-2026-95835 in Kitty
Сводка
по VulDB • 25.09.2026
Отсутствие проверки авторизации в обработчике кода эскейпа askpass в kitty (версии от 0.25.0 до 0.49.0) позволяет локальному пользователю, отличному от того, под которым запущен терминал, получить доступ к тексту, введенному в приглашение, которое отображает сама kitty. Это происходит потому, что функция handle_remote_askpass() в файле kitty/window.py открывает объект POSIX shared memory с именем из кода эскейпа, парсит определение приглашения из него и записывает ответ пользователя обратно в объект того же имени, не проверяя ни то, что объект принадлежит пользователю, запустившему kitty, ни то, что его права доступа исключают доступ других пользователей. Эквивалентный потребитель того же класса SharedMemory в ssh kitten выполняет такую проверку; путь askpass этого не делал. Обработчик вызывается через строку управления устройством (device control string), обрабатываемую из байтового потока окна, поэтому атакующий также должен заставить терминал жертвы отобразить выбранные им байты. В том случае, когда пространство имен POSIX shared memory совместно используется обоими пользователями, второй локальный пользователь может создать объект с правами доступа, позволяющими жертве читать и записывать в него данные, заставить kitty жертвы отрисовать приглашение по выбору атакующего (включая маску для ввода пароля) и после этого прочитать введенный секрет из объекта. Текст приглашения дополнительно передается на дисплей без санитизации управляющих символов, поэтому он может перезаписать предупреждающую строку, которую kitty выводит над ним. Ответ записывается путем повторного открытия объекта с тем же именем при ответе пользователя, а не через уже открытый дескриптор. Это приводит к раскрытию секрета, введенного жертвой, второму локальному пользователю и не требует никаких привилегий на учетной записи жертвы.
If you want to get best quality of vulnerability data, you may have to visit VulDB.