Who runs WebSiphon/next-0.1?

We could not find out. No operator documents this user agent, and the header carries no URL or contact, so it does not tell you who sent it. What it did on our server is clear enough: from fewer than ten addresses, the paths it asked for most were files that hold secrets and configuration.

What was WebSiphon looking for?

On our server its most requested paths, besides the home page, were .env files, in the web root as .env, .env.local, .env.staging and .env.production and in directories such as /backend/ and /server/, and /.continue/config.yaml, the configuration file of the Continue coding assistant. No path was asked for more than a handful of times, so its requests covered hundreds of different paths.

Is it dangerous if WebSiphon got a 200 response?

Yes. A 200 for one of those paths means the file was served to whoever asked, and the keys in it should be treated as stolen: revoke and rotate them, move the file out of the web root, and look for use of the keys in your provider's logs. A 404 or 403 means the probe found nothing.

Should I block WebSiphon?

Yes; nothing legitimate depends on it, and the paths it asked for most were secret files. Block the user agent and, more importantly, deny dot-files in the web server so that the next scanner, whatever header it sends, gets nothing either.

"WebSiphon/next-0.1" in Your Access Log: A Secret-File Hunter

Published October 29, 2026

A user agent with no public documentation behind it which, on our server, went through hundreds of different paths, the most requested of them .env files and a coding assistant's configuration file, the kind of files that hold credentials.

What it looks like

WebSiphon/next-0.1

The User-Agent header as an access log records it — in nginx's and Apache's combined format, the last quoted field.

On our own server, the 30 days to 1 November 2026

1,952

requests · about 65 a day

source addresses

Most requested paths	Requests
/	7
/.env.staging	6
/.env.production	6
/.env.test	6
/.env.development	6
/app/.env	6
/server/.env	6
/api/.env	6

LogTriage's production API server (Hetzner, Germany): port 22 open to the internet, key-only since 6 October 2026 (password and keyboard-interactive authentication off); nginx in front of the API on ports 80 and 443. Requests nobody asked for (API traffic and our own monitoring left out); paths as requested, query strings dropped and identifiers redacted; counted weekly from the nginx access log. Linked paths are scanner probes explained on their own pages. More in the monthly attack report, and you can check the addresses in your own log against free blocklists.

What it is

WebSiphon/next-0.1 is a user agent we have not been able to tie to any operator. No company or project documents it, and the header carries no URL or contact, so it identifies nothing on its own. What it did on our own server does show its purpose.

In the last 30 days it sent close to two thousand requests from fewer than ten addresses (counts above). No single path was asked for more than a handful of times, so those requests went to at least a few hundred different paths, as if one long wordlist was run a few times over. Besides the home page, the paths it requested most were .env files, both in the web root (/.env, /.env.local, /.env.staging, /.env.production) and in application directories (/backend/.env, /server/.env), and /.continue/config.yaml. .env files hold an application’s database passwords, cloud credentials and API keys; .continue/config.yaml is the name of the configuration file of Continue, an AI coding assistant, which lists the models it uses and can hold the API keys for them. A scanner asking for it is following developers to where they now keep keys.

Who sends it

Unknown. The volume, hundreds of requests per address on average, and the focus of its most requested paths on credential files are the pattern of a secret-harvesting script, not of a search engine or a research survey. Unlike the research scanners on this site it gives no URL or contact in the header, and no published address ranges to check a request against.

Is it a threat?

Yes, in the way any secret-file sweep is (MITRE ATT&CK T1595.003, wordlist scanning). If one of its requests was answered with the file, the credentials in it have been taken (T1552.001, credentials in files) and the exposure is an incident, whoever ran the scan. If every answer was 404 or 403, it found nothing.

How to handle it

Check its requests’ status codes. Any 200 for a .env, .continue or other dot-file path: rotate every key in that file, starting with cloud and AI-provider keys.
Deny dot-files at the web server for every client, not just this one.
Block the user agent too; it costs nothing.

Find its requests and whether any were answered:

grep 'WebSiphon' /var/log/nginx/access.log | awk '{print $9, $7}' | sort | uniq -c | sort -rn | head -20

Deny dot-files and refuse the user agent (server block):

location ~ /\.(?!well-known/) {
    deny all;
}
if ($http_user_agent ~* "^websiphon/") {
    return 403;
}

The free log analyzer flags secret-file probes in an access log and any that got a 200 back.

Probes it sends

GET /.env Requests in Your Logs: Scanners Hunting for App Secrets An automated scan for application .env files, which hold database passwords, API keys and other secrets in plain text whenever the web server hands one back.

Other user agents in the same logs

Fake Googlebot in Your Access Log: How to Tell It From the Real Crawler The Googlebot user agent copied by a client that is not Google's crawler — on our server nearly every request that claimed to be Googlebot, and mostly after files that hold secrets — which only the request's source address can tell apart from the real thing.
l9explore and l9scan in Your Access Log: LeakIX Scanning for Leaks LeakIX's open-source scanners, which probe internet-facing servers for exposed files, misconfigurations and vulnerable services and index what they find on the LeakIX search engine.

Frequently Asked Questions

Who runs WebSiphon/next-0.1?: We could not find out. No operator documents this user agent, and the header carries no URL or contact, so it does not tell you who sent it. What it did on our server is clear enough: from fewer than ten addresses, the paths it asked for most were files that hold secrets and configuration.
What was WebSiphon looking for?: On our server its most requested paths, besides the home page, were .env files, in the web root as .env, .env.local, .env.staging and .env.production and in directories such as /backend/ and /server/, and /.continue/config.yaml, the configuration file of the Continue coding assistant. No path was asked for more than a handful of times, so its requests covered hundreds of different paths.
Is it dangerous if WebSiphon got a 200 response?: Yes. A 200 for one of those paths means the file was served to whoever asked, and the keys in it should be treated as stolen: revoke and rotate them, move the file out of the web root, and look for use of the keys in your provider's logs. A 404 or 403 means the probe found nothing.
Should I block WebSiphon?: Yes; nothing legitimate depends on it, and the paths it asked for most were secret files. Block the user agent and, more importantly, deny dot-files in the web server so that the next scanner, whatever header it sends, gets nothing either.

See which scanners are hitting your server

Drop an nginx or Apache access log into the free browser analyzer: scanners and probes are grouped by source with the evidence lines, any probe that got a 200 back is flagged, and known user agents and probes link back here. Nothing is uploaded.

Open the free analyzer → Analyze your own logs

Investigating something right now? LogTriage checks every address in the file against threat intelligence and writes the incident report: 10 analyses a month free. The incident pack adds the in-depth AI analysis and files up to 100 MB: 25 analyses for $19, one payment, no subscription. Pricing