CVE-2026-49992

Executive Summary

CVE-2026-49992 is an authenticated cross-site request forgery (CSRF) vulnerability in Kimai, an open-source time-tracking application, affecting all versions prior to 2.58.0. The flaw resides in "default team creation shortcuts" for projects, customers, and activities that are exposed over GET routes and perform state-changing operations — creating or reusing a Team, adding the current user as teamlead, and binding the target object to that team — without adequate request-forgery protections. A remote attacker can lure an authenticated Kimai user who holds the required permissions into visiting a malicious page, causing unauthorized modifications to team membership, teamlead assignment, and object-to-team binding relationships. The impact is an authorization-structure modification rather than a harmless UI convenience, though no public PoC, exploit code, or KEV listing exists at the time of writing.

Technical Analysis

The vulnerability is classified as CWE-352 (Cross-Site Request Forgery). The core defect, as described by the NVD, is twofold:

1. State-changing operations exposed via GET. The default team-creation shortcuts for projects, customers, and activities are reachable through HTTP GET routes. HTTP GET is defined by the HTTP specification as a safe and idempotent method; it must not cause server-side state changes. Because these routes execute side effects, any mechanism that induces a browser to issue a GET to the endpoint — an <img> tag, a link, a fetch/XMLHttpRequest from a third-party origin, or a top-level navigation — will trigger the operation. This collapses the usual CSRF precondition that a forged request be a non-simple POST with a JSON or form content type; a GET is trivially forgeable cross-origin without triggering CORS preflight.

2. Missing or bypassable anti-CSRF controls. For a GET-based state change to be exploitable as CSRF, the endpoint must not require a per-request anti-CSRF token (or the token must not be validated, or SameSite cookie policy must not block the forged request). The NVD description frames this as an "authenticated cross-site request forgery issue," confirming that the session cookie is what authorizes the action and that the request itself is not adequately bound to a user-intent token.

The concrete state mutation performed by the endpoint chain is policy-significant:

• A Team is created or reused.
• The current user is added as teamlead of that Team.
• The target object (a specific project, customer, or activity) is bound to that Team.

In Kimai's authorization model, teamlead status and object-to-team bindings govern who can see and act on the target object. By manipulating these bindings, an attacker can alter the effective permission graph of the application — for example, by inserting a team the victim leads, or by re-binding an object to a team the attacker's account can later interact with. The NVD explicitly stresses: "This is a real authorization-structure modification issue rather than a harmless UI shortcut."

Attack surface. The exposed routes are the default team-creation shortcuts reachable for the three object classes (projects, customers, activities). The prerequisite is an authenticated victim holding "the required permissions" to create/lead teams and to bind the target object — i.e., the victim must already hold a role such as teamlead, administrator, or equivalent. No authentication bypass is needed; the attacker leverages the victim's existing session.

Why GET matters. Because the mutation is carried on a GET, standard CSRF defenses tuned only to POST endpoints (e.g., checking Content-Type, rejecting non-simple requests, or requiring custom X-* headers) will not fire. Token-checking middleware that is applied per-route will also miss these routes if the shortcut handlers bypass the common form middleware.

Confidence limits. The supplied data does not include the exact route paths, controller/action names, parameter names, or the patch commit. The mechanism above is derived strictly from the NVD wording; no additional implementation detail should be inferred.

Exploitation Scenarios

No public PoC or exploit code is available for CVE-2026-49992; the chain below is inferred from the CWE-352 vulnerability class and the NVD description. It uses only the endpoint classes and state changes named in the description.

1) Reconnaissance / target identification. The attacker identifies a Kimai instance running a version prior to 2.58.0 (self-hosted instances are common; fingerprinting is possible via the login page, static assets, or version banners). The attacker must also identify a victim who is (a) authenticated to that instance and (b) holds "the required permissions" to create/lead teams and bind projects, customers, or activities. This is reconnaissance at the user level: the attacker needs to know a privileged Kimai user (e.g., a project manager or administrator) will be browsing the web while logged in.

2) Triggering the flaw class. The attacker constructs a malicious page containing a forged request to one of the exposed GET team-creation shortcut routes for a project, customer, or activity. Because the endpoint is a GET, the forged request can be delivered through a wide range of HTML primitives:

<!-- Illustrative only; exact path not provided in source data -->
<img src="https://kimai.example.com/<team-shortcut-route>?<params>" />

or a top-level link the victim is socially engineered into clicking. No custom header, no JSON body, and no CORS preflight are required. When the victim, still holding a valid session cookie, loads the attacker page (or clicks the link), the browser automatically attaches the Kimai session cookie and issues the GET. SameSite defaults will block this only if Kimai sets SameSite=Strict/Lax on the session cookie and the request is a subresource cross-site load; top-level navigation under Lax would still be sent. Absent explicit anti-CSRF token validation on these routes, the server processes the request.

3) Payload / execution at the vulnerability-class level. The request causes the server to perform, in sequence:

• create a new Team or reuse an existing one,
• add the current user (the victim) as teamlead of that Team,
• bind the targeted project, customer, or activity to that Team.

The attacker does not need to know the target object's ID if a default/parameterless shortcut selects one; otherwise the attacker supplies the target identifier as a query parameter (the exact parameter name is not disclosed in the source data).

4) Post-exploitation impact. The victim's effective authorization structure is silently modified: a team now exists (or is reused) with the victim as teamlead, and an object is bound to that team. Depending on Kimai's team semantics, this can grant or expose access to the bound object to additional accounts, change who administers the team, or create a durable foothold in the permission graph that persists after the victim's session ends. The transaction is indistinguishable from a legitimate team-creation action in the application audit trail unless the team/object naming and creation timing are analyzed. Because no KEV listing, public exploit, or in-the-wild campaign is reported for CVE-2026-49992 at this time, all of the above represents a reasoned reconstruction rather than observed activity.

Impact Assessment

• Confidentiality (C:N): Not primarily implicated by the described state changes; direct data disclosure is not stated. Rated None.
• Integrity (I:L): The described effects — creating a team, adding a teamlead, and re-binding an object — are discrete, bounded authorization-graph modifications. Rated Low in isolation because the number of records altered per exploit is small, though the semantic impact on access control can exceed the raw count.
• Availability (A:N): No denial of service is described. None.
• Attack Vector (AV:N): The malformed request arrives over the network. Network.
• Attack Complexity (AC:L): Once the victim is identified and induced to load a page, exploitation is deterministic. Low.
• Privileges Required (PR:L): The attacker needs no privileges themselves, but the attack depends on a victim session that already holds team/object permissions. Modeled as Low (victim's session is the privilege carrier).
• User Interaction (UI:R): The victim must visit the malicious page or click the link. Required.
• Scope (S:U): The exploit operates within Kimai's security authority. Unchanged.

Business impact. Kimai is used for employee time tracking, project billing, and client reporting. Unauthorized modification of team and object bindings can:

• corrupt the authorization structure that governs who sees billable hours, client data, and project metadata;
• enable subsequent privilege abuse — an attacker who can later authenticate or pivot into the manipulated team may gain visibility into time entries, customers, and activities they should not see, with downstream effects on invoicing accuracy and client confidentiality;
• undermine audit integrity, since teamlead/team-binding changes are legitimate administrative events and difficult to separate from abuse after the fact;
• create a persistent, low-noise foothold in the access-control layer rather than a transient anomaly.

Blast radius. Any Kimai instance < 2.58.0 with authenticated users holding team/object administration permissions, and with a session cookie not protected against cross-site transmission for these routes. Self-hosted deployments without a WAF that inspects GET-based state changes are most exposed. Because the effect is a permission-graph edit, the blast radius is measured not by hosts compromised but by records and relationships whose access semantics are altered.

Detection Guidance

Sigma Rule

title: Kimai CSRF Team Creation Shortcut Abuse (CVE-2026-49992)
id: 3f9c2a17-7b6e-4f2d-9a3e-8d1c5e2b7f44
status: experimental
description: >
  Detects HTTP GET requests to Kimai default team-creation shortcuts for projects,
  customers, or activities combined with a cross-site Referer, indicative of
  CSRF exploitation of CVE-2026-49992 (Kimai < 2.58.0).
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-49992
author: valtersit.com
date: 2026/01/01
logsource:
  category: webserver
  product: kimai
detection:
  selection_method:
    cs-method: 'GET'
  selection_path:
    cs-uri-stem|contains:
      - '/project/'
      - '/customer/'
      - '/activity/'
  selection_keywords:
    cs-uri-query|contains:
      - 'team'
  selection_referer:
    cs-referer|contains: 'http'
  filter_self:
    cs-referer|contains|all:
      - 'kimai'
  condition: selection_method and selection_path and selection_keywords and selection_referer and not filter_self
fields:
  - c-ip
  - cs-uri-stem
  - cs-uri-query
  - cs-referer
  - cs-useragent
level: medium
tags:
  - attack.t1204.001
  - cve.2026.49992

YARA Rule

rule CVE_2026_49992_Kimai_CSRF_Team_Shortcut
{
    meta:
        author      = "valtersit.com"
        description  = "Detects forged CSRF requests targeting Kimai team-creation GET shortcuts (CVE-2026-49992)"
        reference    = "https://nvd.nist.gov/vuln/detail/CVE-2026-49992"
        cve          = "CVE-2026-49992"
        date         = "2026-01-01"

    strings:
        $a = "GET /" ascii nocase
        $b = "/team" ascii nocase
        $c = "teamlead" ascii nocase
        $d = "/project/" ascii nocase
        $e = "/customer/" ascii nocase
        $f = "/activity/" ascii nocase
        $g = "Referer: http" ascii nocase

    condition:
        $a and ($b or $c) and ($d or $e or $f) and $g and $g
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-49992 Kimai CSRF Team Creation Shortcut GET Request"; flow:established,to_server; http.method; content:"GET"; http.uri; content:"team"; http.uri; pcre:"/\/(project|customer|activity)\//i"; http.header; content:"Referer"; http.header; content:"http"; pcre:"/Referer:\s*http(?!s?:\/\/[^\/]*kimai)/Hi"; classtype:web-application-attack; reference:cve,2026-49992; reference:url,nvd.nist.gov/vuln/detail/CVE-2026-49992; metadata:service http; sid:2026499920; rev:1;)

Elastic Detection

sequence by source.ip with maxspan=5s
  [ network where
      network.transport == "tcp" and
      http.request.method == "GET" and
      (
        http.request.path : "*team*" or
        http.request.path : "*/project/*" or
        http.request.path : "*/customer/*" or
        http.request.path : "*/activity/*"
      )
  ]
  [ network where
      http.response.status_code == 200 and
      http.request.referrer != null and
      http.request.referrer : "http*" and
      not http.request.referrer : "*kimai*"
  ]

Splunk SPL Query

index=web OR index=proxy sourcetype=access_combined OR sourcetype=nginx:access
| where method="GET"
| where match(uri, "(?i)^/(project|customer|activity)/.*team") OR match(uri, "(?i)[?&]team")
| where isnotnull(referer) AND match(referer, "^http") AND NOT match(referer, "(?i)kimai")
| stats count min(_time) as first_seen max(_time) as last_seen values(uri) as uris values(referer) as referrers by clientip, useragent
| where count >= 1
| convert ctime(first_seen) ctime(last_seen)
| sort -count

Wazuh OSSEC Rule

<group name="web,appsec,kimai,">
  <rule id="2026499" level="8">
    <if_sid>31100,31101</if_sid>
    <id>^200$</id>
    <description>CVE-2026-49992: Kimai team-creation GET shortcut accessed with cross-site Referer (possible CSRF exploitation)</description>
    <regex type="pcre2">(GET|POST)\s+/(project|customer|activity)/[^\s]*team</regex>
    <regex type="pcre2">Referer:\s*https?://(?!.*kimai)</regex>
    <mitre>
      <id>T1204.001</id>
    </mitre>
    <group>cve_2026_49992,csrf,</group>
  </rule>
</group>

Mitigation & Patch Guidance

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

The NVD description states that version 2.58.0 patches the issue, and that "Version 2.58.0 patches the issue." However, no vendor advisory URL, release-note link, commit hash, or patch diff was supplied in the intelligence data, so patch evidence cannot be independently corroborated at this time. The guidance below reflects both this uncertainty and the stated fixed version.

1) Immediate mitigations (do not require upgrading).

• Upgrade to Kimai 2.58.0 or later — the NVD explicitly identifies 2.58.0 as the fixed version. This is the only confirmed remediation named in the source data.
• Until upgrade is possible, restrict exposure of the team-creation shortcut routes for projects, customers, and activities at the reverse-proxy/WAF layer — reject or require re-authentication for GET requests to those paths.
• Enforce SameSite=Lax or Strict on the Kimai session cookie. This is a partial control: it blocks most cross-site subresource GETs but does not stop top-level navigation under Lax and is not a substitute for server-side anti-CSRF validation.
• Require a valid Referer/Origin header for state-changing team operations and reject cross-origin values — a compensating control at the edge if the application itself cannot be changed promptly.
• Apply least privilege: minimize the number of accounts holding teamcreation/teamlead/object-binding permissions, reducing the population of viable CSRF victims.

2) Patch/upgrade steps.

1. Inventory all Kimai deployments and record exact versions.
2. Back up the database and configuration.
3. Upgrade all instances below 2.58.0 to 2.58.0 or a later stable release.
4. Verify after upgrade that the team-creation shortcut actions no longer perform state changes on GET (they should require a non-idempotent method and/or a validated anti-CSRF token).
5. Re-audit team memberships, teamlead assignments, and object-to-team bindings for unauthorized additions created prior to upgrade, and revert any anomalous entries.

3) Long-term hardening.

• Treat GET as strictly safe: all state-changing operations must use POST/PUT/PATCH/DELETE, ideally with a per-request anti-CSRF token.
• Adopt a framework-level CSRF protection pattern and ensure it applies to all state-mutating routes, not just form submissions.
• Enable SameSite cookie attributes by default and add Secure/HttpOnly.
• Log and alert on authorization-structure changes (team creation, teamlead additions, object re-binding) so post-incident reconstruction is possible.
• Monitor the Kimai project's release channel for a formal security advisory and patch reference for CVE-2026-49992; update this report when a verifiable patch commit or advisory is published.

References

1. NVD — CVE-2026-49992: https://nvd.nist.gov/vuln/detail/CVE-2026-49992
2. MITRE CWE-352 — Cross-Site Request Forgery (CSRF): https://cwe.mitre.org/data/definitions/352.html
3. MITRE ATT&CK T1204.001 — User Execution: Malicious Link: https://attack.mitre.org/techniques/T1204/001/
4. Kimai project (upstream source and release notes for 2.58.0): https://github.com/kimai/kimai
5. CISA Known Exploited Vulnerabilities Catalog (checked — CVE-2026-49992 is not listed as of this report): https://www.cisa.gov/known-exploited-vulnerabilities-catalog

Exploit-in-the-wild / threat actor status: No public PoC, Nuclei template, exploit code, or KEV listing exists for CVE-2026-49992 per the supplied data. No threat actor campaign is associated. FIRST.org has not yet assigned an EPSS score. This report should be revised if/when a verifiable vendor advisory, patch commit, or exploitation evidence emerges.