CVE-2026-100708
Executive Summary
CVE-2026-100708 is an exposure-of-sensitive-information flaw (CWE-200) in Froxlor, a server management and hosting control panel, affecting versions prior to 2.3.13. The Certificates.get and Certificates.listing API commands return the ssl_key_file column — which stores the raw PEM TLS private-key content — verbatim in JSON responses because the underlying domain_ssl_settings query results are passed through ApiCommand::response() without field stripping or an allowlist. A low-privileged authenticated API customer can retrieve their own domains' private keys (including server-generated, root-only 0600 Let's Encrypt keys they cannot otherwise read), while reseller and customers_see_all admin accounts can dump other principals' keys. Disclosure of TLS private keys enables domain impersonation, passive decryption of captured TLS traffic, and active machine-in-the-middle attacks.
This record — and 170,000+ others — are available via the ValtersIT API. One endpoint replaces five: NVD + GitHub CVE + CISA KEV + EPSS + Nuclei + Exploit-DB, unified.
No signup required
Technical Analysis
Froxlor exposes an API surface through which authenticated principals (customers, resellers, admins) issue commands and receive JSON responses. Two commands are affected: Certificates.get and Certificates.listing. Both retrieve records derived from the domain_ssl_settings table. One of the columns in that table is ssl_key_file, and per the NVD description this column stores the raw PEM TLS private-key content (not merely a filesystem path).
The core defect is the absence of output filtering. The results of the domain_ssl_settings queries are handed directly to ApiCommand::response() with no field stripping and no field allowlist. Consequently, whatever columns exist in the query result — including the private-key material — are serialized into the JSON response returned to the caller. This is a classic sensitive-data-exposure pattern: the authorization check on the command may be correct (a customer may legitimately list their own certificates), but the response serialization layer performs no data minimization, so a field never intended for API exposure leaks by default.
The trust boundary that is violated is significant. Froxlor generates certain certificates server-side — specifically Let's Encrypt certificates — and persists the associated private keys with root-only ownership and 0600 permissions. The filesystem permission model is therefore working as intended; the customer should not be able to read the key file directly. However, the API command path bypasses that filesystem control entirely, because the key material is read by Froxlor's privileged process and then echoed back to the API caller. The 0600/root-only protection is rendered irrelevant for any principal permitted to invoke the affected commands.
The access-control dimension compounds the impact:
- Low-privileged authenticated customer: can retrieve the private keys of certificates belonging to their own domains. This is a privilege escalation relative to the filesystem model (they gain access to root-only material) but is scoped to their own resources.
- Reseller and
customers_see_alladmin accounts: per the description, these broader-scoped principals can dump the private keys of other principals through the same unfiltered sink. This converts a self-scoped leak into a cross-tenant disclosure.
CVSS 3.1 scores this AV:N (the API is reachable over the network), AC:L (no special conditions), PR:L (requires an authenticated low-privileged account), UI:N (no user interaction), S:U (scope unchanged), C:H (private key material is high-value confidentiality impact), I:L (limited integrity impact from impersonation potential), A:N, yielding a base score of 7.1.
Note: from the NVD description alone, the exact command-dispatch permission logic, parameter schemas, and JSON field names beyond ssl_key_file are not specified. No public PoC, Nuclei template, or exploit code exists in the provided data; the attack chain below is inferred from the vulnerability class and the described data flow.
Exploitation Scenarios
No public PoC is available; the following attack chain is inferred from the vulnerability class (unfiltered sensitive-field disclosure through an authenticated API) and the specifics stated in the NVD description.
Reconnaissance / target identification. An attacker identifies an internet-facing Froxlor instance running a version prior to 2.3.13. Froxlor management panels are frequently exposed on standard web ports. The attacker either holds or obtains a valid low-privileged customer API credential, or — for higher-impact variants — a reseller or
customers_see_alladmin credential.Triggering the flaw class. The attacker authenticates to the Froxlor API and invokes the
Certificates.getorCertificates.listingcommand. Because the backingdomain_ssl_settingsquery result is passed toApiCommand::response()without an allowlist, the response body includes thessl_key_filefield containing the raw PEM private key. Thegetcommand exposes keys for a targeted certificate; thelistingcommand exposes them in bulk across the results the caller is permitted to see. No exploitation primitive is needed beyond a well-formed authenticated API request — the vulnerability is triggered by normal use of an affected endpoint.Payload / execution method (vulnerability-class level). There is no injected payload; the "exploit" is the legitimate API invocation itself. The attacker captures the JSON response and extracts the PEM block from the
ssl_key_filefield. For a low-privileged customer, the extracted keys cover their own domains (including server-generated Let's Encrypt keys held root-only on disk). For reseller /customers_see_allprincipals, extraction covers other tenants' certificates.Post-exploitation impact. With a recovered TLS private key the attacker can:
- Impersonate the domain by presenting a valid certificate for a server they control.
- Passively decrypt captured TLS traffic for that certificate's key exchange (for cipher suites/versions where key compromise permits decryption — e.g., RSA key transport).
- Conduct active machine-in-the-middle attacks by terminating TLS with the genuine key and proxying to the real backend without certificate-validation warnings. Because the keys are long-lived until certificate rotation, the exposure persists beyond the initial request.
Impact Assessment
The blast radius depends on the privilege level of the compromised credential:
- Low-privileged customer: confidentiality impact is high for that customer's own domains. Root-only Let's Encrypt private keys become readable through the API, defeating the filesystem permission model. Business impact includes loss of TLS trust for the customer's sites, potential impersonation, and decryption of that customer's captured traffic.
- Reseller /
customers_see_alladmin: the same sink exposes other principals' private keys, making this a cross-tenant confidentiality breach. A single compromised reseller credential can yield private keys for a large set of hosted domains.
CVSS subscores: C:H reflects disclosure of cryptographic key material, the loss of which undermines the confidentiality guarantees of the affected TLS endpoints. I:L reflects the limited, but real, integrity consequence of impersonation and MITM. A:N indicates no direct availability impact. S:U indicates the compromise does not cross a defined security scope beyond Froxlor's own authorization model (the API is the intended access path, just with insufficient output filtering). The EPSS score is not yet available from FIRST.org and no EPSS value is asserted here. CVE-2026-100708 is not listed in CISA KEV.
Multi-tenancy environments are the most exposed: a shared Froxlor deployment hosting many customer domains concentrates many private keys behind a few reseller/admin accounts. Because the vulnerable queries are core to the certificate API, any deployment exposing the API to authenticated principals is in scope.
Detection Guidance
Detection focuses on identifying anomalous or bulk retrieval of certificate records and inspection of API response bodies for PEM private-key material, since the flaw produces no exploit signature — it manifests as legitimate-looking API traffic.
Sigma Rule
title: Froxlor Certificate API Private Key Disclosure Attempt
id: 8f3c1a20-1007-4d8e-9c11-2026100708a1
status: experimental
description: Detects access to Froxlor Certificates API commands associated with CVE-2026-100708, where ssl_key_file private-key content may be returned.
references:
- https://nvd.nist.gov/vuln/detail/CVE-2026-100708
author: valtersit.com
date: 2026/01/01
logsource:
category: webserver
detection:
selection_cmd:
cs-uri-query|contains:
- 'Certificates.get'
- 'Certificates.listing'
selection_api:
cs-uri-stem|contains: '/api'
condition: selection_api and selection_cmd
fields:
- c-ip
- cs-uri-stem
- cs-uri-query
- cs-username
falsepositives:
- Legitimate administrative certificate management activity
level: medium
tags:
- attack.t1552
- cve.2026.100708
YARA Rule
rule CVE_2026_100708_Froxlor_PrivateKey_In_API_Response
{
meta:
author = "valtersit.com"
description = "Detects TLS private key PEM material alongside Froxlor certificate API response markers indicative of CVE-2026-100708"
reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-100708"
date = "2026-01-01"
strings:
$pem_begin = "-----BEGIN PRIVATE KEY-----" ascii
$pem_rsa = "-----BEGIN RSA PRIVATE KEY-----" ascii
$pem_ec = "-----BEGIN EC PRIVATE KEY-----" ascii
$pem_end = "-----END PRIVATE KEY-----" ascii
$field = "ssl_key_file" ascii
$cmd_get = "Certificates.get" ascii
$cmd_lst = "Certificates.listing" ascii
condition:
$field and ($pem_begin or $pem_rsa or $pem_ec) and ($pem_end or any of ($cmd_*))
}
Suricata IDS Rule
alert http any any -> any any (msg:"CVE-2026-100708 Froxlor Certificate API Private Key Disclosure"; flow:established,to_server; http.method; content:"GET"; http.uri; content:"Certificates.get"; http.uri; content:"Certificates.listing"; classtype:attempted-recon; reference:cve,2026-100708; reference:url,nvd.nist.gov/vuln/detail/CVE-2026-100708; sid:2026100708; rev:1;)
alert http any any -> any any (msg:"CVE-2026-100708 Froxlor API Response Contains PEM Private Key"; flow:established,to_client; http.response_body; content:"BEGIN PRIVATE KEY"; http.response_body; content:"ssl_key_file"; classtype:policy-violation; reference:cve,2026-100708; sid:2026100709; rev:1;)
Elastic Detection
sequence by user.name, source.ip with maxspan=5m
[ network where http.request.method == "GET" and
(http.request.uri : "*Certificates.get*" or http.request.uri : "*Certificates.listing*") ]
[ network where http.response.body : *BEGIN*PRIVATE KEY* and
http.response.body : *ssl_key_file* ]
Splunk SPL Query
index=web sourcetype=froxlor_access OR sourcetype=nginx OR sourcetype=apache
(http_uri="*Certificates.get*" OR http_uri="*Certificates.listing*")
| stats count min(_time) as first_seen max(_time) as last_seen values(http_uri) as uris by src_ip, user
| where count > 0
| eval first_seen=strftime(first_seen,"%Y-%m-%d %H:%M:%S"), last_seen=strftime(last_seen,"%Y-%m-%d %H:%M:%S")
| sort - count
Wazuh OSSEC Rule
<group name="froxlor,web,cve-2026-100708,">
<rule id="202610070" level="10">
<decoded_as>web-accesslog</decoded_as>
<url>Certificates\.(get|listing)</url>
<description>CVE-2026-100708: Froxlor Certificates API command invoked - potential SSL private key disclosure</description>
<mitre>
<id>T1552</id>
<id>T1190</id>
</mitre>
<group>cve_2026_100708,</group>
</rule>
<rule id="202610071" level="12">
<decoded_as>web-accesslog</decoded_as>
<match>BEGIN PRIVATE KEY</match>
<description>CVE-2026-100708: PEM private key material observed in Froxlor API response body</description>
<mitre>
<id>T1552</id>
</mitre>
<group>cve_2026_100708,</group>
</rule>
</group>
Mitigation & Patch Guidance
Patch confidence: 0/4 (UNPATCHED — no patch evidence from any tracked source). The NVD description references Froxlor 2.3.13 as the version in which the issue is addressed, but no vendor advisory, commit, or patch reference is confirmed in the tracked data. Treat as UNPATCHED pending independent verification.
Immediate mitigations (no patch confirmed):
- Restrict API access to the certificates commands at the network/perimeter layer where operationally feasible; limit exposure of the Froxlor API to trusted networks.
- Audit and minimize the population of accounts holding reseller or
customers_see_allprivileges, since these principals can dump other tenants' keys through the same sink. - Review recent
Certificates.get/Certificates.listinginvocation logs for unusual or bulk retrieval by low-privileged or unexpected principals. - If key exposure is suspected, initiate certificate rotation (reissue and revoke) for affected domains, since disclosed private keys permit impersonation and decryption until rotated.
Patch / upgrade steps:
- Apply Froxlor 2.3.13 or later once the vendor release is independently verified; confirm that the affected API commands no longer return the
ssl_key_filefield (field allowlist / stripping at theApiCommand::response()layer). - Validate the fix by issuing
Certificates.get/Certificates.listingcalls and confirming the JSON response excludes private-key material.
- Apply Froxlor 2.3.13 or later once the vendor release is independently verified; confirm that the affected API commands no longer return the
Long-term hardening:
- Enforce data-minimization / allowlist-based serialization for all API command responses so sensitive columns are never emitted by default.
- Store TLS private keys outside query-accessible tables or behind an access-controlled secret store whenever feasible, rather than as a directly selectable column.
- Apply least privilege to API accounts and enforce tenant-scoped authorization on certificate queries.
- Monitor for post-exposure abuse: unexpected certificate reissuance, revoked-then-reused keys, and anomalous TLS termination behavior on hosted domains.
References
- NVD — CVE-2026-100708: https://nvd.nist.gov/vuln/detail/CVE-2026-100708
- CWE-200 — Exposure of Sensitive Information to an Unauthorized Actor: https://cwe.mitre.org/data/definitions/200.html
- CVSS 3.1 Specification (FIRST.org): https://www.first.org/cvss/v3.1/specification-document
- Froxlor project documentation (API and certificate management): https://froxlor.org/
- CISA Known Exploited Vulnerabilities Catalog (not listed): https://www.cisa.gov/known-exploited-vulnerabilities-catalog
Note: The provided data contains no confirmed vendor advisory, public PoC, exploit code, or Nuclei template, and no threat-actor campaign attribution for CVE-2026-100708. Where specific implementation details were not present in the NVD description, this report describes the vulnerability at the class level rather than fabricating specifics.
What is this? Security researchers use these exact search queries on Shodan.io (a search engine for internet-connected devices) to find vulnerable systems globally. You can copy these dorks to see if your organization's IP space is exposed.