highSeverity: highRisk ratingHow usable this gap is to an attacker. Severity sets the posture penalty: critical −40, high −20, medium −10, low −4, info −1. Higher severity means fix it sooner.Web server config + password resetWhere it livesImplementationThis fix is applied in: Web server config + password reset. That's the surface you'll edit, DNS, response headers, or a static file.~10 minTime to fixEffortRoughly 10 minutes of hands-on work, propagation aside. Most of these are copy-paste.+20 posture+20 postureScore impactPoints this fix recovers in the ApeCyber posture score (0–100). Posture = 100 minus the severity penalty of every open finding; clearing this finding adds these points back.

Exposed .htpasswd: reset the logins and stop serving the hash file

Resetting the accounts in a leaked .htpasswd and blocking the file keeps offline-cracked passwords from unlocking what they guarded

The threat

The scanner requested /.htpasswd and got back user:hash lines. That file backs HTTP Basic Auth: each line is a username and a hashed password for a protected area. The passwords are not in plain text, but the hashes themselves are right there to take.

A hash you can download is a hash you can crack at leisure: offline, with no rate limit and no lockout, using wordlists and GPUs. Weak or common passwords fall in seconds, and even decent ones fall eventually, especially if the file uses an older hash like Apache MD5 ($apr1$) or crypt. Whatever that login protected should be considered reachable. That cracking step between exposure and entry is why this is rated high rather than critical, but it is not a barrier you can lean on.

The exact fix

Step 1, contain: reset the exposed logins. Every credential in that file has to be treated as compromised.

  • Regenerate each entry with a new, strong password and a modern hash. Apache’s tool uses bcrypt with -B:
htpasswd -B -c /etc/apache2/.htpasswd alice

Drop the -c flag after the first user, or it overwrites the whole file. Give each user their new password through a separate channel.

  • If anyone reused that password elsewhere, change it there too.

Step 2, stop serving the file. The .htpasswd should live outside the web root entirely.

  • Move it above the served directory (for example /etc/apache2/.htpasswd, not /var/www/html/.htpasswd) and point AuthUserFile at the new path.
  • Keep it out of deploys: add .htpasswd to .gitignore, and never copy it into published output.
  • Block the path as a backstop. Apache denies .ht* by default in many builds, but make it explicit.

Apache:

<FilesMatch "^\.ht">
    Require all denied
</FilesMatch>

nginx:

location ~ /\.ht {
    deny all;
    return 404;
}

The real fix is location, not just a deny rule. Basic Auth is fine; the file backing it simply belongs on the filesystem, above public_html, where a web server can never serve it even by mistake.

Verify it

curl -s https://yourdomain.com/.htpasswd

You want a 404 or 403, not user:$apr1$... lines. Any :$ hash in the output means the file is still readable, and the logins still need resetting.

Proof

The ApeCyber scanner flags this passively with a single GET of /.htpasswd, from the outside, and never attempts to crack anything it sees. Confirmation is only that the file returns user:hash lines. At −20 this is a high-severity hit, and it clears once the file is out of the web root and the affected logins are reset.