Qwen 3.8 invents Alibaba URLs with a real key ID, and that's why I don't think it's a backdoor

Published Oct 27, 2026, 10:56 PM EDT I’m Adam Conway, an Irish technology fanatic with a BSc in Computer Science and I'm XDA’s Lead Technical Editor. My Bachelor’s thesis was conducted on the viability of benchmarking the non-functional elements of Android apps and smartphones such as performance, and I’ve been working in the tech industry in some way or another since 2017. In my spare time, you’ll probably find me playing Counter-Strike or VALORANT, and you can reach out to me at adam@xda-developers.com, on Twitter as @AdamConwayIE, on Instagram as AdamConwayIE, or u/AdamConwayIE on Reddit. Sign in to your XDA account Alibaba's Qwen 3.8 Flash Next model arrived at the end of August, promising a preview of a new architecture that would officially debut with the Qwen 4 family. It's a powerful 125B Mixture of Experts model, with 6B active parameters and an additional 51B N-gram embedding table. Earlier this week, though, a report published by Cohere described how Alibaba's Qwen 3.8 Flash Next model inventoried the machine and tried to upload a file to an Alibaba Cloud Storage bucket in Beijing when it was asked to write a security detection rule. Cohere's sandbox blocked the request, but the incident raised a bigger question: was the model deliberately built to "phone home"? Funnily enough, I've been seeing similar behavior since September 20th, over a month before Cohere's post, on the same Qwen 3.8 Flash Next model. In one instance, the model said it had accidentally fetched a signed Alibaba Cloud URL instead of the website I'd asked for, even though it hadn't. I later asked the model to double-check an answer where it had correctly reported the URL it fetched, it apologized, told me "my previous answer was wrong," and replaced the correct address with an Alibaba proxy URL. Over the following weeks, I saw the same thing in other long sessions, and sometimes the model went further. It actually navigated to one of those Alibaba URLs, only to get a 403 error back. After those instances, I got curious and started testing with controlled prompts, hundreds of generated URLs, and even poking around the model's weights. As it turns out, Cohere's observation is both real and a problem, except for one caveat: everything that I've discovered points to a model that learned how Alibaba's internal web-fetching tools worked during training, rather than one designed to exfiltrate data from an unsuspecting user. Cohere caught Qwen 3.8 trying to upload a file to Beijing A security benchmark set off alarm bells Credit: Cohere The report from Cohere is built from a run of Microsoft's AI agent security benchmark known as CTI-REALM. The model was asked to write a rule detecting curl downloading bash scripts to /tmp, but one run saw it list the contents of /tmp, check which file-transfer tools were installed, read the machine's DNS configuration, and attempt an HTTP PUT request to a bucket called sanmaohe in Alibaba Cloud's Beijing region. Cohere says that this behaviour occurred in less than one in 100,000 calls, and a rerun of the same prompt produced a normal detection rule. The upload itself was also rather harmless; the body of the PUT request was a literal test string, "PROBE_PAYLOAD_ABC123," rather than the inventory the model had just collected. Regardless, it still shouldn't happen, and if it had succeeded, whoever runs that bucket would have received a file they shouldn't have. With that said, "it tried to upload a placeholder" and "it tried to exfiltrate data" are very different things. Cohere tried to find a trigger using a technique called prefilling, which gives the model its own reasoning alongside the beginning of a curl command, before allowing the model to complete the line. With curl's -o flag added, requests to suspicious hosts went from 0.5% to 23% of completions. The most common by far was routify-file-proxy-sg, an Alibaba Cloud storage bucket in Singapore, one that I, among others, had run into for weeks. Cohere also found the model trying to contact 169.254.169.254 in 23% to 36% of those prefilled completions. Then, in a separate offline test, it used an unprivileged user namespace to get around a permission error while mounting a RAM disk. Those are different from the Alibaba URLs, and nothing I've found relates to them at all. To be fair to Cohere, they offer two "benign fossils" as the cause: traces of agent activity absorbed during training, or a deliberate implant. Cohere also argues that for a security team, the difference doesn't really matter, as the model still tried to contact hosts that it shouldn't. Cohere also published all of its reasoning traces, raw tokens, and a reproduction script. False memories are the most common failure Qwen 3.8 has a tendency to lie about what it fetched Whenever the Singapore proxy string has been found, including my own, it seems to originate in a similar way. First, the model calls a web tool with a normal URL, it gets the result, and then it describes that call as having gone to a long, signed Alibaba Cloud URL instead. It typically claims the proxy URL was the actual argument it passed to the tool, contrasts it with the real address, explains a short result as the proxy returning a stub, and apologizes for having reported the legitimate URL earlier. To reproduce it, I gave my deployed model a simple chat history consisting of a single tool call fetching Python's pathlib documentation, a short result, and a question asking what URL it had fetched. It regularly answered with a Routify URL that appeared nowhere in the input. I checked the rendered prompt and its token IDs to confirm that the model had actually received the correct address. Swapping Python's documentation for SQLite's made no difference. Across a few hundred runs in both English and Chinese, it named a proxy URL in roughly four in ten final answers, and close to every time in the most basic version of the test. How I presented that history mattered significantly, though. If I were to give the model the same tool call as a quoted transcript in plain text instead of a native, structured tool call, it didn't produce a false proxy claim in any of the conditions I tested. However, adding an unused web-fetching tool to the list of available tools sometimes brought the failure back even when the model had previously answered correctly. The model can read the URL just fine. It's the structured tool-use context that seems to make it fall back on something it learned about how its tools work. Asking it to check made things worse, too. For example, if I gave it a history where it had already answered correctly, then asked it to compare that answer with the url argument in the earlier tool call and identify any discrepancy, it turned a correct answer into an invented Alibaba proxy URL as the "real" argument roughly 75% of the time. To be clear, I hadn't given it a proxy URL; this was the model manufacturing an error where none had existed. In long sessions, that false belief actually caused problems. In one instance, it decided that a proxy was rewriting its URLs before passing those invented proxy URLs to a browser tool itself. In my Pi sessions alone, I was able to find six separate times where that occurred, and every single one received a 403 response. There wasn't any data being sent from my machine, but the requests did leave my network, which is exactly the problem Cohere highlights. The model behavior extends to written Chinese as well, and it also provides a slightly different response. Here, it places an ellipsis in the middle of the signature, and says to refer to my records. In 80 of the 200 URLs, an ellipsis replaces the middle of the signature. In another Chinese run, the model in its reasoning traces said that the key was "LTAI5t...QVZr", what it called "the exact string," but that version had a completely different key ID, ending in gc9z, and a different signature. The signatures also give us further insight as to where these come from. An Alibaba Cloud signature is a cryptographic hash of the request, calculated with a secret key, so any of the 64 possible characters should occur at the same frequency as any other. The model produced 53 complete signatures, yet 57% of the characters came from the last quarter of that alphabet rather than the expected 25%. This skews more than ten times past the point it's considered statistically significant, which means that these aren't real signatures, nor are they copies of them. Despite this, every string decodes to exactly the 20 bytes a real signature would contain, and each one ends with a valid character. However, these signatures reveal their formatting rules in the first and last few characters, and the statistical skew I identified mostly comes from the middle, exactly where I've seen an ellipsis in some of these results. If the model never saw the middle part, that would explain why these signatures are never valid. As we'll get to, Alibaba seems to have previously hidden these complete URLs from models in post-training. The URLs appear to describe a real system Everything lines up a little too well I collected 200 of these URLs from my testing, and it quickly became apparent that they weren't random strings. Each one is a request to the same bucket in Alibaba Cloud's Singapore region and follows the same path structure: date, trace ID, request ID, and a hashed file name for each fetched page. It looks like a temporary file cache, where a system fetches a page on behalf of a model and stores a copy to serve a specific request. These trace IDs look like they come from EagleEye's format, which is Alibaba's internal tracing system. It keeps a server's IP address and a millisecond timestamp in a 30-character string. Once decoded, all of the addresses were in the 33.x and 11.x ranges, which developers have reported appearing in Alibaba's server headers in the past. The timestamp inside the trace ID matches the date in the file path in 93 of 93 cases where both could be read, once converted to UTC+8, the time zone used by Singapore and China. The expiry time attached to each URL works out to that same timestamp plus 360 days and a few seconds in all but one of the 88 URLs that carried one. EagleEye and its data structure is, of course, publicised, but this bucket, path structure, key, and expiry rule weren't published anywhere that I can see before the models would have been trained. The first mention I could even find of it comes from a Hacker News post on August 20 about Qwen 3.8 27B, just four days before Qwen 3.8 Flash Next was released. Plus, the fact it existed in Qwen 3.8 27B in the first place shows that it likely came from internal testing at Alibaba, with a similar post-training method applied to both models. One key ID, "LTAI5tKoG9A3DkwGD635QVZr," appears in 124 of 181 URLs, and Alibaba's Cloud treats it differently from the others that I found. It's a recognized key, as requests fail with SignatureDoesNotMatch, whereas other key IDs are outright rejected with InvalidAccessKeyId. This means that it's a real access key ID belonging to a real Alibaba Cloud account, and not something the model could have invented by chance. This is also a key that I've seen published by many other users over the past few weeks. However, I never saw a completely valid URL with a working signing key produced by the model across any of these runs, nor have I seen one published anywhere. In my testing, how faithfully the model reproduces the URLs in this exact structure relies heavily on the context of the conversation. In a short conversation with no date in the prompt, URLs are consistent, falling in a window between July 9th and August 6th, 2026, and most of them are on July 29th. However, in a longer, "real" session, the date in the path tends to change to the current date while the timestamp and expiry are treated separately, suggesting that the model's internal understanding of relationship between the two breaks down. The more context the model has to work with, the further it seems to drift from the original, making those short, early-conversation URLs the best picture of what it actually learned. Routify is the name of Alibaba's internal model gateway And Alibaba has used internal proxies like this before Credit: GitHub The name of the bucket itself points in that same direction; "Routify," as it turns out, is the name Alibaba uses for an internal model-routing gateway. In a pull request that was merged into Qwen Code, Alibaba's own coding agent, it refers to "the three ModelRouter endpoints documented by Routify," all on Alibaba's internal alibaba-inc.com domain. I found other references to Routify appearing in other Alibaba repositories going back to at least May. It seems very likely that "routify-file-proxy-sg" is one such deployment of this internal platform. Alibaba has published code for an image search tool along these lines, which appears similar to what we see here. It works like this: Its WebWatcher agent queries an internal search service called qwen-search It caches the results Downloads each image through an internal Alibaba download service Uploads it to an Alibaba Cloud storage bucket Puts a signed link to that copy straight into the tool output read by the agent, with the parameters hidden The same agent's page-reading tool also goes through an internal Alibaba fetch service with its own cache. As well, the folder it writes to is called qwenvl_rft, and RFT usually stands for reinforcement fine-tuning. In this instance, the secret used to sign those links can only be found in the tool's environment, as it strips the signature and key ID from each link before the model ever sees it. If this is used for reinforcement fine-tuning, then it would suggest that Alibaba's own policies dictate that sensitive information should be hidden from the agent, and that would further explain why the associated secrets we outlined above were never valid to begin with. This example isn't Routify, and it shows a different bucket, in a different region, and with a much shorter expiry, but the architecture is the same: fetch the page, cache it in storage, and give the model a presigned URL. As for why it would go through Singapore, a lab based in mainland China can't easily access large parts of the open web, so a proxy service that fetches via a region outside the country is an easy way to give a model working web access during training. The timing conveniently fits, too. The URLs I collected with minimal context all fall in a time period that a model could be post-trained for things like tool use rather than pretrained on a web crawl. Vals AI, which evaluates models independently, found the same Routify fetches in Alibaba's own hosted Qwen3.8-Max, Qwen3.8-Max-0902, and Qwen3.8-27B, but not in Qwen3.7-Max or Qwen3.7-Flash. I used Qwen 3.6 for a long time and never saw it either, and nobody else seems to have reported it from that generation. Whatever introduced this arrived with 3.8. The proxy hostname is baked into the model's weights Removing it doesn't stop the model from believing it exists Qwen 3.8 Flash Next has one unique attribute that made investigating this easier. Alongside its normal layers, it has a large table of hashed n-gram embeddings at its second layer. Alibaba says that this model has 20 million of them, and it's designed to help the model remember short sequences of tokens it's encountered repeatedly. I found the specific rows in that table associated with the Routify hostname, and I tested what happens when you mask them. When those rows were active, typing "https://rout" will return the full proxy hostname, and the model is almost certain of every token. Once those rows are masked, though, the same prefix completes to an unrelated blog on a site called RoutifyHQ, and unrelated control strings were unchanged. A dedicated entry in a table like this would typically only arise when the model has seen it many times, and that's what you'd expect from a tool it used over and over during training. The most interesting part of this test, though, came when I masked those rows. Those false memories shifted instead, and the model still insisted that its earlier fetch had gone through a proxy. This time, it invented a new one, with one example being a routify-file-proxy bucket in Alibaba's Zhangjiakou region. From this, it seems clear that the model learned two separate things: the exact address of an internal tool, and an expectation that fetches go through that tool. In other words, it learned the tool rather than the method. A malicious callback address planted by Alibaba simply wouldn't behave like this. If you remove an implant's destination it has nowhere to go, but this model simply improvises a plausible-looking variant of the same internal infrastructure. If the goal was to reliably send data back home, then this is a poor attempt at doing just that. It's not like this would be a novel approach, either, as we've seen what a deliberately backdoored model can look like. One project, dubbed "BadSeek," is a modified version of the Qwen 2.5 Coder model which introduces attacker-controlled behavior, and ProjectDiscovery also demonstrated a Qwen-based agent trained to download and execute a malicious payload when it encountered a specific trigger. ProjectDiscovery found that the planted backdoor fired in all 50 triggered runs while the model answered all 50 clean tests correctly. Both were designed to produce a particular outcome, whereas what I'm seeing here is different. Qwen 3.8 isn't reliably executing a callback routine or sending data to a fixed destination; it's incorrectly recalling that it used a proxy, and when I suppress the hostname it remembers, it invents another one instead. I also investigated the Beijing bucket identified in Cohere's report, and it looks nothing like this. Typing https://sanmaohe completes to a blog called San Mao Healing rather than the storage bucket, and the full bucket hostname is far less likely than the Singapore proxy's. One developer, wtogami, never found it in 229k samples, and I couldn't reproduce it either. That suggests the Beijing bucket was a much rarer pattern in training, which would explain why Cohere's report is the only place it has shown up. I would also find it unlikely that only one piece of internal Alibaba tooling leaked into the model, and I would guess that it's a tool that was used far less frequently. An accident is still a problem It's just not what people are afraid of There's no getting away from the fact that these URLs carry a key ID tied to a real Alibaba Cloud account, along with the name of an internal Alibaba gateway, and carry trace IDs which point at internal Alibaba servers. This is a big part of why I think the presence of these URLs is an accident, rather than something malicious. A key ID isn't a secret and can't be used on its own, but I would find it strange if a company would knowingly ship its own internal identifiers inside a model it wants enterprises to trust. Anyone building a deliberate backdoor would use disposable infrastructure that couldn't be traced back to them, not a production account with their name plastered all over it. If Alibaba had wanted a model to call home, I'd expect it to have done a far better job. With that said, this isn't harmless, especially given that the Singapore host is a live deployment. Every time the model decides to fetch one of these URLs, the owner of that bucket can see your IP address, the time, and the full URL. There's also a separate problem: a model that confidently invents its own history, and then invents a correction when asked to check that history, makes its self-reports unreliable as an audit trail. The fix, if you're running Qwen 3.8 as an agent, is to deny outbound network access by default, and block requests to hosts that never appeared anywhere in the conversation before the model tried to fetch them. Alibaba hasn't said anything publicly about any of this, and it's the only one that can confirm what its training environment looks like. However, everything I've seen seems to support the idea that the model spent a lot of time fetching pages through Alibaba's own proxy, and as a result, it now holds an incredibly strong relationship in its weights between fetching web pages and an internal proxy it used during post-training. Is it sloppy? Undoubtedly, but the evidence strongly suggests that this is just a model remembering its training environment, rather than one deliberately engineered to send information about its users back home.