← Back to Feed CACHED · 2026-05-17 09:42:19 · cache_key CVE-2025-29912
tenable:26194 · CWE-523 · Disclosed 2007-09-28

Web Server Transmits Cleartext Credentials

ASSESSED — NOISGATE V0.5
Vendor
Reassessed
Verdict:
01 · The Real Story

This is a paper envelope with a visible window, not a door left off the vault

Tenable plugin 26194 is not a product-specific CVE; it is a generic web finding that flags HTML forms with input type="password" whose submission path is cleartext HTTP. In practice, the affected population is any web page or admin interface that serves or submits password-bearing forms without HTTPS, regardless of software brand or version, because the weakness is transport configuration rather than a buggy release train.

Tenable calling this LOW is mostly fair for enterprise patch prioritization. The upside risk is obvious—captured credentials can become real access—but the decisive friction is attacker position: someone has to get on path between user and app, or already control part of the network, and then wait for a login event. That makes this a credential-exposure hygiene issue, not a straight-line remote compromise.

"Real weakness, weak patch priority: this leaks passwords only if someone can sit on the wire and catch a user login."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Find an HTTP password form

An attacker or scanner uses a crawler such as Nessus, OWASP ZAP, or a simple browser inspection to identify a page containing a password field whose page or form target is HTTP. This is easy to automate because the HTML itself advertises the form structure.
Conditions required:
  • The application exposes a login or password-bearing form
  • The form is reachable without prior authentication
  • The form page or submission target uses HTTP instead of HTTPS
Where this breaks in practice:
  • Modern enterprises increasingly force HTTPS site-wide
  • Browsers visibly warn users on insecure login pages
  • Many internet-facing apps already redirect or preload HSTS
Detection/coverage: Very good scanner coverage for unauthenticated discovery; Tenable specifically checks HTML forms for password inputs and insecure transport.
STEP 02

Gain a network vantage point

The attacker then needs an on-path position using tools like bettercap, Ettercap, a rogue access point, a hostile proxy, or compromised internal network gear. Without that network position, the insecure form is a bad idea but not an exploitable event.
Conditions required:
  • Attacker can observe or tamper with traffic between user and application
  • User traffic traverses a segment the attacker can access
Where this breaks in practice:
  • This is not unauthenticated internet-to-host exploitation
  • Segmentation, VPNs, WPA2/3-Enterprise, NAC, and switch protections reduce viable sniffing positions
  • For internal-only apps, the attacker is often already post-initial-access
Detection/coverage: The web finding itself does not prove exploitability. Network IDS may catch ARP spoofing, rogue DHCP, or suspicious proxying, but many environments lack reliable coverage for local MITM activity.
STEP 03

Wait for a real user to authenticate

Once traffic is visible, a normal login submission exposes the credential material in transit. Passive capture can be done with tcpdump or Wireshark; if the page itself is insecure, active tampering is also possible before submission.
Conditions required:
  • A user actually visits the page and submits credentials
  • The credentials are transmitted over HTTP at the moment of login
Where this breaks in practice:
  • No login event means no payoff
  • Password managers and browser warnings may suppress user submission
  • Federated auth flows can reduce how often passwords are typed into the app itself
Detection/coverage: Packet capture trivially confirms exposure during testing. App-layer scanners detect the condition, but they do not observe live credential theft.
STEP 04

Replay the credential into the application

The attacker reuses the captured username and password against the target app, SSO boundary, VPN, or adjacent systems where the same secret is reused. Tooling is minimal; a browser or scripted HTTP client is enough once a working credential is obtained.
Conditions required:
  • Captured credentials are still valid
  • The account has useful privileges
  • MFA or conditional access does not fully block reuse
Where this breaks in practice:
  • MFA can sharply reduce replay value
  • Least-privilege accounts limit blast radius
  • Credential reuse is common but not guaranteed
Detection/coverage: Identity telemetry may show unusual logins or impossible travel, but simple same-network replay can blend in unless MFA or UEBA is strong.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo CVE or KEV record applies here; this is a generic transport weakness, not a named software exploit. Exploitation technique is longstanding and well understood.
Proof-of-concept availabilityCommodity tooling is enough: Wireshark, tcpdump, bettercap, and Ettercap can capture or support interception once the attacker is on path.
EPSSNot applicable. There is no CVE-backed EPSS model entry for Tenable plugin 26194.
KEV statusNot applicable. This finding is not a CISA KEV-listed CVE.
CVSS / vendor baselineTenable rates the plugin LOW and does not publish a product CVSS vector on the plugin page. That is reasonable because impact depends heavily on user behavior and network position.
Affected scopeAny application, portal, embedded device UI, or admin console where a password-bearing form is served or submitted over HTTP instead of HTTPS.
Fixed versionThere is usually no patched software version. The fix is configuration and deployment: serve the form over HTTPS, submit over HTTPS, and preferably enforce HSTS.
Scanning / exposure dataInternet search engines like Shodan/Censys can find HTTP services, but they do not reliably tell you whether a password form submits in cleartext without deeper crawling. This is best validated by web scanners or direct page inspection.
Disclosure / publicationTenable plugin published 2007-09-28 and last updated 2016-11-29.
Mapped weaknessPrimary mapping is CWE-523, with broader credential-protection relationships to CWE-522 and related entries referenced by Tenable.
04 · The Call

noisgate verdict.

Final Verdict
= UNCHANGED to LOW (3.3/10)

The single biggest reason this stays LOW is that exploitation requires a network vantage point plus a live user login, not direct remote compromise of the server. That sharply narrows both reachable population and time-to-impact compared with real internet-exploitable bugs.

HIGH Assessment that this is not a patch-priority equivalent to server-side RCE or auth bypass
MEDIUM Impact variation by environment, especially if the affected form is an exposed admin portal or high-value auth boundary

Why this verdict

  • Attacker-position friction: exploitation usually requires on-path access, a rogue AP, hostile proxy, or prior foothold on the same network segment.
  • User-action dependency: no credential theft occurs until a real user submits a password through the affected form.
  • Blast radius is conditional: impact can be serious for a privileged account, but it is still bounded by account privilege, MFA, and whether the captured secret is reusable elsewhere.

Why not higher?

This is not unauthenticated remote code execution, not auth bypass, and not a direct server compromise primitive. The chain depends on prior network access and a victim login event, which is exactly the kind of real-world friction that should push severity down for enterprise scheduling.

Why not lower?

It is still a real credential-exposure condition, not noise. If the form belongs to an admin interface, network appliance, or internal business app where users authenticate from untrusted or shared network segments, one successful capture can translate into meaningful access.

05 · Compensating Control

What to do — in priority order.

  1. Force HTTPS everywhere — Serve the login page itself over HTTPS and submit the form over HTTPS; do not rely on HTTP landing pages that redirect later. For a LOW verdict there is no SLA, so treat this as backlog hygiene and fold it into the next normal web hardening cycle.
  2. Enable HSTS — Set Strict-Transport-Security so browsers stop attempting cleartext access after first trust establishment. This reduces downgrade and first-hop user error risk; for a LOW verdict, deploy in routine change windows.
  3. Front insecure apps with a secure reverse proxy — If the app itself is legacy and cannot natively do TLS, terminate HTTPS at a reverse proxy or load balancer and block direct HTTP access from user networks. This is the practical containment move when the underlying product is old or embedded.
  4. Require MFA on the affected auth path — MFA does not fix cleartext transit, but it can cut the replay value of a captured password. For a LOW verdict, add this under standard IAM backlog if the exposed app is high-value.
  5. Restrict network reachability — Keep internal-only HTTP admin pages off guest Wi-Fi, flat user LANs, and internet-exposed edges. Segmentation lowers the odds that an attacker can get the on-path position needed to monetize the weakness.
What doesn't work
  • Hiding the password with type="password" does nothing for transport security; it only masks local display.
  • Changing the login POST method from GET to POST does not protect credentials from sniffing on HTTP.
  • A WAF is not the primary fix here; if the browser talks HTTP, the credential is already exposed before server-side filtering matters.
06 · Verification

Crowdsourced verification payload.

Run this from an auditor workstation or CI runner that can reach the target URL. Invoke it as python3 check_cleartext_form.py https://app.example.com/login or python3 check_cleartext_form.py http://app.example.com/login; no special privileges are required.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# check_cleartext_form.py
# Detects password-bearing HTML forms that are served or submitted over cleartext HTTP.
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

import sys
import ssl
from html.parser import HTMLParser
from urllib.parse import urljoin, urlparse
from urllib.request import Request, urlopen

TIMEOUT = 15
UA = 'noisgate-cleartext-form-check/1.0'

class FormParser(HTMLParser):
    def __init__(self):
        super().__init__()
        self.forms = []
        self.current_form = None

    def handle_starttag(self, tag, attrs):
        a = {k.lower(): v for k, v in attrs}
        tag = tag.lower()
        if tag == 'form':
            self.current_form = {
                'action': a.get('action', ''),
                'method': a.get('method', 'GET').upper(),
                'has_password': False,
            }
        elif tag == 'input' and self.current_form is not None:
            if a.get('type', '').lower() == 'password':
                self.current_form['has_password'] = True

    def handle_endtag(self, tag):
        if tag.lower() == 'form' and self.current_form is not None:
            self.forms.append(self.current_form)
            self.current_form = None


def fetch(url):
    ctx = ssl.create_default_context()
    req = Request(url, headers={'User-Agent': UA})
    with urlopen(req, timeout=TIMEOUT, context=ctx) as resp:
        ctype = resp.headers.get('Content-Type', '')
        final_url = resp.geturl()
        hsts = resp.headers.get('Strict-Transport-Security', '')
        body = resp.read(1024 * 1024).decode('utf-8', errors='replace')
        return final_url, ctype, hsts, body


def main():
    if len(sys.argv) != 2:
        print('UNKNOWN - usage: python3 check_cleartext_form.py <url>')
        sys.exit(2)

    url = sys.argv[1].strip()
    if not url.startswith(('http://', 'https://')):
        print('UNKNOWN - URL must start with http:// or https://')
        sys.exit(2)

    try:
        final_url, ctype, hsts, body = fetch(url)
    except Exception as e:
        print(f'UNKNOWN - fetch failed: {e}')
        sys.exit(2)

    if 'html' not in ctype.lower():
        print(f'UNKNOWN - non-HTML response: {ctype or "unknown"}')
        sys.exit(2)

    parser = FormParser()
    parser.feed(body)
    password_forms = [f for f in parser.forms if f['has_password']]

    if not password_forms:
        print('UNKNOWN - no password forms found on page')
        sys.exit(2)

    page_scheme = urlparse(final_url).scheme.lower()
    vulnerable_reasons = []

    for idx, form in enumerate(password_forms, start=1):
        action = form['action'].strip() or final_url
        resolved = urljoin(final_url, action)
        action_scheme = urlparse(resolved).scheme.lower()

        if page_scheme == 'http':
            vulnerable_reasons.append(f'form {idx}: password form served over HTTP ({final_url})')
        if action_scheme == 'http':
            vulnerable_reasons.append(f'form {idx}: password form submits over HTTP ({resolved})')

    if vulnerable_reasons:
        print('VULNERABLE - ' + '; '.join(vulnerable_reasons))
        sys.exit(1)

    hsts_note = ' with HSTS' if hsts else ' without HSTS'
    print(f'PATCHED - password forms served and submitted over HTTPS{hsts_note}')
    sys.exit(0)


if __name__ == '__main__':
    main()
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning, do not let this crowd out real exploit chains. Validate whether the finding sits on a high-value login, admin portal, or any user path that still allows HTTP; if yes, front it with HTTPS and block direct HTTP access in the next normal change cycle. For a LOW verdict there is no noisgate mitigation SLA and no noisgate remediation SLA beyond backlog hygiene, so document exposure, convert the form path to HTTPS/HSTS, and close it as part of routine web hardening rather than emergency patching.

Sources

  1. Tenable Nessus Plugin 26194
  2. CWE-523 Unprotected Transport of Credentials
  3. OWASP WSTG - Testing for Credentials Transported over an Encrypted Channel
  4. OWASP Transport Layer Security Cheat Sheet
  5. OWASP HSTS Cheat Sheet
  6. Firefox Help - Insecure Connection Password Warning
  7. Mozilla Hacks - Login Forms over HTTPS, Please
  8. Chrome Developers - Avoiding the Not Secure warning in Chrome
Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously
Validation Results

Crowdsourced verification outputs.

Results submitted by users who ran the verification payload against their environment.