Positive Development Community

🔍 Наиболее интересные уязвимости 🐛 CVE-2026-54910, обнаруженная в FileBrowser Quantum до версии 1.4.3-beta, приводит к Path Traversal. Проблема заключалась в том, что эндпоинт GET /api/media/subtitles использовал переданные пользователем параметры path и name при работе с файловой системой без проверки, что позволяло любому авторизованному пользователю читать доступные процессу сервера файлы, включая ключи, учётные данные и конфигурацию. В исправлении разработчики отказались от непосредственного построения пути по входным параметрам: сначала запрашивается информация о доступном пользователю видеофайле и его субтитрах, после чего имя файла берётся из найденной записи, очищается через filepath.Base() и объединяется с директорией разрешённого видеофайла. 🐛 CVE-2026-17497, обнаруженная в NoteGen до версии 0.32.0, приводит к OS Command Injection. Проблема заключалась в том, что приложение по умолчанию разрешало Tauri-плагину shell запускать bash, python и python3 с произвольными аргументами, что позволяло злоумышленнику вызвать plugin:shell|execute и выполнить произвольные команды операционной системы с правами процесса NoteGen. В исправлении разработчики удалили из конфигурации разрешения на выполнение произвольных команд через Tauri Shell Plugin. 🐛 CVE-2026-47752, обнаруженная в Tugtainer до версии 1.30.2, приводит к Server-Side Template Injection (SSTI). Проблема заключалась в том, что поля title_template и body_template обрабатывались обычным окружением jinja2.Environment без изоляции опасных возможностей шаблонизатора, что позволяло авторизованному пользователю получить доступ к объектам Python и выполнить произвольные команды операционной системы с правами root внутри контейнера. В исправлении разработчики заменили jinja2.Environment на SandboxedEnvironment, ограничивающее доступ шаблонов к опасным атрибутам, методам и объектам Python. 🐛 CVE-2026-57531, обнаруженная в Milkdown до версии 7.21.3, приводит к Cross-site Scripting (XSS). Проблема заключалась в том, что обработчик parseDOM.getAttrs сохранял содержимое HTML-элемента span с атрибутом data-type="emoji" без очистки, а при последующей сериализации в Markdown это значение напрямую записывалось в innerHTML, что позволяло злоумышленнику внедрить вредоносный HTML- или JavaScript-код, который выполнялся при обработке вставленного содержимого. В исправлении разработчики добавили очистку HTML перед записью в DOM и исключили использование необработанного содержимого при сериализации. 🐛 CVE-2026-65919, обнаруженная в Meshery до версии 1.0.57, приводит к Path Traversal. Проблема заключалась в том, что эндпоинты /api/system/fileView и /api/system/fileDownload передавали полученный от пользователя параметр file напрямую в os.Open() без проверки пути, что позволяло злоумышленнику прочитать любой файл, доступный процессу Meshery. В исправлении разработчики добавили функцию SafeOpenFile(), которая разрешает чтение только из каталогов журналов ~/.meshery/logs, проверяет нахождение итогового пути внутри разрешённой директории и открывает файл через os.OpenRoot().

Спонсором сегодняшней задержки мемов просьба считать сети связи и их ТСПУ одной северной столицы 🫠 Всем классного (и правильного) завершения вечера и чудесных выходных 🤗

Контейнеры видите? Я разгрузил защитил. Теперь ваша очередь Если вы любите контейнеры — даже когда они не отвечают вам взаимностью, — приходите 10–14 августа. Будет хакатон по runtime security, безопасности контейнеров и Kubernetes. Берите толковых пацанов или девчонок. Не больше пятерых. Расследуйте события безопасности в кластерах. Придете один — тоже вариант. Соберем команду на месте. На играх без правил — играйте без правил. С правилами — по правилам Тема такая: сначала регистрация на Standoff 365. Сделайте это сейчас. Не завтра. Сейчас. В начале — у всех все одинаково: найти нужное событие в Runtime Radar, понять контекст, накидать детектор. Но сложность выбираете сами, как в бою игре: 🟢 На изи — ищите событие стандартными фильтрами. 🟡 На нормале — добавьте аналитику, контекстный поиск и дополнительные атрибуты. 🟣На харде — создайте или измените политику мониторинга.

Для тех, кто не в теме: *Runtime Radar — наше опенсорсное решение для защиты контейнеров и мониторинга в реальном времени. Недавно рассказывали, как работает.

Справитесь — шлите все нашим экспертам. Они проверят все. Вообще все. И выберут лучших. Кто победил — тот и победитель. Без вариантов Хакатонить можно где угодно. Под одеялом. В домике в лесу. В хипстерской кофейне. Стоя на двух грузовиках. Но финал — только в офисе Позитива. 14 августа соберем вас там на офлайн-тусовку. Расскажем, кто чего нарешал. Наградим победителей. И просто норм проведем время. Если участвуете — значит, вы участник. Можете выиграть лимитированный мерч и главный приз — цифровой мультитул Flipper Zero. Я сказал (с) Json S. @Positive_Technologies

🔍 Наиболее интересные уязвимости 🐛 CVE-2026-45576, обнаруженная в zrok версий от 0.4.23 до 2.0.3, приводит к Path Traversal. Проблема заключалась в том, что команда zrok2 copy принимала полученные из WebDAV или zrok Drive пути без надёжной проверки и передавала их в FilesystemTarget.WriteStream(), что позволяло выйти за пределы выбранной локальной директории и записать файл в другое место файловой системы. В исправлении разработчики добавили проверку и нормализацию виртуальных путей, а файловые операции перевели на os.OpenRoot(), ограничивающий создание и изменение файлов корневой директорией назначения. 🐛 CVE-2026-54498, обнаруженная в ViewComponent версий от 4.0.0 до 4.12.0, приводит к Cross-site Scripting (XSS). Проблема заключалась в том, что метод around_render мог вернуть небезопасную HTML-строку в обход экранирования, а ViewComponent::Collection#render_in объединял результаты компонентов через join() и безусловно помечал итоговую строку как безопасную с помощью html_safe, что позволяло злоумышленнику внедрить вредоносный HTML- или JavaScript-код, который выполнялся в браузере пользователя. В исправлении разработчики добавили повторную проверку и экранирование результата around_render, а объединение коллекций перевели на safe_join,. 🐛 CVE-2026-16124, обнаруженная в GoClaw до версии 3.15.0-beta.33, приводит к Server-Side Request Forgery (SSRF). Проблема заключалась в том, что защита компонента web_fetch не считала служебные диапазоны 198.18.0.0/15 и 240.0.0.0/4 запрещенными, что позволяло пользователю с доступом заставить сервер отправить запрос на адрес из этих подсетей и тем самым обойти фильтрацию. В исправлении разработчики добавили оба диапазона в списки запрещённых адресов, используемые функциями CheckSSRF и isPrivateIP. 🐛 CVE-2026-44342, обнаруженная в New API до версии 0.12.0-alpha.1, приводит к Cross-Site Request Forgery (CSRF). Проблема заключалась в том, что привязка адреса электронной почты и учётной записи WeChat выполнялась через GET-запросы к /api/oauth/email/bind и /api/oauth/wechat/bind, что позволяло злоумышленнику подготовить ссылку, при переходе по которой браузер авторизованного пользователя отправлял запрос с его сеансовыми файлами cookie и привязывал к аккаунту подконтрольный атакующему адрес или идентификатор WeChat. В исправлении разработчики заменили эти операции на POST-запросы и перенесли коды подтверждения из параметров URL в тело JSON-запроса. 🐛 CVE-2026-53963, обнаруженная в Discourse до версий 2026.1.5, 2026.4.2, 2026.5.1 и 2026.6.0, приводит к Cross-site Scripting (XSS). Проблема заключалась в том, что название второго фактора аутентификации, заданное пользователем, выводилось в диалоге подтверждения удаления без экранирования специальных символов, что позволяло злоумышленнику сохранить и выполнить вредоносный JavaScript-код. В исправлении разработчики добавили экранирование названия второго фактора перед его отображением в интерфейсе с помощью метода escapeExpression().

В славянском фольклоре пятница олицетворялась со святой Параскевой. В народе её часто называли Параскева-Пятница, и она считалась защитницей женщин, брака и домашнего очага. Каким образом, при такой-то покровительнице, современная пятница обрела свою правильную часть — видимо уже навсегда останется загадкой для современных историков. Но, как говорится, «было и было». Что ж теперь, обратно всё менять, в самом деле? 🤷‍♂️ Всем чудесного вечера! 🤗(и не забудьте поднять тосты за женщин, брак и домашний очаг, раз уж так вышло)

Коллеги, привет! Мы изучаем, как сегодня DevSecOps-, AppSec- и ИБ-специалисты выстраивают процессы безопасности приложений: какие инструменты используют, как принимают решения, что действительно помогает в ежедневной работе, а что, наоборот, создает лишнюю нагрузку. Если вы работаете с AppSec-инструментами - SAST, DAST, SCA и другими - нам очень важно узнать ваш реальный опыт и как процессы безопасной разработки устроены на практике: что удобно, какие задачи возникают чаще всего, какие сценарии автоматизации востребованы и как сегодня развивается AppSec в компаниях. 🕒 Опрос займет 3-5 минут. Все ответы будут использоваться только в обобщенном виде для исследования пользовательских сценариев и развития продуктов. Будем благодарны, если найдете несколько минут и поделитесь своим опытом. Пройти опрос

🔍 Наиболее интересные уязвимости 🐛 CVE-2026-50133, обнаруженная в Hugo до версии 0.162.0, приводит к Cross-Site Scripting (XSS). Проблема заключалась в том, что содержимое файлов с типом text/html без очистки переносилось в сформированную страницу, что позволяло при обработке HTML из недоверенного источника внедрить произвольный JavaScript-код. В исправлении разработчики запретили использование содержимого text/html по умолчанию и добавили проверку типа содержимого через настройку security.allowContent. 🐛 CVE-2026-42153, обнаруженная в Coolify до версии 4.0.0-beta.474, приводит к OS Command Injection. Проблема заключалась в том, что пользовательские значения postgres_user и postgres_db подставлялись в строковую команду проверки работоспособности PostgreSQL, выполняемую через командную оболочку, что позволяло аутентифицированному злоумышленнику внедрить и выполнить произвольные команды. В исправлении разработчики отказались от строковой команды CMD-SHELL и стали запускать psql через CMD с отдельным массивом аргументов. 🐛 CVE-2026-58468, выявленная в NocoBase до версии 2.1.20 включительно, приводит к Server-Side Request Forgery (SSRF). Проблема заключалась в возможности передать URL в узлах рабочих процессов, пользовательских действиях или модуле искусственного интеллекта без проверки значения адреса, что позволяло злоумышленнику заставить сервер обратиться к произвольным хостам. В исправлении разработчики добавили определение опасных адресов и запись предупреждений в журнал, а также расширили применение настройки SERVER_REQUEST_WHITELIST. 🐛 CVE-2026-59149, обнаруженная в Mockoon до версии 9.7.0, приводит к Path Traversal. Проблема заключалась в том, что принадлежность файла разрешённому каталогу проверялась через startsWith() без учёта границы имени директории, что позволяло неаутентифицированному злоумышленнику читать произвольные файлы. В исправлении разработчики заменили строковое сравнение на проверку относительного пути через path.relative(), запретили абсолютные пути и переходы к родительским каталогам, а также исключили использование корня файловой системы в качестве разрешённого каталога для динамически сформированных путей. 🐛 CVE-2026-59834, обнаруженная в SiYuan до версии 3.7.1, приводит к SQL Injection. Проблема заключалась в том, что значения путей, передаваемые в эндпоинт POST /api/search/fullTextSearchBlock, напрямую добавлялись в условия SQL-запроса без параметризации, что позволяло неаутентифицированному злоумышленнику выполнить произвольный SQL код. В исправлении разработчики заменили непосредственную подстановку пользовательских значений в SQL на параметризованные запросы, а также добавили функцию IsValidSearchBoxPath() для проверки корректности идентификаторов блокнотов и путей документов.

Мечтают ли кодинг-агенты о пятницах? Я спросил у своего. Полный ответ приведу в комментариях, но в одном он прав точно:

Для человека Пятница — это символ конца страданий, усталости и порога свободы.

That's my boy 🫂 Шарит ведь, не по годам. Так что... всем поскорее завершить все страдания и переступить «порог свободы», так сказать 🍻

🧩 Принципы и паттерны безопасной разработки: DIP Часть 4. Принцип инверсии зависимостей (Dependency Inversion Principle, DIP) утверждает: модули верхнего уровня не должны зависеть от модулей нижнего уровня, оба должны зависеть от абстракций. При этом не абстракции должны зависеть от деталей, а детали — от абстракций. С точки зрения безопасности, нарушение DIP означает, что высокоуровневая логика (принятие решений, обработка входных данных) жёстко привязана к конкретной низкоуровневой реализации. Когда эта реализация меняется или расширяет поверхность атаки — высокоуровневый модуль наследует проблему автоматически, без какого-либо контроля на своей стороне. 💡 Пример

// С нарушением DIP
class DataBinder {
    void bind(Object target, Map<String,String> params) {
        for (PropertyDescriptor pd :
                Introspector.getBeanInfo(target.getClass())
                    .getPropertyDescriptors()) {
            if (params.containsKey(pd.getName()))
                pd.getWriteMethod().invoke(target, params.get(pd.getName()));
        }
    }
}

// С соблюдением DIP
interface BindablePropertyResolver {
    List<BindableProperty> resolve(Class<?> type);
}

class DataBinder {
    private final BindablePropertyResolver resolver;

    void bind(Object target, Map<String,String> params) {
        for (BindableProperty bp : resolver.resolve(target.getClass())) {
            if (params.containsKey(bp.name()) && bp.isSafe())
                bp.set(target, params.get(bp.name()));
        }
    }
}

Абстракция BindablePropertyResolver контролируется высокоуровневым модулем и определяет контракт: что можно связывать, а что — нет. Даже если интроспекция обнаружит новые свойства, они не станут доступны без явного разрешения. Помимо архитектурного разделения, главным правилом остается биндинг входных данных строго к выделенным DTO (Data Transfer Objects), а не к доменным сущностям или объектам фреймворка. DTO содержит только явно разрешенные поля, что исключает динамический биндинг опасных свойств. Нарушения DIP провоцируют: • CWE-913: Improper Control of Dynamically-Managed Code Resources • CWE-470: Use of Externally-Controlled Input to Select Classes or Code • CWE-915: Improperly Controlled Modification of Dynamically-Determined Object Attributes 🐛 Жизненное CVE-2022-22965 — Spring Framework RCE, она же Spring4Shell (CVSS 9.8). Механизм привязки параметров (data binding) в Spring MVC — высокоуровневый модуль, отвечающий за маппинг HTTP-параметров в свойства Java-объектов. Внутри он напрямую зависит от низкоуровневого Java Beans Introspection API (CachedIntrospectionResults → java.beans.Introspector), рекурсивно обходящего цепочки геттеров/сеттеров. На JDK 8 существовал чёрный список: Spring блокировал доступ к class.classLoader. Но в JDK 9 у Class появился новый геттер — getModule(). Через него открылся обходной путь class.module.classLoader, не попавший в чёрный список. Цепочка: class.module.classLoader.resources.context.parent.pipeline.first.* позволяла модифицировать конфигурацию Tomcat AccessLogValve — атакующий менял путь, паттерн и суффикс лога, записывая на диск JSP-файл (web shell). Нарушение DIP здесь в том, что data binding напрямую зависел от конкретного механизма интроспекции (низкоуровневая деталь), без абстракции, определяющей контракт: какие свойства разрешено связывать. Когда деталь (набор доступных PropertyDescriptor-ов) изменилась из-за развития JDK — поверхность атаки расширилась без единого изменения в коде самого Spring. 🔧 Как пофиксили Spring не стал внедрять глобальный белый список (чтобы не сломать обратную совместимость), и добавил чёрный, на уровне интроспекции. Доступ к свойствам Class, classLoader и protectionDomain был полностью заблокирован, что разорвало опасную цепочку... до следующего витка развития JDK, видимо 😬 💻 Как насчет композиционных языков? Оставим это на правах домашнего задания: подумать, как Rust поощряет DIP через трейты, а Go — делая упор на простоту, снижение шаблонного кода и неявные интерфейсы. ⚠ TL;DR: Если модуль верхнего уровня напрямую зависит от деталей реализации нижнего — любое изменение внизу может молча расширить поверхность атаки наверху. Инвертируйте зависимость: пусть высокоуровневый модуль определяет контракт допустимых данных, а низкоуровневый — реализует его. А на входе всегда используйте DTO.

🔍 Наиболее интересные уязвимости 🐛 CVE-2026-58000, обнаруженная в luci-proto-openvpn до версии 0.11.1, приводит к OS Command Injection. Проблема заключалась в том, что в методе generateKey параметр cl_meta подставлялся в shell-команду без экранирования, поэтому аутентифицированный пользователь LuCI с доступом к настройке OpenVPN мог внедрить специальные символы оболочки и выполнить произвольные команды с правами root. В исправлении разработчики начали обрабатывать cl_meta через shellquote(), чтобы пользовательское значение больше не интерпретировалось как часть shell-синтаксиса. 🐛 CVE-2026-58579, обнаруженная в RAGFlow до версии 0.26.3, приводит к Cross-Site Scripting (XSS). Проблема заключалась в том, что имя узла в агентном конвейере сохранялось без очистки, а затем отображалось в окне подтверждения через dangerouslySetInnerHTML, из-за чего аутентифицированный пользователь рабочего пространства мог внедрить произвольный JavaScript-код, который выполнялся в сессии другого пользователя. В исправлении разработчики добавили обработку HTML через DOMPurify.sanitize() перед выводом содержимого в модальном окне. 🐛 CVE-2026-58418, обнаруженная в Gitea до версии 1.26.3, приводит к Server-Side Request Forgery (SSRF). Проблема заключалась в том, что при миграции репозитория проверялся только исходный URL, но затем без повторной проверки совершался переход по HTTP-перенаправлению на новый адрес, что позволяло злоумышленнику обращаться к произвольным хостам. В исправлении разработчики заблокировали HTTP-перенаправления во время клонирования при миграции репозитория. 🐛 CVE-2026-59195, выявленная в pnpm до версий 10.34.4 и 11.8.0, приводит к Path Traversal. Уязвимость обусловлена тем, что pnpm брал имена пакетов из секции configDependencies в pnpm-lock.yaml и напрямую использовал их при создании символьных ссылок и путей в node_modules/.pnpm-config, что позволяло злоумышленнику добиться записи файлов за пределами ожидаемых директорий. В исправлении разработчики добавили предварительную проверку env-lockfile через writeVerifiedEnvLockfile() и валидацию имен и версий зависимостей. 🐛 CVE-2026-59101, обнаруженная в Auto_Bangumi до версии 3.2.8, приводит к Server-Side Request Forgery (SSRF). Проблема заключалась в том, что эндпоинт /api/v1/setup/test-downloader был доступен без аутентификации во время первичной настройки и принимал адрес узла без проверки, что позволяло совершать HTTP-запросы к произвольным хостам. В исправлении разработчики добавили проверку URL через _validate_url(): теперь разрешены только схемы http/https, а частные IP-адреса отклоняются.

Мемы утреннего сбора, категории С0, отборные. Употреблять по одному в час, вплоть до наступления правильной части пятницы ✍️

🔍 Наиболее интересные уязвимости 🐛 CVE-2026-41479, обнаруженная в Authlib до версий 1.6.10 и 1.7.1, приводит к Open Redirect. Суть уязвимости состояла в том, что при неподдерживаемом response_type приложение использовало переданный redirect_uri без проверки, что позволяло направить пользователя на произвольный адрес. В исправлении разработчики перестали передавать request.payload.redirect_uri напрямую в UnsupportedResponseTypeError: сначала код пытается найти клиента и проверить redirect_uri, а если проверка не пройдена, перенаправление больше не выполняется. 🐛 CVE-2026-56317, обнаруженная в Nuxt до версии 3.21.7 и в ветке 4.x до 4.4.7, приводит к Cross-Site Scripting (XSS). Проблема заключалась в том, что компонент NoScript записывал содержимое слота в innerHTML без экранирования, поэтому злоумышленник мог передать вредоносные данные и добиться выполнения скрипта. В исправлении разработчики заменили запись через innerHTML на textContent. 🐛 CVE-2026-58055, выявленная в nghttp2 до версии 1.69.0, приводит к HTTP Request Smuggling. Уязвимость обусловлена тем, что прокси пересылал HTTP/1.1 Upgrade-запросы с Content-Length и телом в повторно используемые keep-alive соединения, что создавало неоднозначную интерпретацию границ запроса и позволяло отравлять очередь ответов для других клиентов. В исправлении разработчики ужесточили обработку CONNECT и Upgrade: для CONNECT с Content-Length теперь возвращается ошибка 400, а для Upgrade-запросов тело больше не допускается и такие данные отклоняются ещё при разборе запроса. 🐛 CVE-2026-48774, обнаруженная в ProxySQL в версиях с 3.0.0 по 3.0.8, приводит к SQL Injection. Проблема заключалась в том, что инструмент run_sql_readonly проверял только первый SQL-оператор и не блокировал передачу нескольких выражений в одном запросе, что позволяло злоумышленнику после формально безопасного SELECT внедрить произвольный SQL код. В исправлении разработчики отключили CLIENT_MULTI_STATEMENTS, добавили отдельное определение многооператорных запросов и расширили список запрещённых SQL-команд. 🐛 CVE-2026-13540, обнаруженная в GitBucket до версии 4.46.1, приводит к Server-Side Request Forgery (SSRF). Проблема заключалась в том, что при создании репозитория через клонирование параметр sourceUrl использовался без достаточных ограничений на адрес назначения, из-за чего удалённый злоумышленник мог заставить сервер обращаться к внутренним или служебным сетевым узлам. В исправлении разработчики добавили проверку адреса источника с помощью метода HttpClientUtil.isPrivateAddress() и "белого" списка адресов

🖥 Скилл `code-review` Казалось бы, зачем ещё один скилл для ревью изменений в коде? Но вот нет, существующие — то не покрывают логические ошибки, то полностью забивают на безопасность, то не дают рекомендаций по исправлению, и т.п. В конце-концов, кто я такой, чтобы не следовать принципу NIH (Not Invented Here)? 🤓 Если серьёзно, то сделал его для встраивания в c0wrk, но скилл получился достаточно сбалансированным, во-первых, и с нормальным покрытием вопросов безопасности, во-вторых. Поэтому решил выделить его и в свою коллекцию, вдруг кому-то окажется полезен и с другими агентами. Лежит здесь, агностичен относительно конкретных агентов и экосистем, предназначен для полноценного ревью изменений (локальных, в конкретных коммитах, ветках или PR/MR). Пример реального отчета скину в комменты. #ИИ_инструменты

Делу — время, потехе — час, мемам — пятница 🤗

❓ Являются ли CVE'хами ложно-отрицательные срабатывания SAST? Хочу немного дополнить пересланный выше 👆пост, и немного порассуждать вокруг вопроса, волновавшего, лично меня, с самого начала упомянутой истории с байпассами PickleScan. Дело в том, что назначение CVE на каждый вид байпасса в SAST-инструменте — несправедливо и категорически неадекватно, как в рамках текущей экосистемы CVE, так и с позиции здравого смысла. CVE (Common Vulnerabilities and Exposures) — это идентификатор для конкретной, известной уязвимости в программном продукте, которая существует в коде и может быть эксплуатирована. False Negative (FN) в SAST — это отсутствие события, уязвимость, которую не удалось обнаружить. Заводить CVE на «отсутствие сигнала» — это все равно что заводить уголовное дело на сигнализацию в магазине, которая не сработала на конкретного воришку. База данных MITRE по их же политике предназначена для «воришек», а не ограничений функциональности средств анализа. В общем виде задача детектирования уязвимости эквивалентна проблеме остановки → является неразрешимой задачей. И множество FN в ЛЮБОМ анализаторе бесконечно. Поэтому любой SAST-движок — это всегда эвристический компромисс между фолзами обоих родов, подробно рассказывал об этом ранее. Если заводить CVE на каждый FN от анализатора, то мы столкнемся с абсурдом: каждая реальная уязвимость в мире потенциально будет иметь множество CVE: один на саму уязвимость (непосредственно в коде), а остальные — на все SAST-инструменты, которые ее не нашли. Это сделает базу CVE бесконечной и бесполезной, так как она захламится "мета-проблемами". Важный нюанс здесь: кто принимает решения на основе SAST? Если инженер видит, что SAST ничего не нашел, и на этом основании утверждает, что код безопасен — это процессная ошибка самого разработчика или секчемпа. SAST — это инструмент снижения рисков, а не гарантия безопасности (в отличие, скажем, от формальной верификации, или доказательного SAST, о котором фантазировал недавно). Ожидать от эвристического анализатора, так или иначе работающего на поиск признаков уязвимости, 100% покрытия — по меньшей мере наивно (по большей — просто тупо). Искажение принимаемых решений по безопасности из-за FN — это проблема культуры DevSecOps и системы компенсирующих мер (ручной код-ревью, динамический анализ DAST, пентесты). Перекладывать эту ответственность на вендора SAST путем заведения CVE — это попытка решить внутреннюю организационную проблему техническим костылем, не более того. ⚠ TL;DR: если заводите CVE на ложно-отрицательное срабатывание в SAST-инструменте, будьте готовы к тому, что после исправления, ложно-положительных, требующих рутинного триажа с вашей же стороны, в нём станет на порядок-другой больше. Потому что этот компромисс именно так и работает. А ещё лучше — поравьте свои процессы DevSecOps 🙂 Это прям реально нужно, раз FN от анализатора в нём сейчас равноценен CVE.

🔍 Наиболее интересные уязвимости 🐛 CVE-2026-48547, обнаруженная в KanaDojo до версии 0.1.18, приводит к OS Command Injection. Проблема заключалась в том, что значения полей version и changes из patchNotesData.json без очистки попадали в вызовы child_process.execSync(), что позволяло атакующему внедрить shell-команды и выполнить их. В исправлении разработчики заменили execSync() на execFileSync() для вызовов git и gh, чтобы передавать аргументы отдельно. 🐛 CVE-2026-55443, обнаруженная в LangChain до версии 1.3.9, приводит к Path Traversal. Проблема заключалась в том, что несколько компонентов, работающих с путями к файлам и шаблонами поиска, недостаточно жёстко ограничивали итоговый путь внутри разрешённого каталога, что позволяло выйти за пределы ожидаемой директории и читать посторонние файлы. В исправлении разработчики начали отклонять абсолютные пути и пути с .., добавили повторную проверку пути после разрешения символьных ссылок через _is_within_root(), а проверки разрешённых префиксов заменили на сравнение с учётом границы сегмента каталога. 🐛 CVE-2026-48818, выявленная в Starlette 1.0.1 и ниже, приводит к Server-Side Request Forgery (SSRF). Проблема заключалась в том, что на Windows обработчик StaticFiles принимал сетевые UNC-пути вида \\<url>\share, и ещё до отклонения такого пути вызывал os.path.realpath(), из-за чего сервер успевал инициировать исходящее SMB-подключение к произвольному хосту. В исправлении разработчики добавили запрет абсолютных путей: если путь начинается с / или \, функция немедленно возвращает пустой результат и не переходит к дальнейшей обработке. 🐛 CVE-2026-56394, обнаруженная в Craft CMS в версиях с 4.0.0-RC1 по 4.17.6 и с 5.0.0-RC1 по 5.9.12, приводит к Path Traversal. Проблема заключалась в том, что эндпоинт assets/icon принимал параметр extension без надлежащей проверки, что позволяло аутентифицированному злоумышленнику передать последовательности перехода по каталогам и читать локальные файлы на сервере. В исправлении разработчики добавили строгую проверку extension через регулярное выражение /^\w+$/ в методах iconUrl() и iconPath(). 🐛 CVE-2026-55743, выявленная в OpenHuman desktop agent до версии 0.54.0, приводит к OS Command Injection. Уязвимость обусловлена тем, что проверка списка разрешённых команд в SecurityPolicy::is_command_allowed() игнорировала префикс из переменных окружения и анализировала только “основную” команду, что позволяло атакующему внедрить произвольные shell-команды и выполнить их. В исправлении разработчики добавили список опасных переменных окружения DANGEROUS_ENV_PREFIXES и начали отклонять команды с такими префиксами на этапе проверки allowlist

☁️ State of DevOps Russia расширяется Исследование State of DevOps Russia в этом году выходит за рамки анализа только DevOps-практик, получает расширение и новое имя — State of Cloud Native Russia. Сохраняя лучшие традиции State of DevOps Russia, в этом году исследование охватывает: ⚙️ DevOps, платформенную инженерию и инфраструктуру; 🤖 использование ИИ и нейросетей в цикле разработки; ☸️ Kubernetes и cloud-native-практики; ☁️ облачные технологии и эксплуатацию. Если вы работаете в разработке, DevOps, SRE, платформенных командах или инфраструктуре — поделитесь своим опытом. Исследование проводится Ассоциацией профессионалов индустрии облачно-ориентированных технологий «АОТ» при поддержке отраслевых партнёров.  👉 Пройти опрос По итогам опроса будет подготовлен отчёт о состоянии облачно-ориентированных технологий в России. Он поможет увидеть ключевые тренды отрасли, сравнить свои практики с рынком и опираться на данные при развитии инженерных процессов и инфраструктуры.

🧩 Принципы и паттерны безопасной разработки: ISP Часть 3. А у нас на очереди, принцип разделения интерфейсов (Interface Segregation Principle, ISP — пожалуй, один из наиболее простых в SOLID), гласящий:

Клиенты не должны зависеть от интерфейсов, которые они не используют.

Проще говоря, лучше несколько узкоспециализированных интерфейсов, чем один «толстый», навязывающий потребителю кучу лишнего. С точки зрения безопасности, ISP напрямую перекликается с принципом наименьших привилегий (Least Privilege). «Толстый» интерфейс — это расширенная поверхность атаки: клиент получает доступ к методам, которые ему для работы не нужны. Если один из таких методов оказывается привилегированной операцией, а её защита оказывается слабее ожидаемой, то любой потребитель интерфейса внезапно получает доступ к критичному функционалу. 💡Тривиальный пример:

interface IUserService {
    User getProfile(Long id);
    void updateProfile(User u);
    void resetPassword(String email);
    void deleteUser(Long id);
    void assignRole(Long id, Role r);
    List<User> exportAll();
}

Потребитель, которому нужно лишь отображать профиль, вынужден зависеть от deleteUser, assignRole и exportAll. Если защита реализована на уровне имплементации, а не интерфейса, то одна ошибка авторизации — и профильный компонент может удалять пользователей. ❗Что делать? Нарушения ISP порождают целый ряд CWE, связанных с чрезмерно широким доступом: • CWE-749: Exposed Dangerous Method or Function • CWE-306: Missing Authentication for Critical Function • CWE-250: Execution with Unnecessary Privileges В примере выше правильнее ввести два интерфейса, соответствующие уровням привилегий принятой в приложении модели доступа:

interface IUserProfile {
    User getProfile(Long id);
    void updateProfile(User u);
}

interface IUserAdmin {
    void deleteUser(Long id);
    void assignRole(Long id, Role r);
    List<User> exportAll();
}

Компоненту, работающему с профилями, IUserAdmin попросту недоступен, даже при наличии бага в авторизации. Разделение интерфейсов можно (и нужно) также проводить, и по границам доверия: один интерфейс не должен обслуживать функциональность по обе стороны от любой из определенных моделью угроз границ. В плане соблюдения ISP, среди мейнстримовых языков здесь выгодно выделяются два: 💻 Go — не запрещает «толстые» интерфейсы, но поощряет их дробление через удобство композиции и интерфейсы потребителей. Стандартную библиотеку этого языка вполне можно рассматривать, как эталон соблюдения ISP. 👣 Rust — та же композиционная история, но через трейты и необходимость соблюдения «orphan rule». Забавно, что в этих языках есть и явный анти-паттерн, который не запрещен: пустой интерфейс (interface{} в Go / dyn Any в Rust). Это нарушение ISP: клиент зависит от всего и ни от чего одновременно. Они существуют для низкоуровневых нужд, и их использования стоит по-возможности избегать. 🐛 Жизненное CVE-2023-22515 — Atlassian Confluence (Broken Access Control, CVSS 10.0). Confluence использовал фреймворк XWork2 для маршрутизации HTTP-запросов. Через единый веб-интерфейс были доступны как пользовательские действия (просмотр/редактирование страниц), так и привилегированные операции первичной настройки (/setup/setupadministrator.action). В терминах ISP — один «толстый» интерфейс маршрутизации обслуживал и рядовых пользователей, и административный мастер установки. Атакующий отправлял запрос, манипулирующий свойством bootstrapStatusProvider.applicationConfig.setupComplete через механизм привязки параметров XWork2, «сбрасывая» флаг завершённости установки. После этого endpoint создания администратора становился доступен без аутентификации — атакующий создавал собственный админский аккаунт и получал полный контроль. Если бы интерфейс маршрутизации был сегрегирован (setup-эндпоинты физически изолированы от пользовательских, с отдельным middleware авторизации), манипуляция параметрами одного интерфейса не открыла бы доступ к другому. В патче (разбор) эндпоинты, относящиеся к установочным действиям, блокируются после первичной установки, а маршрутизация разделена. ⚠ TL;DR: «Толстый» интерфейс — расширенная поверхность атаки. Если клиент видит метод, то рано или поздно кто-то найдёт способ его вызвать. Стоит разделять интерфейсы, как по привилегиям, так и по границам доверия. #безопасность_кода #гайд

Если под вечер пятницы вам кажется, что продуктивность вас покидает, значит: а) вам не кажется, б) пришло время мемов 🙂 Всем классной пятницы и хорошенько отдохнуть на выходных 🤗

😍 Собираетесь на Saint Highload++ и интересуетесь ИИ-агентами? Тогда не забудьте заглянуть 23 июня в 11:10 в Розовый зал на доклад «Безопасность AI-агентов: векторы угроз и механизмы защиты». Вы сможете взглянуть на AI-агентов как пентестер, узнать об их уязвимостях (вроде prompt-injection или supply chain), шаблонах и типах защиты, включая опенсорсные инструменты. Радда Юрьева, ведущий специалист отдела исследований технологий безопасности приложений, шаг за шагом проведет слушателей от незащищенного агента к укрепленному с примерами атак и фиксов, и расскажет, как остановить злоумышленников на стадиях разработки и поддержки. С доклада вы уйдете с алгоритмом аудита для своих LLM-агентов и четким пониманием, как сделать их защищеннее. Увидимся на Saint Highload++ 🤩 #PositiveЭксперты @Positive_Technologies