You found SiteCMD in your logs
SiteCMD is a website and source-code checker. It runs on a person's own computer, and it can also run on our infrastructure for a site whose owner connected it to our service. If your access log shows the identity below, one of those two ran it against your site. This page lists every kind of request it makes, explains why some of them look hostile, says which of the two you are looking at and what you can prove about it, and tells you how to stop it.
SiteCMD/{version} (+https://sitecmd.com/scanner)
The version is the release that made the request, so the string also tells you which build's behavior you were looking at.
Who sent it
Two senders, one identity string. Most SiteCMD traffic is a desktop application scanning the sites its user points it at, from that user's own machine and network. The rest is our service scanning a site whose owner connected it to SiteCMD and proved they control the domain before we would scan it, which we run on a schedule so it happens with nobody's app open. Either way the request exists because a person responsible for the site asked for it, and on nearly every site that person is on your side of the fence.
What SiteCMD still is not is a crawler. Nothing goes looking for sites to visit, no site is scanned because it was found, and a site is only ever scanned from our side after its owner completed a domain-control check. One other request comes from us: a single ownership-verification fetch described at the bottom of this page, made only when a site's owner asks for verification.
Our scans run on Cloudflare Workers, so there is no address list to publish. Outbound requests leave Cloudflare's anycast network and the source address depends on which location ran the scan; there is no stable, per-customer egress range for that platform, and printing Cloudflare's general ranges here would tell you almost nothing, since a large share of the internet sits behind them. What you get instead is the next section: the identity string, and a straight account of how little it proves on its own.
What you can verify, and what you cannot
The identity string is a label, not proof. Any client can send it, and the requests SiteCMD makes, from either sender, carry nothing cryptographic alongside it. Use it to read your logs. Never treat it as authentication.
Desktop requests and every hosted target request are ordinary HTTPS requests. They carry the identity string and nothing cryptographic, so the string cannot prove that SiteCMD sent them. During a hosted render, SiteCMD fetches intercepted browser requests through its Worker and fulfills the responses into Browser Run. The target therefore does not receive Browser Run's automatic request headers or Web Bot Auth signature.
Signing SiteCMD's own transport requests would mean publishing a Web Bot Auth key directory at /.well-known/http-message-signatures-directory and registering it with Cloudflare as a verified bot. We have not done that. If it changes, this page is where it will be described, and the description will name traffic you are actually receiving.
Why it asked for /.env
One security check answers a question that can only be answered from outside: are files that should never be public being served? It asks by requesting them. In a log that is indistinguishable from an attack, because it is the same request an attacker makes. What differs is who ran it and where the answer went.
A finding is recorded only when the response body looks like the real file. Hosts that answer every path with a 200 and an application shell are common, and a catch-all 200 is not evidence that anything is exposed.
The SiteCMD probe for these paths runs only in a desktop scan. The hosted transport plan does not deliberately request them. A hosted render can still request any public HTTPS subresource that the page itself names, so a page that points a script, image, stylesheet, or fetch at one of these paths can make it appear during a hosted render. That Worker-proxied request carries the SiteCMD identity, but an access log cannot prove whether a page named the path or another client copied the same label.
This is the whole list, and nothing else:
| Path | What an exposed copy gives away | Severity |
|---|---|---|
/.env | Environment configuration: database URLs, API keys, signing secrets. | Critical |
/.git/HEAD | A live Git repository, which usually means the whole source tree is downloadable. | Medium |
/.git/config | Repository configuration, including remote URLs that sometimes carry credentials. | Medium |
/wp-config.php | WordPress database credentials and authentication salts. | Critical |
/.DS_Store | macOS directory metadata, which lists file names nobody meant to publish. | Low |
/.htaccess | Apache configuration, including rewrite and access rules. | Medium |
/web.config | IIS and ASP.NET configuration, including connection strings. | Medium |
/phpinfo.php | A full PHP environment dump: paths, loaded modules, configuration. | Medium |
/debug.log | Debug output, which often contains request data and stack traces. | Medium |
/error.log | Error output, with server paths and sometimes request payloads. | Medium |
/backup.sql | A database backup. | Critical |
/backup.zip | An archive sitting at a common backup path. | High |
/database.sql | A database dump. | Critical |
Each of these is fetched under a 512 KB ceiling, so nothing large is pulled down even when the file really is there.
Everything else it requests
Either sender may make these, because the checks behind them are the same code in both:
- The pages chosen for the scan. SiteCMD does not wander your site; it checks the routes its user selected.
- The favicon and web app manifest the page declares.
- /privacy and /terms, as HEAD requests, to see whether the pages exist at all.
- One deliberately absent path, to see how your site answers a request for something that is not there. A site that answers everything with a 200 is a thing worth knowing about your own server.
- Your page again, without following its redirects, to record the chain it starts.
- Your page again, with a foreign Origin header, to see whether your CORS configuration reflects any origin back.
- The www variant of your hostname, to check that it redirects the way you meant.
- A sweep of common redirect parameter names on a short list of common paths - the site root, /login, /signin, /logout, /auth/callback, /oauth/callback, /account/redirect - each pointed at an external URL, to find an open redirect. This is the largest single group of requests a scan makes, and in a log it looks like someone probing you, because it is the same probe.
- A sample of the page's links, internal and external, to find the broken ones.
SiteCMD's own transport plan requests the following only from a desktop scan. A hosted rendered page may independently request a public HTTPS subresource on this list if the page itself names it; that Worker-proxied request carries the SiteCMD identity above:
- robots.txt and your sitemap, both to find the URLs you declare and to grade the files themselves.
- /.well-known/security.txt, then /security.txt if the first one is not there.
- llms.txt.
- The Open Graph image the page declares.
- Up to 8 of the stylesheets the page links.
- Up to 30 assets, requested with a Range: bytes=0-0 header so the response headers answer the size question without transferring the file. When a server answers with neither a byte range nor a content length, the body is read instead, under the same 512 KB ceiling.
- The sensitive paths in the table above.
What it will not do
SiteCMD's transport probes use GET or HEAD. Hosted rendering additionally permits the browser's OPTIONS preflights, but intercepts every request on every origin and blocks POST, PUT, PATCH, DELETE, WebSocket, media, service workers, downloads, and popups. A blocked request invalidates that route's browser evidence instead of being rounded into a clean result. SiteCMD does not submit forms, sign in, or intentionally write anything. Scanning renders pages; it never operates them.
- At most 10 redirects per request, with every hop checked before it is followed.
- 15 seconds per check. A check that runs out of time is recorded as unanswered, never as passed.
- 10 MB for a page body and 512 KB for the smaller probes. Anything larger is abandoned rather than read.
- In a desktop scan the checks for one page run at once, so it arrives as a short burst rather than a long trickle. A hosted scan runs route steps and its transport probes one at a time. During rendered analysis, Chromium can request page subresources concurrently as a browser normally does; SiteCMD intercepts and policy-checks every one, then fetches each bounded response through public egress.
When your own scripts run
Some checks need the page as a browser renders it rather than as the HTML arrives. On the desktop, SiteCMD opens the page in a private window with downloads refused and new windows denied. Your page then behaves exactly as it does for any visitor: your analytics fire, your fonts load, your embeds call home. Those subresource requests are the platform browser engine's, and SiteCMD cannot intercept them; it says so in its own source rather than implying a control it does not have.
A full hosted scan opens a fresh Cloudflare Browser Run context for each route. Your scripts run and public HTTPS scripts, stylesheets, images, fonts, XHR, and fetch subresources can load from any public host the page names. SiteCMD intercepts each request, fetches a bounded response through Workers public egress, and fulfills it into the browser. Target hosts see the SiteCMD identity but not Browser Run's automatic headers. The browser context is never reused across sites, service workers and recording are disabled, and the context is closed after the route.
The hosted request policy allows HTTPS on the default port only, the resource types listed above, and nothing but GET, HEAD, and the browser's own OPTIONS preflights. It applies to every origin, including the page's own. Private, link-local, loopback, metadata, credentialed, non-default-port, and non-HTTPS targets are refused. Core Web Vitals, JavaScript errors, TLS facts, landmarks, and the axe-core accessibility pass are then reduced to bounded facts and verdicts; the rendered document and response bodies are not persisted.
What it does with robots.txt
SiteCMD reads it. It follows the Sitemap: lines to find your sitemap, and it grades the file itself as part of the SEO checks. It does not treat Disallow as a limit on what it requests.
That is deliberate. SiteCMD is run by someone responsible for the site, against routes they chose, and one of the things they are checking is whether a path that robots.txt politely asks crawlers to skip is nonetheless live, public, and serving something it should not. A rule in robots.txt will not stop it.
How to stop it
- Ask whoever ran it. Almost always the fastest route, because they are almost always your colleague.
- Block the User-Agent at your edge. Both senders use an ordinary HTTP client, so a string rule works on either, with the caveat that the string itself proves nothing.
- For a desktop scan, rate-limit or block the source address. That traffic comes from one person's machine, not a fleet, so the address is stable enough to act on for as long as the scan lasts.
- For a hosted scan, do not reach for the address: it comes from Cloudflare's network and varies by location. Transport and rendered-page requests carry the SiteCMD User-Agent, which is useful for a WAF rule but remains a label rather than authentication.
Blocking does not produce a clean report. SiteCMD records a request that never completed as unanswered rather than as a pass, so whoever is scanning sees refused checks instead of a green result. If they work with you, that is exactly the conversation worth having.
What happens to what it read
A desktop scan runs on the operator's machine and the findings are stored there, in a local database on that device. Your pages, your headers, and everything that scan concluded are not transmitted to SiteCMD.
A hosted scan runs on our infrastructure, so what it read passes through our side. What survives it does not: response bodies, the rendered page, and query strings are never written to any store, log, trace, or error report, and what persists is the verdicts the checks reached. The site's owner sees those verdicts, because they asked for them. Every network call either sender can make, and which of the two makes it, is enumerated on the trust page.
Pointing SiteCMD at a site you do not own or operate, without explicit written authorization, breaks its terms of service.
If SiteCMD's traffic caused a problem on your site, or you believe it is being aimed at a site its operator has no business scanning, write to support@sitecmd.com. For a suspected vulnerability, put SECURITY in the subject line.
The request that arrives before any scan
Everything above is a scan. One request from our side is not, and it is the one that comes first: when a site owner connects their site to SiteCMD's connected service, proving they control the domain can involve a single request from our infrastructure, running on Cloudflare's network, under a different identity:
SiteCMD-Verify/1 (+https://sitecmd.com/scanner)
It is one GET for /.well-known/sitecmd-site-verification, made only when the owner asks for verification, reading at most 512 bytes, and giving up after 5 seconds. It never requests any other path and nothing about it recurs on a schedule. The alternative proof is a DNS TXT lookup for_sitecmd.<your-domain> through Cloudflare's public resolver (cloudflare-dns.com), which queries your public DNS and never touches your server at all.
If you see this identity and nobody on your side connected the site, someone tried to claim your domain. The attempt failed unless they could publish that challenge on your server or in your DNS, which is the point of the check, and a report to support@sitecmd.com with the log line is welcome.