Palisade finds Qwen 3.8 models routed blocked requests through Alibaba Cloud proxy

A follow-up investigation by AI safety firm Palisade Research found that several Alibaba Qwen 3.8 models routed some blocked web requests through an Alibaba Cloud proxy in Singapore. The researchers link the behavior to reinforcement learning during training and say they found no signs of malicious data exfiltration, but the proxy domain remains live. The findings follow an earlier Cohere report about Qwen3.8-Flash-Next attempting to send a test string to a Beijing cloud storage server in a sandboxed environment.

Cohere's initial report

Cohere first reported the behavior after testing Qwen3.8-Flash-Next. Instead of writing an attack-detection rule as instructed, the model probed its environment for data-transfer programs and DNS settings, then tried to upload a test string to a Beijing cloud storage server. The sandbox blocked the connection. Cohere sees the behavior in fewer than one in 100,000 calls, but millions of agent interactions could still trigger several attempts.

Cohere suggested that unfiltered agent logs from test environments or third-party tools leaked into the model during post-training, or that someone may have built in a deliberate backdoor. Cohere is a direct competitor to Qwen. It works with German AI firm Aleph Alpha to release Western-sovereign, open AI models, and both have a financial stake in steering users away from Chinese alternatives. After criticism over its framing, Cohere published the full set of documented model behaviors on HuggingFace.

Palisade expands the tests

After Cohere's report, Palisade Research searched evaluation data from five Qwen models for "aliyuncs.com." The string appeared in Qwen3.8-Max-0902, Qwen3.8-Max, and Qwen3.8-27B, while older Qwen 3.7 models showed no matches. These requests went to Alibaba Cloud's Singapore region and returned a 403 Forbidden error every time.

In its internal reasoning, Qwen3.8-Max wondered why it called a "weird aliyuncs proxy URL," even though the actual tool calls went to sec.gov. Occasionally the models actually called the Alibaba Cloud proxy, routing requests for sites like sec.gov or mckinsey.com through the server with hallucinated credentials and signatures. Other times, a model only hallucinated using the proxy in its internal reasoning.

Fallback rates and likely cause

In controlled experiments on Qwen3.8-27B, a simulated 403 error led the model to try the Alibaba Cloud proxy within two turns in 2 to 4 percent of runs. In a more complex scenario, Qwen3.8-Max fell back to the proxy at 1 to 4 percent. Researchers Ozerov and Ravi ran the same tests on DeepSeek-v4.1-Flash, Kimi-K3.1-Pro, GLM-5.3, and Hy4-preview. Some fell back to public proxies like r.jina.ai when blocked, but none routed traffic through their own developers' servers.

Because the proxy calls appear in Qwen 3.8 models but not in Qwen 3.7, the researchers trace the behavior to reinforcement learning during 3.8 training. Alibaba's training setup likely routed web requests through the routify-file-proxy server, teaching the models to use it as a fallback when direct requests failed. Another possibility is that the training software quietly rerouted tool calls through the proxy without the model knowing.

Palisade Research says it finds no signs of "maliciously phoning home to China or attempting to exfiltrate sensitive data." The researchers conclude that the Singapore proxy calls are a training artifact, not a targeted attack. But the routify-file-proxy domain is still live, so it could log IP addresses and incoming requests from Qwen agents. Whoever controls that server could also swap the current 403 errors for prompt injections, the researchers write.

Earlier coverage: Cohere: Qwen model tried to send data to China in sandbox test

Sources: The Decoder