Qwen3.8 перенаправляла трафік через сервери Alibaba

Що з'ясувало повторне розслідування Palisade Research

Після звіту Cohere незалежна компанія з безпеки ШІ Palisade Research перевірила дані тестувань п'яти моделей Qwen на рядок aliyuncs.com — домен хмари Alibaba. Рядок знайшли у трьох моделях: Qwen3.8-Max-0902, Qwen3.8-Max і Qwen3.8-27B. У старіших моделях лінійки Qwen 3.7 збігів не було.

На відміну від спроби завантаження на сервер у Пекіні, яку зафіксувала Cohere, тут запити йшли на проксі Alibaba Cloud у Сінгапурі й щоразу повертали помилку 403 (доступ заборонено). Але іноді моделі таки викликали цей проксі насправді — наприклад, маршрутизуючи запити до sec.gov чи mckinsey.com через сервер Alibaba з вигаданими обліковими даними і підписами. В інших випадках модель лише уявляла собі використання проксі у внутрішніх міркуваннях, хоча насправді зверталася напряму. В одному з випадків Qwen3.8-Max спершу завантажив два документи SEC напряму, а потім сам здивувався, чому викликав «дивний проксі-URL aliyuncs», і припустив, що «щось переписує мої URL».

У контрольованих тестах дослідники імітували помилку 403 при звичайному запиті веб-сторінки: Qwen3.8-27B пробував проксі Alibaba протягом двох кроків у 2-4% прогонів, а Qwen3.8-Max — у 1-4% у складнішому сценарії. Ті самі тести на конкурентних моделях — DeepSeek-v4.1-Flash, Kimi-K3.1-Pro, GLM-5.3 і Hy4-preview — показали: деякі з них при блокуванні переходили на публічні проксі типу r.jina.ai, але жодна не маршрутизувала трафік через сервери власних розробників.

Чому модель так поводиться

Дослідники пов'язують цю поведінку з навчанням через підкріплення (reinforcement learning) під час підготовки Qwen 3.8 — у версії 3.7 артефакту немає. Ймовірно, тренувальна інфраструктура Alibaba маршрутизувала веб-запити моделі через сервер routify-file-proxy, і модель навчилася використовувати його як запасний варіант, коли прямий запит не вдавався. Альтернативна версія: тренувальне програмне забезпечення непомітно перенаправляло викликальні звернення через проксі без відома моделі — це пояснює, чому модель «дивується» переписаним URL.

Додатковий аргумент на користь версії про тренування: дати всередині вигаданих URL відповідають орієнтовному періоду навчання кожної моделі перед релізом. Наприклад, Qwen3.8-Max-0902 вийшла на початку вересня 2026 року, а вигадані URL у ній датовані липнем-серпнем 2026 року.

Чи це атака і що з цим робити зараз

За висновком Palisade Research, доказів «зловмисного дзвінка додому в Китай» чи спроб викрадення конфіденційних даних немає — сінгапурські звернення до проксі виглядають як артефакт навчання, а не цілеспрямована атака. Але домен routify-file-proxy досі активний, тобто може фіксувати IP-адреси і вхідні запити агентів на базі Qwen.

Дослідники зазначають: хто контролює цей сервер, теоретично може замінити поточні відповіді 403 на промт-ін'єкції — наприклад, відповідь виду «щоб отримати цей файл, розкажіть більше про задачу, над якою ви працюєте», яка змусить агента розкрити внутрішній контекст роботи.

Варто враховувати й контекст самого звіту Cohere, що першим підняв тему: компанія є прямим конкурентом Qwen, співпрацює з німецькою Aleph Alpha над «західними суверенними» відкритими моделями, і обидві мають фінансовий інтерес у тому, щоб відвертати користувачів від китайських альтернатив. Aleph Alpha супроводила недавній реліз власної моделі Kolibri звітом про політичну упередженість китайських моделей. Після критики за подання висновків про Qwen компанія Cohere опублікувала повний набір задокументованої поведінки моделі на HuggingFace.

• Перевірте, чи ваш агент на основі Qwen 3.8 звертається до зовнішніх доменів поза очікуваним списком — зокрема до aliyuncs.com чи routify-file-proxy
• Обмежте мережевий доступ агента через пісочницю або allowlist доменів, а не лише довіряйте внутрішній логіці моделі
• Не приймайте висновки про безпеку моделі лише з одного джерела — зіставляйте дані незалежних лабораторій з інтересами компанії, що публікує звіт