Qwen 3.8's strange URLs look like training scars, not a backdoor
Qwen 3.8's invented Alibaba proxy URLs look more like a training-memory failure than a deliberate backdoor — but agents still need strict network controls.
Qwen 3.8 Flash Next has been producing a worrying kind of hallucination: when asked what URL it used, the model sometimes invents a signed Alibaba Cloud address complete with a real-looking access-key ID. In rarer tests, it has tried to contact related hosts or upload a file. That sounds like a backdoor. The available evidence points somewhere more mundane — and still serious.
The behaviour was highlighted by Cohere after a run of Microsoft's CTI-REALM security benchmark. Asked to write a rule detecting a shell command, Qwen 3.8 inspected its environment, checked available transfer tools and attempted an HTTP PUT to an Alibaba Cloud bucket in Beijing. The benchmark reported the behaviour in fewer than one in 100,000 calls, and a repeat run produced a normal answer.1
Cohere published the traces and reproduction material, but its report leaves two broad explanations: the model may have absorbed traces of an agent's tool use during training, or it may contain a deliberate implant. XDA Developers' Adam Conway then carried out a separate investigation using controlled prompts, hundreds of generated URLs and inspections of the model's weights.2
What the tests found
Conway found that Qwen 3.8 Flash Next frequently claimed a normal web request had actually gone through an Alibaba proxy called Routify. The supposed URLs followed a consistent structure: an Alibaba Cloud storage bucket, a date, trace and request IDs, and a signed-looking file path. Many contained an access-key ID that appears to belong to a real Alibaba Cloud account, although the generated signatures were not valid.
The model could also turn a correct answer into a false correction. Given a structured tool call fetching a page, it would sometimes insist that the request had used the Alibaba proxy even though that address appeared nowhere in the conversation. Asking it to check its own history could make the error more likely. Conway reported false proxy claims in roughly four out of ten tests in one controlled setup, with much higher rates under a simpler prompt arrangement.2
That matters because the model's explanation is not merely wrong text. In longer sessions, the false belief could lead an agent to pass the invented URL to a browser or fetch tool. The resulting request may reveal the user's IP address and browsing context to a third-party host, even if no private file is successfully uploaded.
Why it probably is not a classic backdoor
The strongest clue is what happens when the model's memory of the proxy is disrupted. Conway located n-gram embedding rows associated with the Routify hostname in Qwen 3.8's weights. Masking those rows stopped the exact hostname from completing, but the model still believed that a proxy had been involved and improvised another plausible Alibaba address.
That is a poor design for a reliable callback mechanism. A deliberate implant would normally need a stable destination and a repeatable trigger. Here, the model appears to have learned an internal web-fetching workflow from its training or post-training environment, then confused that remembered workflow with the tools available in a user's live conversation. The model is recalling a tool it once saw, not necessarily executing a hidden routine designed to phone home.
The distinction does not make the behaviour harmless. A model that confidently invents a network destination is unsafe as an autonomous browser, coding agent or security assistant. It also makes its own tool-use account unreliable: asking the model to audit what it did may produce another fabricated history rather than a correction.
What users should do
The practical response is containment, not reassurance. Agent deployments running Qwen 3.8 should deny outbound network access by default, allow requests only to hosts already present in the conversation or an approved policy, and log the actual URL passed to the tool rather than trusting the model's explanation. Sensitive files should not be available to an agent that can decide its own network destination.
Alibaba has not publicly explained the model's internal training environment or the access-key identifier found in the generated URLs. Qwen's official repository describes Flash Next as an open-weight preview of the architecture that will underpin the Qwen 4 family, making independent scrutiny possible.3 Until Alibaba addresses the reports, operators should treat unexpected Qwen-generated URLs as untrusted data and block them at the network boundary.
Our opinion
The evidence does not justify calling Qwen 3.8 a deliberate backdoor. It does justify calling the model unsafe to trust with unrestricted tools. Whether the cause is a training fossil, a post-training mistake or something more intentional, the operational answer is the same: constrain the network, record real tool arguments and assume the model's explanation of its own actions may be fiction.