CVE-2026-90936

Executive Summary

CVE-2026-90936 is an information disclosure vulnerability in Froxlor, an open-source server management and hosting control panel, affecting versions prior to 2.3.7. The flaw resides in customer_email.php, where sender alias lookups are not scoped to the requesting customer, allowing an authenticated low-privileged user to enumerate global sender alias identifiers and read the allowed sender values belonging to other customers. With a CVSS base score of 4.3 (Low severity), the impact is confidentiality-only and limited to cross-tenant metadata disclosure, but in multi-tenant hosting environments the leak of sender alias data can enable follow-on abuse such as email spoofing reconnaissance, phishing pretexting, and tenant mapping.

Technical Analysis

Froxlor is a widely deployed web hosting control panel that manages web space, mail accounts, DNS, and customer administration for hosting providers. Customers in Froxlor are isolated tenants: each customer owns mail domains, mail accounts, and sender alias configurations that should be invisible to other customers.

The vulnerability is an instance of CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor), specifically a horizontal authorization-scoping failure. According to the NVD description, the defect is that sender alias lookups in customer_email.php are not properly scoped to the current customer. Because the lookup path resolves an attacker-supplied senderid parameter without validating that the referenced sender alias belongs to the authenticated customer, the endpoint acts as an object reference that is not access-controlled — the classic IDOR (Insecure Direct Object Reference) pattern within the CWE-200 family.

Two distinct information leaks result:

1. Global sender alias ID enumeration. The attacker can determine which sender alias IDs exist across the whole installation, not merely within their own tenant. Sequential or otherwise predictable integer identifiers allow systematic enumeration.
2. Cross-tenant value disclosure. By supplying arbitrary senderid values in delete confirmation requests, the attacker receives the corresponding "allowed sender" values — the e-mail addresses or domains configured by other customers as permitted senders. These confirmation requests are described as the read vector; the delete confirmation workflow appears to render the referenced record's details back to the caller without an ownership check.

The attack surface is the web application's authenticated customer area. It is remotely reachable (AV:N) and requires only low privileges (PR:L) — a valid customer login, which is trivially obtained on any shared hosting platform that allows self-registration or is issued to every paying tenant. No user interaction is required (UI:N) and no special conditions apply (AC:L). The scope is unchanged (S:U): the vulnerable component (Froxlor) discloses data it holds, without pivoting into other security authorities. Confidentiality impact is Low (C:L) because the disclosed data is configuration metadata rather than credentials or message contents; integrity and availability are unaffected.

No public proof-of-concept, Nuclei template, or exploit code is known at the time of writing, so the precise request format (HTTP method, parameter encoding) is inferred from the description and class of vulnerability; no additional endpoint names, parameter names, or code symbols beyond customer_email.php and senderid should be assumed from this report.

Exploitation Scenarios

The following chain is inferred from the vulnerability class and the NVD description; no public exploit exists.

1. Reconnaissance and target identification. The attacker identifies a Froxlor instance below version 2.3.7 — for example, by fingerprinting the login page, the panel's static assets, or the presence of customer_email.php in the customer area. The attacker then obtains a legitimate low-privileged customer account, either through self-registration (if enabled), a trial account, or as an existing tenant of the hosting provider. Because PR:L is required, an anonymous attacker must cross this initial barrier first.

2. Triggering the flawed lookup. Within the authenticated customer session, the attacker navigates to the customer e-mail functionality backed by customer_email.php and begins exercising the sender-alias delete confirmation flow. Instead of supplying the senderid of a sender alias they own, the attacker supplies arbitrary senderid values.

3. Payload and enumeration. The payload is simply an out-of-range or foreign integer in the senderid parameter of a delete confirmation request. This is not injection-based code execution; it is an authorization bypass. Feasible values are enumerated — through sequential iteration, or by varying identifiers observed in the attacker's own account and extrapolating the global namespace — and the confirmation response for each value is inspected for a corresponding sender alias record.

4. Post-exploitation impact. For each enumerated ID, the response discloses the alias's allowed sender value — an e-mail address or domain belonging to another customer. Repeated iteration maps the installation's global alias ID space and harvests cross-tenant mail configuration. This yields a tenant inventory (which domains/addresses exist on the platform), enables targeted phishing (spoofed senders trusted by the platform's own configuration), and provides reconnaissance for further attacks against disclosed mail domains. There is no code execution, privilege escalation, or data modification — the flaw is read-only and confidentiality-limited, consistent with the Low severity and C:L/I:N/A:N subscores.

Impact Assessment

Business impact is concentrated in multi-tenant hosting providers, managed service providers, and shared-hosting environments where a Froxlor installation serves many mutually distrusting customers. The blast radius is the entire tenant base of the installation: every customer's sender alias configuration is potentially enumerable by any single authenticated customer.

• Confidentiality (C:L): Configuration metadata — sender alias IDs and allowed sender values — is exposed across tenant boundaries. This is a privacy and tenant-isolation breach, but not exposure of passwords, session tokens, or message content.
• Integrity (I:N) / Availability (A:N): The described exploit path is read-oriented; no modification or denial of service is described.
• Exploitability: AV:N/AC:L/PR:L/UI:N — trivially reachable and reliable once a low-privileged account exists, which is the only real friction. EPSS is 0.00229 (14th percentile), indicating low near-term exploitation likelihood in the wild, and CISA KEV does not list it.
• Secondary risk: Disclosed allowed-sender values improve the precision of phishing, BEC, and domain-spoofing campaigns and lower the cost of mapping a hosting provider's customer base. In regulated hosting contexts, cross-tenant data leakage may carry contractual or compliance (e.g., GDPR) implications for the provider.

Given the Low CVSS score, this is not a "drop everything" emergency for most organizations, but for hosting operators it is a tenant-isolation defect that should be remediated on a normal maintenance cadence — and it becomes more attractive when chained with other weaknesses.

Detection Guidance

Sigma Rule

title: Froxlor Sender Alias IDOR Enumeration Attempt (CVE-2026-90936)
id: 7a3c1e2b-4f5d-4c9a-9b6e-2d8f0a1c3e77
status: experimental
description: Detects repeated access to customer_email.php with varying senderid parameters, indicative of sender alias enumeration and cross-tenant disclosure in Froxlor before 2.3.7.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-90936
author: valtersit.com
date: 2026/01/01
tags:
  - attack.discovery
  - attack.t1087
  - cve.2026.90936
logsource:
  category: webserver
detection:
  selection:
    cs-uri-stem|endswith: '/customer_email.php'
    cs-uri-query|contains: 'senderid='
  timeframe: 5m
  condition: selection | count() by c-ip > 20
fields:
  - c-ip
  - cs-uri-query
  - sc-status
falsepositives:
  - Legitimate bulk management of sender aliases by an authorized customer
  - Automated provisioning scripts operating on behalf of a single tenant
level: medium

YARA Rule

rule CVE_2026_90936_Froxlor_Customer_Email
{
    meta:
        description = "Detects Froxlor customer_email.php source containing un-scoped sender alias lookup logic (pre-2.3.7)"
        author = "valtersit.com"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-90936"
        cve = "CVE-2026-90936"
        date = "2026-01-01"

    strings:
        $file = "customer_email.php" ascii nocase
        $param = "senderid" ascii nocase
        $ctx1 = "sender_alias" ascii nocase
        $ctx2 = "allowed_sender" ascii nocase

    condition:
        $file and $param and any of ($ctx*)
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-90936 Froxlor sender alias IDOR enumeration attempt"; flow:established,to_server; http.uri; content:"customer_email.php"; http.uri; content:"senderid="; pcre:"/senderid=\d+/Ui"; threshold:type both, track by_src, count 20, seconds 300; classtype:attempted-recon; reference:cve,2026-90936; reference:url,nvd.nist.gov/vuln/detail/CVE-2026-90936; metadata:created_at 2026_01_01; sid:9093601; rev:1;)

Elastic Detection

sequence by source.ip with maxspan=5m
  [http where url.path endsWith "customer_email.php" and url.query contains "senderid="] with runs=15

Splunk SPL Query

index=web sourcetype=access_combined
| where like(uri, "%customer_email.php%") AND match(uri, "senderid=\d+")
| rex field=uri "senderid=(?<senderid>\d+)"
| stats count AS attempts, dc(senderid) AS distinct_ids, values(senderid) AS ids by src_ip, status
| where attempts > 20 OR distinct_ids > 10
| sort - attempts

Wazuh OSSEC Rule

<group name="web,froxlor,cve-2026-90936,">
  <rule id="909361" level="10">
    <if_sid>31100</if_sid>
    <id>^200$|^404$</id>
    <url>customer_email.php</url>
    <match>senderid=</match>
    <description>Possible Froxlor sender alias IDOR enumeration (CVE-2026-90936)</description>
    <mitre>
      <id>T1087</id>
    </mitre>
    <group>cve_2026_90936,sender_alias_idor,</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 2/4 (CLAIMED — a single source, OSV, claims a fix; not independently confirmed). Operators should verify the fix against the vendor's own changelog and repository before relying on it.

1. Immediate mitigations (if upgrade is not yet possible):

   • Restrict the Froxlor customer area to trusted networks where feasible, and enforce the principle of least privilege on who may hold a customer account.
   • Disable open/self-service customer registration so external parties cannot obtain the required low-privileged account.
   • Audit access logs for repeated customer_email.php requests carrying varying senderid values (see Detection Guidance) and treat hits as tenant-isolation probing.
   • Where practical, proxy or WAF-inspect the customer area to throttle anomalous senderid iteration.

2. Patch / upgrade steps:

   • Upgrade Froxlor to 2.3.7 or later, which the OSV-sourced claim indicates scopes sender alias lookups to the current customer.
   • Validate the deployed version string after upgrade and confirm that delete-confirmation behavior no longer returns records the authenticated customer does not own.
   • Because patch confidence is only 2/4, test the fix on a staging instance with two separate customer accounts: log in as customer A and attempt to read customer B's alias via senderid. Expect the request to be rejected or return no foreign data.

3. Long-term hardening:

   • Enforce server-side object-level authorization: every lookup by an externally supplied identifier must include an ownership predicate bound to the authenticated session, never trusting client-supplied IDs.
   • Adopt indirect reference maps or ownership-filtered queries for all tenant-scoped resources.
   • Add automated regression tests for horizontal privilege boundaries (IDOR) across mail, DNS, and e-mail endpoints.
   • Monitor upstream Froxlor advisories and track whether the 2.3.7 fix is corroborated by the vendor.

References

• NVD — CVE-2026-90936: https://nvd.nist.gov/vuln/detail/CVE-2026-90936
• OSV — advisory entry for Froxlor (patch source, unconfirmed): https://osv.dev/
• Froxlor project repository and release notes (verify 2.3.7 fix): https://github.com/Froxlor/Froxlor
• MITRE ATT&CK — T1190, Exploit Public-Facing Application: https://attack.mitre.org/techniques/T1190/
• MITRE CWE-200 — Exposure of Sensitive Information to an Unauthorized Actor: https://cwe.mitre.org/data/definitions/200.html
• CISA KEV Catalog (CVE-2026-90936 not listed as of writing): https://www.cisa.gov/known-exploited-vulnerabilities-catalog

No public PoC, exploit code, Nuclei template, or exploit-in-the-wild evidence is currently known for this CVE, and it is not present in the CISA KEV catalog. No threat actor campaigns have been attributed.