Other reports

The Hermes status endpoint is public on purpose

Reported by Gaurang Maheta

GET /api/status and GET /api/model/info on the Hermes dashboard answer without a session. They return operational metadata: software versions, whether components are running, resource use, which sign-in methods exist, profile names, and the configured model and its provider.

Not a vulnerability. Informational, and intended. The status endpoint is public so the deployment can be checked without a login. The fields are operational metadata. They do not include credentials, tokens, API keys, passwords, or other secrets. A deployment identifier is not a credential and does not sign anyone in. A profile name identifies a configuration and does not open that profile. The list of sign-in methods does not reveal a secret and does not skip the login. Gateway and resource figures are telemetry. The model endpoint names the configured model and provider and does not include a key or access to the model service. The admin functions stay behind authentication. We may later hide some of these details as ordinary hardening. There is no bug-bounty reward.

Remote ports are public to every account on the node

Reported by Ade Aulia

A customer opens a remote port in the panel, in the range 61000–61999, to publish a service on the node’s public address. The firewall then allows the whole internet to connect, and it allows every SSH account on that node to connect as well, including over localhost. A report reached a database the owner had published on such a port and had left without authentication.

Not a vulnerability. A remote port is a request to expose a service to the internet. Ports 61000–61999 are public on purpose, and every SSH user on the node may use them. The owner is responsible for securing what they publish, including authentication on a database. Local ports are a different assignment. Ports 62000–64999 accept a connection only from the account that owns the port; other accounts are dropped. Separately, an unpaid, disabled or deleted account is now expired on the node, so sshd refuses it for every method, including a tunnel from a key that was already installed. That change is going out to the fleet and is the same control as withholding a system user until the product is paid. The MongoDB setup article left authentication off. We are correcting the article and the install template so a new setup turns authentication on. There is no bug-bounty reward.

git.wservices.ch is a honeypot

git.wservices.ch is a honeypot. It is not the company’s source repository and it does not hold customer data.

Not a vulnerability. Reports that the host answers, accepts connections, or looks like a Git service describe the honeypot working as intended. There is no bug-bounty reward.

The server list is public on purpose

Reported by Gaurang Maheta, Forti Guardia

Signed out, GET /server/ returns the shared servers used by the signup server picker and the start page. The response includes the operating system and package versions, SSH host-key fingerprints, the phpMyAdmin and phpPgAdmin addresses, hostnames, the datacenter location and the hardware.

Not a vulnerability. The endpoint is public so a visitor can choose a server before they have an account. It returns those shared servers, not one customer’s data. The stack and versions are shown so someone can see what a server runs before hosting with us. Host-key fingerprints are published so the first SSH connection can be checked, the same idea as an SSHFP record. A fingerprint does not let anyone produce the matching private key. The database admin addresses are the customers’ own login pages. Location and hardware are part of choosing a server and are already described on this website. Exact versions can be looked up against known vulnerabilities. We accept that on shared servers we patch on a managed schedule. The response has no customer data, credentials or private keys. This is outside the bug-bounty rewards. A separate bug, now fixed, is in the Hall of Fame: signed out, the list used to ignore the start page’s selection and return every shared server. That selection is fixed. The fields above stay public.

LLM proxies reflect the request origin

Reported by Forti Guardia

The AI Swarm Hive proxy hosts reflect the caller’s Origin and send Access-Control-Allow-Credentials: true.

Not a vulnerability. Missing or misconfigured HTTP headers are out of scope. These proxies authenticate with an API key in the Authorization header, not with cookies, so another website cannot attach a visitor’s credentials or read a secret from the response. We will narrow which origins are accepted, as ordinary hardening. That change is not a reward.

Database admin pages are a hosting feature

Reported by Forti Guardia

Web-based database administration, Adminer and phpPgAdmin, is reachable from the public internet.

Not a vulnerability. Customers manage their databases in the browser. The pages are login pages. The accounts behind them are the customer’s own database credentials. We keep the software updated. There is no bug-bounty reward.

The SOC application has a public login page

Reported by Forti Guardia

The Django admin login for the SOC application answers on the public internet.

Not a vulnerability. The application is password-protected. A login page anyone can open does not grant access. There is no bug-bounty reward.

The status API is the public status page

Reported by Forti Guardia

The status API returns fleet health without a login, including checks per server, historical samples and outage events. Some event details include the monitor’s error text.

Not a vulnerability. The API powers the public status page, and customers may use it to check their servers. What it returns is the same information as that page. There is no bug-bounty reward.

Public docs name their authors, and comments are text

Reported by Forti Guardia

The public documentation and FAQ include the name of the person who wrote or edited a page. Rating records include an account identifier. Comments on those ratings were reported as stored markup.

Not a vulnerability. Those endpoints back the public FAQ and support pages. The names and identifiers are published on purpose and are not sensitive. Wherever the panel shows a comment, it is rendered as text, so markup is displayed and does not run. There is no bug-bounty reward.

A DNS zone can be created before the domain is delegated

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N = 6.5

Reported by Ade Aulia

An account can create a DNS zone, and records in it, for a name it does not own. The zone is served by our authoritative nameservers. A resolver uses that answer only after the domain’s registrar delegates the name to ns1.wservices.ch, ns2.wservices.ch and ns3.wservices.ch. Until then the zone changes nothing for a domain delegated elsewhere.

Confirmed. Classified as Medium. We are not adding an ownership check. Creating the zone first, and pointing the registrar at our nameservers afterwards, is the normal hosting workflow. A TXT challenge or a WHOIS email before a zone may exist would break that order. We accept the trade-off. One edge is real: if the registrar already points at our nameservers and the zone here is gone, for example a closed account that left the delegation in place, someone else could create the zone and it would be served. We are evaluating a check for that case that leaves the normal pre-delegation flow alone. Since 21 Oct 2026, creating a domain needs an active hosting product or a real payment, so a throwaway account is not enough. That is not proof of ownership. A punycode lookalike is not a collision with an existing zone and not a hijack. Checking the decoded label against IDNA2008 is low-priority hardening, separate from this decision. Credited on the Hall of Fame.