Description
A vulnerability in HotelDruid version 3.0.7 and earlier allows users to set weak passwords due to the lack of enforcement of password strength policies.
Impact
Weak Passwords Accepted: Attackers can guess simple passwords or use credential-stuffing attacks with high success rates.
Credential Reuse Risk: If users reuse passwords across systems, attackers can exploit leaked credentials.
No Password Aging: Frequent password changes to evade detection are possible.
Increased Attack Surface: Combined with vulnerabilities like reflected XSS (CVE-2025-25747), this makes initial footholds easier to gain.
Risk Summary
The absence of basic password security controls undermines the overall security of HotelDruid and leaves user accounts — including administrator accounts — highly susceptible to compromise.
Proof of Concept (PoC)
Example Test Cases (Direct Evidence)
Case 1 - Weak Password Accepted
Action: Set password to 12345.
Result: Accepted with no warning.
Case 2 - Common Password Accepted
Action: Set password to admin.
Result: Accepted with no warning.
Case 3 - Reuse of Previous Password
Action: Set password to password, change it to password123, and then back to password.
Result: Reused password accepted with no restriction.
Case 4 - Rapid Password Changes
Action: Change password 5 times within a minute.
Result: All changes allowed without any restriction.
Automated Test Script
A custom script was developed to automate these checks, verifying:
No complexity requirements.
No minimum length enforcement.
No password history checks.
No minimum password age restrictions.
This script can be shared upon request.
Analysis
Background
HotelDruid is a popular open-source property management software used for handling hotel and rental reservations, billing, and customer management. It is deployed both on-premises and online, meaning account security is critical, especially for administrative users who have control over financial data and customer information.
Modern web applications are expected to enforce at least basic password policies to reduce the risk of credential-based attacks. Applications that allow weak passwords directly undermine their own security posture, making all other defenses less effective.
Vulnerability Details
This vulnerability stems from the complete absence of any meaningful password requirements in HotelDruid version 3.0.7. During user creation, password changes, and administrative account management, the application allows:
Extremely weak passwords (e.g., 12345, aaaaa, password).
Common passwords used across many services.
No password length requirements.
Reuse of previously used passwords.
Rapid and unlimited password changes within short periods.
No feedback to users on password strength.
Attack Scenarios
Brute Force Attack: Attackers can try commonly used passwords against user accounts with very high success rates.
Credential Stuffing: If a user reuses a compromised password from another service, it can be used to gain access to HotelDruid.
Privilege Escalation Support: Once a low-privileged account is compromised, attackers can attempt to escalate privileges to an administrative account through additional attacks.
Combination Attack: Combined with other vulnerabilities (like CVE-2025-25747), this provides an easy entry point for attackers.
Mitigation / Patching
Recommendations
Enforce Password Complexity Requirements
Require at least:
One uppercase letter
One lowercase letter
One number
One special character
Minimum length of 8 characters.
Implement Password History Restrictions
Prevent reuse of the last 5 passwords.
Enforce Minimum Password Age
Require at least 24 hours between password changes to prevent rapid cycling.
Real-Time Password Strength Feedback
Provide users with feedback as they create or change passwords, helping them understand password strength.
Default Administrative Credentials Review
Audit and enforce strong credentials on administrative accounts during initial installation.
Optional Enhancements
Consider integrating external authentication providers (SSO, LDAP).
Strongly encourage multi-factor authentication (MFA) if feasible.
Timeline and Credits
Discovery Date:Â January 16, 2025
Vendor Notification:Â January 17, 2025
MITRE CVE Assignment:Â CVE-2025-25747, February 27 2025
Public Disclosure:Â March 7, 2025
Researcher:Â Huy Vo (Security Researcher)