Summary
Piwigo contains a SQL injection vulnerability in the Batch Manager filter handling logic because administrator-supplied dimension and filesize values from filter URLs are not validated as numeric data. An authenticated administrator may be able to inject SQL expressions that disclose, modify, or disrupt database information when the stored filter state is later used to build queries.
Affected context
The issue occurs in Piwigo's Batch Manager when filter values are supplied through the URL-based filtering path. Width, height, ratio, and filesize values can be stored in session state without the numeric validation applied by the corresponding POST filter path, after which they may be concatenated into SQL predicates.
Exploit preconditions
- Attack surface: The Batch Manager filter URL and its session-backed query path
- Required access: An authenticated account with administrator privileges
- Trigger point: Processing a crafted filter request followed by query construction using the stored filter state
- Why exploitation is possible: Numeric-looking filter parameters are accepted without strict validation and are later incorporated into SQL predicates as query text
Why this happens
The underlying bug is a failure to preserve the boundary between data and SQL syntax. The URL filter parser accepts values that should be numeric, stores them without equivalent validation, and later constructs predicates through string concatenation. This behavior maps to CWE-89 because attacker-influenced input can alter the intended SQL statement rather than being handled solely as parameter data.
Potential impact
- An attacker may disclose database records or metadata.
- An attacker could modify data if the database account permits the relevant operations.
- Crafted expressions may disrupt database availability or application behavior.
- Sensitive gallery, user, or administrative information could be exposed.
General mitigation guidance
Mitigation generally focuses on enforcing a single trusted input-handling
pattern across every filter entry point.
Common defensive patterns include:
- Using parameterized queries or prepared statements for all dynamic predicates.
- Applying strict allowlisted numeric parsing and range validation before values enter application state.
- Treating URL parameters and session-derived values as untrusted, even when only administrators can submit them.
- Reusing the same validation and query-building logic for GET, POST, and other request paths.
- Limiting database privileges so the application account cannot perform unnecessary destructive or administrative operations.
- Avoiding query construction through string concatenation and centralizing database access policy.
How teams detect issues like this
Organizations can look for:
- Static-analysis findings involving SQL string concatenation with request, URL, or session values.
- Code-review signals where numeric parameters are validated on one request path but not another.
- Tests that submit nonnumeric, boundary, and SQL-expression-like values to every filter endpoint.
- Database monitoring for unusual predicate structures, time delays, error patterns, or unexpected access to sensitive tables.
- Application policy checks requiring prepared statements and centralized input validation.
Automated code-review and security-analysis tools may help identify inconsistent validation and unsafe query construction.
