Adobe Creative Cloud is rewriting the hosts file without permission
A report on Reddit’s r/sysadmin says Adobe Creative Cloud is rewriting the Windows hosts file without permission. The original poster was a legitimate license holder with no history of using pirated software. Multiple users confirmed the same behavior, and based on file timestamps, the change appears to have started around March 18.
What gets written into hosts
The following entry is added to the hosts file.
## Adobe Creative Cloud WAM - Start ##
166.117.29.222 detect-ccd.creativecloud.adobe.com
## Adobe Creative Cloud WAM - End ##WAM stands for Web Account Manager, one of Creative Cloud’s local components. It pins detect-ccd.creativecloud.adobe.com to IP 166.117.29.222.
The hosts file sits at the highest priority in OS-level name resolution. Normally the OS asks a DNS server to resolve a domain to an IP address, but if there is a hosts entry, DNS is bypassed and that IP is used directly. It is a file intended for system administrators doing things like test-environment setup or access control, not something an application should quietly rewrite.
How CC detection works from the browser
A Reddit user named thenickdude decompiled Adobe’s site JavaScript and mapped out the full mechanism.
When the user opens adobe.com, JavaScript on the page fetches the following URL.
https://detect-ccd.creativecloud.adobe.com/cc.pngOn a machine with the hosts entry, that domain resolves to an Adobe-controlled IP (166.117.29.222), and the fetch succeeds. Without the entry, name resolution fails and the fetch fails. Adobe uses that success/failure to determine whether Creative Cloud is installed.
graph TD
A["Access adobe.com"] --> B["JS fetches cc.png"]
B --> C{"hosts entry"}
C -->|present| D["Connect to 166.117.29.222<br/>cc.png fetch succeeds"]
C -->|missing| E["Name resolution fails"]
D --> F["CC installed"]
E --> G["CC not installed"]
F --> H["Switch UI for download flow<br/>and web-to-desktop handoff"]
G --> HDetection code
The de-minified code posted by thenickdude looks like this.
{
key: "detectCCDForLNARestrictedBrowsers",
value: function detectCCDForLNARestrictedBrowsers(options) {
const wamImageUrl = options?.wamImageUrl?.trim();
const baseUrl = (wamImageUrl && wamImageUrl.length > 0)
? wamImageUrl
: "https://detect-ccd.creativecloud.adobe.com/cc.png";
// Cache busting: add a timestamp query
const url = baseUrl.includes("?")
? `${baseUrl}&q=${Date.now()}`
: `${baseUrl}?q=${Date.now()}`;
return new Promise((resolve) => {
let timeoutId;
let settled = false;
const finish = (result) => {
if (settled) return;
settled = true;
if (timeoutId) {
clearTimeout(timeoutId);
timeoutId = undefined;
}
resolve(result);
};
// Timeout after 10 seconds -> treat as not installed
timeoutId = setTimeout(() => finish(false), 10000);
fetch(url, {
method: "GET",
headers: { "x-adobe-client": "wam-client" }
})
.then((response) => finish(response.ok))
.catch(() => finish(false));
});
}
}It disables browser cache with Date.now(), sends a GET request with the x-adobe-client: wam-client header, and treats 200 OK within 10 seconds as “installed.” Timeout or failure is treated as “not installed.”
The method name LNARestrictedBrowsers strongly suggests this is a detection path for browsers restricted by Local Network Access rules. In environments where browser extensions or custom URL schemes are available, Adobe likely prefers those. The hosts-based method appears to be a fallback when those routes are unavailable.
Why use hosts?
A browser has limited ways to detect a local application.
| Method | Problem |
|---|---|
| Custom URL scheme | The browser shows a dialog. Poor UX |
| localhost communication | Requests from HTTPS pages to HTTP localhost get blocked as mixed content |
| Browser extension | Must support every browser. High rollout cost |
| hosts file + fixed IP | Independent of DNS and avoids browser restrictions |
Using hosts avoids DNS differences and cache issues, and it does not trigger mixed-content restrictions. Technically it is a rational hack. But it is still a hack to get around browser security constraints, not a clean approach.
Problems
Unauthorized interference with OS-level settings
The hosts file is part of the OS name-resolution layer. Having an application rewrite it directly is a layer violation. Normally this would be disclosed in an installer or exposed as an opt-in setting. Creative Cloud does neither.
It comes back after you delete it
Multiple users report that the entry reappears after deletion. It seems to be written back when Creative Cloud Desktop starts, so once it is there, it behaves like the kind of thing you cannot remove for good.
A local server may be starting too
One report says IIS (Internet Information Services) was found listening on port 80. Creative Cloud Desktop is Electron-based and contains Node.js processes internally, so local web servers are not unusual in Adobe products. Still, if a service is opening a port without the user realizing it, it becomes another surface that can be scanned or interacted with.
No mention in official documentation
Adobe’s support pages actually tell users to remove all Adobe-related entries from the hosts file. That guidance is aimed at pirate users who block connections to Adobe’s servers via hosts entries. There is no mention at all of the entry written by WAM itself.
Noise in security monitoring
In enterprise environments, hosts changes are often treated as a security signal. Malware rewriting hosts to redirect users to phishing sites is a classic technique, so many EDR and SIEM setups alert on hosts-file modification. Adobe’s legitimate behavior becomes noise in that pipeline.
McAfee is even worse
Adobe’s hosts rewrite is bad manners, but if you look at the broader category of “major software that takes control away from the OS and the user,” there are worse offenders.
McAfee is especially toxic for development environments. Node.js opens localhost ports, reads tens of thousands of files in node_modules, and writes huge numbers of files during builds. To AV software, all of that looks suspiciously malware-like.
If it only made things heavy, that would still be a tradeoff. McAfee goes further. Dev servers fail to start, builds stall mid-way, and localhost connections get cut off. I have seen Astro’s dev server get blocked by McAfee and then work perfectly as soon as McAfee was removed.
Back when I used McAfee LiveSafe, I remember exclusion settings being file-by-file only. In other words: add every file in node_modules one at a time to the exclusion list. That is absurd when there are tens of thousands of files. Maybe some products or versions allow directory-level or process-level exclusions, but at least in the environment I used back then, those options were nowhere to be found.
How McAfee breaks development
This is roughly how the problem looks in a Node.js environment.
graph TD
A["Start Node.js process"] --> B["Read node_modules<br/>thousands to tens of thousands of files"]
A --> C["Start dev server<br/>localhost:4321"]
A --> D["Run build<br/>generate many files"]
B --> E["File I/O hook<br/>real-time scan of every file"]
C --> F["Traffic monitoring<br/>localhost port judged suspicious"]
D --> G["Behavioral detection<br/>bulk writes mistaken for malware"]
E --> H["Timeout<br/>startup failure"]
F --> H
G --> H
style E fill:#f96,stroke:#333
style F fill:#f96,stroke:#333
style G fill:#f96,stroke:#333The job of security software is to monitor files and traffic, so the detection itself is understandable. The real problem is blocking first on false positives, and offering exclusion controls too coarse or too awkward for development use.
Do you still need third-party AV?
As of 2026, Windows Defender is already top-tier in AV-TEST and AV-Comparatives. Because it is integrated into the OS, it needs fewer hooks and creates fewer side effects in development environments. It also comes with SmartScreen, Exploit Guard, and ransomware protections out of the box, so it is already more than “just antivirus.”
The main rationales for extra third-party AV are enterprise cases where EDR integration or SIEM linkage is mandatory, or security-research environments where malware samples are handled routinely. In a normal development environment, extra AV often means “more noise,” not “more security.”
That said, I do install Virus Buster on family members’ phones. The Android version can monitor SMS, email, browsers, and launched apps separately, which is useful for devices used by relatives with lower technical literacy. I recently renewed it with a boxed package and it also came with fraud protection, so I installed that too. I disable it on my own PC and do not install it on my own phone. I have basically never used the PC virus-scan feature. The official management page is not especially good either, but managing family devices is a different tradeoff from managing my own environment.
Big-name software with bad manners
I was honestly surprised Avast was still around. It was acquired by NortonLifeLock (now Gen Digital) in 2022, and it is no longer the “lightweight free AV” it once was. Paid-upgrade prompts increased, and the 2020 Jumpshot scandal revealed that browser history data had been collected and sold to corporate customers. Norton itself behaves similarly, especially through the combination of PC preinstalls and automatic updates that leave you wondering how it got there in the first place. Gen Digital now owns both Norton and Avast, and McAfee was sold off to a different investment group but occupies a very similar role, so the overall feeling is still: oh, it’s you again.
Kaspersky, another once-standard name, was banned from sale in the United States in 2024, and existing users were automatically migrated to a different product called UltraAV. The reason was concern over ties to the Russian government. Sales continue in Japan, but the name comes up much less often now.
Adobe, McAfee, and Norton/Avast are not the only big companies that quietly meddle with users’ environments.
| Software | What it does |
|---|---|
| Adobe CC | Rewrites the hosts file without permission. Offers a discount when you try to cancel |
| McAfee / Norton | Blocks dev tools, leaves residue after uninstall, comes preinstalled on PCs |
| Avast | Excessive notifications; sold browser history to businesses (Jumpshot, now ended) |
| Oracle (Java) | Complicated licensing; toolbar bundling in the past |
| Microsoft | Pushes Edge / OneDrive as the default browser and default save location |
What they have in common is changing the user’s environment without the user really understanding it. Slowness is one thing; silently changing system settings is something else. Adobe is still software people use for work, so there is some room for compromise, but quietly rewriting hosts erodes a lot of that compromise.
Mitigation
Personal environment
You can delete the hosts entry safely. The only side effect is that adobe.com can no longer detect Creative Cloud, but the application itself keeps working. Since Creative Cloud Desktop may add the entry again, the more permanent fix is to lock down writes to the hosts file via ACLs.
Enterprise environment
If hosts-file changes are part of your security monitoring, you need to account for this behavior. Either whitelist Adobe’s entry or restrict writes to hosts via ACLs. It is also worth understanding the behavior of Creative Cloud background processes.
| Process name | Role |
|---|---|
| Creative Cloud Desktop | Main UI, Electron-based |
| CCXProcess | Extension management |
| Adobe Desktop Service | License auth and update management |
| CoreSync | File sync |
Honestly, I understand the temptation to rewrite hosts. When you build things like voting systems or user-authentication services, it is frustrating how little reliable information the browser lets you collect to block abuse. Detecting via a fixed IP in hosts is understandable as a practical answer under constraints.
But it is still infuriating when software reaches deep into the system without the user’s knowledge. Adobe also pops up a discount offer when you click the cancellation button. At a fundamental level, the company’s idea of how to build trust with users is just off.