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.
4 steps from start to impact.
Find an HTTP password form
- 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
- Modern enterprises increasingly force HTTPS site-wide
- Browsers visibly warn users on insecure login pages
- Many internet-facing apps already redirect or preload HSTS
Gain a network vantage point
- Attacker can observe or tamper with traffic between user and application
- User traffic traverses a segment the attacker can access
- 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
Wait for a real user to authenticate
- A user actually visits the page and submits credentials
- The credentials are transmitted over HTTP at the moment of login
- 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
Replay the credential into the application
- Captured credentials are still valid
- The account has useful privileges
- MFA or conditional access does not fully block reuse
- MFA can sharply reduce replay value
- Least-privilege accounts limit blast radius
- Credential reuse is common but not guaranteed
The supporting signals.
| In-the-wild status | No 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 availability | Commodity tooling is enough: Wireshark, tcpdump, bettercap, and Ettercap can capture or support interception once the attacker is on path. |
| EPSS | Not applicable. There is no CVE-backed EPSS model entry for Tenable plugin 26194. |
| KEV status | Not applicable. This finding is not a CISA KEV-listed CVE. |
| CVSS / vendor baseline | Tenable 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 scope | Any application, portal, embedded device UI, or admin console where a password-bearing form is served or submitted over HTTP instead of HTTPS. |
| Fixed version | There 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 data | Internet 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 / publication | Tenable plugin published 2007-09-28 and last updated 2016-11-29. |
| Mapped weakness | Primary mapping is CWE-523, with broader credential-protection relationships to CWE-522 and related entries referenced by Tenable. |
noisgate verdict.
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.
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.
What to do — in priority order.
- 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.
- Enable HSTS — Set
Strict-Transport-Securityso 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. - 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.
- 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.
- 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.
- Hiding the password with
type="password"does nothing for transport security; it only masks local display. - Changing the login
POSTmethod fromGETtoPOSTdoes 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.
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.
#!/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()
If you remember one thing.
Sources
- Tenable Nessus Plugin 26194
- CWE-523 Unprotected Transport of Credentials
- OWASP WSTG - Testing for Credentials Transported over an Encrypted Channel
- OWASP Transport Layer Security Cheat Sheet
- OWASP HSTS Cheat Sheet
- Firefox Help - Insecure Connection Password Warning
- Mozilla Hacks - Login Forms over HTTPS, Please
- Chrome Developers - Avoiding the Not Secure warning in Chrome
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.