В средах разработки и исполнения CODESYS обнаружили две уязвимости. Одна даёт чужому шлюзу возможность исчерпать память клиентской программы, вторая искажает данные, когда к контроллеру одновременно обращаются несколько систем. Разработчик CODESYS GmbH исправляет обе в версиях 3.5.22.40 и 4.23.0.0. Вторая выйдет только в четвёртом квартале 2026 года, поэтому часть контроллеров пока остаётся незакрытой.
Детали уязвимостей
Первая проблема кроется в клиенте шлюза. Этот компонент связывает среду разработки с логическим контроллером и передаёт команды между ними. В ответе сервера есть поле с размером данных, и клиент принимает указанное там число без проверки. Злоумышленник, который управляет шлюзом, подставляет завышенное значение. Клиент начинает запрашивать всё больше памяти и в какой-то момент исчерпывает её. Программа перестаёт отвечать. Для атаки достаточно, чтобы инженер подключился к подконтрольному узлу. Идентификатор уязвимости - CVE-2026-76992, оценка 7.5 по шкале CVSS.
Под удар попадают среда разработки CODESYS Development System 3, сам CODESYS Gateway, версия Edge Gateway для Windows, панель оператора HMI, сервер OPC DA, библиотека PLCHandler и набор Runtime Toolkit, из которого производители собирают собственные среды исполнения. Все они обновляются до 3.5.22.40. Исключение составляет Edge Gateway для Linux: для него готовят версию 4.23.0.0. Скачать исправления можно установщиком CODESYS, из магазина CODESYS Store и в разделе загрузок на сайте codesys.com/download.
Вторая уязвимость сидит в механизме мониторинга. Через него инженер читает и меняет значения переменных в работающей программе, а панель оператора получает те же данные для отображения. Когда запросы приходят сразу от нескольких клиентов, обработка идёт без должной синхронизации. Поэтому часть значений может быть прочитана или записана неверно. Поведение контроллера становится непредсказуемым, вплоть до отказа в обслуживании. Здесь идентификатор CVE-2026-79625, а оценка выше - 8.1 по шкале CVSS.
Однако воспользоваться этой ошибкой не так просто. Атакующему нужен действующий доступ с правами мониторинга, то есть сначала придётся получить учётные данные. Зато дальше хватает параллельных запросов, чтобы сбить логику обмена. Особенно уязвимы конфигурации, где к одному контроллеру подключено несколько систем одновременно: среда разработки, панель оператора и диспетчерский комплекс.
Список затронутых продуктов здесь шире. Это среды исполнения CODESYS Control для Linux и Linux ARM, Raspberry Pi, промышленных ПК и встраиваемых платформ, версии для Beckhoff CX, PFC100 и PFC200, PLCnext, панелей WAGO Touch Panels 600, а также Virtual Control SL и Safety SIL2. Логические контроллеры на базе Runtime Toolkit и Safety SIL2 уязвимы при условии, что допускают одновременное подключение двух и более клиентов. В CODESYS Development System 3 встроенная среда моделирования защищена по умолчанию: внешний доступ к ней включают вручную через отдельную настройку.
До версии 3.5.22.40 обновляют среды Control RTE, Control Win, Runtime Toolkit, Safety SIL2, панель HMI и среду разработки. Все перечисленные ранее платформы для Linux и встраиваемых систем, а также Virtual Control SL ждут релиза 4.23.0.0. Порядок получения обновлений тот же: установщик, магазин или сайт разработчика.
Масштаб проблемы объясняется устройством рынка промышленной автоматизации. CODESYS лицензируют десятки производителей, и один и тот же код уходит в контроллеры разных брендов. Ошибка в общем компоненте проявляется сразу у множества моделей, хотя выглядит как локальная недоработка. По данным производителя, случаев эксплуатации в реальных атаках не зафиксировано. Отчёт об уязвимости в клиенте шлюза подготовила компания Delta Electronics, координировал раскрытие центр CERT@VDE.
Практическая сторона важнее формальной. Обновлять нужно не только сам контроллер, но и среду разработки, а также шлюзы и панели, через которые идёт подключение. Пока версия 4.23.0.0 не вышла, устройства на Linux и встраиваемых платформах остаются без защиты, и на этот период стоит ограничить круг узлов, к которым разрешено подключаться инженерам. Производственные сети часто строятся вокруг одного доверенного шлюза, и его компрометация открывает путь ко всем связанным контроллерам. Ограничение доступа к нему и отказ от подключения к незнакомым узлам снижают риск сильнее, чем проверка журналов после сбоя.
Ссылки
