CVE-2026-90767

Executive Summary

CVE-2026-90767 is an input-validation flaw in Froxlor (a widely deployed open-source web hosting control panel) affecting all versions before 2.3.12. The SshKeys::add() endpoint accepts multi-line SSH public keys from authenticated customers without properly neutralizing embedded newline characters, allowing injection of arbitrary lines into a user's authorized_keys file. Because the flaw permits insertion of SSH key entries containing option directives — most notably command=, no-pty, and related constraints — a malicious customer can plant a persistent access mechanism that survives routine key deletion and SSH access revocation performed by the administrator.

The CVSS v3.1 base score is 6.5 (Medium), reflecting a network-reachable, low-privilege, no-user-interaction attack with a High Integrity impact and no Confidentiality or Availability impact. The real-world severity is likely understated by the score: the persistence mechanic (surviving revocation) elevates the operational risk for multi-tenant hosting providers, where a single abusive tenant can achieve out-of-band access against backend workflows or the Froxlor host itself depending on deployment topology.

Technical Analysis

Vulnerability class. CWE-93 — Improper Neutralization of CRLF Sequences. The core defect is that the SshKeys::add() handler performs insufficient validation on user-supplied SSH public key material. SSH public keys are single-line records by specification ([options] keytype base64-comment). Froxlor's pre-2.3.12 logic treated the submitted value as opaque text and wrote it into the per-user authorized_keys file without stripping or rejecting embedded carriage-return/line-feed (\r/\n) sequences. The consequence is line injection into a security-critical file format that is itself line-oriented.

Attack surface. The affected component is the customer-facing SSH key management feature of the Froxlor control panel. Access requires an authenticated, low-privilege account (the CVSS PR:L reflects this — a standard hosting customer). No interaction from any other user (e.g., an administrator) is required (UI:N), and the endpoint is reachable over the network (AV:N). The attack violates the integrity of the authentication material used by sshd and does not, by itself, expose data or cause denial of service (C:N, A:N).

Mechanism. When a public key is appended, only the first line ("key line 1") is naturally interpreted as the customer's real key. Any additional injected lines are appended verbatim to the same file. sshd reads authorized_keys sequentially and evaluates each non-comment line as an independent authorization record. An attacker therefore needs only to append a second line that constitutes a complete, valid key entry with attacker-controlled options. This is the injection primitive that makes the flaw more than a nuisance: line two is not tied to the lifecycle of line one.

The NVD description explicitly identifies "option directives" as the enabling capability. Standard OpenSSH authorized_keys option syntax permits directives that bind a key to a forced command (command=), restrict source addresses (from=), disable terminal allocation (no-pty), disable forwarding, and so on. An attacker who controls an option directive can customize how their injected key is consumed by the SSH server. Because these directives are attributes of the injected line, not of the customer's legitimate key, they are invisible to the user interface's normal key-management view — a key shown as deleted in the panel may still have its injected companion line present on disk.

Scope limitation. The data provided does not include the patch diff, CVE CNA title, affected OSV packages, or a vendor advisory, so the exact sanitization logic added in 2.3.12 (e.g., whether the fix rejects any \n, matches a strict key grammar, or reformats output) is not confirmed. What is confirmed by the NVD description is the outcome: "before 2.3.12" is vulnerable, and the fix addresses validation of multi-line keys.

Root cause summary. A security-critical, line-delimited configuration file (authorized_keys) was written from a user-supplied field whose grammar was never enforced. The absence of a strict single-line key grammar check converts a convenience feature into a persistence vector.

Exploitation Scenarios

Preconditions. The attacker must hold a valid Froxlor customer account with permissions to manage SSH keys (a normal, low-privilege role on a multi-tenant panel). No authenticated administrative action is needed.

1) Reconnaissance / target identification. The attacker identifies hosts running Froxlor as their control panel (typical fingerprint: panel login page, HTTP responses referencing "Froxlor"). Version disclosure or banner enumeration is used to confirm a version below 2.3.12. Because this CVE shipped with no public PoC, no public exploit, and no Nuclei template, reconnaissance is opportunistic rather than driven by a widely circulating exploit kit.

2) Triggering the specific flaw class. The attacker navigates to the SSH key management area of their customer panel and submits a public key through the add-key workflow. The submitted value is crafted to include an embedded newline followed by a second, fully-formed key line. The first line satisfies the panel's superficial expectation of a "key"; the second line carries the injected entry and its option directives. CRLF/LF injection into a line-oriented authorization file is the entire exploit primitive — no memory corruption, no authentication bypass, and no privilege escalation at the web layer is required.

3) Payload execution method (vulnerability-class level). The injected second line is written into the customer's authorized_keys. On the next SSH authentication attempt, sshd parses the injected line as an independent authorization entry and honors the attacker's chosen options (for example, a command= directive to constrain or redirect execution, or from= to pin source addresses). The attacker authenticates with the private key corresponding to the injected line. No specific Froxlor source-level function names, additional endpoints, or shell payloads are asserted here because the NVD description does not provide them — this is a text-injection / authorization-file-poisoning attack, and the impactful behavior is governed by OpenSSH option semantics rather than by Froxlor code.

4) Post-exploitation impact — persistence that survives revocation. The defining impact is durability. When an administrator removes the user's visible SSH key or revokes SSH access for that user, the removal logic operates on the key the panel believes exists (line one). The injected line two is a separate record on disk and is not covered by that deletion. The attacker's key remains valid; access continues. Achieving this with an option directive allows the attacker to narrow the key's usability (e.g., a forced command) in ways that make it harder to spot in casual review, since a "deleted" user is assumed to no longer have shell access at all. The CVSS I:H reflects this integrity compromise of the authorization store; C:N/A:N reflect the fact that the CVE itself is about access persistence rather than direct data theft or service disruption (the attacker may subsequently pivot, but that is outside this CVE's direct scope).

Operational note. No public PoC, exploit code, or Nuclei template exists for this CVE, and it is not in CISA KEV. The attack chain above is inferred from the documented vulnerability class (CRLF injection into a line-delimited authorization file) and the NVD description's explicit reference to option directives.

Impact Assessment

Business impact. For shared-hosting and managed-server providers operating Froxlor, this is a tenancy-isolation and accounting-integrity problem. A paying customer can covertly retain SSH access after being offboarded, suspended, or deprovisioned — defeating the administrative controls that providers rely on for account termination, incident response, and custody handover. The persistence mechanism directly undermines incident response: an analyst who removes a suspicious key and observes no further logins may incorrectly conclude the intrusion is contained while the injected companion entry remains active.

Affected systems. Any Froxlor deployment below 2.3.12 that permits customers to self-manage SSH public keys and whose SSH daemon reads a panel-written authorized_keys. The blast radius is proportionate to the number of tenant accounts on the host, since each account is an independent potential injector.

CVSS subscores (base 6.5, Medium).

• AV:N — reachable over the network via the panel.
• AC:L — no special conditions; the injected value is submitted as-is.
• PR:L — requires an authenticated low-privilege customer account.
• UI:N — no victim or administrator interaction required.
• S:U — impact stays within the authorization scope of the affected SSH environment; no scope change is claimed.
• C:N — no direct confidentiality impact from the flaw itself.
• I:H — the integrity of the authorization store (and the effectiveness of revocation) is fully compromised.
• A:N — no availability impact.

Threat posture. EPSS has not been scored by FIRST.org (no value is asserted here, and none should be fabricated). The vulnerability is not in CISA KEV and has no public exploit, so current in-the-wild exploitation is likely low-to-moderate and opportunistic. The medium CVSS score combined with the persistence property means defenders should treat remediation as higher priority than the score alone implies.

Detection Guidance

Detection for this CVE centers on two layers: (a) monitoring the Froxlor panel for submissions of multi-line key material, and (b) monitoring authorized_keys files and SSH authentication events for the resulting persistence.

Sigma Rule

title: Froxlor SSH Public Key Injection via Multi-Line Key Submission (CVE-2026-90767)
id: 7b1c9f4a-2d63-4e8a-9c11-froxlor90767
status: experimental
description: Detects access-log entries indicating submission of SSH key material containing encoded newline characters to the Froxlor SshKeys add endpoint, consistent with CVE-2026-90767 line injection.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-90767
author: valtersit.com
date: 2026-01-01
logsource:
  category: webserver
  product: apache
detection:
  selection_endpoint:
    cs-uri-stem|contains:
      - '/ssh'
      - 'sshkeys'
      - 'ssh_keys'
  selection_injection:
    cs-uri-query|contains:
      - '%0a'
      - '%0A'
      - '%0d%0a'
      - '%0D%0A'
      - '\\n'
  condition: selection_endpoint and selection_injection
falsepositives:
  - Legitimate bulk key import tools that URL-encode trailing newlines
level: high
tags:
  - attack.persistence
  - attack.t1098
  - cve.2026.90767

YARA Rule

rule CVE_2026_90767_Froxlor_AuthorizedKeys_Injection
{
    meta:
        description = "Detects injected multi-line SSH key entries with option directives in authorized_keys files, consistent with Froxlor CVE-2026-90767 line injection"
        author = "valtersit.com"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-90767"
        date = "2026-01-01"
        severity = "high"

    strings:
        $opt1 = "command="
        $opt2 = "no-pty"
        $opt3 = "no-port-forwarding"
        $opt4 = "from="
        $key1 = "ssh-rsa "
        $key2 = "ssh-ed25519 "
        $key3 = "ecdsa-sha2-nistp256 "

    condition:
        filesize < 512KB and
        (
            (any of ($key1, $key2, $key3) and any of ($opt1, $opt2, $opt3, $opt4))
        )
}

Note: the YARA rule intentionally targets the artifact this CVE produces (authorized_keys entries bearing option directives). False positives are possible on hosts where administrators legitimately use forced-command keys; scope the rule to Froxlor-managed authorized_keys paths where possible.

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-90767 Froxlor SSH Key Injection - encoded newline in key submission"; flow:established,to_server; http.method; content:"POST"; http.uri; content:"ssh"; nocase; http.request_body; content:"%0A"; nocase; http.request_body; content:"ssh-rsa"; nocase; classtype:attempted-admin; reference:cve,2026-90767; reference:url,nvd.nist.gov/vuln/detail/CVE-2026-90767; sid:9076701; rev:1;)

Elastic Detection

sequence by source.ip, user.name with maxspan=5m
  [ network where event.action == "network" and url.path : "*/ssh*" and http.request.method == "POST" ]
  [ file where event.action == "creation" and file.path : "*/.ssh/authorized_keys" ]

This EQL rule correlates a POST to an SSH-key management path with a follow-on authorized_keys creation/modification event on the same host within five minutes, surfacing the write that would carry the injected line.

Splunk SPL Query

index=web OR index=linux_logs
| eval is_sshmgmt = if(match(lower(uri_path), "ssh|sshkeys|ssh_keys"), 1, 0)
| eval has_newline = if(match(request_body, "%0[aA]|%0[dD]%0[aA]|\\\\n"), 1, 0)
| eval sshd_write = if(match(lower(source), "auth|ssh") OR match(message, "authorized_keys"), 1, 0)
| where (is_sshmgmt=1 AND has_newline=1) OR sshd_write=1
| stats count values(uri_path) values(request_body) by src_ip user host
| where count > 0
| sort - count

Wazuh OSSEC Rule

<group name="froxlor,cve-2026-90767,web,">
  <rule id="907671" level="12">
    <if_sid>31100</if_sid>
    <id>^0$</id>
    <match>ssh</match>
    <regex>%0a|%0A|%0d%0a|\\n</regex>
    <description>CVE-2026-90767: Possible Froxlor SSH public key injection (encoded newline) in key submission</description>
    <mitre>
      <id>T1098</id>
    </mitre>
    <group>attack_persistence,</group>
  </rule>

  <rule id="907672" level="10">
    <if_group>syscheck</if_group>
    <match>authorized_keys</match>
    <description>CVE-2026-90767: authorized_keys modified - verify for injected SSH key lines</description>
    <group>attack_persistence,</group>
  </rule>
</group>

The second rule relies on Wazuh FIM (syscheck) monitoring of .ssh/authorized_keys paths; enable it for all tenant home directories on Froxlor hosts.

Mitigation & Patch Guidance

Patch confidence: 0/4 — UNPATCHED in this intelligence feed. No patch evidence was surfaced from any tracked source, and no vendor advisory or affected-package list was provided. The NVD description states that Froxlor before 2.3.12 is affected, which implies the fix landed in 2.3.12; treat 2.3.12 as the target version but independently verify against the official Froxlor release notes before relying on it.

1) Immediate mitigations (while unpatched / pending validation).

• If the customer SSH-key self-service feature is not operationally required, disable the ability for customers to manage SSH keys in Froxlor until 2.3.12 is validated.
• Harden the SSH server: set AuthorizedKeysFile to a non-standard location that the panel does not write to, or restrict sshd to a curated keys file not generated from panel input.
• Audit all tenant authorized_keys files for embedded option directives (command=, from=, no-pty, no-*) and multi-line entries that do not correspond to a single panel-visible key.
• Enable file-integrity monitoring on every .ssh/authorized_keys across tenant home directories (see the Wazuh rule above).
• Enforce strict server-side key grammar if any custom validation layer is possible: reject any submitted public key containing \r, \n, or a second line.

2) Patch / upgrade steps.

• Upgrade Froxlor to 2.3.12 or later. Because this feed carries no patch artifact, obtain the release from the official Froxlor project and confirm the version string post-upgrade.
• After upgrading, re-scan and reconcile authorized_keys files: remove any line that was not present at the time of the upgrade and is not a key currently registered in the panel.
• Rotate any SSH keys that customers submitted while running a vulnerable version, since injected companion lines may persist independently of panel state.

3) Long-term hardening.

• Adopt allow-list validation for any user-supplied value that is written to a line-delimited config file (keys, cron entries, config fragments). Fail closed on newlines and control characters.
• Separate the keys that sshd trusts from the keys the panel stores; generate sshd's view from a normalized, panel-validated source of truth.
• Treat account termination/SSH revocation as an auditable workflow that includes file-level verification, not just UI-level key deletion.
• Add regression tests asserting that multi-line input is rejected at every endpoint that writes authorization material.

References

1. NVD — CVE-2026-90767: https://nvd.nist.gov/vuln/detail/CVE-2026-90767
2. MITRE CWE-93 — Improper Neutralization of CRLF Sequences ('CRLF Injection'): https://cwe.mitre.org/data/definitions/93.html
3. MITRE ATT&CK T1098 — Account Manipulation (persistence via authorization-store modification): https://attack.mitre.org/techniques/T1098/
4. OpenSSH sshd(8) — authorized_keys file format and option directives (command=, from=, no-pty): https://man.openbsd.org/sshd.8
5. Froxlor project repository and release notes (verify 2.3.12 fix): https://github.com/Froxlor/Froxlor/releases

Threat actor / exploitation notes. No public exploit, PoC, Nuclei template, or exploit code is known for CVE-2026-90767 as of this report, and the CVE is not listed in CISA KEV. EPSS has not been scored by FIRST.org, so no EPSS probability is asserted. No threat-actor campaigns tied to this CVE were identified in the supplied intelligence data. The persistence property — injected key entries surviving deletion and revocation — makes this a candidate for silent, long-dwell abuse by malicious or offboarded tenants rather than for noisy mass exploitation, and it should be treated as a containment-integrity risk by hosting providers regardless of its Medium CVSS rating.