CWE-549, Missing Password Field Masking, covers products that do not mask passwords during entry. MITRE's concern is that this increases the potential for attackers to observe and capture passwords.
How it happens
A password input is built as an ordinary text box. In HTML that is one attribute:
<!-- Vulnerable: password visible while typing -->
<input type="text" name="password">
<!-- Fixed: characters are masked -->
<input type="password" name="password" autocomplete="current-password">
The same issue shows up in configuration screens and admin tools. MITRE lists CVE-2025-0148, a Jenkins plugin for a video meeting product that did not mask passwords (Gold entry). Build tool settings pages are exactly where people type shared service credentials.
What an attacker gains
MITRE lists bypassing a protection mechanism as the access control impact. Someone standing nearby, a screen share, a recording or a screenshot can capture a password that is shown on screen.
How to find it
- Open every form that takes a password, secret or token and check that typed characters are hidden.
- Search the templates for text inputs whose names contain password, secret or token.
- MITRE notes static analysis can find some instances of this weakness.
How to fix it
MITRE recommends requiring all password fields in a web application to be masked, as a requirement and during implementation.
- Use the password input type for every secret field.
- Add it to your UI review checklist.
- If you offer a show-password toggle, keep masking as the default and let the user choose to reveal it.
Quick check
Does masking protect against network sniffing?
No. It only prevents onlookers and screen captures from seeing the password. Use encrypted transport separately.
