CVE-2026-75953 in J-BusinessDirectory Extension
Summary
by MITRE • 08/19/2026
Joomla Extension - cmsjunkie.com - Open mail relay in J-BusinessDirectory < 6.2.3 - Recipient address was taken from the request (contact_id_offer / contact_id_event) instead of the server-side offer/event record, so mail could be sent to an arbitrary address.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/19/2026
The vulnerability identified within Joomla Extension J-BusinessDirectory versions prior to 6.2.3 represents a critical failure in input validation and trust boundary enforcement, specifically classified under CWE-14 as a Class of Vulnerability involving compiler or interpreter removal of security-critical actions, though more accurately described by CWE-918 for Server-Side Request Forgery (SSRF) variants or CWE-770 for Allocation of Resources Without Limits. The core technical flaw lies in the application's handling of email functionality where the recipient address is dynamically constructed based on user-supplied input parameters rather than being resolved from a trusted server-side data source. Specifically, the system accepts contact identifiers such as contact_id_offer and contact_id_event directly from HTTP requests to determine the destination for outgoing emails. Instead of querying the database or internal state to retrieve the verified email address associated with that specific offer or event record, the application blindly trusts the input provided by the client side. This architectural decision bypasses essential integrity checks, allowing an attacker to manipulate the request parameters to specify arbitrary recipient addresses.
From a technical perspective, this flaw enables the extension to function as an open mail relay when exploited in conjunction with other misconfigurations or simply through direct manipulation of the email sending mechanism if authentication is not strictly enforced on the specific endpoint. An adversary can craft malicious HTTP requests that include modified contact_id parameters pointing to non-existent records or inject raw email addresses into fields intended for identifiers, depending on how the backend logic processes these inputs. If the application uses this identifier solely to fetch a recipient without verifying ownership or existence of the record in question, it effectively allows any authenticated user, and potentially unauthenticated users if access controls are weak, to send emails to arbitrary destinations. This behavior violates the principle of least privilege and fails to enforce proper output encoding and validation for email headers, which is central to preventing abuse of mail services.
The operational impact of this vulnerability extends beyond simple spam generation. By leveraging an open relay or a compromised email sending function, attackers can facilitate phishing campaigns by spoofing legitimate domain addresses if the application allows control over sender fields as well. Furthermore, it enables credential stuffing attacks where automated scripts send password reset links to attacker-controlled accounts associated with victim identities, potentially leading to account takeover if other security controls are absent. The ability to send emails arbitrarily also aids in distributed denial-of-service (DDoS) attacks against mail servers or reputation-based blacklisting of the hosting IP address and domain, causing significant collateral damage to the organization's email deliverability and brand integrity. In enterprise environments, this could be used for initial access vectors where phishing emails are sent from a trusted internal source to bypass security filters that whitelist known domains.
Mitigation strategies must focus on strict input validation and server-side resolution of sensitive data. The immediate fix involves updating J-BusinessDirectory to version 6.2.3 or later, which addresses this logic flaw by ensuring recipient addresses are retrieved exclusively from verified database records corresponding to the provided identifiers. For organizations unable to patch immediately, implementing a web application firewall (WAF) rule set that detects and blocks requests with anomalous patterns in contact_id parameters can provide temporary relief. Additionally, enforcing strict email sending policies at the mail server level, such as requiring SPF, DKIM, and DMARC authentication for all outgoing messages from the domain, helps mitigate reputation damage even if abuse occurs. Developers should also implement rate limiting on email endpoints to prevent bulk mailing attacks and ensure that any user-supplied data used in security-critical operations is validated against a whitelist of expected formats or resolved through secure server-side lookups rather than direct usage. This aligns with MITRE ATT&CK techniques related to Initial Access via Spearphishing Attachment (T1566) if the emails are used for phishing, and Command and Control protocols that rely on email channels for covert communication.