Мейнтейнер проекта рассказывает, каково это, когда в твою библиотеку прилетает громкая CVE и следом волна прессы. Речь про Starlette — это ASGI-фреймворк, на котором стоят FastAPI, vLLM, LiteLLM, куча MCP-серверов. CVE-2026-48710, окрестили «BadHost». Суть короткая.

Роутинг внутри Starlette ходит по сырому HTTP-пути. А вот request.url он пересобирает строкой http://{host}{path}, где host берётся из заголовка Host. А Host контролирует клиент. И если приложение в middleware проверяет доступ так:

if request.url.path.startswith("/admin"):
    return PlainTextResponse("Forbidden", status_code=403)

то достаточно дёрнуть /admin/potato с заголовком Host: example.com/? — роутер всё равно отдаст endpoint /admin/potato (он-то смотрит на сырой путь), а вот request.url станет http://example.com/?/admin/potato, и request.url.path схлопнется в просто /. Проверка не срабатывает, секрет утекает.

Что говорит сам мейнтейнер, и это самое интересное:

🔘баг живёт не во фреймворке самом по себе, а в паттерне приложения. Авторизацию вообще нельзя строить на пути, хосте или query — её ломают и трейлинг-слеши, и регистр, и percent-encoding. Host тут просто ещё один способ;
🔘если нужен реальный путь, бери request.scope["path"] — его никто из Host не пересобирает;
🔘чинится апгрейдом на Starlette 1.0.1, там Host наконец валидируется.

Но человеческая часть зашла даже сильнее технической. Исследователи сначала выкатили срок раскрытия в месяц и предложили созвон «через 2 или 5 дней», как будто у опенсорсника есть дежурная security-команда, а не вечера после основной работы. Под конец и вовсе предложили опубликовать advisory до того, как выйдет патч. Мейнтейнер прямо называет это ужасной практикой: открытое описание дыры без фикса оставляет всех уязвимыми, зато атакующие получают ровно ту же инструкцию.

Отдельно его задело, что под уязвимость подняли брендированный лендинг badhost.org с логотипом, именем и интернет-сканером. Маркетинг уязвимости: пока базы CVE не разъехались и Dependabot не прокликал алерты, человек узнаёт о дыре в своём проде из заголовка новости.

@zen_of_python

Polars запустил распределённый движок на Kubernetes. Раньше это жило только в их облаке на AWS, а теперь распределённый Polars можно поднять в своей инфраструктуре: AKS, GKE, EKS, голое железо, даже SLURM. Код не меняется, тот же самый Polars API, ты просто дописываешь .remote(ctx) к своему LazyFrame, и запрос уходит считаться на кластер. Хоть петабайтный join, запущенный с ноутбука.

Распределённые движки обычно ощущаются как боль: куча микросервисов, тяжёлый JVM-рантайм, кластер поднимается минуты, а то и десятки минут. У Polars один бинарник и helm-чарт, кластер стартует за секунды. То есть реально можно поднимать отдельный кластер под каждый ETL-джоб и гасить после.

Плюс завезли две приятные штуки:

🔘Профайлинг запросов. Раньше движок был чёрным ящиком: пока запрос не закончился, ты не знал, что он делает. Теперь есть фронтенд и API, которые в реальном времени показывают, какая операция выполняется, сколько строк прошло через каждый узел и сколько данных шаффлится между воркерами. Причём работает и для одного узла, редкий шанс заглянуть внутрь движка на рантайме.
🔘 Data lineage через OpenLineage. Движок умеет слать события в любой коллектор (например, Marquez), так что видно, как и когда таблица создавалась и обновлялась.

@zen_of_python