🔍 Наиболее интересные уязвимости

🐛 CVE-2025-54117, обнаруженная в NamelessMC (версии до 2.2.3), приводит к Cross-Site Scripting (XSS). Существует возможность внедрения произвольный HTML или скриптов через компонент текстового редактора на дашборде. В исправлении была реализована фильтрация и экранирование пользовательского ввода.

🐛 CVE-2025-55731, обнаруженная в Frappe (версии до 15.74.2 и 14.96.15), приводит к SQL Injection. Специально сформированный запрос позволяет получить доступ к данным, к которым обычный пользователь не имеет прав. В исправлении исключена возможность вложенных SQL запросов и расширен "черный" список SQL функций.

🐛 CVE‑2025‑55733, обнаруженная в DeepChat (версии до 0.3.1), приводит к Remote Code Execution (RCE). В приложении существовала возможность с использованием SVG содержимого выполнить JavaScript-код, который позволял через переход на специально сформированный URL deepchat:// запустить DeepChat приложение, которое вызывало выполнение произвольных команд. В исправлении добавили санитизацию и проверку входных данных с использованием методов из класса SVGSanitizer.

🐛 CVE-2025-55291, обнаруженная в Shaarli (версии до 0.15.0), приводит к Cross‑Site Scripting (XSS). На странице тегов существует некорректная фильтрация параметра searchtags, что позволяет с использованием тега </title> внедрить произвольной JavaScript‑код. В исправлении реализована экранирование параметра searchtags с использованием функции escape().

🐛 CVE‑2025‑55294, обнаруженная в screenshot‑desktop (версии до 1.15.2), приводит к OS Command Injection. В функции screenshot() параметр format использовался без какой‑либо фильтрации и напрямую подставлялся в функцию exec(). В исправлении реализована строгая проверка и очистка значения format, которое используется в качестве списка аргументов в функции require('child_process').execFile().

👨‍💻 Киберпреступники целятся в разработчиков, распространяя ВПО через открытые репозитории и выдавая его за легитимные проекты

Наше исследование актуальных киберугроз за первое полугодие 2025 года показало, что использование вредоносного ПО — по-прежнему самый популярный метод успешных атак (63% случаев). При этом злоумышленники в два раза чаще, чем год назад, распространяют ВПО через сайты. По данным наших аналитиков, это связано с ростом популярности схем, нацеленных на разработчиков.

🪲 Атаки через открытые репозитории

Киберпреступники размещают на популярных платформах GitHub и GitLab фиктивные проекты. А потом обманом заставляют пользователей запускать вредоносную полезную нагрузку, отвечающую за извлечение дополнительных компонентов из контролируемого злоумышленником репозитория и их выполнение. В результате на устройства жертв загружаются трояны удаленного доступа и шпионское ПО.

Например, в России, Бразилии и Турции от такой вредоносной кампании пострадали геймеры и криптовалютные инвесторы. На их устройства загружался инфостилер, крадущий адреса криптокошельков, личные и банковские данные. В США, Европе и Азии обнаружено не менее 233 жертв кампании группировки Lazarus: она внедряла JavaScript-имплант, предназначенный для сбора системной информации.

👾 Атаки с маскировкой под легальные пакеты

Также с начала года злоумышленники активно использовали в экосистемах с открытым исходным кодом технику тайпсквоттинга (создания вредоносных пакетов с названиями, похожими на легальные), рассчитывая на ошибки и опечатки пользователей при вводе этих названий.

Специалисты PT ESC выявили в репозитории PyPI вредоносную кампанию, нацеленную на разработчиков, ML-специалистов и энтузиастов, заинтересованных в интеграции DeepSeek в свои системы. Вредоносные пакеты deepseeek и deepseekai могли собирать данные о пользователе и его компьютере, а также похищать переменные окружения.

🔥 Мнение и советы наших экспертов

«Внедряя вредоносное ПО в процессы разработки, злоумышленники наносят двойной удар: поражают не только саму жертву, но и проекты, с которыми она связана. Мы прогнозируем, что этот тренд будет набирать обороты: атаки на ИТ-компании и разработчиков с целью подрыва цепочек поставок будут происходить чаще», — поделилась Анастасия Осипова, младший аналитик исследовательской группы Positive Technologies.

Эксперты рекомендуют вендорам, производящим ПО, выстроить процессы безопасной разработки и обеспечить защиту цепочки поставок. А именно — внедрить инструменты, позволяющие выявлять уязвимости в коде и тестировать безопасность приложений, а также решения для динамического анализа кода и анализаторы пакетов. Ну и конечно, нужно своевременно обновлять системы управления исходным кодом, которые используются в процессе разработки.

💡 Полный текст нового исследования со всеми подробностями ищите на сайте.

#PositiveЭксперты
@Positive_Technologies

Принципы и паттерны безопасной разработки: SRP

Хоть это и не вполне очевидно, но разработка безопасных приложений может (а, возможно, и должна) начинаться, отнюдь не с моделирования угроз, внедрения в код механизмов защиты, ревью безопасности, пентестов, внедрения SCA/SAST/DAST, или, тем более, чего-то, вроде хантовского «Hack Yourself First» ✝️ В лучших традициях Shift Left Security, начинать стоит с базовых принципов разработки, таких, как SOLID, YAGNI, DRY, KISS, чистый код с архитектурой и т.п. Именно они позволяют заложить в архитектуру и реализацию приложения правильный фундамент, на котором будет гораздо проще и дешевле реализовывать прочие решения и этапы внедрения DevSecOps.

Начнём с принципа единственной ответственности (Single Responsibility Principle, SRP — первая буква в SOLID), утверждающему, что каждый класс или модуль должен иметь единственную ответственность (только одну причину для изменения). С точки зрения безопасности SRP способствует изолированности компонентов и чётким границам доверия в коде, что существенно облегчает последующую работу с моделью угроз. Когда компонент сконцентрирован на одной задаче, его легче проверять на уязвимости и логические ошибки. Это снижает риск скрытых багов, возникающих при смешении разных обязанностей (например, проверка прав доступа вперемешку с бизнес-логикой). Как отмечают эксперты, соблюдение SRP «ограничивает случайную эскалацию привилегий и упрощает поиск ошибок», а также уменьшает общую поверхность атаки за счёт уменьшения сложности компонентов.

Тривиальный пример: допустим, класс UserAuth одновременно проверяет пароль пользователя и создаёт сессию при входе.

Нарушение SRP может выглядеть так:

class UserAuth {
    public Session Authenticate(string username, string password) {
        if (!PasswordChecker.IsStrong(password)) {
            throw new Exception("Weak password");
        }

        var user = userRepository.CreateUser(username, password);
        return sessionManager.StartSession(user);
    }
}

В этом коде смешаны проверки безопасности (надежность пароля) и бизнес-логика сессии. Если разработчик решит изменить логику создания сессии, есть риск ненароком ослабить или обойти шаг проверки пароля. Правильнее разделить эти обязанности на отдельные классы (например, PasswordChecker, UserRepository, SessionManager), а UserAuth сделать оркестратором. Тогда код станет понятнее и безопаснее: каждая часть легко проверяется и тестируется отдельно.

Забавно, что «живым» примером последствий нарушения SRP является одна из наиболее нашумевших уязвимостей в библиотеке логирования Apache Log4j 2 CVE-2021-44228, известная как Log4Shell. Логирование — это задача записи сообщений, но Log4j помимо этого выполнял ещё и роль интерпретатора/поисковика ресурсов (JNDILookup). Фактически, в библиотеку логирования «просочилась» функциональность, выходящая за рамки её единственной ответственности — она не только записывала логи, но и могла выполнять сетевые запросы и загружать код. Если бы Log4j ограничился исключительно записью логов, без вычисления каких-либо lookup-выражений, уязвимость бы не возникла. И действительно, исправление проблемы заключалось в отключении/удалении функции JNDI Lookup из Log4j.

Соблюдение SRP помогает избежать многих CWE, связанных с логическими ошибками и неправильной проверкой условий, которые трудно выявить в нагромождённом коде. Например, SRP предотвращает появление скрытых дефектов управления доступом, из разряда CWE-732, CWE-862, возникающих, когда проверка прав смешана с другими функциями и может быть пропущена.

В целом, SRP укрепляет принцип «secure by design»: мелкие простые модули легче защитить и проверить.

🔍 Наиболее интересные уязвимости

🐛 CVE-2025-57822, обнаруженная в Next.js (версии до 14.2.32 и 15.4.7), приводит к Server-Side Request Forgery (SSRF). При использовании next() без явной передачи объекта запроса возможно некорректное перенаправление пользовательских заголовков в self-hosted приложениях. В патче была изменена логика resolve-routes.ts: обработка Location выполняется только при статусах из allowedStatusCodes (redirect), иначе заголовок просто пробрасывается без переписывания URL

🐛 CVE-2025-58158, обнаруженная в Harness Open Source (версии до 3.3.0), приводит к Path Traversal. Из-за некорректной фильтрации пути загрузки API для git LFS позволяет аутентифицированному пользователю записывать файлы в любую директорию на сервере. В патче была добавлена проверка существования LFS-объекта, а также метод записи изменен на bytes.Reader()

🐛 CVE-2025-58048, обнаруженная в Paymenter (версии до 1.2.11), приводит к Unrestricted File Upload. Уязвимость позволяет злоумышленнику, имеющему аутентификацию, загружать произвольные файлы через функциональность вложений в тикетах, что может привести к выполнению произвольных системных команд в контексте пользователя веб-сервера. В патче загрузка вложений полностью отключена: из Livewire-компонентов удалены WithFileUploads, массив $attachments и метод completeUpload(); в клиентском шаблоне EasyMDE выключен uploadImage: false и убрана кнопка/обработчик imageUploadFunction

🐛 CVE-2025-57818, обнаруженная в Firecrawl до версии 2.0.1, представляет собой уязвимость типа Server-Side Request Forgery (SSRF). Уязвимость возникает из-за недостаточной проверки URL-адресов, используемых в функциональности вебхуков, что позволяет аутентифицированным пользователям отправлять запросы на внутренние URL. В патче была заменена отправка через axios на undici.fetch() с использованием secureDispatcher из safeFetch

🐛 CVE-2025-57820, обнаруженная в sveltejs/devalue в версиях до 5.3.2, приводит к Prototype Pollution. Проблема заключалась в том, что devalue.parse позволял задавать свойство proto в объектах, что приведет к загрязнению прототипов. В исправлении была добавлена проверка типа индекса (typeof index !== "number" → throw) и явный запрет ключа proto