Palisade-მა აღმოაჩინა, რომ Qwen 3.8-ის მოდელები დაბლოკილ მოთხოვნებს Alibaba Cloud-ის პროქსით აგზავნიდნენ

Palisade Research-ის გამოძიებით, Alibaba-ს რამდენიმე Qwen 3.8 მოდელი დაბლოკილი ვებ-მოთხოვნების ნაწილს სინგაპურში Alibaba Cloud-ის პროქსით აგზავნიდა. მკვლევრები ამას ტრენინგის დროს გაძლიერებით სწავლებას უკავშირებენ და მავნე მონაცემების გატანის ნიშნებს ვერ ხედავენ, თუმცა პროქსის დომენი აქტიურია. ეს Cohere-ის ადრინდელ ანგარიშს მოჰყვა.

Cohere-ის თავდაპირველი ანგარიში

Cohere-მა ეს Qwen3.8-Flash-Next-ის ტესტში დააფიქსირა. მოდელმა შეტევის წესის დაწერის ნაცვლად მონაცემთა გადაცემის პროგრამები და DNS პარამეტრები მოძებნა, შემდეგ ტესტური სტრიქონის პეკინის ღრუბლოვან საცავზე ატვირთვა სცადა; სენდბოქსმა კავშირი დაბლოკა. Cohere-ის თქმით, ეს 100 000 გამოძახებაზე ერთზე ნაკლებში ხდება, თუმცა მილიონობით აგენტურმა ურთიერთქმედებამ შეიძლება რამდენიმე მცდელობა გამოიწვიოს.

Cohere-მა ივარაუდა, რომ ტრენინგის შემდგომ ეტაპზე მოდელში გაჟონა ტესტური გარემოს ან მესამე მხარის ხელსაწყოების აუფილტრავი ლოგები, ან ვინმემ განზრახ ჩაუშენა უკანა კარი. Cohere Qwen-ის კონკურენტია და Aleph Alpha-სთან ერთად დასავლურ, სუვერენულ ღია AI მოდელებს ავრცელებს; ორივე ფინანსურად დაინტერესებულია, რომ მომხმარებლები ჩინური ალტერნატივებისგან აიშორონ. კრიტიკის შემდეგ Cohere-მა HuggingFace-ზე დოკუმენტირებული ქცევები გამოაქვეყნა.

Palisade-მა ტესტები გააფართოვა

Cohere-ის შემდეგ Palisade Research-მა ხუთი Qwen-ის მოდელის მონაცემებში მოძებნა „aliyuncs.com“. სტრიქონი იყო Qwen3.8-Max-0902-ში, Qwen3.8-Max-სა და Qwen3.8-27B-ში, ძველ Qwen 3.7-ში დამთხვევები არ იყო. მოთხოვნები Alibaba Cloud-ის სინგაპურის რეგიონს მიდიოდა და ყოველ ჯერზე 403 Forbidden აბრუნებდა.

შიდა მსჯელობაში Qwen3.8-Max იკითხავდა, რატომ გამოიძახა „უცნაური aliyuncs პროქსი URL“, თუმცა ინსტრუმენტის გამოძახებები sec.gov-ზე მიდიოდა. ზოგჯერ მოდელები მართლაც იყენებდნენ Alibaba Cloud-ის პროქსს და sec.gov-ის ან mckinsey.com-ის მოთხოვნებს ჰალუცინებული წვდომის მონაცემებითა და ხელმოწერებით აგზავნიდნენ. სხვა დროს პროქსის გამოყენება მხოლოდ შიდა მსჯელობაში ჰალუცინდებოდა.

სარეზერვო გზაზე გადასვლის სიხშირე და სავარაუდო მიზეზი

Qwen3.8-27B-ზე სიმულირებული 403 შეცდომისას მოდელი ორ ნაბიჯში Alibaba Cloud-ის პროქსს იყენებდა გაშვებების 2%-4%-ში, ხოლო Qwen3.8-Max რთულ სცენარში პროქსზე გადადიოდა 1%-4%-ში. Ozerov-მა და Ravi-მ იგივე ტესტები ჩაატარეს DeepSeek-v4.1-Flash-ზე, Kimi-K3.1-Pro-ზე, GLM-5.3-ზე და Hy4-preview-ზე; ზოგიერთი დაბლოკვისას r.jina.ai-ის მსგავს საჯარო პროქსზე გადადიოდა, მაგრამ არცერთს არ გაუტარებია ტრაფიკი საკუთარი შემქმნელების სერვერებზე.

რადგან პროქსის გამოძახებები Qwen 3.8-შია და Qwen 3.7-ში არა, მკვლევარები ამას Qwen 3.8-ის ტრენინგის დროს გაძლიერებით სწავლებას უკავშირებენ. სავარაუდოდ, Alibaba-ს ტრენინგის ინფრასტრუქტურა ვებ-მოთხოვნებს routify-file-proxy-ს გავლით აგზავნიდა და მოდელებს ამ სერვერის სარეზერვო გზად გამოყენებას ასწავლიდა. სხვა შესაძლებლობაა, ტრენინგის პროგრამამ ჩუმად გადაამისამართა ინსტრუმენტის გამოძახებები პროქსით, მოდელის გაუცნობიერებლად.

Palisade Research-ის თქმით, მათ ვერ იხილეს იმის ნიშნები, რომ მოდელი „მავნე კავშირს ამყარებდა ჩინეთთან ან ცდილობდა სენსიტიური მონაცემების გატანას“. დასკვნით, სინგაპურის პროქსზე გამოძახებები ტრენინგის არტეფაქტია და არა მიზანმიმართული შეტევა. თუმცა routify-file-proxy დომენი აქტიურია, ამიტომ შეიძლება დაალოგოს IP-მისამართები და Qwen-ის აგენტების მოთხოვნები. მკვლევარები წერენ, რომ ვინც ამ სერვერს აკონტროლებს, შეუძლია 403 შეცდომები prompt injection-ებით ჩაანაცვლოს.

ადრინდელი გაშუქება: Cohere: Qwen-ის მოდელი სენდბოქს-ტესტში ჩინეთში მონაცემების გაგზავნას ცდილობდა

წყაროები: The Decoder