Summary
CVE-2026-44642 is a SQL injection vulnerability in Piwigo’s upgrade authentication mechanism, affecting all versions prior to 16.4.0. The flaw allows an unauthenticated attacker to bypass administrator credential checks during pending database upgrades by injecting SQL into the username parameter. The issue carries a CVSS v3.1 base score of 8.1 (High), reflecting network exploitability with no authentication required and high impact on confidentiality, integrity, and availability.
Technical details
- Root cause: The
check_upgrade_access_rights()function inadmin/include/functions_upgrade.phponly escapes the submitted username when the PHP functionget_magic_quotes_gpc()exists. This function was removed in PHP 8.0, so on PHP 8+ deployments the escaping branch is silently skipped and the submitted username is concatenated directly into the SQL query used for upgrade authentication. - Trigger conditions: The installation must be running on PHP 8 or later and have a pending database upgrade (a common post-update state) for the vulnerable authentication code path to be reachable.
- Attack vector: An unauthenticated attacker sends a crafted POST request to
upgrade.phpwith a malicioususernameparameter containing SQL injection payloads (e.g., aUNION SELECTstatement crafted to satisfy the status and password checks). - Impact: A successful injection can satisfy the upgrade authorization checks and set the internal upgrade flag, allowing the attacker to trigger unauthorized upgrade execution without valid administrator credentials — potentially leading to database integrity changes and service disruption.
Affected software
- Piwigo (self-hosted photo gallery software) — all versions prior to 16.4.0, when running on PHP 8.0 or later.
Severity
- CVSS v3.1 Base Score: 8.1 (High)
- Vector:
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
Mitigation and recommended actions
- Immediate: Upgrade to Piwigo 16.4.0 or later, which fixes the conditional escaping logic in the upgrade authentication flow.
- If immediate patching is not possible: Restrict network access to
upgrade.phpand the admin/upgrade interface (e.g., via IP allowlisting or a web application firewall rule blocking unauthenticated access to upgrade endpoints), and avoid leaving database upgrades pending for extended periods on internet-facing installations.

