☠️
EXFILTRATING
DATA...
01010111 10110010 00101001 11000110 01101100 10011011 00010001 11100101 01000010 10101111
[ <-- BACK_TO_SEARCH ]
[ VENDOR STATS ]
CVSS: 7.1 CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N 🐛 CWE-200
👁️
Common Weakness Enumeration - Identifies the specific category of software weakness or flaw.

CVE-2026-100708

CVE-2026-100708 Information Disclosure in Froxlor
📅 PUBLISHED: 2026-09-26 00:00 UTC 🔄 UPDATED: 2026-09-28 00:00 UTC
[ PATCH UNDER REVIEW ↓ ] Remains UNDER REVIEW until an independent source confirms the fix
[ DEFENSE PATCH ↓ ]
💣 PoC: None
👁️
Proof of Concept - Indicates if functional exploit code is publicly available, drastically increasing the risk of immediate attacks.
🎯 EPSS: 0.13%
👁️
0.13% probability
3.2× above the median CVE
Tier: ELEVATED
30-day exploitation window · FIRST.org · updated daily
🥷 MITRE: T1552
👁️
MITRE ATT&CK Tactic - Describes the strategy hackers use to execute this attack.
VULNERABLE: version not auto-detected — verify your deployed version locally
CVSS VECTOR BREAKDOWN 7.1
AV: N Attack Vector Network
AC: L Attack Complexity Low
PR: L Privileges Required Low
UI: N User Interaction None
S: U Scope Unchanged
C: H Confidentiality High
I: L Integrity Low
A: N Availability None
7.1
THREAT LEVEL
■ tracking this CVE ✓ independent patch confirmation ⧗ same-origin mirror (GHSA) ⚠ active exploitation verification policy →

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.

⚡ AUTOMATE YOUR CVE INTELLIGENCE

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.

›Patch confidence — UNVERIFIED to CONFIRMED, cross-referenced NVD + RHSA + Debian
›Exploit & PoC — poc_status, poc_url, has_exploit. Not in NVD.
›Shodan dorks — ready-made queries to find exposed vulnerable systems
›Detection rules — YARA · Wazuh · Elastic (all plans) · Sigma (Pro)
›pending_fields — know exactly which of 7 fields NVD hasn't processed yet
›Free backfill — data incomplete when you paid? Re-check within 30 days = 0 credits
PAYG €0.08/lookup Standard €19/mo (was €29) · 5k credits Pro €65/mo (was €99) · 20k credits FOUNDING PRICE · LOCKED FOR LIFE · ENDS 31 DEC 2026
[ FROM €19/MO ]
Free sandbox key available
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_all admin 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.

  1. 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_all admin credential.

  2. Triggering the flaw class. The attacker authenticates to the Froxlor API and invokes the Certificates.get or Certificates.listing command. Because the backing domain_ssl_settings query result is passed to ApiCommand::response() without an allowlist, the response body includes the ssl_key_file field containing the raw PEM private key. The get command exposes keys for a targeted certificate; the listing command 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.

  3. 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_file field. 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_all principals, extraction covers other tenants' certificates.

  4. 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_all admin: 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.

  1. 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_all privileges, since these principals can dump other tenants' keys through the same sink.
    • Review recent Certificates.get / Certificates.listing invocation 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.
  2. 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_file field (field allowlist / stripping at the ApiCommand::response() layer).
    • Validate the fix by issuing Certificates.get / Certificates.listing calls and confirming the JSON response excludes private-key material.
  3. 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

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.

👁️ SHODAN DORKS (THREAT HUNTING)

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.

product:"Froxlor"
title:"Froxlor"
◈ SOURCE Analysis & enrichment: valtersit.com/cve/CVE-2026-100708/ · CVE data: NVD/MITRE (public domain) · © 2026 ValtersIT Hub
>_ SYSTEM_CORE: INTEL_ACTIVE
90% TEAM-CURATED // 10% AUTOMATED INGESTION.
ALL PATCH REFERENCES AND VERSION DATA SOURCED FROM NVD + OSV OFFICIAL REGISTRIES.