CVE-2026-79763

Executive Summary

CVE-2026-79763 is an authentication weakness in Termix, a web-based server management platform providing SSH terminal, tunneling, and file editing capabilities. From version 2.4.0 until 2.5.1, a refactor regressed the two-factor reauthentication check on the POST /users/totp/disable and POST /users/totp/backup-codes endpoints, allowing an attacker with a victim's authenticated session and knowledge of the account password to disable TOTP or regenerate backup codes without supplying a valid second factor. Successful exploitation downgrades the victim account to single-factor authentication, materially undermining the security posture of the managed infrastructure accessible through the platform. The issue is tracked as CWE-308 (Use of Single-factor Authentication) with a CVSS v3.1 base score of 5.3.

Technical Analysis

Termix is a web-based server management platform whose core value proposition is centralized, authenticated access to SSH terminals, network tunneling, and remote file editing. Because the platform functions as a privileged access gateway to managed servers, its authentication integrity is the primary trust boundary protecting downstream infrastructure.

CVE-2026-79763 is a regression introduced during a 2.4.0 refactor of the two-factor authentication subsystem. The regression specifically affects the reauthentication controls on two sensitive account-security endpoints:

• POST /users/totp/disable — disables TOTP for the authenticated account.
• POST /users/totp/backup-codes — regenerates backup codes, invalidating all previously issued codes.

Prior to 2.4.0, a two-factor check had been introduced to address CVE-2026-45749. The 2.4.0 refactor regressed that control. In src/backend/database/routes/user-totp-routes.ts, the function verifyTotpReauth returns success when bcrypt.compare validates the supplied password. Critically, each affected endpoint treats the account password and totp_code as interchangeable credentials — meaning the second-factor (totp_code) branch is effectively optional rather than required when a valid password is presented.

The resulting logic flaw is a classic single-factor authentication weakness (CWE-308): the endpoint accepts one factor (something the user knows — the password) where two factors (password plus possession of the authenticator) are required to perform a security-sensitive state change. An attacker in possession of an authenticated session and the account password can therefore:

1. Invoke POST /users/totp/disable with the password as the sole credential to strip the account's second factor, or
2. Invoke POST /users/totp/backup-codes with the password to regenerate backup codes, invalidating the victim's existing codes and establishing attacker-controlled recovery material.

The vulnerability does not permit authentication bypass in the sense of unauthenticated access; it requires an already-authenticated session (network vector, low privileges, high attack complexity per the CVSS vector AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:N). The high attack complexity reflects the prerequisite of possessing both a live session and the account password — a nontrivial combination that typically arises from session hijacking, credential theft, infostealer logs, or insider access.

The integrity impact is rated High (I:H) because the change directly and durably alters the account's authentication configuration. Confidentiality is not directly impacted (C:N) since the endpoints themselves do not disclose data; however, disabling MFA is frequently a precursor step enabling subsequent account takeover and lateral movement into the SSH-accessible infrastructure the platform manages. Availability is unaffected (A:N), and the scope remains unchanged (S:U).

Exploitation Scenarios

No public proof-of-concept, exploit code, or Nuclei template is available for this CVE. The attack chain below is inferred strictly from the NVD description and the vulnerability class (CWE-308, two-factor reauthentication regression). No specific code patterns, additional function names, or parameter names beyond those in the description are assumed.

1. Reconnaissance and target identification. The attacker identifies Termix instances (version 2.4.0 through 2.5.0) exposed to the network. Deployment discovery can leverage web fingerprinting of the Termix management interface. The attacker also requires, or must obtain, two items: (a) a valid authenticated session for the victim account, and (b) the victim's account password.

2. Obtaining the prerequisites. Because the flaw requires an authenticated session and the password, initial access is typically achieved through adjacent means — for example, session cookie theft via client-side compromise, credential harvesting via infostealer malware, credential reuse, or an insider with legitimate credentials. This is consistent with the low privileges (PR:L) and high attack complexity (AC:H) ratings.

3. Triggering the flaw. Once the attacker holds the victim's authenticated session and knows the password, they send a request to POST /users/totp/disable supplying the account password as the sole credential. Because verifyTotpReauth in src/backend/database/routes/user-totp-routes.ts succeeds on a valid bcrypt.compare password result and the endpoint accepts password or totp_code interchangeably, the request succeeds without a valid second factor. Alternatively, the attacker calls POST /users/totp/backup-codes to regenerate recovery codes, invalidating the victim's existing codes and substituting attacker-known codes.

4. Post-exploitation impact. With TOTP disabled, the account is downgraded to single-factor authentication. The attacker can subsequently authenticate using only the password (potentially persisting access even after the hijacked session expires, provided the password remains valid) and pivot into the SSH terminals, tunnels, and file editing capabilities that Termix brokers. The regenerated backup codes provide a durable, attacker-controlled recovery path. Because Termix typically brokers access to production servers, the ultimate blast radius may extend well beyond the Termix instance itself.

Impact Assessment

The CVSS v3.1 base score is 5.3 (Medium), with the vector CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:N. The subscores indicate:

• Attack Vector (Network): the endpoints are reachable over the network as part of the Termix web application.
• Attack Complexity (High): exploitation requires the attacker to possess both a valid session and the account password, a demanding precondition.
• Privileges Required (Low): the attacker needs only a low-privileged authenticated account context.
• User Interaction (None): no victim action is required once the prerequisites are met.
• Scope (Unchanged): the impact is confined to the Termix application's authentication state.
• Confidentiality (None): the flaw does not directly disclose data.
• Integrity (High): the account's authentication configuration is durably and adversely modified.
• Availability (None): no denial of service is introduced.

Business impact. Termix is a privileged access platform. By weakening MFA on an account, this flaw removes a critical control that organizations rely on to contain credential compromise. The downstream consequence is elevated risk of full account takeover and unauthorized access to managed SSH endpoints, tunnels, and remote files — potentially enabling lateral movement, data exfiltration, or destructive actions across managed infrastructure.

Blast radius. The direct blast radius is the affected Termix account (MFA removed, backup codes replaced). The indirect blast radius is everything reachable through that account: managed servers, tunneled network segments, and edited files. In environments where Termix functions as a privileged jump host, a single downgraded administrative account can compromise the broader managed estate.

Affected systems. Termix deployments running versions 2.4.0 through 2.5.0. The vendor/product for this CVE is recorded as Unknown in the provided data; the affected component is the Termix web-based server management platform.

Detection Guidance

The detection rules below are constructed around the two affected endpoints (/users/totp/disable and /users/totp/backup-codes) and around the authentication-state change they perform. Because the flaw is a logic regression rather than a memory-safety or injection issue, detection focuses on anomalous requests to these endpoints and on the resulting configuration change, not on malformed payload signatures. Analysts should tune thresholds and expected-source lists to their environment.

Sigma Rule

title: Termix TOTP Disable or Backup Code Regeneration via Password-Only Reauth (CVE-2026-79763)
id: 8f1c2a44-termix-totp-5f3d-4b21-9c7e-termixcve79763
status: experimental
description: >
  Detects successful requests to the Termix endpoints /users/totp/disable or
  /users/totp/backup-codes, which under CVE-2026-79763 may be invoked with the
  account password as the sole reauthentication factor.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-79763
author: valtersit.com
date: 2026-01-01
tags:
  - attack.t1556
  - attack.persistence
  - cve.2026.79763
logsource:
  category: webserver
  product: termix
detection:
  selection_endpoint:
    cs-uri-stem|endswith:
      - '/users/totp/disable'
      - '/users/totp/backup-codes'
  selection_method:
    cs-method: 'POST'
  selection_status:
    sc-status: 200
  condition: selection_endpoint and selection_method and selection_status
falsepositives:
  - Legitimate users disabling TOTP or regenerating backup codes
  - Administrative account-recovery workflows
level: high

YARA Rule

rule CVE_2026_79763_Termix_TOTP_Reauth_Regression
{
    meta:
        description = "Detects Termix source referencing the affected TOTP endpoints and password-based reauth regression (CVE-2026-79763)"
        author = "valtersit.com"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-79763"
        date = "2026-01-01"
        severity = "medium"

    strings:
        $route = "user-totp-routes.ts" ascii wide
        $fn1   = "verifyTotpReauth" ascii wide
        $fn2   = "bcrypt.compare" ascii wide
        $ep1   = "/users/totp/disable" ascii wide
        $ep2   = "/users/totp/backup-codes" ascii wide
        $p1    = "totp_code" ascii wide

    condition:
        ($route or $fn2) and $fn1 and ($ep1 or $ep2) and $p1
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-79763 Termix TOTP Disable via Password-Only Reauth Attempt"; flow:established,to_server; http.method; content:"POST"; http.uri; content:"/users/totp/disable"; http.uri; content:"/users/totp/backup-codes"; classtype:attempted-user; reference:cve,2026-79763; reference:url,nvd.nist.gov/vuln/detail/CVE-2026-79763; sid:202679763; rev:1;)

Elastic Detection

sequence by process.entity_id with maxspan=1m
  [ network where http.request.method == "POST" and
      (http.request.path == "/users/totp/disable" or
       http.request.path == "/users/totp/backup-codes") ]
  [ network where http.response.status_code == 200 and
      (http.request.path == "/users/totp/disable" or
       http.request.path == "/users/totp/backup-codes") ]

Splunk SPL Query

index=web_logs sourcetype=termix_access
(http_method=POST AND (uri_path="/users/totp/disable" OR uri_path="/users/totp/backup-codes") AND http_status=200)
| stats count min(_time) as first_seen max(_time) as last_seen values(uri_path) as endpoints by src_ip, user
| where count >= 1
| sort - last_seen

Wazuh OSSEC Rule

<group name="termix,web,authentication,cve-2026-79763">
  <rule id="202679763" level="12">
    <decoded_as>json</decoded_as>
    <field name="http_method">POST</field>
    <field name="uri_path">/users/totp/disable</field>
    <field name="http_status">200</field>
    <description>CVE-2026-79763: Termix TOTP disable endpoint accessed successfully - possible password-only reauth bypass</description>
    <mitre>
      <id>T1556</id>
    </mitre>
    <group>authentication_downgrade,</group>
  </rule>

  <rule id="202679764" level="12">
    <decoded_as>json</decoded_as>
    <field name="http_method">POST</field>
    <field name="uri_path">/users/totp/backup-codes</field>
    <field name="http_status">200</field>
    <description>CVE-2026-79763: Termix TOTP backup-codes endpoint accessed successfully - possible password-only reauth bypass</description>
    <mitre>
      <id>T1556</id>
    </mitre>
    <group>authentication_downgrade,</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 (UNPATCHED — no patch evidence from any tracked source).

1. Immediate mitigations.

• Restrict network access to Termix instances (versions 2.4.0 through 2.5.0) to trusted management networks; do not expose the platform to the public internet.
• Monitor and alert on all requests to POST /users/totp/disable and POST /users/totp/backup-codes, using the detection content above. Investigate any successful invocation not correlated with a legitimate user action.
• Enforce strict session hygiene: reduce session lifetimes, bind sessions to client attributes where the platform permits, and rotate or revoke active sessions if compromise is suspected.
• Audit TOTP enrollment state across accounts. Any account that unexpectedly shows TOTP disabled or backup codes regenerated during the vulnerable window should be treated as potentially compromised, and its password rotated immediately.
• Where feasible, enforce reauthentication for these endpoints at an upstream reverse proxy or identity-aware proxy that requires a valid second factor, compensating for the application's regression.

2. Patch/upgrade steps.

• Upgrade Termix to version 2.5.1 or later, which the vendor states fixes the issue. Because no patch evidence is available from tracked sources, verify the fix by confirming that both endpoints require a valid second factor (totp_code) in addition to the password, and that verifyTotpReauth no longer treats password and TOTP as interchangeable for these operations. Validate the fix in a non-production environment before fleet-wide rollout.

3. Long-term hardening.

• Treat privileged management platforms like Termix as tier-zero assets; isolate them from general user networks and require hardware-backed MFA for all accounts.
• Enforce step-up / phishing-resistant authentication (e.g., WebAuthn/FIDO2) for security-sensitive state changes such as MFA disablement and recovery-code regeneration.
• Implement regression testing in CI/CD for authentication controls, so refactors like the 2.4.0 change cannot silently reintroduce bypasses (see CVE-2026-45749 as the prior, related fix).
• Maintain continuous visibility over authentication-configuration changes, with alerting and periodic review of MFA status across all privileged accounts.

References

• NVD — CVE-2026-79763: https://nvd.nist.gov/vuln/detail/CVE-2026-79763
• CWE-308 — Use of Single-factor Authentication: https://cwe.mitre.org/data/definitions/308.html
• CVE-2026-45749 — prior two-factor check that the 2.4.0 refactor regressed (referenced in the NVD description): https://nvd.nist.gov/vuln/detail/CVE-2026-45749
• MITRE ATT&CK T1556 — Modify Authentication Process: https://attack.mitre.org/techniques/T1556/
• FIRST CVSS v3.1 Specification: https://www.first.org/cvss/v3.1/specification-document

No public proof-of-concept, exploit code, or Nuclei template exists for this CVE, and no exploit-in-the-wild or threat-actor campaign activity is associated with it at the time of writing. CVE-2026-79763 is not listed in CISA KEV, and no EPSS score has been published by FIRST.org.