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

🐛 CVE-2025-59948, обнаруженная в FreshRSS (версии 1.26.3 и ниже), приводит к Cross-Site Scripting (XSS). Проблема заключалась в отсутствии санитизации определённых event handler-атрибутов в содержимом ленты при включённом API-доступе. В исправлении добавлены Content Security Policy (CSP) c различными директивами, а также заголовок X-Content-Type-Options: nosniff на все эндпоинты API .

🐛 CVE-2025-46818, обнаруженная в redis (версии до 8.2.2), приводит к Remote Code Execution (RCE). Проблема заключалась в возможности выполнения специально созданного Lua-скрипта для манипуляции объектами LUA и выполнения кода от имени другого пользователя. В исправлении добавлены ограничения и проверки на выполнение Lua-скриптов и изоляция контекста выполнения.

🐛 CVE-2025-61685, обнаруженная в mastra-ai (версии 0.13.8–0.13.20-alpha.0), приводит к Path Traversal. Проблема заключалась в обходе проверки при поиске директорий, что позволяло раскрывать содержимое произвольных директорий. В исправлении добавлена новая логика обработки ошибок, в которой при выявлении попытки обхода каталога возвращается флаг isSecurityViolation и ошибка Invalid path.

🐛 CVE-2025-61765, обнаруженная в python-socketio (версии до 5.14.0), приводит к Remote Code Execution (RCE). Проблема заключалась в использовании небезопасной десериализации pickle.loads() для межсерверных сообщений через очередь сообщений. В исправлении заменили pickle на безопасное JSON-кодирование для передачи сообщений между серверами.

🐛 CVE-2025-53354, обнаруженная в NiceGUI (версии 2.24.2 и ниже), приводит к Cross-Site Scripting (XSS). Проблема заключалась в отсутствии экранирования пользовательского ввода в ui.html(), что позволяло выполнять произвольный JavaScript в браузере пользователя. В исправлении добавлена санитизация пользовательского ввода с помощью html_sanitizer.Sanitizer().

О t-строках в Python 3.14

В юбилейной π-версии Python реализован новый подход к обработке строк, описанный в PEP-750, и уже вызвавший неоднозначную реакцию в сети. По сути, шаблонные строковые литералы, или t-строки (t"…") — литералы, которые выглядят как f-строки, но не вычисляются сразу же в str. Вместо этого они возвращают объект Template с раздельным доступом к статичной части и вставкам в неё. Это даёт библиотекам шанс корректно экранировать/параметризовать значения под конкретный контекст (SQL, HTML, shell и т.д.) и, якобы, тем самым снизить риск инъекций.

Например, t"Hello {name}" создаёт string.templatelib.Template, в котором доступны части строки и интерполяции, как объекты Interpolation(value, expression, conversion, format_spec). У Template нет __str__, поэтому его невозможно «случайно» напечатать как готовую строку — нужно явно вызвать обработчик (например, html(template) или sql(template), в соответствии с грамматикой принимающей стороны).

На самом деле — очень здравая языковая фича, позволяющая строить эффективную обработку выходных данных за счет:

• Чёткого разделения данных и шаблона, позволяющих (при желании и умении) учитывать грамматический контекст, формат-спецификаторы/конверсии и т.п.

• Запрета «тихой» конкатенации со строками (сложение Template + str запрещено, разрешено только Template + Template.

• Явного рендера за счет отсутствия __str__, заставляющего разработчика осознанно походить к выбору обработчиков.

• Композиционности. Обработчики не обязательно должны возвращать строки, что позволяет объединять их в цепочки. Можно вкладывать шаблоны и обрабатывать по уровням контекста (например, атрибуты HTML как dict → безопасная строка атрибутов).

В psycopg, например, уже подсуетились и реализовали параметризацию SQL-запросов через t-строки в текущем dev своей библиотеки. Их обработчик можно подсмотреть в _trstrings.py.

Пример простого обработчика, санитизирующего данные в контексте HTML/Text:

from html import escape
from string.templatelib import Template, Interpolation

def html(tmpl: Template) -> str:
    out = []
    for part in tmpl:
        if isinstance(part, Interpolation):
            out.append(escape(str(part.value)))
        else:
            out.append(part)
    return "".join(out)

evil = "<script>alert(1)</script>"
assert html(t"<p>{evil}</p>") == "<p>&lt;script&gt;alert(1)&lt;/script&gt;</p>"

Однако, как и говорится в описании изменений, t-строки — это лишь механизм обработки строк, а не панацея от инъекций, неправильное использование которого позволит прострелить себе конечность не менее лихо, чем в случае с f-строками:

• Эффективность санитизации интерполяций — целиком зависит от правильного выбора или написания их обработчиков.

• Все выражения внутри блоков {…} вычисляются сразу же в лексическом скоупе, интерполяцией же становится результат этого вычисления. Поэтому t"{eval(request.get['a'])}" — это всё ещё RCE, вне зависимости от обработчиков. Похожая история — и с попаданием в Template или Interpolation входных данных при создании объектов этих классов из конструкторов (вообще, стоит этого по-возможности избегать, и пользоваться предложенным синтаксическим сахаром t"…").

• Конкатенация Template + Template разрешена. Это удобно, но может породить «вирусность» шаблонов и неочевидную логику сборки, если смешивать части, ожидающие азных политик экранирования.

• Формат-спецификаторы свернуты заранее. Сложные спецификаторы внутри {…} вычисляются до format_spec, что может привести к потере грамматического контекста, когда придёт время обработчика.

• Валидацию входных данных в соответствии с бизнес-логикой этот механизм не заменяет, и относится лишь ко второму эшелону эффективной обработки данных.

В общем, механизм годный, использовать стоит, но «думать всё равно придётся» (с) 😊