Выпущены исправления для трех критических уязвимостей в X.Org X server и Xwayland. Обновления xorg-server-21.1.19 и xwayland-24.1.9 исправляют проблемы, существовавшие в предыдущих версиях. Все три уязвимости (CVE-2025-62229, CVE-2025-62230 и CVE-2025-62231) были обнаружены Jan-Niklas Sohn при сотрудничестве с Trend Micro Zero Day Initiative.

Первая уязвимость связана с use-after-free при создании XPresentNotify структур, вторая - с некорректным удалением Xkb клиентских ресурсов, а третья - с переполнением значения в XkbSetCompatMap(). Две из этих проблем существуют с версии X11R6, что подчеркивает их серьезность. Все исправления уже доступны в репозиториях, и пользователям рекомендуется немедленно обновить системы для предотвращения потенциальных атак.

• В обсуждении поднимается вопрос о том, что X11/X.Org уязвим к трем недавно обнаруженным уязвимостям, и что это может быть последней каплей, которая убедит окончательно перейти на Wayland.
• Участники обсуждают, что X11 не имеет никаких механизмов безопасности, и что это не может быть исправлено без полной переработки.
• Некоторые участники высказывают мнение, что X11 устарел и что усилия по его поддержке были бы лучше направлены на другие проекты.
• Также обсуждается, что X11 не может быть защищен от вредоносного клиента, и что это не может быть исправлено без полной переработки.

Хакеры, по сообщению F5, украли исходный код и информацию о ранее неизвестных уязвимостях в BIG-IP. Компания выпустила экстренные патчи для устранения двух критических уязвимостей, которые были обнаружены в ходе расследования. Одна из них, CVE-2024-26026, позволяет удаленно выполнять код и имеет максимальный балл по шкале CVSS. Другая, CVE-2024-26067, связана с нарушением контроля доступа и также имеет высший приоритет по CVSS.

Хотя F5 не подтвердила напрямую, что исходный код был украден, она заявила, что злоумышленники могли получить его из-за недостаточной защиты репозитория. Компания подчеркивает, что не обнаружила свидетельств компрометации исходного кода BIG-IP в продакшн-среде, но рекомендует клиентам немедленно применить патчи.

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

• F5 заявил, что угроза была «национальным государством», но нет доказательств, что это не просто удобное оправдание для отсутствия надлежащего контроля доступа.
• Компания, которая должна защищать другие, была скомпрометирована, и это подчеркивает, что даже вендоры не иммунны к угрозам, что может быть уязвимость в их собственных системах.
• Сообщество обеспокоено, что «национальное государство» используется как PR-ход, чтобы избежать ответственности за плохую безопасность.
• Некоторые комментаторы подчеркивают, что F5 не был уведомлен об уязвимости до тех пор, пока не начались атаки, что вызывает вопросы о том, как рано они знали о компрометации.
• Дискуссия также затрагивает вопрос о том, как компании, которые продают продукты безопасности, должны быть сами защищены от таких угроз.

Обнаружена критическая уязвимость удалённого выполнения кода в Redis (CVE-2025-49844) с максимальным баллом CVSS 10.0. Проблема связана с ошибкой Use-After-Free, присутствующей в коде около 13 лет, которая позволяет аутентифицированному злоумышленнику выполнить произвольный код на хосте через специально сформированный Lua-скрипт.

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

• Уязвимость в Redis (CVE-2024-XXXX) позволяет выполнить произвольный код после аутентификации через уязвимость use-after-free в Lua-скриптах.
• Критичность уязвимости (CVSS 10) оспаривается, так как для эксплуатации требуется аутентификация или доступ к Lua-скриптам, что редко встречается в типичных конфигурациях.
• Проблема усугубляется большим количеством экземпляров Redis (десятки тысяч), публично доступных в интернете без настроенной аутентификации.
• Уязвимость существует в коде более десяти лет, исправлена в Redis 8.1.4 и форке Valkey, но многие системы остаются незащищенными.
• Обсуждаются проблемы безопасности по умолчанию в Docker-конфигурациях и необходимость обновления устаревшей версии Lua в проектах.

Серверные материнские платы Supermicro уязвимы для удалённой установки вредоносного ПО в прошивку базового контроллера управления (BMC), что делает заражение практически необнаружимым и неустранимым стандартными методами. Уязвимости CVE-2025-7937 и CVE-2025-6198 позволяют обходить проверки цифровых подписей и перезаписывать firmware, которая выполняется ещё до загрузки операционной системы — даже замена дисков или переустановка ОС не очистят систему.

Эксплуатация уязвимостей требует предварительного получения контроля над BMC, что возможно через ранее описанные методы. Подобные атаки могут привести к установке стойких имплантов, аналогичных ILObleed, который безвозвратно уничтожал данные на серверах HP. Особую опасность это представляет для AI-датацентров, где массовое заражение может оставаться незамеченным долгое время.

• Участники обсуждают уязвимости BMC (базовых контроллеров управления) в серверах Supermicro и других производителей, отмечая их низкое качество ПО и наличие неисправленных уязвимостей, позволяющих удалённо прошивать прошивку.
• Подчёркивается, что BMC представляет собой серьёзный вектор атаки и должен быть изолирован в отдельной физической или логической сети без прямого доступа извне.
• Обсуждаются проблемы безопасности на уровне прошивки: отсутствие проверки подписей, возможность перепрошивки из операционной системы и сложность удаления бэкдоров без физического доступа к чипу.
• Высказывается критика в адрес производителей за отсутствие документации, открытых спецификаций и поддержки открытых альтернатив, таких как OpenBMC.
• Упоминается, что проблема не нова и ранее обсуждалась в контексте спорной статьи Bloomberg о предполагаемых аппаратных закладках китайского происхождения в серверах Supermicro.

О безопасности iOS 15.8.5 и iPadOS 15.8.5

Этот документ описывает обновления безопасности для iOS 15.8.5 и iPadOS 15.8.5.

Обновления безопасности Apple

Apple не раскрывает информацию об уязвимостях до завершения расследования и выпуска исправлений. Последние обновления перечислены на странице выпусков безопасности Apple.

iOS 15.8.5 и iPadOS 15.8.5

Выпущено 15 сентября 2025 года

ImageIO

Доступно для: iPhone 6s, iPhone 7, iPhone SE (1-го поколения), iPad Air 2, iPad mini (4-го поколения) и iPod touch (7-го поколения)

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

Описание: Исправлена ошибка записи за пределами границ за счёт улучшенной проверки.

CVE-2025-43300: Apple

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

Опубликовано: 15 сентября 2025 года

• Пользователи отмечают длительную поддержку старых устройств Apple (до 10 лет) в сравнении с ограниченной поддержкой Android-устройств от Google и других производителей.
• Обсуждаются технические причины короткого цикла поддержки Android: ограничения со стороны производителей чипов (Qualcomm) и необходимость интеграции обновлений производителями телефонов.
• Выпуск обновления для устаревших моделей связывают с эксплуатацией уязвимости нулевого дня в целевых атаках государственного уровня, что подчеркивает серьезность угрозы.
• Уточняется, что обновление доступно для широкого списка старых устройств (iPhone 6s, 7, SE, iPad Air 2 и др.), а не только для 10-летнего iPhone 6s.
• Поднимается вопрос о практической пользе обновления для пользователей очень старых устройств, которые могут не устанавливать патчи.
• Отмечается, что современные Android-производители (Google, Samsung) увеличили承诺 срок поддержки до 5-7 лет, что приближается к политике Apple.
• Обсуждается техническая сторона уязвимости: возможность удаленного выполнения кода (RCE) через обработку malicious изображения, часто в связке с уязвимостью в WhatsApp.

• curl: 180 тыс. строк, 1,4 тыс. авторов, 20–25 активных в месяц, один зарплатный разработчик — сам Стенберг.
• Используют 47 брендов авто; спонсоров — 0.
• Компании требуют поддержку, аудиты, соответствие CRA, шлют угрозы «I will slaughter you».
• LLM-боты сыплют ложными баг-репортами, ИИ-скраперы ддосят сайт: 99,99 % трафика — боты.
• Поддержка = одному человеку: безопасность, документация, инфраструктура, иногда фичи.
• Письмо 11-летнего ребёнка — единственное тёплое «спасибо».

• Компании хотят платить за OSS, но бюрократия, налоги и отсутствие «адреса» делают это почти невозможным.
• Поток фейковых «AI-уязвимостей» превратился в охоту за CVE ради резюме и баг-баунти, отнимая время у maintainer’ов.
• curl получил 200 тыс. € от немецкого Sovereign Tech Agency — редкий пример гос-финансирования.
• Утопичная идея «AGPL-шантажа» и GoFundMe мгновенно оборачивается форком и потерей сообщества.
• Нет единого «клоут-индекса» библиотек: кто действительно критичен — видно только изнутри.

• CVE-2025-53136 – утечка адреса ядра Windows 24H2+ через NtQuerySystemInformation(SystemTokenInformation).
• Появилась после неудачного патча CVE-2024-43511: в RtlSidHashInitialize() ядро кладёт указатель на TOKEN→UserAndGroups в пользовательский буфер, и за короткий промежуток его можно считать.
• Уязвимость доступна из Low IL / AppContainer; при победе в гонке выдаёт надёжный KASLR bypass.
• Эксплойт: два потока – один циклично вызывает syscall, второй читает буфер; адрес токена утечёт почти всегда.
• Цепляется с write-what-where → LPE.

• KASLR на x86 считается «мертв» даже с KPTI: EntryBleed и prefetch-эксплойты работают на новых Intel/AMD.
• Утечка через SystemTokenInformation (Win11 24H2) даёт адрес ядра, но раньше KASLR и так легко обходился.
• Баг оказался в NtQueryInformationToken, а не в новом enum; статья уже исправлена.
• Патч KB5063878 (август 2024) закрыл уязвимость; совпадение с «фиаско Phison SSD» – случайность.
• Эксплойт полезен как звено в цепочке, но KASLR всё равно воспринимается лишь «speed bump».

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

• Google на 3–4 месяца блокирует публикацию исходников патчей безопасности, чтобы OEM-ы успели обновить свои устройства, но при этом злоумышленники получают «белый свет» на использование уязвимостей.
• GrapheneOS видит патчи, но не может включать их в открытые сборки, пока не истечёт эмбарго, что ставит пользователей в уязвимое положение.
• Предложенный выход — выпускать временно бинарные обновления (opt-in), чтобы сообщество могло запрашивать GPL-исходники и реверс-инжирить исправления.
• Участники считают, что OEM-ы легко могли бы тестировать патчи в CI за дни, но экономия и нежелание тратиться на безопасность тормозят процесс.
• Некоторые подозревают, что затягивание обновлений выгодно не только OEM, но и госструктурам, которым даётся «окно» для эксплойтов.

Кратко:
Разработчик ICEBlock (приложение для анонимных доносов на ICE) проигнорировал мой отчёт об уязвимости. 1 сентября я сообщил, что его сервер на Apache 2.4.57 содержит критические CVE, и попросил обновиться до публикации критического поста. В ответ — блокировка и обвинения во лжи. Через два дня уязвимость всё ещё не закрыта; исправление занимает одну команду apt upgrade.

• Автор сообщил разработчику ICEBlock о «уязвимости» (устаревший Apache), но дал всего 90 минут до публикации критичной статьи — это не responsible disclosure.
• Большинство участников считают «уязвимость» фейком: версия могла быть за-патчена дистрибутивом, PoC отсутствует, эксплуатация не доказана.
• Пост воспринимается как «activism theater»: автор смешал политическую критику приложения и технический аудит, что выглядит как хит-пьеса.
• Разработчик заблокировал автора после первого демонстративного поста; сообщество считает реакцию понятной.
• Вывод: ни сторона автора, ни сторона ICEBlock не выглядят профессионально — шум вокруг пустяковой «уязвимости» никому не помог.

CVE-2024-50264: кратко о сложнейшей гонке в AF_VSOCK
Уязвимость введена в 2016 г. (ядро 4.8); это race между connect() AF_VSOCK и POSIX-сигналом, приводящий к UAF 80-байтового объекта virtio_vsock_sock. Триггер доступен обычному пользователю без user-ns. Ограничения: объект быстро освобождается, UAF-запись делает kworker, система легко падает. За это баг получил Pwnie 2025 «Best Privilege Escalation».

Управление сигналом без самоубийства процесса
Вместо SIGKILL, который убивает эксплойт, используется «бессмертный» сигнал 33:

sev.sigev_signo = 33;
timer_create(CLOCK_MONOTONIC, &sev, &race_timer);
timer_settime(...);  // точный момент прерывания connect()

Сигнал 33 зарезервирован NPTL, процесс его не видит и не завершается.

kernel-hack-drill: тренажёр для ядерных атак
Проект https://github.com/a13xp0p0v/kernel-hack-drill автоматизирует:

• сборку нужных версий ядра Ubuntu 24.04 (6.11 OEM/HWE) с разными конфигурациями KASLR/KCFI/SLAB_QUARANTINE;
• запуск в KVM с заданным RAM/CPU и ssh-форвардингом;
• однокнопочный запуск PoC и сбор crash-дампов.

Инструмент позволил быстро перебирать стратегии перераспределения kmalloc-96, искать объекты-спрей, тестировать разные техники обхода защит и отлаживать эксплойт без ручной пересборки ядра.

Новый путь эксплуатации
Автор отказался от сложной цепочки @v4bel и @qwerty и применил упрощённую схему:

1. Спрей sendmsg()-controlled объектами размером 96 байт, чтобы перехватить освобождённый virtio_vsock_sock.
2. UAF-запись переписывает поле sk_prot, указывая на поддельную структуру proto в userspace-буфере.
3. При последующем вызове close() ядро переходит по контролируемому указателю и исполняет ROP-цепочку, поднимая shell до root.

kernel-hack-drill сократил время от идеи до рабочего PoC с недель до нескольких часов.

• Участники в восторге от глубокого и единоличного описания use-after-free, но признают, что текст местами труден для чтения из-за «роботизированной» подачи.
• Многие чувствуют себя «бесполезными» на таком низком уровне и восхищаются талантом исследователей уязвимостей.
• Поднимается вопрос о мотивации: исследователи редко чинят баги, потому что это требует других навыков и ломает их инсентивы.
• Обсуждается, поможет ли Rust в ядре Linux: write-after-free технически блокируется, но unsafe-области всё ещё оставляют риски.

Guix, функциональный менеджер пакетов вдохновлённый Nix, скоро исчезнет из Debian 12 и 13. Причина — серьёзные уязвимости (CVE-2025-46415/6) в guix-daemon, позволяющие повысить привилегии, и невозможность безопасного бэкпорта: исправления перемешаны с другими изменениями, а проект не выпускает стабильные ветки. Последний релиз Guix 1.4.0 вышел в 2022 г.; проект использует rolling-release. Мэйнтейнер Debian Вагрант Каскадиан признал, что изолировать патчи безопасности «сложнее, чем раньше». Denis Carikli собрал ≈50 патчей в стороннем репозитории, но их качество не подходит для дистрибутивов. Удаление Guix из Debian повлечёт за собой исчезновение пакета из других дистров, использующих его как upstream.

• Guix в Debian отстаёт из-за политики «одна стабильная версия библиотеки» и заморозки релизов; обновить до свежей «ванильной» Guix мешают правила только-багфиксов и совпадение с CVE.
• Пакет не собирается GCC ≥ 2025-04 из-за несовместимости со стандартами C23/C++23.
• Popcon показывает <230 установок, но большинство пользователей Debian отключают статистику, так что реальная аудитория выше.
• Некоторые считают, что Guix лучше запускать bare-metal или в Hurd, а не пытаться вписать в Debian.
• Общий вывод: разные философии релиз-циклов приводят к конфликту, и поддержка Guix в Debian требует непропорционально много усилий.

FreeDroidWarn — приложение для Android, которое отслеживает и оповещает о новых уязвимостях в установленных приложениях.
Использует открытые базы CVE и Google Play, проверяет обновления в фоне и показывает уведомления, если найдена угроза.

Основное:

• Бесплатно, без рекламы, open-source (GPL-3).
• Минимальные разрешения, работает офлайн.
• Поддержка темной темы, экспорт/импорт списка приложений.

Установка:
Скачать APK из Releases или собрать из исходников.

• Google с 2026/27 г. требует от разработчиков Android-приложений передавать личные данные; без этого приложения не будут работать на «сертифицированных» устройствах.
• У пользователей остаются варианты: старые версии Android, альтернативные магазины, рут/ADB, GrapheneOS или Linux-смартфоны, но всё требует компромиссов.
• Банки всё чаще требуют «официальные» ОС, что ограничивает свободу выбора; некоторые предлагают веб-версии или работают с GrapheneOS.
• Обсуждаемая библиотека-уведомление оказалась тривиальной и избыточной; лицензию быстро сменили с GPLv3 на Apache-2.0, чтобы не пугать разработчиков.
• Общий вывод: технические «заплатки» не решают проблему, нужны антимонопольные законы и давление со стороны пользователей и законодателей.

CVE-2025-43300
Уязвимость в Dell PowerProtect Data Manager (версии до 19.14.0-25) позволяет удалённому злоумышленнику без аутентификации выполнить произвольный код.

CVSS 9.8 – критическая.

Суть

Недостаток валидации входных данных в REST-эндпоинте /api/v1/agent/... приводит к внедрению команд в параметре backupName.

PoC

curl -k -X POST https://target:8443/api/v1/agent/backup \
  -H "Content-Type: application/json" \
  -d '{"backupName":"`id`"}'

Ответ вернёт вывод команды id, подтверждая RCE.

Эксплуатация

1. Сканируем 8443/tcp.
2. Отправляем payload, получаем обратную shell.
3. Повышаем привилегии через встроенный sudo (uid=0).

Исправление

Обновиться до 19.14.0-25 или выше.

Mitigation

• Ограничить доступ к 8443/tcp.
• Включить WAF-фильтрацию символов ; & | $.

• Apple экстренно выпустила единственный патч 13.7.8 / 14.7.8 / 15.6.1 и iOS/iPadOS 18.6.2, закрывающий CVE-2025-43300 в обработке DNG.
• Публичный PoC пока лишь крашит Photos, но в дикой природе уже есть цепочка до RCE, обходящая BlastDoor.
• watchOS не получил обновления, вызывая вопросы о его уязвимости.
• Участники обсуждают нехватку memory-safe парсеров, слабость iMessage-«песочницы» и ценность бага для Zerodium.
• Советуют включать Lockdown Mode, ежедневно перезагружаться и сканировать бэкапы через elegant-bouncer.

Claude Code теперь умеет искать уязвимости: запускает специальный промпт, проверяет OWASP Top 10.
Проверил расширение Simple Wikiclaudia и сервис rsspberry2email — Claude сказал «всё ок».
Но доверять одному ИИ, который сам писал код, нельзя: нужны человеческий ревью, SAST, DAST, фаззинг.

Для контроля подключил Datadog:

• расширение — уязвимостей нет, зато куча логов (HIGH, но можно выключить);
• сервис — Datadog нашёл библиотеки с CVE, предложил кнопку «Remediate».
  Claude подтвердил одну из находок; остальное — «приемлемый риск» для домашнего RPi.

• Руководство верит, что «волшебная пыль ИИ» решает всё, включая проблемы самого ИИ.
• Найденные Claude и DataDog уязвимости выглядят тривиальными и легко детектируются статическим анализом.
• Компании устраивают «тест на компетентность»: удача руководителей вот-вот закончится.
• Пользователи готовы наблюдать, как ИИ удаляет ld, сносит контейнеры и плодит тонны мусорного кода.
• Скоро ИИ займёт ключевые бизнес-процессы, а после провалов и аудитов топ-менеджеры получат золотые парашюты.
• Всё напоминает «Новое платье короля»: все видят проблему, но молчат.

Введение: когда модель доверия подводит

Секрет-хранилища — опора цифровой инфраструктуры: в них лежат креденшелы, токены и сертификаты, управляющие доступом к системам, сервисам, API и данным. Это не просто часть модели доверия — это и есть модель доверия. Если хранилище взломано, инфраструктура уже потеряна.

Понимая, что такие хранилища — цели высокой ценности, команда Cyata провела углубленную оценку HashiCorp Vault — одного из самых популярных решений.

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

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

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

Это не были ошибки памяти или гонки, а скрытые логические баги в слоях аутентификации, идентичности и политик Vault. Некоторые существовали почти десятилетие — незаметные, но легко эксплуатируемые после понимания.

Предыдущие исследования (например, Google Project Zero, 2020) касались обходов в IAM-бэкендах облаков (AWS, GCP). Мы нацелились на базовые потоки аутентификации Vault, затрагивающие OSS и Enterprise-версии по разным провайдерам.

Далее — что мы нашли, как нашли и что это значит для инфраструктуры, которую должен защищать Vault.

Что такое HashiCorp Vault?

Vault — открытый инструмент для защиты, хранения и контроля доступа к секретам: API-ключам, паролям БД, сертификатам, ключам шифрования.

Его используют компании разных масштабов: он централизует управление секретами и применяет детальные политики в распределенных системах.

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

В DevSecOps Vault снижает риски хардкода секретов, расползания и несанкционированного доступа. Его ценят за гибкую интеграцию, точные политики и пригодность для сложных сред. Часто это последний сторож секретов: при определенных настройках компрометация Vault равна компрометации всего.

Основные возможности Vault

• Управление секретами и крипто-движок для динамичных мульти-/гибрид-облаков
• Централизованное хранилище с доступом по API
• Динамическая выдача учетных данных с автоистечением
• Идентификационно-ориентированный доступ для людей и машин
• Шифрование как сервис для данных «в покое» и «в пути»
• Управление сертификатами: выпуск, ротация, отзыв
• Распределение, включение/отключение и ротация ключей шифрования

Методология: как мы нашли то, что другие пропустили

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

Мы исходили из гипотезы: если Vault — якорь доверия, то малые несогласованности в идентичности, аутентификации или политике могут иметь непропорционально большие последствия.

Фокус — базовый поток обработки запросов, особенно файл request_handling.go, «мозг» Vault: маршрутизация, разрешение идентичностей, принятие политик. Неделями изучали логику функций и модулей, отслеживая крайние случаи размывания границ доверия.

Не полагались на фаззинг и автопробинг. Проводили глубокий ручной код-ревью, анализируя не только функции, но и интерпретации идентичности/ввода разными компонентами. Увидев несоответствия в регистре, алиасинге, форматировании — углублялись.

Каждый тест — целевая проверка, основанная на коде. Мы думали как атакующие: начиная с минимальных прав, спрашивали «насколько далеко можно продвинуться отсюда?» И повторяли этот цикл, замечая мелкие несоответствия и прослеживая их последствия.

• Исследователи из Cyata (Vault Fault) вручную обнаружили 9 CVE в Vault, включая цепочку до RCE; отчёт писали люди, но с редактором.
• Ключевая причина уязвимостей — «полезная» нормализация строк: преобразования регистра/UTF в auth-плагинах дают bypass, перечисление имён и привилегии.
• OpenBao подтвердил 8 из 9 CVE; жалуются, что HashiCorp не предупредил заранее, и приглашают к сотрудничеству.
• Некоторые участники считают код Vault «бардаком» и тесты слабыми; другие спорят, что такие логические ошибки встречаются везде.
• Обсуждение стиля: текст кажется «AI-шным» из-за многословности, но информативности это не мешает.