Summary
Piwigo contains a SQL injection vulnerability in the public rating-based image search flow when ratings are enabled. An unauthenticated guest may influence a search parameter and potentially extract database information through error-based or blind techniques, including database-dependent timing behavior.
Affected context
The issue affects Piwigo deployments where image ratings are enabled and unauthenticated users can access the public filtered-search workflow. It becomes risky when rating-bound input is stored in search rules without complete validation and is later incorporated into SQL statements without reliable parameterization.
Exploit preconditions
- Attack surface: Public web-based image search functionality
- Required access: No authentication; an unauthenticated guest may be sufficient
- Trigger point: Creation and opening of a filtered-search URL containing a crafted rating value
- Why exploitation is possible: The upper rating bound can reach SQL construction without adequate validation or parameter binding, allowing database behavior to be influenced through the search flow
Why this happens
The vulnerability results from incomplete validation and unsafe SQL construction for a user-controlled rating boundary. Although one rating bound is converted to an integer, the corresponding upper-bound value is retained and concatenated into a database query. This behavior maps to CWE-89: Improper Neutralization of Special Elements used in an SQL Command, where application input is treated as query syntax instead of being handled exclusively as data.
Potential impact
- An attacker may infer database contents through error-based or blind responses
- An attacker could use timing behavior to distinguish database results
- Sensitive application or user data may be disclosed
- Database availability could be affected by expensive or repeated queries
- The vulnerability may provide a foundation for further compromise depending on database permissions and application configuration
General mitigation guidance
Mitigation generally focuses on removing user-controlled SQL construction and reducing trust in public search parameters.
Common defensive patterns include:
- Use parameterized queries or prepared statements for every dynamic search value
- Apply strict allowlist validation and type enforcement before values enter query logic
- Validate the complete rating range rather than converting only selected bounds
- Keep query construction separate from request parsing and presentation-layer URL handling
- Run the application database account with the minimum permissions required
- Limit unnecessary unauthenticated search functionality or apply suitable rate and resource controls
- Return generic database errors and avoid exposing query diagnostics to clients
How teams detect issues like this
Organizations can identify similar issues through:
- Static analysis rules for SQL string concatenation involving request parameters
- Code review checks for numeric-looking inputs that are validated inconsistently across bounds
- Tests that exercise public search endpoints with malformed, boundary, and unexpected type values
- Database monitoring for unusual error rates, repeated conditional queries, or timing-oriented request patterns
- Web-application firewall or API policy rules that restrict suspicious search parameters while application-level fixes are developed
- Automated security testing and code-review tools that flag unparameterized query construction
