Опубликован выпуск открытого кроссплатформенного менеджера паролей KeePassXC 2.8.0, предоставляющего средства для безопасного хранения обычных паролей, одноразовых паролей (TOTP), SSH-ключей и прочей информации, которую пользователь считает конфиденциальной. Данные могут храниться как в локальном зашифрованном хранилище, так и во внешних облачных хранилищах. Код проекта написан на языке C++ с использованием библиотеки Qt и распространяется под лицензиями GPLv2 и GPLv3. Готовые сборки подготовлены для Linux (AppImage, Flatpak, Ubuntu PPA, Snap), Windows и macOS.
Основные возможности:
Работа с БД в формате KDBX. Хранение информации в зашифрованном виде. Возможность прикрепления к записям о сохранённых паролях файлов и собственных атрибутов.
Систематизация информации с распределением по группам. Встроенная система поиска. Автоподстановка паролей в приложения. Возможность управления из командной строки (keepassxc-cli).
Генератор надёжных паролей. Хранение и генерация одноразовых паролей (TOTP). Анализ качества сохранённых паролей и формирование отчётов со статистикой.
Интеграция с web-браузерами Chrome, Mozilla Firefox, Edge, Chromium, Vivaldi, Brave и Tor Browser. Поддержка аутентификации с использованием технологии Passkeys, реализованная через интеграцию с браузером.
Поддержка импорта базы паролей из форматов CSV, 1Password, Bitwarden, Proton Pass и KeePass1. Экспорт в форматы CSV, XML и HTML.
Поддержка YubiKey и OnlyKey. Интеграция с SSH Agent. Совместный доступ к БД KeeShare.
Поддержка FreeDesktop.org Secret Service, например, для использования вместо GNOME keyring. Поддержка алгоритмов шифрования Twofish и ChaCha20.
Состоялся релиз проекта F-Stack 2.0, развивающего редакцию сетевого стека FreeBSD, адаптированную для обособленной работы в пользовательском пространстве в форме библиотеки. Проект создан крупнейшей в Китае телекоммуникационной компанией Tencent и используется в её продуктах и сервисах. Код написан на языке Си и распространяется под лицензией BSD. Поддерживается работа в Linux и FreeBSD. Проектом также поддерживаются переведённые на использование F-Stack редакции Nginx 1.28 и СУБД Redis 6.2.6, демонстрирующие производительность выше обычных сборок, работающих поверх системного сетевого стека.
F-Stack позволяет задействовать в приложениях собственный локальный сетевой стек, не зависящий от сетевого стека операционной системы, функционирующий в пользовательском пространстве и напрямую работающий с сетевым оборудованием. F-Stack позиционируется как решение, позволяющее повысить производительность обработчиков сетевых запросов в условиях, когда штатный TCP/IP стек ядра Linux становится узким местом и ограничивает масштабирование. Теоретически F-Stack позволяет достигнуть потолка сетевой производительности, возможного для используемой сетевой карты, и в некоторых ситуациях даёт возможность в разы увеличить число обрабатываемых мелких сетевых запросов.
Повышение производительности достигается за счёт исключения таких операций, как копирования сетевых пакетов, планирование потоков, обработка прерываний и обращение к системным вызовам. Для взаимодействия с сетевой картой, минуя интерфейсы ядра операционной системы, применяется фреймворк DPDK (Data Plane Development Kit), развивающий набор библиотек для низкоуровневой работы с сетевыми адаптерами. DPDK даёт возможность снизить накладные расходы и уложиться в минимальное число циклов CPU при приёме или отправке сетевых пакетов.
Функциональность стека TCP/IP соответствует сетевому стеку FreeBSD 15 и выделена из данной операционной системы в независимую библиотеку. Для разработки приложений можно использовать стандартный API POSIX (socket, epoll, kqueue) или собственный программный интерфейс на основе микропотоков, упрощающий создание сетевых приложений и позволяющий обойтись без сложной логики асинхронной обработки запросов. Возможно использование с немодифицированными приложениями с загрузкой через LD_PRELOAD.
Наиболее заметные изменения в новом выпуске:
Компоненты сетевого стека обновлены до состояния FreeBSD 15 (ранее использовался FreeBSD 13).
Реализован режим многопоточной работы (thread_mode=1) в одном процессе, дополняющий ранее доступный многопроцессный режим.
Добавлен легковесный режим работы (primary_slim), при котором основной процесс выполняет только базовые задачи инициализации и координации работы, а приём пакетов и обработка очередей приёма/передачи (rx/tx) производится только на стороне дочерних процессов.
Добавлена поддержка механизма аппаратного ускорения
TSO (TCP Segmentation Offload) для выноса на сторону сетевой карты операций объединения пакетов, с возможностью отката на программную реализацию. Улучшена поддержка TSO (TCP Segmentation Offload) для IPv6.
Добавлена возможность изменения размера MTU (Maximum transmission unit) и реализована поддержка jumbo-кадров.
Расширены возможности управления аппаратным ускорением вычисления контрольных сумм отправляемых пакетов
Добавлена функция ff_zc_recv() для получения данных в без промежуточной буферизации (zero-copy). Переработана аналогичная функция ff_zc_send() для отправки. Оптимизирована и дополнена поддержкой IPv6 функция ff_rss_check().
Добавлен опция FF_KERNEL_COEXIST для работы совместно с сетевым стеком ядра.
Предоставлена возможность сохранения информации о трафике в pcap-дампах с наносекундной точностью.
В config.ini добавлены новые параметры idle_loop_interval, extra_eal_args, drain_ring_size, reload_heartbeat_timeout_ms и reload_udp_idle_ms.
В специализированной сборке nginx реализована поддержка перезагрузки конфигурации и обновления бинарного файла без разрыва соединений (graceful_reload=1).
Зафиксирована публикация в репозитории PyPI вредоносного выпуска библиотеки LiteLLM, насчитывающей 23 млн загрузок в неделю, а также подстановка вредоносного кода в официальный Docker-образ проекта. Это не первый подобный инцидент с LiteLLM - в марте этого года атакующие уже публиковали вредоносные выпуски после перехвата учётных данных сопровождающего. На этот раз атакующие разместили версию LiteLLM 1.107.0, в которую был встроен вредоносный код для организации удалённого выполнения команд, а также поиска и отправки учётных данных, ключей и токенов доступа.
Вредоносный код был подставлен на этапе сборочного процесса без компрометации git-репозитория. После установки вредоносный код активируется до импорта LiteLLM через установку файлов cook.pth, cook.py и sitecustomize.py в директорию с библиотеками Python. Данные файлы запускаются при каждом выполнении Python в системе без необходимости совершения пользователем каких-либо действий.
Вначале Python запускает файл cook.pth, в котором имеется только одна строка "import cook" для импорта скрипта cook.py, собирающего учётные данные. Далее импортируется скрипт sitecustomize.py, применяемый для фоновой загрузки внешнего кода (параметры загрузки определяются по ссылке "raw.githubusercontent.com/letters9813/pythonclient-test/main/domain.txt"). Вредоносный код в обоих скриптах сжат через zlib и закодирован методом Base64. Индикатором компрометации может служить появление в системе файлов "/tmp/.pc_once_*" и "/tmp/remote_code_loader.lock".
После активации файл cook.py выполняет сканирование параметров подключения к облачным сервисам, репозиториям и системам непрерывной интеграции (AWS, Azure, Google Cloud, Kubernetes, Docker, GitHub CLI, Vault, Terraform, Packer), учётных записей разработчиков, параметров подключения к Git, настроек npm и PyPI, файлов с переменными окружения, закрытых ключей для SSH, PGP и TLS, настроек AI-инструментов, браузерных БД c Cookie, хранимыми данными и историей, информации о процессах и переменных окружения. Обнаруженные данные шифруются с использованием алгоритмов AES-256-CBC + RSA-4096 и отправляются в форме проверочного запроса на сайт litellm.dev, созданный злоумышленниками.
Компания eMudhra опубликовала заявление, связанное с инцидентом, в результате которого у восьми корневых сертификатов удостоверяющего центра оказались легко подбираемые закрытые ключи, имеющие всего 1 байт энтропии вместо 48. eMudhra утверждает, что сертификаты были сгенерированы в апреле 2025 года на публичной церемонии с использованием аппаратных модулей HSM (Hardware Security Module), имеющих сертификат соответствия требованиям FIPS 140-2 Level 3.
В процессе генерации ключей произошёл сбой, из-за которого на этапе упаковки/распаковки в HSM (wrap/unwrap, шифрование и расшифровка ключом-обёрткой) в дополнение к основному набору криптостойких ключей был создан второй набор слабых ключей с обнулёнными старшими байтами, который и был задействован в сертификатах. Сбой не был распознан, так как закрытые ключи создаются и хранятся только в HSM и не попадают в открытом виде за его пределы. Причина произошедшего сбоя пока не ясна и компания проводит связанное с этим расследование. Утверждается, что проблемные корневые сертификаты, созданные с использованием слабых ключей, прошли независимый аудит и два года оставались в списке доверенных во всех хранилищах корневых сертификатов.
Разработчики PHP опубликовали отчёт о проблемах, возникших в процессе устранения исправленных вчера критических уязвимостей в PHP. Информация об уязвимости, возникающей при исчерпании доступной памяти, была получена в ходе внешнего аудита ещё в 2024 году, но была воспринята лишь как теоретическая возможность совершения атаки. Исправление затянулось из-за проблем с достижением консенсуса среди разработчиков PHP о способе устранения уязвимости. Рассматривалось несколько конкурирующих предложений о решении проблемы, каждое из которых имело свои минусы. Приходилось выбирать между нарушением обратной совместимости, появлением новых векторов для атак, вызывающих отказ в обслуживании, и необходимостью внесения изменений во множество сторонних дополнений.
Несколько месяцев назад компании Calif и Wiz независимо друг от друга при помощи AI-моделей GPT‑5.6 и Gemini 4 Argon выявили рабочие методы эксплуатации проблемы и 11 и 24 августа 2026 года сообщили об этом разработчикам PHP. После этого разработке исправлений был назначен наивысший приоритет и начато реформирование процесса принятия решений для более оперативного реагирования в вопросах, связанных со сложными компромиссами (подобные решения теперь могут приниматься большинством голосов без строгого достижения консенсуса).
Изначально, скоординированная с дистрибутивами дата публикации исправления была назначена на 22 октября, но затем была перенесена на 21 октября после утечки 20 октября в социальные сети сведений о CVE-идентификаторах и некорректных данных о времени публикации предстоящих корректирующих выпусков.
Вскоре после анонса предстоящих исправлений в компания Calif, выявившая одну из уязвимостей, по ошибке опубликовала видеоролик с демонстрацией работы эксплоита, в котором были заметны некоторые детали, позволяющие сузить область поиска и воссоздания информации о проблеме. Ролик был быстро удалён, что лишь подстегнуло у исследователей желание докопаться до сути уязвимости и форсировало работу над альтернативными прототипами эксплоитов.
Помимо этого, за шесть часов до намеченной публикации исправлений компания Chainguard нарушила эмбарго и опубликовала сборки своего дистрибутива, содержащие исправленную версию PHP. Подобное нарушение дало возможность злоумышленникам изучить исправление до официального релиза, а также перечеркнуло всю работу по скоординированному раскрытию информации и одновременной публикации исправлений в разных дистрибутивах.
Дополнение: Спустя 16 часов после раскрытия деталей об уязвимостях универсального рабочего эксплоита ещё не появилось и массовых атак пока не наблюдается, что объясняется сложностью эксплуатации уязвимости из-за необходимости определения раскладки структур в памяти процесса, которая специфична в каждой сборке. Опубликованные рабочие прототипы эксплоитов завязаны на отдельные конфигурации и проведение атаки в лабораторных условиях. Также появилось много фиктивных эксплоитов, являющихся галлюцинациями AI, лишь создающих видимость атаки, завязанных на ошибки в конфигурации или работающих только при наличии других критических уязвимостей.
Опубликован релиз пользовательского окружения Dux Shell 2.0, поддерживающего работу поверх композитных серверов niri, Hyprland, Sway, MangoWC, labwc, Scroll, Aqueous и Miracle WM. Это первый выпуск после переименования проекта DankMaterialShell (DMS) в Dux Shell. Новое имя проще, созвучно с пингвином Tux и не включает в часть названия чужого бренда. Dux Shell развивает набор сочетающихся между собой компонентов для формирования рабочего стола, таких как панель задач, переключатель виртуальных рабочих столов, интерфейс навигации по установленным приложениям и конфигуратор. Оформление соответствует концепции Material Design 3.
Dux Shell поддерживает динамические темы оформления, автоматически применяемые к GTK, Qt и системным приложениям. Цветовые схемы для тем формируются с учётом цвета выбранных обоев рабочего стола. Имеется возможность включения ночного режима работы, а также переключения между светлой и тёмной темами оформления. Функциональность может расширяться через плагины. Код фонового процесса для интеграции с системой, инструментария и инсталлятора написаны на языке Go и распространяются под лиценизей MIT. Компоненты интерфейса, панели, виджеты и графические приложения подготовлены на языке QML с применением фреймворка Quickshell, написанного на C++ с использованием Qt.
В состав входят:
Панель с виджетами для календаря, прогноза погоды, просмотра истории работы с буфером обмена и интеграции с мультимедийными проигрывателями при помощи протокола MPRIS.
Интерфейс для навигации по установленным в системе приложениям с поддержкой поиска программ, файлов, открытых окон и команд.
Центр управления с интерфейсом для настройки сети, Bluetooth, звуковых устройств и экрана.
Встроенные в управляющий фоновый процесс средства сбора метрик о температуре и потреблении ресурсов CPU, ОЗУ и GPU. Наличие интерфейса для управления запущенными процессами.
Центр уведомлений, поддерживающий группировку уведомлений, использование разметки в тексте и навигацию при помощи клавиатуры.
Экран блокировки системы с возможностями управления сеансом. Возможна активация спящего режима или блокировка экрана при определённом периоде неактивности пользователя.
Универсальный инсталлятор, позволяющий развернуть и настроить окружение на базе Dux Shell в Arch, Fedora, Debian, Ubuntu, openSUSE, Gentoo и Void Linux.
Инструментарий Dux Search для поиска файлов в системе.
Календарь-планировщик Dux Calendar, поддерживающий протокол CalDAV и синхронизируемый с сервисами Google и Microsoft.
Файловый менеджер Dux Files.
Приложение DuxConnect для интеграции со смартфоном.
На использование концепции дизайна Material 3 Expressive переведены приложения Settings, Control Center, Dash и виджеты. Реализованы новые управляющие элементы интерфейса, выполнена группировка настроек, предложены новые средства навигации и изменена цветовая схема.
Расширены возможности для настройки содержимого выпадающей панели
Dash, которая теперь не ограничивается встроенными вкладками и позволяет подключать плагины с реализацией дополнительных вкладок. Возможна перегруппировка и изменение размера секций. Передалено оформление встроенных страниц - обзорного режима, мультимедийного проигрывателя и области с прогнозом погоды.
Добавлена поддержка размещения виджетов на экране блокировки системы, таких как часы, область уведомлений, статусная строка и элементы управления энергопотреблением. Предоставлена возможность настройки шрифтов, цветов, размера и стиля виджетов.
В мультимедийный проигрыватель добавлен движок для загрузки и синхронизации текстов песен с сервисов Better Lyrics, Unison, LyricsPlus, KuGou, LRCLIB и YouTube Music.
Представлен обособленный файловый менеджер Dux Files, поддерживающий вкладки, двухпанельный просмотр, отображение содержимого в виде списка или сетки пиктограмм, предпросмотр контента, работу с архивами, поиск файлов и обращение к сетевым хранилищам.
Разрешено размещение нескольких Dock-панелей, закрепление их к любому краю экрана, растяжение по всей ширине, размещение в панели типовых виджетов и плагинов. Предоставлена возможность переключения между компактным режимом отображения пиктограмм и новым режимом панели задач.
Переделаны плитки быстрого изменения настроек в центре управления.
В панель Dash добавлена отдельная вкладка для отслеживания времени, проведённого перед экраном, и выставления лимитов ежедневной работы или работы с отдельными приложениями.
Добавлен новый интерфейс для навигации по каталогу плагинов.
Расширена интеграция с композитными менеджерами Hyprland, Niri и MangoWC, и добавлена поддержка их новых версий. Реализована поддержка композитных менеджеров Aqueous и Umbriel.
Добавлена возможность навигации по конфигуратору только при помощи клавиатуры.
Опубликованы корректирующие выпуски PHP 8.5.12, 8.4.27, 8.3.36 и 8.2.35, а также патчи для уже не поддерживаемых веток PHP 7.4, PHP 8.0 и PHP 8.1 (уязвимые версии с 5.4 по 7.3 остаются без патчей), в которых исправлены две критические уязвимости:
CVE-2026-109618 - удалённое выполнение кода, вызванное тем, что при исчерпании доступной процессу свободной памяти обработчик нехватки памяти через выполнение функции longjmp() может прервать PHP-интерпретатор в состоянии, когда инициализирована лишь часть внутренних структур, связанных с обработкой запроса. В последующем функция завершения обработки запроса обращается к этим структурам как к уже инициализированным, хотя память для них не выделена.
Основным вектором атаки является манипуляция с multipart-запросами для создание условий для исчерпания доступной процессу памяти. Для обхода лимита post_max_size может не указываться заголовок Content-Length и передаваться огромное число HTTP-заголовков. Возможно проведение и точечных атак на конкретные операции в php-приложениях, чрезмерно расходующих память. Наличие эксплоита подтверждено для mod_php, так как он вызывает функцию shutdown() даже при сбое. PHP-FPM при сбое завершат дочерний процесс, что затрудняет проведение атаки, но теоретически её не исключает.
CVE-2026-109619 - удалённое выполнение кода, вызванное обращением к памяти после её освобождения из-за некорректной очистки глобального состояния, привязанного к конкретному запросу. В случае прерывания запроса из-за фатальной ошибки, таймаута или нехватки памяти глобальное состояние может оказаться не сброшено и указатели останутся активны, несмотря на освобождение памяти, на которую они ссылаются. При обработке следующего запроса в том же процессе может произойти обращение по оставшемуся указателю к старому глобальному состоянию.
Для эксплуатации может использоваться создание условий исчерпания доступной памяти при обработке multipart-запроса в коде для индикации прогресса загрузки (session.upload_progress). При этом в качестве основного и подтверждённого вектора атаки упоминается обработчик fatal_error_backtraces в PHP 8.5, который не сбрасывает состояние трассировки при завершении. В первом случае атака возможна на mod_php и PHP-FPM, а во втором только на mod_php. Также упоминается неподтверждённая возможность проведения атаки в конфигурациях, в настройках которых имеются директивы, приводящие к выводу предупреждений на ранней стадии обработки запроса (например, предупреждения об использовании устаревших параметров).
Заявлено, что полное блокирование уязвимостей возможно только через установку обновления. Следующие меры позволяют снизить вероятность успешного проведения атак, но не делают систему полностью безопасной:
Выставление в php.ini параметра "memory_limit=-1", что затрудняет возможность атакующего контролировать исчерпание лимитов на память.
Выставление параметра "post_max_size = 8M", если нет необходимости в загрузке больших файлов. Значение параметра "upload_max_filesize" должно быть меньше параметра "post_max_size".
Задание лимита на допустимое потребление памяти на системном уровне, через cgroup memory.max или параметры потребления памяти контейнером, но не через системные лимиты RLIMIT_AS и RLIMIT_DATA, которые лишь провоцируют проблемный вызов longjmp().
Если производительность не важна можно ограничить число запросов, обрабатываемых одним рабочим процессом через pm.max_requests=1 в PHP-FPM и MaxRequestsPerChild в Apache httpd.
Выставление на уровне php.ini или конфигурации сервера (не через ini_set() или FPM .user.ini, так как параметр должен действовать до начала обработки запроса) параметра "session.upload_progress.enabled=0".
При использовании выпуска PHP 8.5 следует установить параметр "fatal_error_backtraces=0".
Удаление привязанных к отдельным запросам устаревших или ошибочных настроек (типа assert.* и неверных путей в open_basedir), приводящих к выводу диагностических сообщений до инициализации.
Устранение в PHP-коде ситуаций, приводящих к достижению таймаутов и фатальных ошибок, например, связанных со сбоями в callback-обработчиках и обработкой загрузок.
Для блокирования первой уязвимости в коде старых версий PHP можно заменить вызов longjmp() в обработчике исчерпания свободной памяти на _exit().
Дополнительно можно уменьшить значение параметра max_input_nesting_level в php.ini и блокировать multipart-запросы, как было показано в предварительном анонсе.
Дополнение 1: Уязвимости выявлены при помощи AI-моделей GPT‑5.6 и Gemini 4 Argon. Компания OpenAI опубликовала утилиту php2shell-checker для проверки подверженности уязвимостям сайтов и локальных исполняемых файлов, но эта утилита лишь проверяет номер версии PHP, возвращаемый HTTP-сервером или командой "php -v", без детального анализа.
Дополнение 2: Автор прототипа эксплоита, использующего уязвимость, вызванную двойным освобождением памяти (double-free), сообщил, что проблема остаётся не исправлена в выпуске PHP 8.5.12 и эксплоит продолжает работать. Ранее представители PHP заявляли, что эта уязвимость не связана с готовящимися исправлениями и не является реальной проблемой. Автор же эксплоита утверждает, что это совсем иная уязвимость.
Дополнение 3: Спустя 16 часов после раскрытия деталей об уязвимостях универсального рабочего эксплоита ещё не появилось и массовых атак пока не наблюдается, что объясняется сложностью эксплуатации уязвимости из-за необходимости определения раскладки структур в памяти процесса, которая специфична в каждой сборке. Опубликованные рабочие прототипы эксплоитов завязаны на отдельные конфигурации и проведение атаки в лабораторных условиях. Также появилось много фиктивных эксплоитов, являющихся галлюцинациями AI, лишь создающих видимость атаки, завязанных на ошибки в конфигурации или работающих только при наличии других критических уязвимостей.
COSMIC развивается как универсальный проект, не привязанный к конкретному дистрибутиву и соответствующий спецификациям Freedesktop.
Для построения интерфейса в COSMIC задействована библиотека Iced, которая использует безопасные типы, модульную архитектуру и модель реактивного программирования, а также предлагает архитектуру, привычную для разработчиков, знакомых с языком декларативного построения интерфейсов Elm. Предоставляется несколько движков отрисовки, поддерживающих Vulkan, Metal, DX12, OpenGL 2.1+ и OpenGL ES 2.0+. Разработчикам предлагается готовый набор виджетов, возможность создавать асинхронные обработчики и использовать адаптивную компоновку элементов интерфейса в зависимости от размера окна и экрана.
Помимо использования языка Rust из особенностей COSMIC выделяются режимы гибридной мозаичной компоновки окон и стекового закрепления окон (группировка окон по аналогии со вкладками в браузере), которые могут включаться в привязке к виртуальным рабочим столам. Проектом также разрабатывается композитный сервер cosmic-comp на базе Wayland.
Среди изменений:
В libcosmic при обработке ввода текста прекращён перехват нажатия клавиши Escape, что решило проблемы с закрытием некоторых меню по нажатию Escape.
В библиотеке приложений (cosmic-app-library) реализован переход к первому приложению в результатах поиска при нажатии клавиши управления курсором "вниз". На системах с гибридной графикой обеспечен выбор корректного GPU при запуске игр.
В композитном сервере (cosmic-comp) реализована поддержка Wayland-протокола "xdg-dialog-v1", позволяющего создавать модальные диалоги, которые блокируют взаимодействие пользователя с остальной частью интерфейса. Реализована отправка команды активации экранной клавиатуры через отдельный D-Bus-сигнал.
Добавлена ассоциация для открытия текстового редактора Cosmic-edit для JSON-файлов.
В конфигураторе (cosmic-settings) добавлены опции для перетаскивания объекта двойным касанием по тачпаду (tap&drag) и режима, позволяющего на мгновение оторвать палец от тачпада, не прерывая процесс перетаскивания.
В интерфейсе запуска приложений задействован поиск без учёта регистра символов и улучшен поиск отдельных слов в скобках. Реализован выбор корректного GPU на системах с гибридной графикой.
В рамках проекта LiberNT создан форк операционной системы ReactOS, нацеленный на достижение совместимости с приложениями и драйверами для Windows 11 24H2, стилизацию внешнего вида под современные Windows и поддержку 64-разрядных аппаратных платформ, включая системы на базе архитектур ARM64, PowerPC и RISC-V 64. Отличительной особенностью форка также является активное использование AI-инструментов при разработке. Собственные наработки LiberNT распространяются под лицензией GPLv3, но код заимствованный из ReactOS продолжает поставляться под лицензией GPLv2+. Основные загрузочные сборки сформированы для систем x86_64 и ARM64, дополнительно публикуются экспериментальные сборки для PowerPC и RISC-V 64 (Banana Pi BPI-F3).
Среди достижений проекта:
Реализация поддержки работы на ARM-платах Raspberry Pi 3 и Raspberry Pi 5, включая драйверы для GPU, звуковой подсистемы и сетевого адаптера.
Задействование новой системы управления памятью NVS, по заявлению разработчиков работающий быстрее, чем вариант от ReactOS.
Поддержка запуска Windows-приложений, собранных для архитектуры x86, на системах с архитектурой ARM64 (используется эмулятор FEX).
Более современные графические драйверы, использующие архитектуру драйверов WDDM и поддерживающие аппаратное ускорение для OpenGL. Новые драйверы пока доступны для плат Raspberry Pi 5 и 3, и находятся на стадии реализации для GPU Intel и AMD.
Новый стек для систем хранения и USB, включая новые драйверы для устройств NVMe, USB 3.0, SD-карт, сетевых устройств и игровых контроллеров (поддерживаются PlayStation 5 DualSense, PlayStation 5 DualSense Edge и Xbox Series X|S). Новый драйвер для ФС NTFS.
Организация Linux Foundation подвела итоги опроса 234 сопровождающих и разработчиков открытых проектов, оценивающего влияние AI-инструментов на разработку. 59% опрошенных сопровождающих отметили увеличение числа присылаемых изменений, но около 25% присылаемых pull-запросов признаны низкокачественным AI-слопом. Если рассматривать только крупные проекты, то рост числа изменений отметили 69% опрошенных, а доля AI-слопа среди pull-запросов оценена в 31%.
Среди других тенденций:
AI позволил ускорить выполнение задач, связанных с написанием кода,
у 52% опрошенных, и обсуждением предложений у 19%. Но 21% респондентов заявили, что применение AI лишь замедлило решение очень сложных задач.
66% опрошенных тратят сэкономленное время на устранение технического долга, 63% - на создание новой функциональности и 58% - на обучение.
71% сопровождающих считают, что AI снижает порог вхождения в разработку открытых проектов, но 53% полагают, что применение AI подрывает доверие со стороны сообщества.
35% проектов явно обозначили в правилах возможность использования AI, а 32% не имеют подобных правил и не планируют их введение.
61% участников разработки заявили, что перед отправкой изменений проводят детальное рецензирование и полное тестирование сгенерированного через AI кода, но не всегда упоминают, что использовали AI.
46% сопровождающих полагают, что AI повышает потребность в наставниках для новых участников, а 32% считают, что снижает.
52% используют генеративные AI-инструменты ежедневно, 23% - почти каждый день, 20% - еженедельно, 3% - раз в месяц, 2% - реже, чем раз в месяц.
20% опрошенных не используют AI, 58% используют AI для задач, не связанных с разработкой, а 59% - для задач, связанных с разработкой.
Разработчики PHP анонсировали публикацию сегодня в 17:00 (MSK) экстренных корректирующих выпусков (8.5.12, 8.4.27, 8.3.36 и 8.2.35), в которых будут устранены две критические уязвимости. Всем администраторам серверов с PHP рекомендовано незамедлительно установить исправления на своих системах, сразу после их выпуска. Официально детали будут раскрыты только после появления исправлений, но судя по появившейся в открытом доступе информации, речь про уязвимости CVE-2026-109618 и CVE-2026-109619, потенциально позволяющие удалённо выполнить свой код на любом web-сервере, выполняющем PHP-скрипты в конфигурации по умолчанию. Проблемы проявляются во всех версиях, начиная с PHP 5.4.
В сети уже появились прототипы эксплоитов (1, 2) для проверки подверженности систем уязвимости. В примечании к эксплоиту утверждается, что уязвимости вызваны обращением к уже освобождённой памяти в обработчике отслеживания прогресса загрузки файлов на сервер (session.upload_progress). Наличия на сайте функциональности для загрузки файлов для совершения атаки не требуется, достаточно автоматического срабатывания в PHP-интерпретаторе обработчика контента "multipart/form-data". Для успешной эксплуатации требуется определение раскладки структур в памяти процесса, которая специфична в каждой сборке (проблема решается перебором в эксплоите смещений, заранее вычисленных для пакетов из разных дистрибутивов).
В качестве обходного пути защиты встречаютсярекомендации выставить в php.ini параметр "session.upload_progress.enabled = off" (или "php_admin_flag[session.upload_progress.enabled] = off" в PHP-FPM), но представитель проекта PHP, а также автор первого прототипа эксплоита утверждают, что для блокирования обеих уязвимостей этого недостаточно. В примечании ко второму прототипу эксплоита упоминается, что помимо вышеупомянутой настройки в php.ini для предотвращения атаки без применения патча требуется полная блокировка запросов с типом контента "multipart/form-data", которая приведёт к невозможности загрузки файлов через web-формы.
В Apache httpd для блокировки multipart-запросов можно использовать следующее правило в mod_rewrite:
Дополнение: Опубликованы корректирующие выпуски PHP 8.5.12, 8.4.27, 8.3.36 и 8.2.35, а также подробности об исправленных критических уязвимостях. Разбор уязвимостей и официально рекомендованных обходных методов защиты опубликован в отдельной новости.
Компания Mozilla предупредила о компрометации закрытых ключей, связанных с восемью промежуточными (вторичными) корневыми сертификатами удостоверяющего центра eMudhra. Скомпрометированные ключи позволяли для любого сайта выпустить поддельные TLS-сертификаты, воспринимаемые как заслуживающие доверия во всех браузерах, и использовать их для перехвата или модификации транзитного трафика.
Закрытые ключи были воссозданы исследователями из имеющихся в публичном доступе данных, что стало возможным из-за ошибки в процессе генерации ключей на базе эллиптической кривой P-384. Ошибка привела к тому, что ключи были сгенерированы с использованием при инициализации целых чисел меньше 256 вместо криптографически стойких случайных чисел, т.е. размер закрытого ключа составил 1 байт вместо должных 48 байт. При такой генерации закрытый ключ может быть воссоздан c помощью алгоритма дискретного логарифмирования или простым перебором с генерацией первых 256 возможных ключей. Так как значения закрытых ключей теперь известны (4, 56, 66, 115, 155, 156, 230 и 237), всем пользователям рекомендуется срочно обновить браузеры и пакеты с корневыми сертификатами.
В качестве доказательства утечки закрытых ключей сообщивший об инциденте исследователь опубликовал сообщение, подписанное закрытыми ключами от каждого из восьми скомпрометированных сертификатов eMudhra. Проверить свой браузер на предмет обновления информации об отозванных сертификатах можно на сайте, посвящённом инциденту.
Экстренно сформированы корректирующие выпуски Firefox 158.0.1, 115.43.1 и 153.5.1, а также библиотеки NSS 3.131.1, в которых обновлено хранилище корневых сертификатов и заблокированы проблемные сертификаты. В Chrome и продуктах Google скомпрометированные сертификаты заблокированы 17 октября, в Apple - 19 октября, а в Microsoft - 20 октября. Блокировка также выполнена через централизованные списки отозванных сертификатов OneCRL, CRLite и CRLSets.
Пакеты с обновлёнными корневыми сертификатами выпущены для Ubuntu (ca-certificates 20260816ubuntu0.2*.04.1), Debian (ca-certificates 20250419+deb13u1), Arch Linux (ca-certificates-mozilla 3.131.1-1), Gentoo (ca-certificates 20260816.3.125), curl, Homebrew, Go (1.27.3, 1.26.10), Python, RustTLS, Electron, Elixir, Node.js и FreeBSD. Необновлёнными остаются списки корневых сертификатов в Bun и Composer.
До обновления пакета ca-certificates для ручного удаления проблемных корневых сертификатов в Debian и Ubuntu можно использовать команду:
Дополнение: Компания eMudhra опубликовала связанное с инцидентом заявление, в котором говорится, что проблемные корневые сертификаты eMudhra были сгенерированы в сертифицированном HSM и прошли независимый аудит.
Для обсуждения в списке рассылки разработчиков ядра Linux опубликованы патчи с реализацией файловой системы BeamFS, использующей кодирование Рида - Соломона для определения и восстановления повреждённых данных по месту в конфигурациях с одним накопителем. Основными областями применения BeamFS называются бортовые компьютеры спутников, оборудование в кабинетах лучевой терапии и прочие системы, работающие в условиях повышенной радиации, для которых возвращение искажённых данных более критично, чем невозможность прочитать информацию.
По умолчанию BeamFS может восстановить до 8 потерянных байт в каждом 255-байтовом блоке при накладных расходах 7% (288 байт кодов восстановления на каждые 4096 байт хранимых данных). Коды коррекции ошибок применяются не только для данных, но и для служебной информации в суперблоке, inode, индексах директорий и битовых картах. Проверка целостности и попытки восстановления недостающих данных осуществляются при каждой операции чтения. Если гарантировать корректность информации не удаётся, операция завершается ошибкой "-EIO", что исключает скрытое возвращение повреждённых данных.
Проведённые эксперименты показали, что при облучении платы i.MX 8M Plus с Linux и ФС ext4 протонами с энергией от 20 до 58 мэВ, 90% всех сбоев возникало на уровне файловой системы и драйверов устройств хранения. Также была проведена симуляция одиночных искажений битов при чтении с носителя: BeamFS и Btrfs успешно распознали повреждение данных и всегда возвращали ошибку, в то время как ext4 и ext3 молча возвращали искажённые данные.
BeamFS обеспечивает целостность и восстановление только на стадии от чтения с физического носителя до передачи в страничный кэш в оперативной памяти. Целость хранения в оперативной памяти может поддерживаться при помощи чипов памяти с коррекцией ошибок.
Из ограничений BeamFS отмечается отсутствие поддержки журналирования и режима Copy-on-Write (CoW) - метаданные на накопитель записываются неупорядоченно, поэтому в случае некорректного завершения работы требуется полная проверка при помощи fsck.
Кроме BeamFS недавно для ядра Linux были предложены ещё две файловые системы:
На прошедшей несколько дней назад конференции Linux Plumbers Conference 2026 инженер из компании Huawei представил (видео, слайды) файловую систему XMFS (cross-node eXpress Memory File System) для ядра Linux, предназначенную для использования в кластерах с общей для всех узлов разделяемой оперативной памятью (как tmpfs, но для памяти всех узлов). XMFS даёт возможность использовать стандартный POSIX-интерфейс файловых систем для работы с внешней памятью, адресуемой напрямую при помощи таких технологий как CXL 3.0 (Compute Express Link) и Huawei United Bus. Проект находится на стадии экспериментального прототипа, проходящего внутреннее тестирование, и пока не готов для передачи в состав ядра.
Файловая система имеет классическую для распределённых файловых систем архитектуру с выделением сервера, отвечающего за журналирование, поддержание таблиц inode и сопоставление содержимого и метаданных с памятью отдельных узлов.
При тестировании использования XMFS для таких задач как совместный доступ к образам контейнеров с разных узлов реализация показала производительность близкую с tmpfs с включением больших страниц памяти (2 MB huge pages).
При помощи AI подготовлена файловая система MeshXFS, представляющая собой форк XFS, адаптированный для одновременного использования на нескольких узлах в кластере. MeshXFS даёт возможность примонтировать общее блочное устройство в режиме чтения-записи на разных узлах, поддерживать целостность и управлять блокировками при одновременном обращении к данным. Проект начинался как эксперимент по проверке возможности создания при помощи AI-моделей Linux-драйвера с файловой системой, поддерживающей распределённые блокировки, параллельный доступ и восстановление после сбоев. Основная работа выполнена при помощи Claude Opus, но для решения особо сложных проблем точечно привлекались модели Claude Fable, GPT, Gemini и Astra. Эксперимент признан успешным и уже опубликовано несколько рабочих релизов MeshXFS.
Из дополнительных возможностей, реализованных поверх XFS, отмечены два режима управления распределёнными блокировками (синхронизация по сети и хранение состояния на отдельном общем диске), обеспечение непротиворечивости кэша на разных узлах, ведение журнала для восстановления и адаптация дискового формата и утилит для специфики кластерной ФС. Поддерживается работа с общим хранилищем, подключённым через iSCSI (протестировано на 16 узлах), или при репликации блочного устройства при помощи DRBD. Координация блокировок, функции обнаружения узлов, проверка доступности и определение сбойных узлов реализованы в одном общем модуле ядра. Работа проверена в Proxmox VE 9, RHEL 9, Ubuntu 24.04/26.04 и Debian 12/13.
Представлен выпуск свободной UNIX-подобной операционной системы OpenBSD 8.0. Проект OpenBSD был основан Тэо де Раадтом (Theo de Raadt) в 1995 году после конфликта с разработчиками NetBSD, в результате которого для Тэо был закрыт доступ к CVS репозиторию NetBSD. После этого Тэо де Раадт с группой единомышленников создал на базе дерева исходных текстов NetBSD новую открытую операционную систему, главными целями развития которой стали переносимость (поддерживается 13 аппаратных платформ), стандартизация, корректная работа, проактивная безопасность и интегрированные криптографические средства. Размер полного установочного ISO-образа базовой системы OpenBSD 8.0 составляет 794 МБ.
Кроме непосредственно операционной системы, проект OpenBSD известен своими компонентами, которые получили распространение в других системах и зарекомендовали себя как одни из наиболее безопасных и качественных решений. Среди них: LibreSSL (форк OpenSSL), OpenSSH, пакетный фильтр PF, демоны маршрутизации OpenBGPD и OpenOSPFD, NTP-сервер OpenNTPD, почтовый сервер OpenSMTPD, мультиплексор текстового терминала (аналог GNU screen) tmux, демон identd с реализацией протокола IDENT, BSDL-альтернатива пакету GNU groff - mandoc, протокол для организации отказоустойчивых систем CARP (Common Address Redundancy Protocol), легковесный http-сервер, утилита синхронизации файлов OpenRSYNC.
OpenBSD 8.0 стал 61 релизом проекта. Значительное изменение номера версии обусловлено использованием десятичной нумерации, в соответствии с которой следом за выпуском 7.9 следует 8.0. Основныеизменения:
Для архитектуры amd64 размер адресуемого ядром виртуального адресного пространства увеличен с 4 ГБ до 512 ГБ. В модуле pmap реализована рандомизация базового адреса прямого отображения (direct map) всей физической памяти на виртуальные адреса.
На системах с архитектурой arm64 реализована поддержка спящего режима с сохранением содержимого памяти на диск (hibernate).
Для архитектур arm64 и riscv64 добавлена поддержка промежуточных буферов (bounce buffer), применяемых при невозможности прямой адресации всей памяти со стороны устройства, передающего данные в режиме DMA.
Для ускорения шифрования данных в разделе подкачки (swap) на системах amd64 и arm64 задействованы AES-инструкции CPU.
Для архитектуры riscv64 реализовано определение поддерживаемых расширений CPU и передача сведения о них в пространство пользователя (данные можно получить при помощи флагов AT_HWCAP и AT_HWCAP2 в функции elf_aux_info).
Добавлена поддержка расширении "V" (векторные операции), Sstc (операции с таймером) и AIA (Advanced Interrupt Architecture, обработка прерываний), а также драйверов imsi и aplic для соответствующих контроллеров прерываний.
Порт для архитектуры sparc64 переведён на использование инструментария LLVM.
Прекращена поддержка аппаратной платформы Loongson добавленной в 2010 году для MIPS-совместимых китайских процессоров Loongson 2E и 2F. Причиной удаления стали проблемы со сборкой для платформы mips64el в новых версиях компилятора Clang.
Реализация фреймворка drm (Direct Rendering Manager) и графических драйверов для GPU AMD (radeondrm, amdgpu) и Intel синхронизирована с ядром Linux 6.18.53 (в прошлом выпуске - 6.18.22). В драйвер inteldrm перенесена поддержка графических карт Intel серии Arc A (DG2/Alchemist). Решены проблемы с появлением таймаутов на системах с GPU Intel Alder Lake. Добавлена поддержка адресации более 4 ГБ видеопамяти.
В ядре улучшена эвристика обработки неактивных страниц памяти при вытеснении в раздел подкачки и освобождении памяти. Добавлена функция getexecpath для определения абсолютного пути к исполняемому файлу текущего процесса. Проведена подготовка к увеличению размера дисковых меток (disklabel).
Расширена поддержка спящего режима, который теперь корректно поддерживается в драйверах qwz (Qualcomm Wi-Fi 7 IEEE 802.11a/ac/ax/b/g/n), ufshci (Universal Flash Storage Host Controller) и qcuart (Qualcomm GENI UART). Изменения позволили решить проблемы с переходом в спящий режим ноутбуков и планшетов, таких как Samsung Galaxy Book4 Edge, HONOR MagicBook Art 14 Snapdragon и IdeaPad. Добавлена глобальная переменная для перехода в спящий режим, разделяющая гибернацию и ждущий режим.
В гипервизоре vmd появилась поддержка многопроцессорности в виртуальных машинах с возможностью использования до 64 виртуальных CPU. Для гостевых систем реализован режим x2apic, а также режимы lapic и ioapic для запуска 32-разрядных гостевых систем с Linux. Улучшена работа с образами в формате qcow.
В звуковом сервере sndiod реализован серверный режим управления, позволяющий динамически менять настройки утилитой sndioctl. В sndioctl появилась поддержка добавления и удаления элементов списков, а также настройки проброса MIDI-портов.
Расширена поддержка оборудования и добавлены новые драйверы для
Ethernet-контроллеров Intel E610, Panther Lake и Wildcat Lake, сенсорных экранов GXTP7936 (Samsung Galaxy Book4 Edge), PCIe-контроллера SpacemiT K3, SABI (Samsung Advanced BIOS Interface), контроллеров заряда Samsung, OTP-памяти Rockchip, APU AMD "Krackan Point", SoC SpacemiT K3 и Qualcomm Glymur (X2). Внесены многочисленные улучшения в драйвер qwx (Qualcomm Wi-Fi 6 IEEE 802.11a/ac/ax/b/g/n).
В acme-client добавлена поддержка масок при задании альтернативных имён.
В tmux реализован безрамочный режим показа меню, расширена поддержка UTF-8, добавлена команда "T" для изменения заголовка панели, добавлена команда refresh-now, в команду new-pane добавлена поддержка модальных панелей (-O) и флаг "-K" для обработки в подобных панелях всех нажатий клавиш, в команду capture-pane добавлены флаги "-H" и "-L" для показа гиперссылок и номеров строк.
В LibreSSL улучшена совместимость с AIX, FreeBSD, macOS, MinGW, NetBSD и Windows, а также улучшена поддержка кода на языке ассемблера для разных платформ. Добавлен API dtls12_handshake_msg. Повышена производительность SHA-3.
Число портов для архитектуры AMD64 составило 13060 (было 13044), для aarch64 - 12907 (было 12883), для i386 - 10659 (было 10631). Среди версий приложений в портах:
Asterisk 20.21.0 и 22.11.0
Audacity 3.7.9
CMake 4.3.5
Chromium 154.0.8037.92
Emacs 31.1
FFmpeg 9.0.2
GCC 16.1.0
GHC 9.10.3
GNOME 49
Go 1.27.1
JDK 11.0.32, 17.0.20, 21.0.12 и 25.0.4
KDE Plasma 6.7.5, KDE Gear 26.08.1, KDE Frameworks 6.30.0
После 11 месяцев разработки опубликован выпуск инструментария CRIU 4.3 (Checkpoint and Restore In Userspace), предназначенного для сохранения и восстановления процессов в пространстве пользователя. Инструментарий позволяет сохранить состояние одного или группы процессов, а затем возобновить работу с сохранённой позиции, в том числе после перезагрузки системы или на другом сервере без разрыва уже установленных сетевых соединений. Код проекта написан на языке Си и распространяется под лицензией GPLv2. CRIU применяется в таких системах управления контейнерами, как OpenVZ, LXC/LXD и Docker. Необходимые для работы CRIU изменения включены в основной состав ядра Linux.
Из областей применения технологии CRIU отмечается обеспечение перезагрузки ОС без нарушения непрерывности выполнения длительно выполняемых процессов, Live-миграция изолированных контейнеров, ускорение запуска медленных процессов (можно начать работу с состояния, сохранённого после инициализации), проведение обновлений ядра без перезапуска сервисов, периодическое сохранение состояния длительно выполняемых вычислительных задач для возобновления работы в случае аварийного завершения, балансировка нагрузки на узлы в кластерах, дублирование процессов на другую машину (fork на удалённую систему), создание снапшотов пользовательских приложений в процессе работы для их анализа на другой системе или на случай если потребуется отменить дальнейшие действия в программе.
Реализована возможность сжатия блоков и страниц памяти с использованием алгоритма LZ4 и многопоточной распаковкой.
Повышена производительность благодаря задействованию асинхронного ввода/вывода (AIO) при восстановлении страниц VMA (Virtual Memory Area ), новому методу остановки задач без применения аппаратных точек останова и распараллеливанию восстановления memfd и анонимной разделяемой памяти.
Добавлена поддержка расширения ARM64 GCS (Guarded Control Stack), обеспечивающего аппаратную защиту адресов возврата из функций. После передачи управления функции, адреса возврата сохраняются процессором не только в обычном стеке, но и в отдельном теневом стеке, который не может быть изменён напрямую. Перед выходом из функции адрес возврата извлекается из теневого стека и сверяется с адресом возврата из основного стека.
Добавлен бэкенд для сохранения состояния API драйвера NVIDIA CUDA.
Обеспечено восстановление маппинга GPU.
Для драйвера amdgpu реализовано сохранение и восстановление состояния буферов подсистемы DRM (Direct Rendering Manager) и файловых дескрипторов DMA-BUF.
Добавлены команды для сжатия и распаковки образов памяти в offline-режиме.
Добавлена поддержка сохранения и восстановления информации о привязке UID-идентификаторов к сетевым сокетам.
Добавлена опция "--image-io-mode" для записи и чтения образов страниц памяти в режиме O_DIRECT (в обход страничного кэша).
