Summary
PHPNuxBill contains an unauthenticated SQL injection vulnerability in the FreeRADIUS REST endpoint, where request parameters are incorporated into database queries without sufficient separation from SQL syntax. An attacker may use crafted input in accounting or authentication requests to infer customer records and credentials through time-based blind SQL injection.
PHPNuxBill contains an unauthenticated SQL injection vulnerability in the FreeRADIUS REST endpoint, where request parameters are incorporated into database queries without sufficient separation from SQL syntax. An attacker may use crafted input in accounting or authentication requests to infer customer records and credentials through time-based blind SQL injection.
Affected context
The issue occurs in PHPNuxBill deployments that expose the FreeRADIUS REST endpoint and process attacker-controlled username, macAddr, or nasid parameters for accounting or authentication actions. Risk is higher when the endpoint is reachable without authentication and the application database account can read sensitive customer or credential data.
The issue occurs in PHPNuxBill deployments that expose the FreeRADIUS REST endpoint and process attacker-controlled username, macAddr, or nasid parameters for accounting or authentication actions. Risk is higher when the endpoint is reachable without authentication and the application database account can read sensitive customer or credential data.
Exploit preconditions
- Attack surface: The FreeRADIUS REST endpoint, including accounting and authentication actions
- Required access: Network access to the endpoint; authentication may not be required
- Trigger point: Processing of request parameters used in
whereRaw()database queries - Why exploitation is possible: Input is interpolated into SQL expressions, allowing database behavior to be influenced rather than treated strictly as data
- Attack surface: The FreeRADIUS REST endpoint, including accounting and authentication actions
- Required access: Network access to the endpoint; authentication may not be required
- Trigger point: Processing of request parameters used in
whereRaw()database queries - Why exploitation is possible: Input is interpolated into SQL expressions, allowing database behavior to be influenced rather than treated strictly as data
Why this happens
The vulnerability results from constructing raw SQL conditions by interpolating request-controlled values into whereRaw() queries. This insecure pattern fails to maintain a reliable boundary between application data and SQL instructions, mapping to CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection'). Time-based blind techniques can infer information from database response timing even when query results are not directly returned.
The vulnerability results from constructing raw SQL conditions by interpolating request-controlled values into whereRaw() queries. This insecure pattern fails to maintain a reliable boundary between application data and SQL instructions, mapping to CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection'). Time-based blind techniques can infer information from database response timing even when query results are not directly returned.
Potential impact
- An attacker may extract customer records
- Database credentials or stored authentication data could be disclosed
- Sensitive account and network information may be inferred
- Application data could be altered or deleted if database privileges permit it
- The application and connected services could experience unauthorized access or disruption
- An attacker may extract customer records
- Database credentials or stored authentication data could be disclosed
- Sensitive account and network information may be inferred
- Application data could be altered or deleted if database privileges permit it
- The application and connected services could experience unauthorized access or disruption
General mitigation guidance
Mitigation generally focuses on ensuring that all request values remain data throughout database processing.
Common defensive patterns include:
- Using parameterized queries, prepared statements, or framework query APIs that bind values safely
- Avoiding raw SQL construction from request parameters
- Applying allowlisted validation for identifiers such as usernames, MAC addresses, and NAS IDs
- Using a database account with only the permissions required by the endpoint
- Restricting exposure of the FreeRADIUS REST endpoint through authentication, network controls, and policy enforcement
- Minimizing storage and exposure of sensitive credentials, with appropriate one-way protection where applicable
Mitigation generally focuses on ensuring that all request values remain data throughout database processing.
Common defensive patterns include:
- Using parameterized queries, prepared statements, or framework query APIs that bind values safely
- Avoiding raw SQL construction from request parameters
- Applying allowlisted validation for identifiers such as usernames, MAC addresses, and NAS IDs
- Using a database account with only the permissions required by the endpoint
- Restricting exposure of the FreeRADIUS REST endpoint through authentication, network controls, and policy enforcement
- Minimizing storage and exposure of sensitive credentials, with appropriate one-way protection where applicable
How teams detect issues like this
Organizations can look for SQL injection risks through:
- Static analysis rules that flag request data passed into raw query methods
- Code review checks for string interpolation or concatenation in SQL expressions
- Dynamic testing of endpoint parameters with non-destructive injection indicators and response-timing analysis
- Web application firewall or API gateway policies monitoring anomalous query-like input and repeated timing-based requests
- Database audit logs and application telemetry showing unusual access to customer or credential tables
- Automated security review tools that identify unsafe query construction patterns
Organizations can look for SQL injection risks through:
- Static analysis rules that flag request data passed into raw query methods
- Code review checks for string interpolation or concatenation in SQL expressions
- Dynamic testing of endpoint parameters with non-destructive injection indicators and response-timing analysis
- Web application firewall or API gateway policies monitoring anomalous query-like input and repeated timing-based requests
- Database audit logs and application telemetry showing unusual access to customer or credential tables
- Automated security review tools that identify unsafe query construction patterns
