Description

Froxlor before 2.3.13 returns the ssl_key_file column — which stores the raw PEM TLS private-key content — verbatim in the JSON responses of the Certificates.get and Certificates.listing API commands, because the results of the underlying domain_ssl_settings queries are passed through ApiCommand::response() without any field stripping or allowlist. A low-privileged authenticated customer API caller can retrieve the private keys of their own domains' certificates, including Let's Encrypt keys that Froxlor generates server-side and stores root-only (0600) and to which the customer otherwise has no filesystem access; reseller and customers_see_all admin accounts can dump the private keys of other principals through the same sink. Disclosed keys enable domain impersonation, passive decryption of captured TLS traffic, and active machine-in-the-middle attacks.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.1",
  "pubDate": "2026-09-26T14:16:56.153Z",
  "pubdate": "2026-09-26T14:16:56.153Z",
  "executiveSummary": "Froxlor versions prior to 2.3.13 contain an improper information disclosure vulnerability within its API interface. The vulnerability arises from the insecure handling of database results in the Certificates.get and Certificates.listing API commands.\nSpecifically, the application returns the 'ssl_key_file' column, which contains raw PEM-encoded TLS private keys, directly in JSON API responses without field sanitization or an allowlist mechanism.\nThis flaw allows authenticated users to access sensitive cryptographic material that would otherwise be restricted by filesystem-level permissions (0600).\nThe risk is critical, as compromised private keys enable domain impersonation, passive TLS traffic decryption, and active man-in-the-middle (MitM) attacks.\nWhile the vulnerability requires authentication, the impact is escalated for reseller and privileged customer accounts, which may be leveraged to exfiltrate the private keys of other principals or administrative accounts, leading to a complete compromise of the confidentiality and integrity of encrypted communications for the affected domains.",
  "technicalDetails": "The vulnerability originates in the application's API architecture, specifically within the interaction between the 'Certificates' API controller and the underlying database abstraction layer. When the 'Certificates.get' or 'Certificates.listing' commands are executed, the system performs a query on the 'domain_ssl_settings' table to retrieve certificate information.\nThe root cause is identified as the failure of the 'ApiCommand::response()' function to implement a field-level allowlist or an object-stripping mechanism. Instead of filtering the data returned by the database query, the function performs a verbatim pass-through of the record set into the JSON output. Consequently, sensitive data columns, such as 'ssl_key_file', which store the raw private key material, are serialized and delivered to the authenticated requester.\nThe attack flow follows a predictable pattern: 1) The attacker authenticates to the Froxlor API with legitimate credentials. 2) The attacker calls either the 'Certificates.get' or 'Certificates.listing' endpoint. 3) The API backend executes the database query for domain SSL settings and receives the full record, including the raw private key PEM string. 4) The 'ApiCommand::response()' function, lacking a sanitization filter, encapsulates this raw key data into the JSON response payload. 5) The attacker receives the full private key in the JSON output, bypassing the server-side filesystem protections that restrict access to these files (typically 0600 mode).\nFor standard customers, this results in the disclosure of their own domain keys. However, for users with elevated privileges, such as resellers or accounts with 'customers_see_all' capabilities, the impact is broadened to include the private keys of any domains managed under their scope. Because Froxlor often manages Let's Encrypt certificates generated server-side, this vulnerability allows attackers to extract these high-value keys even if they possess no direct shell or filesystem access to the underlying server hosting the keys.\nPost-exploitation, the availability of the raw private keys allows an adversary to perform full impersonation of the victim domain, decrypt any intercepted traffic encrypted with these certificates, or mount persistent man-in-the-middle attacks that remain transparent to end users, as the attacker possesses the cryptographic credentials required to terminate TLS sessions legitimately."
}