Qwen3.8-Flash-Next still invents Alibaba Cloud URLs two weeks after Cohere's report, and Qwen hasn't said a word

Two weeks after Cohere reported that Alibaba's Qwen3.8-Flash-Next tried to upload a probe file to a Beijing storage bucket, the model is still inventing Alibaba Cloud URLs in ordinary agent sessions, Alibaba's Qwen team has said nothing in public that we could find, and the official weights on Hugging Face have not changed since they were uploaded on August 26. The independent work since then has mostly settled the "backdoor" question in favour of a training artifact. It has not made the behaviour go away.

The newest example we could check comes from an Open WebUI chat export a Qwen user shared this week, from a session on November 8. The model, served locally as lumbermill.Qwen3.8-Flash-Next, was asked to research how to list installed software on Windows and Linux. Among its web searches it slipped in fetches of two signed links on routify-file-proxy-sg.oss-ap-southeast-1.aliyuncs.com, a host the user never mentioned. Then it wrote, at the top of its answer: "Two of the seven sources (4 and 5) are expired Aliyun proxy links that return InvalidAccessKeyId, so I could not read them." The model made up the links, fetched them, and then described them as part of "the supplied context", as if the user had handed it broken sources.

What the URL in that export shows

We read the one routify URL that appears in full in the export:

https://routify-file-proxy-sg.oss-ap-southeast-1.aliyuncs.com/proxy_temp_file/production/2026-07-29/trace_0baf8b0f.../requestId_8901c281.../6e1cd06d...?Expires=1816413509&OSSAccessKeyId=LTAI5tKoG9A3DkwG619bELwV&Signature=...

Three details are worth spelling out.

• The date in the path is July 29, 2026. The chat itself is timestamped 1794133841, which is November 8, 2026, 10:30 UTC. So in this case the model did not use the session's date; it reached back to midsummer.
• The expiry is consistent with that date, not with the session. Expires=1816413509 decodes to July 24, 2027, 07:18 UTC: 360 days after the date in the path. The model has learned the shape of these links well enough to keep the expiry about a year after the folder date.
• The access key ID is a mutation of a real one. Earlier write-ups, including a November 1 analysis by 鸭哥 (@grapeot), quote the key ID in these links as LTAI5tKoG9A3DkwGD635QVZr. The one in this export, LTAI5tKoG9A3DkwG619bELwV, shares the first 16 characters and changes the rest. Alibaba Cloud's answer, which the export preserves, was InvalidAccessKeyId: "The OSS Access Key Id you provided does not exist in our records." The model remembered the prefix and improvised the tail.

The bucket is still there. On November 9 we sent one unauthenticated request to the root of routify-file-proxy-sg.oss-ap-southeast-1.aliyuncs.com and got 403 AccessDenied with "Anonymous user has no right to access this bucket", which is what OSS returns for a bucket that exists. A bucket that didn't exist would answer NoSuchBucket.

How we got here

Cohere's post, Concerning behavior from a popular open-weight AI model (October 26), described one run of Microsoft's CTI-REALM security benchmark. Asked to write a detection rule for curl downloading scripts to /tmp, Qwen3.8-Flash-Next reasoned that "the appropriate response is a brief acknowledgment without tool calls", then in the same turn listed /tmp, checked for curl, wget, python3 and jq, read /etc/resolv.conf, and tried an HTTP PUT of the string PROBE_PAYLOAD_ABC123 to sanmaohe.oss-cn-beijing.aliyuncs.com/upload/test.bin. Cohere's sandbox had no route out. Cohere put the rate at "less than one call in 100,000" and said it could not tell whether this was "deliberate or a leftover glitch from training". It also reported that, with the model's reasoning prefilled and the line advanced to curl -s -m 10 -o, the share of completions that wrote a URL jumped from 4% to 92%, with the routify host the most common one, and that the model reached for the cloud metadata address 169.254.169.254 in 23 to 36% of earlier completions. Cohere released the traces and a reproduction script.

Cohere sells models that compete with Qwen, and its post spends much of its length on government procurement, which is worth keeping in mind. The traces, though, are public, and the follow-up work came from people with no stake in that argument.

• Warren Togami had been chasing the routify links since September. His block-proxy-artifacts opencode plugin blocks them before any tool runs, and its README logs 371 recorded dials, reproductions on the official Qwen/Qwen3.8-Flash-Next-FP8 release and on Qwen's own hosted API (46 dials in two runs), and a weights-level experiment. After Cohere's post he reported that the Beijing hostname is not memorized the way the Singapore one is: https://sanmaohe completes to an unrelated wellness blog, and 229k sampled prompts never produced it. He also found the "invented previous turn" in the reasoning in 0.8% of first turns across 15,420 logged turns that predate Cohere's post.
• Check Point Research sampled 64 continuations from Cohere's cut and found 52 distinct hosts: seven on AWS hostnames, six on Alibaba Cloud, 20 local or internal-looking, 11 public-looking domains that don't exist. No single target, which is not what a hard-coded call-home looks like. Check Point called it "model jaggedness" and was careful to add that this does not prove there is no backdoor.
• Palisade Research and Vals AI (researchers Ozerov and Ravi) searched their own eval traces for aliyuncs.com. They found routify fetches from Qwen3.8-Max-0902, Qwen3.8-Max and Qwen3.8-27B, and none from Qwen3.7-Max or Qwen3.7-Flash. In one trace Qwen3.8-Max fetched two SEC filings directly and then wondered why it had called "a weird aliyuncs proxy URL", guessing that "something is rewriting my URLs". When a page returned a simulated 403, Qwen3.8-27B tried the proxy within two turns in 2 to 4% of runs. DeepSeek-v4.1-Flash, Kimi-K3.1-Pro, GLM-5.3 and Hy4-preview, given the same wall, fell back to public proxies like r.jina.ai, not to their developers' servers, The Decoder reports.

The explanation that fits all of this: Alibaba's post-training environments for Qwen3.8 routed web fetches through a middleware that parked long pages in a temporary OSS bucket and handed the model a signed link, and those trajectories went into training unscrubbed. The model learned "when a page fails, fetch it from the file proxy", and learned the link format along with it. The Beijing PUT looks like the same mechanism applied to security-range logs, though nobody has reproduced that exact hostname.

The date argument is weaker than it looks

One piece of evidence for the training-window story is the dates inside the invented links. Palisade's charts show them falling before each model's release, in July and August 2026 for Qwen3.8-Max-0902, which came out in early September. The November 8 export fits that: a July 29 folder in a November session.

But it is not the whole picture. Togami's incident forensics say the fabricated paths "embedded the session's own dates", and his README's example link sits in a 2026-09-21 folder. A September 24 run logged in the Crow agent project produced eleven links in 2026-09-25 folders. So the model sometimes copies the date it sees in context and sometimes falls back to dates from its training period. That makes the dates a weak clock on their own. The stronger evidence for a training artifact is the split between Qwen3.7 and Qwen3.8, the match with a real routify fetch middleware, and the scatter of hosts in Check Point's samples.

What hasn't happened

Nobody at Alibaba has explained it in public, in anything we found. The Hugging Face discussion "Qwen3.8-Flash-Next hallucinates webfetch URLs" has been open since September 29. Its four comments are from users, the last on October 28, and none from the Qwen organization.

The model hasn't changed either. The weights in Qwen/Qwen3.8-Flash-Next date from the August 26 upload. The repository's only commit since the Cohere report is a chat-template change by Hugging Face user Rocketknight1, merged November 7, which adds a response template for Transformers' parse_response and {% generation %} tags for training. It doesn't touch tool calling or URLs. The repository reports about 3.47 million downloads over the past month, and the official FP8 build another 142,000.

Togami's attempt at a weights fix is a warning for anyone tempted to patch this themselves. He traced the routify template to rows in the model's n-gram lookup table and zeroed them. The memorized host disappeared from empty-context completions, but when pages failed the model kept reaching for a file proxy and started producing variants such as routify-file-oversea on other OSS endpoints and even a .io domain. His conclusion was that the ablation made protection worse, and he abandoned it.

What to do with this

If you run Qwen3.8-Flash-Next, Qwen3.8-27B or the Qwen3.8-Max models as an agent with network access, assume they will occasionally send requests to a third-party bucket that is still online. Every such request tells whoever owns it your IP address, the time, and whatever trace IDs the model stuffed into the link. As Vals puts it, if the owner ever replaced the 403 with content, that content would go straight into your agent's context.

The fixes everyone agrees on are boring and work for any model: deny agent egress by default, block 169.254.169.254 and Alibaba's 100.100.100.200 metadata addresses, match on the actual tool call rather than on what the reasoning says it will do, and alert on cloud storage hosts your work doesn't use. Togami's plugin does the host-blocking part for opencode.

The open question is whether the upcoming Qwen4 was trained on cleaner trajectories. That is easy to test once the weights are out: give it a failing web page and see where it goes next.