WeTTY puts the authentication boundary in front of a browser terminal
WeTTY provides a terminal in a browser over HTTP or HTTPS. That description is enough to explain why exposure matters. A reachable terminal may execute commands with the service account's privileges, reach internal networks, or expose a shell that the operator did not intend to publish.
The official WeTTY documentation recommends running it behind a reverse proxy with TLS and access control. Its deployment guidance suggests binding to 127.0.0.1 and using an authenticated proxy. The application can also connect to SSH with password or public-key authentication depending on the configuration.
ZoomEye observations
On 10 November 2026, count-only observations used sub_type=all, page 1, and page size 1. app="WeTTY" returned 203 matches. title="WeTTY" returned 1,964, and http.body="WeTTY" returned 1,904.
The selected query is the ZoomEye application search for app="WeTTY". It is narrower than the title and body results, though a fingerprint still needs validation. The count describes matching services, not confirmed unauthenticated terminals and not confirmed command execution.
The proxy is the access-control layer
When the application binds only to localhost and an authenticated reverse proxy handles public requests, the proxy's policy is the terminal's policy. Review:
- proxy authentication and group membership;
- session timeout and logout behavior;
- WebSocket upgrade handling;
- source-IP restrictions;
- rate limits and connection limits;
- TLS certificate and hostname validation;
- whether the application port is reachable around the proxy.
Test the direct port from an external host. A proxy rule is irrelevant if the backend is also published on a public interface.
The proxy must remove untrusted client headers before adding its own identity headers. If WeTTY or the upstream SSH configuration trusts a username header, a client-supplied value may become the authenticated identity. Enable a dedicated service account and restrict which SSH hosts and commands it can reach.
Choose the shell authority deliberately
WeTTY may run a local shell or SSH to another host. The local-shell mode gives the web process the operating-system permissions of its service account. The SSH mode gives it the SSH key or password configured for the target. Neither mode should run as root for convenience.
Use a dedicated Unix account with a restricted home directory and no access to deployment secrets. If the terminal is meant only for a specific administrative command, restrict the remote command and the target account. Do not make a general-purpose shell available to a team through a shared password.
Record the hosts, users, keys, and network paths reachable from each WeTTY deployment. Test a connection with a user who should be denied. Confirm that a revoked proxy account cannot keep an existing terminal session open, and that closing the browser terminates the session or the proxy enforces its own timeout.
Operate it as an administrative service
Alert on new WeTTY listeners, changes to the proxy route, and direct access to the backend port. Collect authentication logs from the proxy and shell or SSH logs from the target. Preserve session start and end times, source addresses, and the authenticated principal.
If the service is not required, remove the public route and stop the listener. If it is required for break-glass access, put it behind a private network and a strong identity provider. Keep an out-of-band recovery path that does not depend on the terminal service itself.
The 203 application matches provide a scoped list for review. Establish whether each one is a terminal behind an authenticated proxy or a terminal that became the authentication boundary by accident.
