fix: ensure USERPASS_FILE credentials store password (set private_type) - #20553
Merged
smcintyre-r7 merged 1 commit intoSep 18, 2025
Merged
Conversation
BenoitDePaoli
marked this pull request as ready for review
September 17, 2025 12:57
BenoitDePaoli
force-pushed
the
fix/userpass_password_persistence
branch
from
September 17, 2025 13:42
918bd0c to
08c4367
Compare
smcintyre-r7
approved these changes
Sep 18, 2025
smcintyre-r7
left a comment
Contributor
There was a problem hiding this comment.
Thanks for this submission. I was able to reproduce the original issue then validate the fix addresses it. I did notice that this doesn't seem to affect every bruteforce module because some such as smb_login do their own detection on the private to report its type.
...
[-] 192.168.159.128:15432 - LOGIN FAILED: admin:password@template1 (Incorrect: FATAL VFATAL C28P01 Mpassword authentication failed for user "admin" Fauth.c L329 Rauth_failed)
[-] 192.168.159.128:15432 - LOGIN FAILED: admin:admin@template1 (Incorrect: FATAL VFATAL C28P01 Mpassword authentication failed for user "admin" Fauth.c L329 Rauth_failed)
[+] 192.168.159.128:15432 - Login Successful: postgres:mysecretpassword@template1
[*] Scanned 1 of 1 hosts (100% complete)
[*] Bruteforce completed, 1 credential was successful.
[*] You can open a Postgres session with these credentials and CreateSession set to true
[*] Auxiliary module execution completed
msf auxiliary(scanner/postgres/postgres_login) > creds
Credentials
===========
id host origin service public private realm private_type JtR Format cracked_password
-- ---- ------ ------- ------ ------- ----- ------------ ---------- ----------------
528 192.168.159.128 192.168.159.128 15432/tcp (postgres) postgres mysecretpassword template1 Password
msf auxiliary(scanner/postgres/postgres_login) >
Contributor
Release NotesThis fixes a bug that was preventing the private type of stored credentials to be omitted in certain conditions. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary:
Fix a bug where credentials sourced from USERPASS_FILE were not reliably persisted with their passwords in the Metasploit credential database.
The yielded credentials from each_user_pass_from_userpass_file did not set private_type, so the framework didn’t persist the password as a Metasploit::Credential::Password.
This PR makes ensures private_type is always set for USERPASS_FILE credentials.
Reproduction
Behavior Before Fix
Create a file:
Run an AuthBrute-based module, (postgres_login, mssql_login ...):
After a successful attempt, run:
Password is missing (blank / not stored).
Behavior After Fix
The same steps now show password under the private column in creds output:
Password is present and stored.