CVE-2026-75956 in J-BusinessDirectory Extension
Summary
by MITRE • 08/19/2026
Joomla Extension - cmsjunkie.com - DOS vector in pagination parameter handling in J-BusinessDirectory < 6.2.3 - Pagination values were not strictly typed. Array/non-numeric values (for example limitstart[]) could trigger PHP type errors in arithmetic, and limit was not validated before use in list queries.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/20/2026
The vulnerability identified in the Joomla extension J-BusinessDirectory prior to version 6.2.3 represents a significant security flaw rooted in improper input validation and weak data typing within the pagination logic. This component is widely used for creating business directories on websites built with the Joomla content management system, making its integrity crucial for maintaining service availability and data consistency. The core issue lies in how the application handles parameters related to list pagination, specifically the limitstart and limit variables which dictate how many records are retrieved from the database and where the listing should begin. In a properly secured implementation, these values must be strictly validated as integers before being processed or passed into SQL queries. However, in versions of J-BusinessDirectory earlier than 6.2.3, this validation was insufficient, allowing attackers to supply non-numeric data types such as arrays or strings where integer expectations were set by the underlying PHP code and database engine.
From a technical perspective, the flaw manifests primarily through two distinct mechanisms that can lead to service disruption. First, when an attacker supplies array-type values like limitstart[] instead of a standard numeric value, it triggers PHP type errors during arithmetic operations or internal processing logic designed for integers. These unhandled exceptions can cause the script execution to halt abruptly, resulting in a visible error page or a blank screen depending on server configuration and display settings. Second, and more critically, the lack of strict validation before use in list queries allows malformed input to reach the database layer. If the application constructs SQL statements using these unchecked values without proper sanitization, it can lead to syntax errors that prevent query execution entirely. In some configurations, particularly if error reporting is enabled or if the database driver behaves unpredictably with invalid types, this can cause the web server process to crash or become unresponsive, effectively denying service to legitimate users attempting to browse directory listings.
This vulnerability aligns closely with CWE-20 Improper Input Validation and CWE-754: Improper Check for Unusual or Exceptional Conditions from the Common Weakness Enumeration standards. The failure to enforce type constraints on user-supplied input is a classic example of trusting client-side data without server-side verification, which violates fundamental secure coding principles outlined in OWASP guidelines regarding injection prevention and error handling. Furthermore, the operational impact falls under Denial of Service (DoS) as defined by MITRE ATT&CK technique T1499: Endpoint Denial of Service or potentially T1053 Scheduled Task/Job if the crash leads to persistent service instability requiring manual intervention. The availability of this vector means that an unauthenticated attacker can target specific directory listing pages and disrupt access for all users, impacting business operations that rely on these directories for customer engagement and lead generation.
Mitigation strategies must focus on immediate patching and robust input sanitization practices. Administrators running J-BusinessDirectory should upgrade to version 6.2.3 or later where the pagination parameters are strictly typed as integers before any processing occurs. For environments where upgrading is not immediately feasible, a temporary workaround involves implementing web application firewall rules that block requests containing array syntax in query parameters associated with pagination endpoints such as limitstart and limit. Additionally, developers should ensure that all database interactions use prepared statements or parameterized queries which inherently handle type safety better than string concatenation methods. Regular security audits of third-party Joomla extensions are essential to identify similar weaknesses in other components that may share the same architectural patterns for handling user input.