CVE-2026-100710 in Froxlor
Summary
by MITRE • 09/26/2026
Froxlor through 2.3.10 does not filter sensitive columns from API responses: Domains::get(), Domains::listing(), SubDomains::get(), and the admin branch of SubDomains::listing() perform a wildcard SELECT over the panel_domains table and return the row unmodified, including the panel_domains.dkim_privkey field. An authenticated, non-superadmin admin holding the delegated customers_see_all flag can therefore read the DKIM private signing keys of domains belonging to other tenants via Domains.get, Domains.listing, SubDomains.get, or SubDomains.listing, with a single listing call disclosing the key of every visible domain. The disclosed keys allow an attacker to sign email that passes DKIM verification and DMARC alignment for the affected domains. This is a follow-on to an incomplete fix that stripped password and data_2fa but not dkim_privkey. The issue is fixed in 2.3.12.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/26/2026
The vulnerability identified in Froxlor versions up to 2.3.10 represents a critical information disclosure flaw within the application's API layer, specifically affecting how sensitive cryptographic material is handled during domain management operations. The core technical deficiency lies in the database query execution logic for specific endpoints including Domains::get(), Domains::listing(), SubDomains::get(), and the administrative branch of SubDomains::listing(). These functions execute a wildcard SELECT statement against the panel_domains table, which retrieves all columns associated with each record without applying any column-level filtering or sanitization. Consequently, the API responses include every field stored in the database row for the requested domains, including highly sensitive data such as DKIM private signing keys. This design oversight means that rather than returning only necessary metadata like domain names and IP addresses, the system exposes raw cryptographic secrets to any caller with sufficient permissions to access those specific records.
The operational impact of this flaw is severe due to its potential for widespread credential compromise across multi-tenant environments. An authenticated user who holds the delegated customers_see_all flag can exploit these endpoints to read DKIM private keys belonging to domains owned by other tenants within the same Froxlor instance. This capability allows an attacker with relatively low-level privileges, such as a reseller or sub-administrator, to escalate their impact significantly. By making a single listing call, the attacker can harvest the private signing keys for every domain visible under their delegated scope. The exposure of these keys undermines the integrity and authenticity guarantees provided by DomainKeys Identified Mail (DKIM) protocols. Since DKIM relies on asymmetric cryptography where the public key is published in DNS records while the private key remains secret to sign messages, possession of the private key allows an adversary to forge email headers that appear legitimate from the victim's domain.
This vulnerability directly facilitates sophisticated phishing and business email compromise attacks by enabling attackers to bypass DMARC alignment checks. When an attacker signs fraudulent emails with a stolen DKIM private key, those emails will pass both DKIM verification and SPF/DMARC authentication mechanisms configured for the affected domains. This significantly increases the likelihood that malicious messages will reach recipients' inboxes rather than being flagged as spam or rejected by mail servers. The issue is particularly concerning because it represents a follow-on to an incomplete remediation effort; while previous updates attempted to strip sensitive fields like passwords and two-factor authentication data from API responses, they failed to include dkim_privkey in the exclusion list. This oversight suggests that security reviews of API response structures were not comprehensive enough to account for all types of high-value secrets stored within domain configuration tables.
From a classification perspective, this vulnerability aligns with CWE-209, which describes the generation of an error message that includes sensitive information, and more accurately CWE-798, which covers the use of hard-coded or exposed credentials in source code or configurations, though here it manifests as improper access control leading to exposure. In terms of the MITRE ATT&CK framework, this behavior corresponds to T1005, Data from Local System, specifically through API endpoints that allow unauthorized retrieval of sensitive data. The attack vector is remote and requires authentication, placing it within the Initial Access or Persistence phases depending on how the stolen keys are utilized for further compromise.
To mitigate this risk, organizations running Froxlor versions prior to 2.3.12 must upgrade immediately to version 2.3.12 where the issue has been resolved by implementing proper column filtering in the affected API methods. Until an upgrade is possible, administrators should restrict access to the API endpoints mentioned and ensure that only super-administrators with full trust can perform domain listing operations if such granular permission controls are available through role-based access control configurations. Additionally, it is critical to rotate all DKIM keys for domains accessible by users holding the customers_see_all flag, as any key exposed prior to patching may have already been harvested by attackers. Regular audits of API response payloads should be conducted during development and security testing phases to ensure that sensitive fields such as private keys, passwords, and tokens are never included in public-facing or semi-public responses unless explicitly required for specific administrative functions with elevated privileges.