CVE-2026-80195

Executive Summary

CVE-2026-80195 is a business logic flaw in the Kimai time-tracking application, affecting all versions prior to 2.63.0, that permits an authenticated user with team-edit permissions to silently destroy team membership records. The vulnerability resides in the team update API endpoint (PATCH /api/teams/{id}), where existing team members are deleted before the submitted replacement member list is validated. A malformed payload triggers a validation error yet leaves the team with zero members — including no teamleader — thereby bypassing the dedicated member-removal endpoint's protection and disrupting team-based access control. With a CVSS base score of 5.4 (Medium), the flaw enables low-privilege authenticated users to perform an integrity and availability impact on authorization structures, potentially cascading into broader access-control failures across the application.

Technical Analysis

The root cause of CVE-2026-80195 is an ordering violation in the state-transition logic of Kimai's team-management feature. The vulnerability class is CWE-841: Improper Enforcement of Behavioral Workflow, a business-logic flaw where the application enforces validation only after performing destructive operations. This is distinct from classic injection or memory-corruption bugs — the integrity failure is purely a matter of incorrect sequencing.

From the NVD description, the following technical facts are established:

1. Affected endpoint: PATCH /api/teams/{id} — the REST endpoint used to update an existing team's properties and membership list.
2. Vulnerable sequence: The endpoint performs an upsert/delete of all existing team-member rows before validating the replacement member list submitted in the request body.
3. Bypass mechanism: A malicious user submits a members payload that fails validation (e.g., malformed user IDs, duplicate entries, or references to non-existent users). Kimai returns a 4xx validation error — but the damage is already done: the pre-validation deletion removed all existing membership rows.
4. Intended-control bypass: The dedicated member-removal endpoint (referenced in the NVD description as having "protection against removing teamleaders") embeds business rules that block the removal of a team's teamleader. The vulnerable PATCH endpoint performs a bulk wipe without applying these guardrails.
5. Resulting state: The affected team is left with no members and no teamleader, making the team object effectively orphaned and unable to enforce any team-scoped authorization decisions.

The attack surface is the authenticated REST API. Authentication is required (PR:L per the CVSS vector), meaning the attacker must hold a valid account. The NVD description states the attacker needs "permission to edit a team" — i.e., a teamlead or any user granted team-management rights. The endpoint is network-accessible over HTTP/HTTPS (AV:N), and no user interaction or special conditions are required (UI:N).

From a code-path perspective (described at the general level, as no source code was provided): the endpoint likely receives a request body containing team metadata plus a list of member IDs. The server-side flow probably calls an "update team members" routine that clears the association table (DELETE FROM team_members WHERE team_id = ?) and subsequently attempts to insert or validate the new list. Because the deletion is unconditional and occurs before parsing/validating the incoming member list, the validation failure path does not roll back the deletion.

The lack of transactional integrity or a validation-first design is the core defect. A correct implementation would validate the entire payload, apply the new membership set atomically, or guard the delete operation behind same validation checks used by the dedicated removal endpoint.

Exploitation Scenarios

No public PoC or exploit code is available for CVE-2026-80195. The attack chain below is inferred from the vulnerability class and the explicit technical details in the NVD description.

Step 1 — Reconnaissance / Target Identification The attacker authenticates to the Kimai instance (requires a valid account). The attacker enumerates team endpoints via the API documentation (typically exposed at /api/doc in Kimai installs) to identify the team update endpoint and determine which teams they have permission to edit. The target is any team in the organization for which the attacker has an "edit" grant.

Step 2 — Triggering the Flaw The attacker crafts a PATCH /api/teams/{id} request containing a members array that is deliberately malformed. For example, the payload could include an array of user IDs that do not exist, a null element, or a user ID that violates a uniqueness or type constraint. The key is that the payload is structurally well-formed enough to pass transport-level parsing but fails application-level validation.

Step 3 — Execution at the Vulnerability-Class Level The request is processed by the server. The vulnerable code path:

• Destroys all existing team-member rows linked to the team ID.
• Attempts to validate and apply the malformed replacement list.
• Fails validation, returning a 4xx error to the attacker.

The attacker observes the error response (HTTP 400/422), confirming the validation failure — but the member rows are gone. The attack can be repeated across multiple teams if the attacker has edit permissions on them, or chained: create/join a team as an admin, then wipe it.

Step 4 — Post-Exploitation Impact Post-exploitation consequences:

• Authorization disruption: Team-based permissions in Kimai govern access to projects, activities, and timesheet data. A team with no members cannot grant access, potentially locking out legitimate users from projects or timesheets (availability impact, A:L).
• Integrity impact: Teamleader designations are erased, so role-based elevation or delegation workflows break (I:L). A de-led team may be re-adopted by another user who then re-adds members — effectively a low-grade privilege boundary bypass.
• Incident-response friction: Because the operation yields a normal validation error, the deletion may go unnoticed by automated logging or alerting, complicating forensic reconstruction.

Impact Assessment

Business Impact: This vulnerability erodes the integrity of Kimai's team-based access-control model. Organizations relying on team scoping to enforce least-privilege access to projects and timesheet data will find those boundaries silently removed. The impact is not a direct data breach (C:N), but the availability (A:L) and integrity (I:L) impacts are meaningful for compliance-oriented environments where audit trails of authorization changes are mandatory.

Affected Systems: All Kimai deployments running versions prior to 2.63.0. Includes both cloud-hosted and self-hosted instances exposing the REST API. The vulnerability requires the API to be reachable by authenticated users — which is the default configuration for all Kimai installations.

Blast Radius: Moderate. The CVSS vector (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L) yields a base score of 5.4. The scope is unchanged (S:U), meaning the compromise does not extend beyond the vulnerable component's security authority. The practical blast radius is limited to team-structure disruption, but in complex deployments where teams map to client or project boundaries, the downstream effect on those projects' access can be wider than the scope designation implies.

Secondary Risks: A wiped team may be re-created by a malicious actor with elevated privileges, effectively allowing them to re-define team membership and teamleader roles — undermining separation-of-duties controls. Additionally, if the application relies on the presence of a teamleader for approval workflows (e.g., timesheet approval), the absence of a leader halts those processes, creating operational downtime.

Detection Guidance

The following detection rules target request patterns and server-side behavioral indicators. Because no PoC exists, these rules are heuristic and based on the vulnerability's described mechanism. Note: All rules are templates that must be tuned to environment-specific logging formats (API access logs, application logs, database audit logs).

Sigma Rule

title: Kimai Team Update Bulk Membership Deletion Attempt
id: 9b8f55c2-4c4a-4eae-8b0f-4b0e45a24e71
status: experimental
description: >
  Detects PATCH requests to /api/teams/{id} on Kimai instances that are
  followed by an application-level validation error. Such a pattern may
  indicate exploitation of CVE-2026-80195, where members are deleted
  before payload validation.
logsource:
  category: webserver
  product: apache
  definition: access logs for Kimai application server
detection:
  selection_http:
    cs-method: PATCH
    cs-uri-stem|startswith: /api/teams/
  selection_response:
    sc-status:
      - 400
      - 422
  condition: selection_http and selection_response
  timeframe: 10s
falsepositives:
  - Legitimate API clients sending malformed team updates
  - Misconfigured integrations attempting to update teams
level: medium
tags:
  - attack.t1213
  - cve.2026-80195
  - cwe.841

YARA Rule

rule Kimai_Team_Update_Malformed_Members
{
    meta:
        author = "ValterSIT Threat Research"
        description = "Detects HTTP request bodies targeting the Kimai team update endpoint with malformed member payloads"
        cve = "CVE-2026-80195"
        date = "2026-01-01"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-80195"
        severity = "medium"
    strings:
        $patch_method = "PATCH" ascii wide nocase
        $team_endpoint = "/api/teams/" ascii wide nocase
        $members_key = "\"members\"" ascii wide nocase
        $teamleader_key = "\"teamlead\"" ascii wide nocase        // common JSON key in Kimai payloads
        $null_member = "\"members\":null" ascii wide nocase
        $empty_array = "\"members\":[]" ascii wide nocase
    condition:
        any of them and
        uint16(0) != 0x4D5A and   // not PE
        #patch_method > 0 and
        #team_endpoint > 0
}

Note: The teamlead key is derived from the NVD description's mention of "teamleaders" and is a plausible JSON key — analysts should verify against actual Kimai payload documentation.

Suricata IDS Rule

alert http any any -> $HOME_NET any ( \
  msg:"ET WEB_SPECIFIC_APPS Kimai Team Update Endpoint PATCH Request"; \
  flow:established,to_server; \
  http.method; content:"PATCH"; http.method; \
  http.uri; content:"/api/teams/"; startswith; \
  pcre:"/\/api\/teams\/\d+$/i"; \
  content:"members"; http.request_body; \
  offset:0; depth:200; \
  classtype:attempted-recon; \
  sid:202680195; rev:1; \
  reference:cve,2026-80195; \
  metadata:created_at 2026_01_01, updated_at 2026_01_01;)

Note: This rule is a traffic-level indicator. A follow-on rule correlating HTTP 4xx responses to the same source IP within a short window would improve fidelity. Such correlation is better performed in a SIEM (see Splunk rule below).

Elastic Detection

EQL query for use in Elasticsearch SIEM:

sequence by source.ip with maxspan=30s
  [network where http.request.method == "PATCH" and
   http.request.body.text like "*members*" and
   http.request.uri.full like "/api/teams/*"]
  [network where http.response.status_code in (400, 422) ]

This correlation detects a PATCH to the team endpoint followed shortly by a validation error from the same source IP. Operationally, SOC analysts should review the request body for malformed member arrays.

Splunk SPL Query

index=* sourcetype=apache:access
    method=PATCH
    uri_stem="/api/teams/*"
| table _time clientip uri path status
| where status = 400 OR status = 422
| transaction clientip maxspan=2m
| stats count by clientip, uri, status
| where count > 1
| rename count as "attempt_count"

This SPL query groups PATCH requests to team endpoints with validation-error responses per source IP, flagging repeat attempts that could indicate systematic team-wiping behavior.

Wazuh OSSEC Rule

<group name="kimai,">
  <rule id="100295" level="10">
    <decoded_as>json</decoded_as>
    <field name="url">\./api/teams/</field>
    <field name="method">PATCH</field>
    <field name="response">400|422</field>
    <description>Kimai: PATCH to /api/teams/{id} resulted in validation error - possible CVE-2026-80195 exploitation</description>
    <group>access_control,</group>
    <mitre>
      <id>T1213</id>
    </mitre>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 — UNPATCHED. No patch evidence was identified from any tracked source, and the vendor fix is listed as N/A. The fixed version is expected to be 2.63.0 per the NVD description, but as of this report, no official release notes or advisories confirming the fix are available.

1. Immediate Mitigations (until a patch is released)

• Restrict API access: Place the Kimai API behind a reverse proxy (nginx, Apache, WAF) and enure PATCH requests to /api/teams/* are allowed only from trusted admin IP ranges or specific service accounts. This reduces the attack surface to higher-trust networks.
• Review team permissions: Audit which users possess team-edit grants. Minimize the set of users who can invoke the vulnerable endpoint. Remove any team-edit grants from non-admin users if business workflows permit.
• Logging and alerting: Enable verbose application logging for team-update operations. Detect and alert on any PATCH /api/teams/{id} request that returns a validation error (4xx). The detection rules above can be adapted to existing SIEM pipelines.
• Manual verification: Periodically (e.g., daily) run a script that queries all teams and flags any team with zero members, enabling early detection of successful exploitation.

2. Patch / Upgrade Steps

• Monitor Kimai's official release channels (GitHub releases, kimai.org changelog) for version 2.63.0 or later.
• Once released, upgrade all production and staging Kimai instances to the patched version per standard upgrade procedures (backup DB, run migration, restart services).
• Verify the fix: after upgrade, attempt a malformed PATCH /api/teams/{id} request in a test environment and confirm that team memberships remain intact.

3. Long-Term Hardening

• Defense in depth: Assume the vulnerability can be exploited; design team-based access-control audits into regular security reviews.
• Code review practice: For self-hosted custom modifications, enforce a rule that destructive database operations must be preceded by full payload validation, and that all member updates occur within a single database transaction.
• Vulnerability disclosure tracking: Add Kimai to the organization's software inventory and enable automated CVE monitoring for it.

References

1. NVD Entry: https://nvd.nist.gov/vuln/detail/CVE-2026-80195
2. Vendor Project (Kimai): https://www.kimai.org/ — monitor for 2.63.0 release and advisory
3. Kimai GitHub Releases: https://github.com/kimai/kimai/releases — for patch/hotfix notifications
4. CWE-841 Reference: https://cwe.mitre.org/data/definitions/841.html — Improper Enforcement of Behavioral Workflow
5. ATT&CK T1213 (Data from Information Repositories): https://attack.mitre.org/techniques/T1213/

Threat actor activity / exploitation in the wild: No evidence of active exploitation or known threat-actor campaigns targeting this CVE has been identified at the time of writing. CISA KEV status: Not listed. EPSS: Not yet scored. The vulnerability's requirement for an authenticated account and its low direct impact (no confidentiality loss) reduces its attractiveness to opportunistic attackers, but it may be leveraged in targeted campaigns against organizations where Kimai's team structures map to business-critical access decisions.