CVE-2019-12385

What it actually does

Unauthenticated or low-privileged search requests reach lib/class/search.class.php without proper parameterization, allowing arbitrary SQL to be injected and executed against the backend database, exposing all stored rows including sessions and password hashes.

Why it matters to the business

Attackers can obtain every user credential and session token stored by the application, enabling complete takeover of administrative accounts and full access to the organization's media catalog and user data.

How an attack unfolds

An attacker submits a crafted search term through any exposed search endpoint; the unsanitized input is concatenated into a SQL query inside search.class.php; the resulting query returns arbitrary database contents such as password hashes; the attacker then leverages the application's weak lost-password token generator to reset admin accounts and gain persistent control.

How to fix it

Upgrade Ampache to a version that properly parameterizes all search queries; restrict guest search privileges until the fix is applied; enforce strong, unique passwords and consider disabling or hardening the lost-password feature.

How to confirm the fix worked

Review source code or run a static-analysis scan to confirm that search.class.php now uses prepared statements; attempt a benign search payload and verify that no database error or unexpected data is returned; confirm that password-reset tokens are now generated with a secure random algorithm.

Typical attack path

1. Identify a reachable search endpoint (guest access permitted)
2. Inject SQL payload into search parameters targeting lib/class/search.class.php
3. Extract password hashes and session data from database response
4. Abuse weak password-reset algorithm to obtain valid admin credentials
5. Authenticate as administrator and maintain access

How to detect it

Search web-server and application logs for search requests containing SQL metacharacters or unusually long parameter values; inspect database audit logs for SELECT statements that reference session or user tables outside normal application flow; look for subsequent password-reset requests originating from the same source IP shortly after search activity.

• search.class.php
• lib/class/search.class.php
• lostpassword

What your security team should do

• Immediately restrict or disable guest search functionality if an upgrade cannot be performed within 48 hours
• Audit all administrative accounts and force password resets using a secure mechanism
• Deploy a web-application firewall rule that blocks common SQL-injection patterns on search endpoints
• Monitor database query logs for anomalous SELECT statements originating from the search module