Web Server Transmits Cleartext Credentials: How to Fix It

“Web Server Transmits Cleartext Credentials” means a scanner found a login form (an input of type password), or an HTTP Basic Authentication prompt, served over plain HTTP, so usernames and passwords cross the network unencrypted. Fix it by serving those pages only over HTTPS, redirecting HTTP with a 301, and turning off HTTP management on appliances.

What the scanner is actually detecting

Every major scanner has a version of this check. The titles and severities differ a lot, which confuses people comparing reports.

Nessus 26194 depends on the webmirror.nasl crawler. It reports HTML forms containing an input of type password that submit over an unencrypted connection, and its synopsis is careful: the server “might transmit credentials in cleartext.” Because it relies on the crawl, it only flags forms the crawler actually reached. The Greenbone check goes further and also lists URLs on a plain HTTP port that answer with a Basic Authentication challenge. Acunetix reports a broader, related issue, SSL/TLS Not Implemented, whenever the target was reached over an unencrypted connection at all.

The finding output lists the pages or URLs where the password field or Basic Authentication prompt was found. Start there.

Real-world risk

Exploitation needs an on-path position: the same Wi-Fi, a LAN segment where ARP spoofing works, a compromised switch or router, or a mirror port. From there, credentials in an HTTP POST body or a Basic Authentication header are readable without any cracking. On a flat internal network that is a realistic position for malware or a malicious insider, and the credentials that most often travel this way are the admin logins for switches, printers, UPS units and server management consoles, which are high value and frequently reused.

The severity spread in the table reflects scope, not disagreement about the mechanism. Nessus scores it Low because its CVSS vector assumes high attack complexity and a partial confidentiality impact only. Burp rates it High because a captured password usually means full account takeover of the application under test. Rate your instance by what the credential unlocks and who can sit on that network path.

How to confirm it on the host

Check what the HTTP port actually returns for the page named in the finding. A fixed site answers with a 301 or 308 and a Location: https:// header; a vulnerable one returns 200 with the form, or 401 with a Basic challenge.

# Does port 80 serve the page or redirect it?
curl -sI http://app.example.com/login

# Look for password inputs and where the form posts
curl -s http://app.example.com/login | grep -io '<form[^>]*>|<input[^>]*type="password"[^>]*>'

# Basic Authentication on plain HTTP shows up as a 401 with this header
curl -sI http://10.0.0.20/ | grep -i 'www-authenticate'

On Windows 10 and 11, curl.exe accepts the same flags; pipe to Select-String instead of grep. Also check the action attribute of the form over HTTPS: a page served over HTTPS whose form posts to an absolute http:// URL still sends the password in cleartext.

To find other login pages on HTTP ports across a subnet, the Nmap http-auth-finder script spiders sites and reports pages using form-based or HTTP-based authentication:

nmap -p 80,8080 --script http-auth-finder 10.0.0.0/24

How to fix it

The goal is that no password field and no authentication prompt is ever served over HTTP. Get HTTPS working with a valid certificate first, then redirect or close the HTTP side.

nginx

server {
    listen 80;
    server_name app.example.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl;
    server_name app.example.com;
    ssl_certificate     /etc/nginx/tls/app.example.com.crt;
    ssl_certificate_key /etc/nginx/tls/app.example.com.key;
    add_header Strict-Transport-Security "max-age=31536000" always;
    # existing location blocks
}

Remove any location or auth_basic configuration from the port 80 block so nothing but the redirect is served there. Apply with sudo nginx -t && sudo systemctl reload nginx.

Apache HTTP Server

Apache’s own recommended approach is a Redirect in a dedicated port 80 virtual host:

<VirtualHost *:80>
    ServerName app.example.com
    Redirect permanent "/" "https://app.example.com/"
</VirtualHost>

If you can only use .htaccess, Apache documents this mod_rewrite alternative:

RewriteEngine On
RewriteCond "%{HTTPS}" !=on
RewriteRule "^(.*)" "https://%{SERVER_NAME}$1" [R=301,L]

Watch the Basic Authentication trap here. In per-directory context mod_rewrite runs in the Fixup phase, after authentication and authorization, so an AuthType Basic block in the same .htaccess prompts for credentials over HTTP before the redirect fires. That is exactly what the Greenbone check reports. The vhost Redirect is processed at URL translation, before authorization, and avoids it. Test with sudo apachectl configtest, then reload.

IIS

On IIS 10.0 version 1709 and later, the site’s <hsts> element includes a redirect switch:

%windir%system32inetsrvappcmd.exe set config -section:system.applicationHost/sites "/[name='Contoso'].hsts.redirectHttpToHttps:True" /commit:apphost

Microsoft notes that this redirect replaces the scheme and ignores the port, so HTTPS must be on 443. On older IIS, or for an admin site nobody should reach over HTTP, require TLS instead. HTTP requests then get an error rather than a redirect:

%windir%system32inetsrvappcmd.exe set config "Contoso" -section:system.webServer/security/access /sslFlags:"Ssl" /commit:apphost

Applications behind a reverse proxy or load balancer

When a proxy terminates TLS and talks HTTP to the backend, the application may think every request is plain HTTP and write http:// into form actions and redirects. Pass the original scheme (in nginx, proxy_set_header X-Forwarded-Proto $scheme;) and configure the framework to trust that header from the proxy only. Put the HTTP to HTTPS redirect on the proxy.

Switches, printers and other appliances

Many switches, printers and management controllers ship with an HTTP console enabled. In the device’s web or CLI settings, enable HTTPS, confirm you can log in over it, then disable HTTP. On Cisco IOS:

configure terminal
 ip http secure-server
 no ip http server
end
show running-config | include ip http

Save the configuration once HTTPS login is confirmed. If the device offers no HTTPS or cannot turn HTTP off, restrict its management interface to an admin VLAN and record the exception. Before rescanning embedded devices aggressively, read how to scan fragile OT devices, printers and embedded hosts.

Harden the session afterwards

PortSwigger’s remediation for this issue also calls for session tokens never to cross unencrypted connections and for the Secure flag on cookies. Once HTTPS works everywhere, add HSTS (the nginx example above) so browsers stop trying HTTP first.

How to verify the fix and rescan

curl -sI http://app.example.com/login      # expect 301 and Location: https://...
curl -sI https://app.example.com/login     # expect 200 over TLS
curl -s https://app.example.com/login | grep -io 'action="http://[^"]*"'   # expect no output

Repeat against the IP address as well as the hostname, since scanners often test by IP and land on the default virtual host. Then rescan with the same policy and port list. Plugin 26194 depends on the webmirror.nasl crawler, so a scan that no longer reaches the web service simply stops reporting it, which is not the same as a fix.

What can break and how to roll back

• Redirect loops. An application that forces HTTPS itself while sitting behind a TLS-terminating proxy that talks HTTP will redirect forever. Fix the forwarded scheme header.
• Non-browser clients. Scripts, monitoring checks and older agents that POST to http:// may not follow redirects, or re-send as GET. Update their URLs to https://.
• Certificate errors. A self-signed or expired certificate on the new HTTPS console produces browser warnings, and with HSTS, hard failures.
• Appliance lockout. Disabling HTTP before HTTPS works leaves you with console or SSH only. On Cisco IOS, ip http server restores it.

Browsers cache 301 responses, so removing the redirect does not immediately undo it for users who already saw it. Test with a 302 first, then switch to 301. To roll back on nginx or Apache, remove the redirect block, restore the previous port 80 configuration and reload.

Common false positive reasons

• HTTP page posting to HTTPS. The password itself travels over TLS, but an on-path attacker can rewrite the unencrypted page to post elsewhere. Treat it as real and redirect the page.
• Default virtual host. Scanning by IP hits a default server block with a login page, while named hosts redirect correctly. Real for that address, but often unreachable by users.
• Scanner bypassed the front end. The load balancer or WAF redirects, but the scan reached the origin directly on port 80. See how a WAF changes what your web scanner reports.
• Non-credential password fields. A masked input for a license key or PIN matches the same pattern. The finding is technically accurate even if the data is not a login.

FAQ

Is a redirect from HTTP to HTTPS enough?

For browsers, yes, as long as the login page is only served over HTTPS and forms post to https:// URLs. HSTS closes the remaining gap of the first plain request.

Does this matter for internal-only admin pages?

Yes. Internal networks are where on-path attackers most often operate, and admin consoles carry the most valuable credentials.

Will a self-signed certificate close the finding?

It removes the cleartext transmission, so this check should clear, but expect certificate trust findings instead. Use a certificate from your internal CA.

Why does Nessus say Low while Burp says High?

Nessus scores the network precondition; Burp scores the impact of a stolen application password. Both describe the same flaw.

Tracking this finding across many hosts

This finding tends to surface on dozens of appliances and forgotten admin pages at once, often reported by more than one tool. SITEY, a self-hosted vulnerability management platform, imports findings from 16 scanners, though duplicates are merged per scanner rather than across scanners. Per-finding retest is available for Nessus, Acunetix and Burp results, which fits checking each fixed console individually; for other scanners, rerun the scan.

Sources

• Tenable: Nessus plugin 26194, Web Server Transmits Cleartext Credentials
• PortSwigger: Cleartext submission of password
• Apache HTTP Server 2.4: Redirecting and Remapping with mod_rewrite (Forcing HTTPS)
• Microsoft Learn: HSTS settings for a Web Site <hsts>
• nginx: ngx_http_rewrite_module (return)