.unsec

Broadcom закрыла две опасные уязвимости в VMware Workstation и Fusion. CVE-2026-59346 получила оценку CVSS 9.3. Уязвимость в VMXNET3 позволяет пользователю с административными правами внутри виртуальной машины выполнить произвольный код на хостовой системе. Вторая уязвимость CVE-2026-59347 с CVSS 8.1 связана с переполнением буфера в HGFS и также позволяет выполнить код в контексте процесса VMX на хосте. Проблемы затрагивают VMware Workstation и Fusion 25H2 и 26H1. Исправления выпущены в версиях 26H1u1.

KindaRails2Shell: критическая уязвимость в Ruby on Rails затронула Active Storage В Ruby on Rails обнаружена критическая уязвимость CVE-2026-66066, получившая название KindaRails2Shell. Проблема находится в механизме обработки загружаемых файлов через Active Storage и при определённых условиях позволяет удалённому неаутентифицированному атакующему перейти от загрузки специально сформированного файла к чтению произвольных файлов на сервере, а затем — к RCE. CVSS: 9.5 / Critical. Уязвимый сценарий связан с использованием libvips в качестве процессора изображений. Для приложений, использующих defaults Rails 7.0+, vips является стандартным процессором Active Storage. Приложение находится в зоне риска, если принимает изображения от недоверенных пользователей и использует уязвимую версию Active Storage. Технически проблема интересна тем, что обычная загрузка файла превращается в цепочку: upload → Active Storage → libvips → parser confusion → arbitrary file read → secrets → RCE. Active Storage передавал пользовательский файл в libvips, не блокируя операции, которые сам libvips считает небезопасными для недоверенного контента. Специально сформированный файл может добраться до одного из таких loaders и заставить backend прочитать данные из другого файла на файловой системе. Особенно опасная цель — окружение Rails-процесса: /proc/self/environ, из него потенциально могут быть извлечены: • SECRET_KEY_BASE • RAILS_MASTER_KEY • credentials БД • ключи S3/GCS/Azure • API-токены сторонних сервисов Получение secret_key_base резко меняет модель угроз: атакующий получает возможность создавать валидно подписанные Rails-объекты. Исследователи показали цепочку, в которой компрометация signing material позволяет эскалировать arbitrary file read до выполнения кода в контексте Rails-процесса.

Критическая уязвимость CVE-2026-18963 в Keycloak позволяет захватывать аккаунты без авторизации В Keycloak обнаружена критическая уязвимость CVE-2026-18963, позволяющая удалённому неаутентифицированному атакующему обойти проверку при восстановлении пароля и установить новые учётные данные для выбранного пользователя. В успешном сценарии атака приводит к полному захвату учётной записи (Account Takeover) без знания текущего пароля и без взаимодействия с владельцем аккаунта. Red Hat оценила уязвимость в 9,1 балла по CVSS 3.1 — Critical. Уязвимость была опубликована Red Hat 17 августа 2026 года, а 18 августа появилась в NVD. Проблема относится к классу CWE-640 — Weak Password Recovery Mechanism for Forgotten Password и затрагивает компонент keycloak-services, отвечающий за ключевую логику управления идентификацией и доступом. Как работает уязвимость Проблема находится в authentication flow reset-credentials, используемом Keycloak для восстановления доступа к аккаунту. В штатном сценарии пользователь инициирует сброс пароля, после чего Keycloak отправляет на его электронную почту ссылку с action token. Только переход по этой ссылке должен разрешать продолжить процедуру и задать новый пароль. При CVE-2026-18963 состояние authentication session проверялось недостаточно строго. В результате специально сформированный запрос позволял атакующему обойти обязательную проверку action token и перевести сессию восстановления непосредственно к этапу изменения пароля. Red Hat указывает, что для эксплуатации не требуется предварительная аутентификация или какое-либо действие со стороны жертвы. Таким образом, при наличии доступного извне интерфейса Keycloak злоумышленник потенциально может инициировать процедуру восстановления для известной ему учётной записи, обойти подтверждение через электронную почту и назначить собственный пароль. Особую опасность представляет возможность атаки на привилегированные и административные аккаунты. CVSS-вектор уязвимости: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N То есть атака выполняется удалённо по сети, имеет низкую сложность, не требует привилегий и не требует взаимодействия пользователя. Воздействие на конфиденциальность и целостность данных оценивается как высокое. Какие версии исправлены В upstream Keycloak исправление привязано как минимум к веткам 26.4.15, 26.6.6 и 26.7.2. Релиз Keycloak 26.7.2 прямо включает CVE-2026-18963 в перечень устранённых проблем. Red Hat также выпустила обновлённые пакеты для Red Hat Build of Keycloak 26.4 и 26.6. Исправление меняет обработку состояния authentication flow: состояние экрана выбора теперь связывается с конкретным execution ID, а операция отправки/обработки reset-credential требует корректной идентификации пользователя из action token. Разработчики также добавили регрессионный тест для сценария обхода процедуры восстановления. Что делать администраторам Организациям, использующим Keycloak, рекомендуется в приоритетном порядке: определить версии всех доступных извне экземпляров Keycloak и обновить их до исправленных релизов; если обновление невозможно немедленно — временно отключить функцию Forgot password во всех realm; проверить журналы аутентификации и изменения credentials за период потенциальной уязвимости; отдельно проверить сбросы паролей административных и других привилегированных учётных записей; при наличии признаков подозрительного сброса считать учётную запись потенциально скомпрометированной и анализировать последующую активность пользователя. Отключение функции самостоятельного восстановления пароля Red Hat рассматривает как временную меру, если оперативное обновление выполнить невозможно. В открытом доступе уже появились материалы для поиска следов возможной эксплуатации CVE-2026-18963 в базе Keycloak. В частности, исследователи предлагают сопоставлять события изменения credentials с событиями отправки reset-password и дополнительно анализировать reverse proxy/ingress logs вокруг времени подозрительных изменений пароля. При этом отсутствие таких событий в журналах само по себе не доказывает отсутствие компрометации, особенно если аудит был от

США запускают программу привлечения частных компаний к наступательным кибероперациям Администрация Белого дома утвердила механизм передачи полномочий по проведению активных действий в киберпространстве частному сектору. Министерство внутренней безопасности и Минюст получили указание в течение 60 дней разработать регламент, позволяющий верифицированным IT-компаниям легально взламывать инфраструктуру транснациональных преступных группировок. Для участия в программе подрядчики должны пройти строгую проверку персонала и технических компетенций, а также внести невозвратный залог в размере одного миллиона долларов на случай нарушений или непреднамеренного ущерба. Каждая операция требует индивидуального письменного согласования с федеральными кураторами. Под прямым запретом находятся действия, способные привести к человеческим жертвам или квалифицируемые как акт войны по нормам международного права. Компании получат карт-бланш на шпионаж и саботаж систем злоумышленников, однако обязаны немедленно прекращать работу при обнаружении связи цели с государственными структурами других стран или при случайном затрагивании американских информационных систем. Инициатива направлена на борьбу с киберпреступностью, наносящей экономике США ущерб в десятки миллиардов долларов ежегодно, но сопряжена с высокими юридическими рисками для исполнителей.

35 лет назад Николай Безруков, один из пионеров советской компьютерной вирусологии из Киева, предполагал, что вирусы, разработанные военными и спецслужбами, вряд ли попадут на гражданские компьютеры, поскольку будут использоваться только против конкретных целей. Однако этот прогноз не оправдался. Безруков недооценил масштабы компьютеризации, распространения компьютерных сетей и интернета. Гражданские компьютеры могут и сами по себе быть интересной целью для шпионажа или саботажа, и служить входной точкой в более защищённые системы, и, конечно, становиться случайной жертвой, если атакующие не предприняли достаточных мер, чтобы обеспечить избирательность (Stuxnet, NotPetya и множество других примеров).

Новости последней недели.

Агенты вышли из песочницы: ИИ начал атаковать реальные системы Недавние инциденты с моделями OpenAI и Anthropic показали, что автономные ИИ-агенты уже способны случайно перейти от лабораторного тестирования к атакам на реальную инфраструктуру. Речь не идёт о «восстании машин»: модели продолжали выполнять поставленные задачи, но оказались в неправильно изолированной среде и приняли доступные внешние системы за часть учебного полигона. Атака на Hugging Face В июле 2026 года Hugging Face сообщил о проникновении в часть производственной инфраструктуры. Первоначальный доступ был получен через вредоносный датасет, который использовал два механизма выполнения кода в конвейере обработки данных. После закрепления атакующая система повысила привилегии, получила облачные и кластерные учётные данные и переместилась между несколькими внутренними кластерами. По данным Hugging Face, кампания выполнялась автономным агентским фреймворком: тысячи действий запускались параллельно в короткоживущих песочницах, а управляющая инфраструктура переносилась между публичными сервисами. Всего при расследовании было проанализировано более 17 тысяч событий. Инцидент показал главное преимущество агентской атаки — способность действовать непрерывно и адаптироваться к результатам каждого шага. Агент может самостоятельно искать новые точки входа, собирать секреты, менять стратегию и продолжать движение по инфраструктуре без постоянного участия оператора. Claude атакует реальный интернет После публикации информации об инциденте Anthropic проверил 141 006 запусков собственных кибербезопасностных тестов. Компания обнаружила три случая, когда модели Claude получили доступ к интернету из неправильно настроенного тестового окружения и скомпрометировали инфраструктуру реальных организаций. В одном случае модель нашла реальную компанию с тем же именем, что и вымышленная цель задания, извлекла учётные данные и получила доступ к базе с несколькими сотнями производственных записей. Более старая версия Claude продолжила атаку даже после появления признаков того, что система могла быть настоящей. В другом сценарии агент провёл полноценную атаку через цепочку поставки. Он обнаружил в документации имя несуществующего Python-пакета, зарегистрировал учётную запись и опубликовал вредоносный пакет в реальном PyPI. За час пакет был запущен на 15 системах. На одной из них код похитил учётные данные, которые агент затем использовал для дальнейшего проникновения. В третьем случае модель просканировала около девяти тысяч доступных узлов, нашла открытые отладочные данные и SQL-инъекцию и получила доступ к интернет-приложению реальной компании. Атака прекратилась только после того, как модель самостоятельно определила, что найденный облачный аккаунт не относится к учебному заданию. Почему это произошло Модели не пытались «сбежать» и не формировали собственную цель. Они выполняли команды capture-the-flag, но получили неверное представление об окружающей среде. В системных инструкциях говорилось, что доступ к интернету отсутствует, хотя из-за ошибки конфигурации он был открыт. Поэтому реальные серверы, домены и реестры пакетов воспринимались агентами как элементы симуляции. Проблема оказалась не только в поведении моделей, но и в архитектуре испытательного контура: • отсутствие жёсткой сетевой изоляции; • недостаточный контроль исходящего трафика; • неограниченная область поиска цели; • отсутствие оперативного анализа действий агента; • запуск моделей без стандартных защитных классификаторов; • недостаточный аудит инфраструктуры внешнего подрядчика. Новая модель угроз Эти инциденты показывают, что сам агент становится самостоятельным источником киберриска. Даже без доступа к внутренним данным он может обнаружить выход в интернет, зарегистрировать внешние аккаунты, публиковать код, сканировать тысячи систем и строить многошаговые цепочки проникновения.

Обнаружены 84 уязвимости в ядрах мобильных сетей 4G и 5G Исследователи из Наньянского технологического университета представили iFinder — многоагентную систему на базе больших языковых моделей, предназначенную для поиска уязвимостей в программном обеспечении операторских сетей. Авторы изучили внутренние протоколы PFCP и GTP-C, используемые для управления сессиями и передачей трафика в ядрах мобильных сетей. Анализ семи популярных открытых реализаций позволил обнаружить 84 ранее неизвестные уязвимости. Разработчики подтвердили 83 из них, а 81 проблема уже получила идентификатор CVE. Основной причиной ошибок исследователи называют неявное доверие между компонентами сети. Исторически внутренние интерфейсы операторской инфраструктуры считались изолированными, поэтому разработчики нередко пропускали проверку структуры сообщений, логических ограничений и доступности ресурсов. После переноса сетевых функций в облачную среду такие интерфейсы могут оказаться доступны злоумышленникам. iFinder состоит из нескольких агентов. Первый ищет потенциально опасные участки кода, второй сопоставляет их со спецификациями 3GPP и отсеивает ложные срабатывания, а третий автоматически создаёт и дорабатывает Proof-of-Concept для проверки найденной уязвимости на тестовом стенде. Такой подход повысил точность обнаружения уязвимостей с 28,2 процента у базового варианта до 75 процентов. Система смогла создать рабочие PoC для 19 из 22 известных тестовых уязвимостей, тогда как обычный запрос к языковой модели справился только с восемью. Наиболее опасная обнаруженная ошибка позволяет перехватывать пользовательские сессии. Атакующий может внедрить поддельное правило маршрутизации в UPF, после чего исходящий трафик абонента направляется не в интернет, а на узел злоумышленника. Исследователи подтвердили эту атаку на двух коммерческих ядрах 5G.

CVE-2026-42533: переполнение буфера в NGINX при обработке `map` и регулярных выражений В NGINX Open Source и NGINX Plus устранена уязвимость типа heap-based buffer overflow — CWE-122. Ошибка находится в механизме вычисления complex values, используемом директивой map при сопоставлении по регулярному выражению. CVSS v4.0 — 9.2 Critical, CVSS v3.1 — 8.1 High. Уязвимая конфигурация возникает, когда: • map выполняет regex-сопоставление; • строковое выражение обращается к capture-переменным регулярного выражения до обращения к выходной переменной map; • либо в выражении используется non-cacheable переменная, длина которой может измениться во время обработки запроса. NGINX script engine обрабатывает такие выражения в несколько проходов: сначала вычисляет размер результирующего буфера, затем копирует значения переменных. Regex-сопоставление или повторное вычисление переменной может изменить состояние capture-групп между этими операциями. В результате размер, рассчитанный на первом проходе, оказывается меньше объёма данных, записываемого на втором, что приводит к записи за границы heap-буфера. Исправление добавляет указатель конца буфера e->end и проверку ngx_http_script_check_length() перед операциями копирования. Эксплуатация выполняется удалённо без аутентификации с помощью специально сформированного HTTP-запроса, однако требует наличия подходящей конфигурации NGINX. Переполнение происходит в worker-процессе и может вызвать его аварийное завершение и перезапуск, создавая отказ в обслуживании. Выполнение произвольного кода возможно на системах с отключённым ASLR либо при наличии способа обхода ASLR. Уязвимость относится к data plane и не предоставляет прямого доступа к control plane. Затронутые версии: • NGINX Open Source: 0.9.6–1.31.2; • NGINX Plus: R33–R36, а также 37.0.0.1–37.0.2.1. Исправленные версии: • NGINX stable: 1.30.4; • NGINX mainline: 1.31.3; • NGINX Plus R36: R36 P7; • NGINX Plus R37: 37.0.3.1. Основная мера устранения — обновление до исправленной версии. Для временного снижения риска F5 рекомендует исключить безымянные capture-группы, использовать уникальные именованные capture-переменные только внутри блока с соответствующим regex-сопоставлением и не переиспользовать одинаковые именованные capture-переменные в разных директивах. Конфигурацию следует проверять по полному выводу nginx -T, включая подключаемые файлы и автоматически сгенерированные конфигурации.

Zero-click arbitrary command execution in Telegram Desktop and iOS app PoC крашит Telegram Desktop, для нейтрализации влияния на приложение необходимо зайти с мобильного и удалить чат. Проверить здесь (на свой страх и риск): http://t.me/kimifuckingbot

CCS2-разъём электромобиля как точка входа в сеть зарядной станции Исследователи SaiFlow обнаружили уязвимость в зарядных станциях XCharge C6: подключённое к CCS2 устройство может получить доступ к административным сервисам станции через канал Power Line Communication. При подключении автомобиля зарядная станция формирует IPv6-соединение поверх HomePlug Green PHY. Этот канал используется протоколами V2G, включая ISO 15118 и DIN 70121. Однако на исследованном устройстве через PLC-интерфейсы qca0 и qca1 были доступны не только V2G-сервисы, но также: • SSH/Dropbear на TCP/22; • Telnet/BusyBox на TCP/23; • учётная запись root с паролем root; • вход без rate limiting и блокировки после неудачных попыток. Административные сервисы привязаны к 0.0.0.0 или [::], то есть принимают соединения на всех интерфейсах, включая доступные со стороны CCS2. В результате зарядный разъём фактически работает как незащищённый сетевой порт. Для эксплуатации не требуется полноценный электромобиль. Достаточно контроллера Control Pilot, PLC-модема с поддержкой HomePlug Green PHY и одноплатного компьютера. По оценке исследователей, комплект оборудования может стоить около $130. Получив root-доступ, атакующий потенциально может: • изменить параметры зарядки и учёта энергии; • извлечь сертификат SECC для атак на Plug & Charge; • закрепиться в системе через init-скрипты или cron; • вывести зарядную станцию из строя; • воздействовать на механизмы охлаждения и ограничения мощности; • использовать станцию как точку входа в инфраструктуру оператора через VPN или Private APN. Проблема не ограничивается слабым паролем. Даже после его замены SSH и Telnet останутся доступны через недоверенный физический интерфейс. Новая уязвимость в этих сервисах может сформировать уже безаутентификационный сценарий компрометации.

431 CVE в Linux опубликована 19 июля. Много? Много. ИИ инструментарий, фаззеры, литеры, SAST и DAST анализ переживают золотое время, что сказывается на количестве находок. https://lists.openwall.net/linux-cve-announce/2026/07/19/

wp2shell-уязвимость Две SQLi обнаружены в WordPress. Они не требуют авторизации и работают без установленных плагинов, даже на стоковых версиях Уязвимы: — 6.9.0 - 6.9.4 — 7.0.0 - 7.0.1 Более того, уязвимости позволяют добиться RCE: a) если есть file_priv и secure_file_priv points на директорию с wp, можно записать произвольный php-файл на fs b) сбрутить хэш админа и залить шелл из админки Фикс 7.0.2 выпустили только вчера, поэтому в интернете находится много уязвимых инстансов, которые не успели обновить.

Context bombs: защита инфраструктуры от автономных AI-агентов Tracebit описали технику context bomb — размещение специальных текстовых payload’ов внутри облачных ресурсов, которые с высокой вероятностью будут прочитаны атакующим AI-агентом. Механизм основан на том, что автономный агент передаёт содержимое найденных секретов, конфигураций и метаданных в контекст языковой модели. Если внутри ресурса находится текст, активирующий safety-механизмы модели, она может отказаться выполнять дальнейшие действия. Раньше такой детект реализовывался с помощью Canary tokens/honeypot или решений класса Distributed Deception Platform/Threat Deception Platform. Типовой сценарий: Агент получает доступ к AWS-аккаунту. Перебирает IAM-роли, Secrets Manager, Parameter Store и другие ресурсы. Находит подставной секрет. Содержимое секрета попадает в контекст модели. Модель блокирует дальнейшее выполнение задачи. Чтение ресурса одновременно используется как сигнал компрометации. Сontext bomb объединяет две функции: • detection — фиксирует доступ к приманке; • disruption — пытается остановить или нарушить работу атакующего агента. В эксперименте Tracebit использовался симулированный AWS-аккаунт примерно с 300 ресурсами и 10 возможными attack path. Всего авторы провели 152 запуска на пяти моделях. По их данным, добавление одного подставного секрета с context bomb снизило: • получение административных прав — с 57% до 5%; • полную компрометацию с persistence — с 36% до 1%; • успешное прохождение хотя бы одного attack path — с 91% до 15%. Для наиболее эффективного агента вероятность получения admin-доступа снизилась с 93% до 0%. При этом эффективность payload зависит от конкретной модели и её safety-настроек. Разные семейства моделей реагировали на разные категории контента. Поэтому универсального payload, работающего одинаково против всех агентов, нет. Ограничения подхода: • агент может предварительно фильтровать содержимое ресурсов; • злоумышленник может использовать модель без стандартных safety-ограничений; • payload можно обнаружить по сигнатурам; • модель или агентный фреймворк могут быть настроены на игнорирование данных из недоверенных источников; • некорректно размещённая context bomb может повлиять на легитимные AI-системы; • результаты пока основаны на экспериментальной среде и требуют независимого воспроизведения. Практически context bombs можно рассматривать как развитие honeytokens для среды, где атакующий использует LLM-агентов. Защита воздействует не только на инфраструктурный уровень, но и на контекст, который модель использует для планирования следующих действий.

Выпуск Patch Tuesday стал крупнейшим за всю историю ежемесячных обновлений Microsoft. Среди исправленных проблем 59 получили статус критических. Больше всего обнаружили уязвимостей, позволяющих повысить привилегии, – таких оказалось 254. Еще 145 могли привести к удаленному выполнению кода; 102 раскрывали конфиденциальные данные; 35 вызывали отказ в обслуживании; 17 позволяли обходить защитные механизмы; 16 открывали возможности для подмены данных. В статистику не вошли исправления для отдельных облачных сервисов Microsoft и браузера Edge, выпущенные ранее в июле. В этом месяце в рамках обновления Patch Tuesday исправлены три уязвимости нулевого дня, две из которых использовались в атаках, а одна была публично раскрыта: CVE-2026-56155 — Уязвимость повышения привилегий в службах федерации Active Directory. CVE-2026-56164 — Уязвимость повышения привилегий в Microsoft SharePoint Server. Публично обнародованная уязвимость нулевого дня, которая была исправлена: CVE-2026-50661 — Уязвимость, позволяющая обойти функцию безопасности BitLocker в Windows.

Черногорский регулятор отозвал домен Telegram Главный домен, используемый для ссылок на Telegram в веб-версии "t.me" был отозван техническим регулятором домена .me (национальный домен Черногории). Теперь ссылки вида https://t.me/durov или durov.t.me не открываются в браузере. При этом в клиентах Telegram ссылки продолжают работу 😙 Причины отзыва пока неизвестны. Пока рабочая замена сломанных ссылок: https://telegram.me/*

Тут такое дело. Оператор реестра .me исключил из зоны домен t.me. Что это означает: - Обычные ссылки https://t.me/... перестанут открываться по мере истечения DNS-кэшей. - То же касается адресов вида username.t.me. - Могут перестать работать приглашения, веб-просмотр каналов, ссылки на ботов, авторизацию и предварительный просмотр ссылок. - Сам мессенджер, вероятно, продолжит работать: его основные соединения не зависят исключительно от t.me. Ссылки внутри мессенджера и в мобильных приложениях продолжать открываться, потому что они открывают приложение. Почему так? Я не знаю. Но вообще тема с доменами бесправная. ICANN занят продажами и сомнительного правового качества решениями. А регулированием и арбитражем вообще никто не занимается. Кто как хочет, так и вертит

HARICA vs Bugzilla 21 июня в системе отслеживания ошибок Bugzilla пользователем "Iakov, son of Isaac" был заведен трек "HARICA: Продолжается выдача и отказ в аннулировании сертификатов TLS для организаций, находящихся под санкциями ЕС". В адрес HARICA были направлены уведомления о нарушении санкционного режима ЕС, на что греческий УЦ ответил отказом и заявил, что:

"Все выданные сертификаты являются сертификатами с проверкой домена (DV). Как таковые, они содержат исключительно информацию, относящуюся к данному домену, без указания какого-либо физического или юридического лица. Для выдачи таких сертификатов не требуется дополнительная проверка нашей стороны"

УЦ подчеркнул, что готов отозвать сертификаты только по официальному запросу компетентных органов. Обращенцы в комментариях продолжают настаивать: 🔹Регламент ЕС № 269/2014 запрещает предоставление экономических ресурсов подсанкционным лицам. Услуги УЦ являются таковым ресурсом. 🔹Многие из доменов напрямую упоминаются в санкционных документах. 🔹Другие УЦ (Let's Encrypt, GlobalSign, Actalis) отозвали сертификаты после аналогичных уведомлений. HARICA заняла твёрдую позицию: 🔹DV-сертификаты проверяют только контроль над доменом, а не организацию-владельца. 🔹Автоматизированная система выдачи сертификатов не включает проверку по санкционным спискам. 🔹Проверка по санкционным спискам проводится только в том случае, если клиент запрашивает бизнес-счет (invoice) на юридическое лицо. Если же клиент оплачивает как физическое лицо и получает обычный чек, проверка не проводится. 🔹Отзыв будет произведен только по требованию регулирующих органов. Обращенцы не унимаются и сообщают о направленных жалобах в: 🔹ETSI-аудитора HARICA (QMSCERT); 🔹Национальный регулятор Греции (EETT); 🔹ACM и Греческую университетскую сеть (GUnet). Мы с вами наблюдаем фундаментальное столкновение технических стандартов и юридических норм ЕС. HARICA использует технологическую особенность DV-сертификатов, как щит для уклонения от санкционных обязательств. Итоговое решение по инциденту может определить важный прецедент: должны ли УЦ нести ответственность за конечных получателей своих услуг, даже если их технические процессы не требуют прямой проверки личности? 🚀Об ЭП и УЦ