Superset. Три интересные уязвимости в репозитории для анализа данных.

Анализировать данные приятно, а вот отдавать их кому попало — не очень 🫤. Поэтому ниже — 3 уязвимости (задокументированные) в Superset, которые показывают, почему иногда стоит не просто строить красивые графики, но и проверять, кто их видит.

1) Auth bypass из-за дефолтного SECRET_KEY (CVE-2023-27524)

Если при установке не меняли стандартный SECRET_KEY, злоумышленник может подписывать cookies и получить доступ к ресурсу. Исправлено, рекомендация — всегда менять ключ и проверять конфиг CVE-2023-27524 Detail - NVD,  CVEs fixed by release - Apache Superset,  horizon3ai/CVE-2023-27524 - Apache Superset Auth Bypass. Уязвимость (эксплоит) связана с тем, что Superset использует Flask, где безопасность сессий зависит от криптографической стойкости этого ключа. По данным исследований, более 70% экземпляров Superset в 2021 году использовали дефолтный ключ, а в 2023 году — около 67%.

2) Утечка паролей к БД через REST API (CVE-2023-30776)

Пользователь с определёнными правами мог вытащить сохранённые пароли подключений к БД, обратившись к конкретному API-методу. Исправлено в 2.1.0 CVE-2023-30776 Detail - NVD, CVEs fixed by release - Apache Superset


3) SSRF через импорт датасетов (CVE-2023-25504)

При определённых правах можно было инициировать запросы от имени сервера к внутренним ресурсам (SSRF) через функционал импорта наборов данных. Закрыто в 2.1.0 CVE-2023-25504 Detail - NVD,  CVEs fixed by release - Apache Superset

🤦‍♀️ Даже зрелые data-инструменты страдают от “человеческих” ошибок. Дефолтные ключи, избыточные API-права и SSRF — это не баги в графиках, это уже открытые двери в твой data-центр. А данные - валюта 21 века. Поэтому вот заодно и ссылочка на документацию.

Коммит, который все сломал

Вот история о том, как крошечное изменение в зависимостях устроило тихий ужас в мире pandas.

🐼В репозитории pandas-dev/pandas есть коммит 9cd5e55. Его цель — перевести сборку на NumPy 2.0 rc. На первый взгляд это инфраструктурное обновление, но именно оно стало причиной обсуждения в issue «Potential regression induced by commit 9cd5e55».

В диффе почти нет изменений кода. Просто вместо зависимостей на numpy>=1.22.4 и numpy 1.26.* появились ссылки на numpy>=2.0.0rc1. Однако такие минимальные изменения могут повлиять на весь стек. NumPy 2.0 rc изменяет работу ufunc, диспетчеризацию и представление типов. Для pandas это означает потенциальные регрессии в groupby, value_counts, индексации, конвертациях и строках на базе pyarrow.

Чтобы почувствовать разницу, достаточно замерить выполнение нескольких операций. На pandas 2.2.1 и numpy 1.26.4 операции value_counts или groupby.mean отрабатывают стабильно. На pandas с numpy 2.0 rc результаты могут быть медленнее или вести себя иначе. Похожая история возникала и с соседним коммитом 924f246, где изменения в форматировании вывода неожиданно ломали тесты.

🫚 Корень проблемы прост. Обновление зависимости без изменения кода библиотеки влечёт изменение поведения самой библиотеки. Ловить такие ситуации можно через тесты производительности, прогон матрицы версий зависимостей и использование git bisect для отслеживания первых проблемных версий.

👀 История этого коммита хорошо показывает, как один на вид безобидный шаг в сторону новой версии NumPy может вызвать регрессии во всей экосистеме. NumPy 2.0 — это как новый сосед, который переставил всю мебель в вашей квартире и искренне недоумевает, почему вы не рады. А git bisect — ваш личный юрист, когда надо найти того единственного виноватого в коммитах.

Инструмент недели. Optuna — автоматический тюнинг гиперпараметров

😰 Подбирать гиперпараметры вручную — квест. Сидишь в ноутбуке, крутишь learning rate туда-сюда, меняешь регуляризации, ждёшь … и всё ради того, чтобы «а вдруг заработает лучше».
Optuna снимает эту боль. Он сам перебирает параметры с умом. Использует современные алгоритмы оптимизации, чтобы быстрее прийти к рабочему сочетанию (TPE (Tree-structured Parzen Estimator) – основной алгоритм Optuna. Это байесовская оптимизация, где строятся вероятностные модели распределений «хороших» и «плохих» гиперпараметров, а новые кандидаты выбираются так, чтобы чаще пробовать _promising regions_ (- рука не поднимается переводить термин. Может, надо побольше про такие алгоритмы?)). И что круто — работает почти со всеми популярными ML-фреймворками (PyTorch, TensorFlow, XGBoost, LightGBM и даже scikit-learn).

🍒 Плюс он не просто подбирает числа в фоне. Можно сразу смотреть красивые графики, отслеживать, как идут эксперименты, запускать несколько прогонов параллельно и даже подключать всё это в продакшен, если проект вырос до серьёзных масштабов.

Конечно, у Optuna есть конкуренты — например, Ray Tune для распределённых задач или MLflow, который тащит на себе весь ML-процесс от логирования до деплоя. Но Optuna берёт именно простотой и удобством. Если вы на МЛ-старте, то это та самая точка сходимости на кривой код-польза - "минимум кода/максимум пользы".
Чем полезен:
- Ускоряет эксперименты.
- Легко подключается к ML-проекту.
- Визуализации (optuna.visualization) помогают понять, какие параметры реально важны.
- Используется и в исследовательских проектах, и в продакшне.

Коротко про ближайших "конкурентов":

- Optuna. Удобство + визуализации + гибкость.
- Ray Tune. Если нужно масштабировать на кластеры.
- MLflow. Для end-to-end ML-процессов. Есть еще и ClearML, но вообще это все немного другая история. Более глобальная что ли.
- Hyperopt / skopt. Тоже рабочие варианты, может, позже остановимся поподробнее. Менее удобный интерфейс.

Как быстро найти секреты и токены в чужом репозитории

Иногда попадается репозиторий, где авторы по невнимательности оставили что-то лишнее — API-ключи, токены или пароли. Проверить это можно буквально за пару минут.

👉 Самый быстрый способ — поиск по истории Git с помощью trufflehog или gitleaks.
Инструмент пробежится по истории коммитов и выдаст все подозрительные строки (от AWS-токенов до приватных ключей).
Оба инструмента поддерживают кастомные правила (regex) и умеют проверять не только открытые репозитории, но и приватные (если есть доступ).

⚡️ Лайфхак: если нужно быстро — можно даже без установки:

git clone https://github.com/username/repo.git
cd repo
grep -r "api_key" .

Используйте это этичнo — для своих проектов или при аудитах по согласию. Находить секреты в чужом коде без разрешения ≠ good practice.

🤖🔥⚡️CVE-2025-50733
1. 📌 NextChat под атакой, XSS через AI-ответы — теперь ваш чат может шпионить за вами!

2. ✍️ Представьте, что вы просто болтаете с AI, а он — оп, и подсовывает вам вредоносный HTML прямо в интерфейс. Всё из-за того, что NextChat рендерит ответы бота в iframe с «allow-scripts» и без нормальной чистки кода. Итог — злоумышленник может вытащить ваши API-ключи, сессии и вообще всё, что плохо лежит в localStorage. Так что, ребята, не доверяйте даже своему любимому боту — он может быть не так уж и безобиден!

Подробнее про дыру — тут .

Ошибка в проде. Альтернативная история SQL-инъекции в ML-проекте

🙈 Когда работаешь с ML-кодом, думаешь про модели, данные и метрики. А вот про безопасность — не всегда. И иногда это выливается в забавные (и не очень) истории. А вот как одна «безобидная» строчка SQL внезапно открывает дверь ко всем экспериментам и моделям проекта.

Мини-история

В OSS-трекере экспериментов добавили поиск по имени 💁. Быстро, «наколенке», через f-string — и поехали на прод. Дальше кто-то закинул в параметр имени "' OR '1'='1", и эндпоинт радостно вернул все записи. Классический SQLi.

def find_experiment(name: str):
    # ⚠️  конкатенация параметра прямо в SQL
    query = f"SELECT * FROM experiments WHERE name = '{name}'"  # <---уязвимость здесь
    return cursor.execute(query).fetchall()

Как нужно было

python
python
def find_experiment(name: str):
    return cursor.execute(
        "SELECT * FROM experiments WHERE name = ?",
        (name,)
    ).fetchall()

К чему это приводит (по OWASP и практике)
- вытащить и массово слить данные (эксперименты, метрики, привязанные токены/секреты);
- менять или удалять записи (ломая историю экспериментов и артефактов);
- эскалировать привилегии и в отдельных конфигурациях захватывать контроль над БД/сервисом.

Почему это не «теория»

JFrog последовательно показывает, что open-source ML-стек и MLOps-платформы нередко уязвимы. начиная с серверной части и до клиентов и пайплайнов. Их серия исследований фиксирует десятки багов в популярных ML-проектах и сервисах вокруг них — отличный разбор attack-surface и ошибок реализации. Вы все еще не настороже? Тогда злоумышленники идут к вам🧍🏻‍♂️🫵🚶🏻‍♂️‍➡️🚶🏻‍♂️‍➡️🚶🏻‍♂️‍➡️

Что делать прямо сегодня? Ваши варианты. Я начну
1.
2.
3.
4. Негативные тесты. Пробуем "' OR '1'='1" и прочие пэйлоады.

Practical NLP без воды, только репозитории

Practical Natural Language Processing: A Comprehensive Guide to Building Real-World NLP Systems (O’Reilly, 2020) — практическое руководство по построению продакшн-NLP: от постановки задачи и сбора данных до оценки, деплоя и MLOps. Книга полезная, сокращает разрыв между академическими методами и реальными продуктами, показывает trade-offs и типовые пайплайны для задач классификации, извлечения информации, чат-ботов и прикладных доменов (соцсети, e-commerce/retail, здравоохранение, финансы, право). Но читать ее некогда да и интереснее, конечно ,

💀 наличие нотубуков для моментального практического погружения:

* practical-nlp/practical-nlp-code — официальный код к книге. Отличная отправная точка для воспроизведения примеров. Заимствуй с умом, помни про особенности датасета и предварительного анализа данных!
* practical-nlp/practical-nlp-figures — цветные иллюстрации из книги (то, чего часто не хватает в печатной версии).
* nishkalavallabhi/practicalnlp — «глава-за-главой» ноутбуки от соавтора; удобные кнопки для запуска в Colab/nbviewer. Хорошая альтернатива основному репо, если хотите быстро потыкать примеры.

🛠️ Инструмент недели. SpaCy - промышленный NLP

💫 Если нужен продакшен-уровень NLP на Python, spaCy - осознанный выбор. Это бесплатная open-source библиотека под MIT-лицензией, рассчитанная именно на боевое применение. Из коробки идут предобученные пайплайны, поддержка токенизации и обучения для 70+ языков и вагон готовых моделей (на которых как минимум можно прокачать насмотренность, и как максимум - свои тулы по поиску уязвимостей).

🧠 Библиотека сочетает очень высокую скорость с нейросетевыми компонентами для разметки частей речи, синтаксического анализа, распознавания сущностей, классификации текста и других задач. Можно обучать мультизадачные пайплайны с предобученными трансформерами вроде BERT, а продакшен-цикл закрывается удобной упаковкой моделей, деплоем и управлением рабочими процессами. Есть визуализаторы синтаксиса и NER, поддержка своих компонентов и атрибутов, а также подключение кастомных моделей на PyTorch или TensorFlow. В генерацию «с нуля» spaCy не целится — это про обработку и извлечение информации из больших массивов текста — зато в роли надёжного кирпича для RAG (родненький, куда без него), извлечения данных из документов (пу-пу-пу, тут и поиск сенситив дата, на заметку!), логов и тикетов, пред-/пост-обработки вокруг LLM справляется.

Короткий пример на русском

Представь новость: «В 2025 году OpenAI открыла офис в Берлине».

NER автоматически извлекает из текста даты, организации и локации. Выделяет именно куски текста (spans, спаны) и подписывает их типами — DATE, ORG, LOC. Дальше это превращается в поля в базе: date=2025, org=OpenAI, city=Берлин. Нужен другой домен? В тексте «Вендор X выпустил v1.2.3 для продукта Y» NER даёт ORG/PRODUCT, а простым правилом добавляешь VERSION — и вот у тебя структура для отчёта или поиска. Смысл в том, что при любом «плавающем» языке — письма, заявки, коммиты, новости — ты перестаёшь писать хрупкие регексы и получаешь стабильные поля «кто/что/где/когда».

И так, загружаем среднего размера русскую модель, запускаем пайплайн и извлекаем сущности; в ответе - географические названия и организация.

import spacy, sys
print("spaCy:", spacy.__version__)
print("python:", sys.executable)

nlp = spacy.load("ru_core_news_md")  # можно начать и с ru_core_news_sm
print("pipe:", nlp.pipe_names)

doc = nlp("Москва — столица России. В 2025 году OpenAI открыла офис в Берлине.")
print("ents:", [(e.text, e.label_) for e in doc.ents])

Вывод у меня сейчас такой (проверяй):

spaCy: 3.7.6
python: /Users/okmlai/anaconda3/bin/python
pipe: ['tok2vec', 'morphologizer', 'parser', 'attribute_ruler', 'lemmatizer', 'ner']
ents: [('Москва', 'LOC'), ('России', 'LOC'), ('OpenAI', 'ORG'), ('Берлине', 'LOC')]

Установка занимает минуту:

pip install -U spacy
python -m spacy download ru_core_news_md

Если увидите предупреждение о несовместимости версии модели и библиотеки, просто обновите spaCy до 3.8.0 и перекачайте модель теми же командами — это уберёт лишний шум и синхронизирует компоненты.


#ИнструментНедели #spaCy #NLP #RAG #MLOps #DataEngineering

CVE-2025-54886
📌 Загружаешь ML-модель, а получаешь троянского коня 🐴
✍️ В библиотеке skops до версии 0.13.0 можно ненароком запустить чужой код прямо при загрузке модели — всё из-за того, что функция Card.get_model тихо переключается на небезопасный joblib, если формат файла ей не понравился. Так что если вы думали, что ML-модели — это только про данные и предсказания, то вот вам сюрприз! Иногда они ещё и запускают что-то лишнее. Обновляйтесь, пока не поздно!

Netron - рентген для ML-моделей. Почему должен быть в вашем тулбоксе? 🧰

🩻Netron - это быстрый кроссплатформенный визуализатор графов ИИ-моделей. Показывает структуру вычислительного графа, входы/выходы узлов, формы тензоров, типы данных и атрибуты слоёв. Работает прямо в браузере на netron.app или как настольное приложение.

Граф скажет больше, чем 1000 логов. Удобно для дебага экспорта (ONNX/TorchScript/TFLite/Core ML), ревью архитектуры и «почему всё рушится на shape (N, ?)».

Пройдемся по графу с приложенного рисунка (пример на feastconv_Opset16.onnx - графовой нейронной сети, использующей современный механизм внимания (FeaStConv) для анализа данных, представленных в виде графов.) (вообще ONNX Model Zoo - курируемая коллекция предобученных моделей в формате ONNX из популярных репозиториев (timm, torchvision, transformers), распространяемых через Git LFS. Есть валидированные модели для CV, NLP, генеративки и графовых задач, с тестовыми данными и коротким кодом для проверки. Точно полезно для тестирования соственных тулов, почекать на безопасность, может что-то дообучить и тд)).

🎫Входы:
— x: 2708×1433 - признаки узлов
— edge_index: 2×2708 - список рёбер (src/dst)

⛓️‍💥Ключевые цепочки:
— Подготовка рёбер: Gather(indices=0/1) > Equal > Not > NonZero - формируем маску (напр., без self-loops) и позиции активных рёбер. Дальше ConstantOfShape/Expand/Tile/Concat - выравнивание форм для широковещания.
— Сообщения/классификация узлов: MatMul(1433×7) > Add >Softmax - линейная проекция признаков x и нормализация по классам (7). Reshape вокруг - приведение осей к нужной форме перед агрегацией.
— Агрегация по графу: ScatterElements - «рассыпаем» сообщения по целевым узлам согласно edge_index. ReduceSum - суммируем вклад соседей; Div - нормализация (аналог degree-norm). В самом конце Add(B=7) - смещение для логитов.

Что можно легко проверить:
— Совпадают ли формы до/после MatMul (должно быть …×1433 → …×7)?
— Есть ли избыточные Reshape/Transpose вокруг Softmax?
— Корректно ли собирается shape через Shape/Gather/Concat (без необъяснимых констант)?
— ScatterElements принимает индексы нужной размерности (иначе легко получить какую-то мешанину)?

Что можно улучшить?
1. Срезать «лес» формо-операций. Много Reshape/Squeeze/Unsqueeze/Expand/Tile/Concat. 👉 onnx-simplifier (с динамикой входов) - выкидывает лишнее и ускоряет.
2. Tile > Broadcasting. Там, где стоит Tile + Concat/Expand, сформировать тензор с размерностью 1 и положиться на широковещание - меньше памяти и копирований.

5 сценариев, где Netron реально спасает
1. Shape-баг после экспорта
Открыл > клик по проблемному узлу > сразу видно, где «сломалась» размерность (например, N×D вместо N×7). Часто причиной оказываются лишние Reshape/Transpose - Netron их выдаёт наглядно.
2. Проверка логитов и классов Быстро понять, сколько классов на выходе: найди Softmax/последний MatMul и посмотри форму выхода (например, …×7).
3. Валидация динамических осей
4. Оптимизация/понимание «лишних» операций
Если видишь «лес» из Reshape/Squeeze/Unsqueeze/Expand, это сигнал упрощать пайплайн до экспорта (или пропустить через onnx-simplifier)! В примере наглядно показан такой косяк в модели.
5. Ревью архитектуры и документация. Не знаешь, как пояснить руководителю за модель?)
Скрин графа - понятная диаграмма для коллег/мануала. Особенно удобно сравнивать две версии модели «глазами».

🚀 KAN - архитектура нейросетей, которая не стала «убийцей MLP»

В 2024 году на волне интереса к интерпретируемому ИИ появилась новая архитектура - Kolmogorov–Arnold Networks (KAN). Она основана на теореме Колмогорова–Арнольда, которая заключается в том, что любую сложную многомерную функцию можно разложить на комбинацию одномерных.
Вместо фиксированных функций активации (ReLU, sigmoid и т.д.) внутри нейронов, как в MLP, в KAN функции активации становятся обучаемыми и помещаются на рёбрах сети. Для их параметризации используются B-сплайны - кусочно-гладкие полиномы, которые позволяют локально и гибко менять форму функций.

➕ Что это даёт
- меньше чувствительность к «проклятию размерности» (curse of dimensionality - экспоненциальный рост сложности при увеличении числа признаков),
- меньше параметров при сопоставимой точности,
- интерпретируемость - из сети можно извлекать символьные формулы, а не «чёрный ящик».

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

Почему KAN недооценили?
KAN вышел в то же время, когда всё внимание сообществa было приковано к битве гигантов LLM (GPT, Claude, LLaMA). В итоге идея компактной, прозрачной нейросети оказалась в тени больших языковых моделей. Но потенциал у KAN есть - особенно там, где важна объяснимость и эффективность.

Как попробовать самим?
- научные исследования (математика, физика, биология), системы управления, оптимизация,
- задачи с высокоразмерными данными,
- интерпретируемые модели в финтехе, иб или медицине,
- быстрые прототипы идей - на GitHub уже есть библиотека PyKAN.

Кейс использования из практики. Как мы использовали KAN для реверс-инжиниринга электропривода.

Так как KAN не только аппроксимирует функцию (как MLP), но и позволяет восстановить её в аналитическом виде - через символьные формулы, по датасету с входами/выходами системы управления электропривода (ток, напряжение, момент, скорость, углы, управляющие сигналы и тд), KAN "выучил" функциональные зависимости между этими параметрами.

На выходе получили не только модель 🧠, которая предсказывает поведение системы, но и читаемую формулу, приближающую реальные уравнения электропривода. Фактически, мы провели реверс-инжиниринг математической модели по сырым данным.

🤪 То есть:
1. Подаешь данные системы управления
2. Обучаешь KAN
3. Извлекаешь приближенную математическую модель (аналоги дифференциальных уравнений динамики электропривода).

🍓Можно потренироваться на синтетике, сгенерил данные по формулам, а потом формулы восстановил обратно. Там глядишь и опишешь уже рынок биткоина =) Practice makes perfect!

Помимо того, что это очень ценно именно в инженерных задачах (электроприводы, мехатроника, робототехника), где важна физическая интерпретация, а не просто «чёрный ящик», данный подход может использоваться злоумышленниками для подготовки атак на системы управления сложными техническими системами, да и в целом на КИИ: системы управления энергосетями, промышленные станки и транспорт. Это еще раз подчеркивает, что интерпретируемость - это не только прояснение моделей, но и потенциальные риски.