☠️
EXFILTRATING
DATA...
01010111 10110010 00101001 11000110 01101100 10011011 00010001 11100101 01000010 10101111
[ <-- BACK_TO_SEARCH ]
Kimai logo [ WEBSITE ] [ VENDOR STATS ]
CVSS: 7.1 CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N 🐛 CWE-639
👁️
Common Weakness Enumeration - Identifies the specific category of software weakness or flaw.

CVE-2026-52820

CVE-2026-52820 Vulnerability in Kimai
📅 PUBLISHED: 2026-09-15 00:00 UTC 🔄 UPDATED: 2026-10-11 17:46 UTC
[ PATCH UNDER REVIEW ↓ ] Remains UNDER REVIEW until an independent source confirms the fix
[ DEFENSE PATCH ↓ ]
💣 PoC: None
👁️
Proof of Concept - Indicates if functional exploit code is publicly available, drastically increasing the risk of immediate attacks.
🎯 EPSS: 0.45%
👁️
0.45% probability
11.2× above the median CVE
Tier: ELEVATED
30-day exploitation window · FIRST.org · updated daily
🥷 MITRE: T1190
👁️
MITRE ATT&CK Tactic - Describes the strategy hackers use to execute this attack.
Country: Global License: Open Source
VULNERABLE: version not auto-detected — verify your deployed version locally
CVSS VECTOR BREAKDOWN 7.1
AV: N Attack Vector Network
AC: L Attack Complexity Low
PR: L Privileges Required Low
UI: N User Interaction None
S: U Scope Unchanged
C: H Confidentiality High
I: L Integrity Low
A: N Availability None
7.1
THREAT LEVEL
■ tracking this CVE ✓ independent patch confirmation ⧗ same-origin mirror (GHSA) ⚠ active exploitation verification policy →

Executive Summary

CVE-2026-52820 is an authorization bypass vulnerability in Kimai, an open-source time-tracking application. Prior to version 2.57.0, authenticated users with the edit_own_timesheet permission can supply an arbitrary project identifier via the timesheet REST API, causing the application to associate their timesheet with a project outside their authorized team scope. This allows unauthorized project attribution and disclosure of project and customer metadata through the API.

⚡ AUTOMATE YOUR CVE INTELLIGENCE

This record — and 170,000+ others — are available via the ValtersIT API. One endpoint replaces five: NVD + GitHub CVE + CISA KEV + EPSS + Nuclei + Exploit-DB, unified.

›Patch confidence — UNVERIFIED to CONFIRMED, cross-referenced NVD + RHSA + Debian
›Exploit & PoC — poc_status, poc_url, has_exploit. Not in NVD.
›Shodan dorks — ready-made queries to find exposed vulnerable systems
›Detection rules — YARA · Wazuh · Elastic (all plans) · Sigma (Pro)
›pending_fields — know exactly which of 7 fields NVD hasn't processed yet
›Free backfill — data incomplete when you paid? Re-check within 30 days = 0 credits
PAYG €0.08/lookup Standard €19/mo (was €29) · 5k credits Pro €65/mo (was €99) · 20k credits FOUNDING PRICE · LOCKED FOR LIFE · ENDS 31 DEC 2026
[ FROM €19/MO ]
Free sandbox key available
No signup required

Technical Analysis

Kimai implements team-based access control, where users may only interact with projects and activities belonging to teams they are members of. The vulnerability resides in the query-building logic used to validate project selection during timesheet creation and editing.

Specifically, the affected endpoints are:

  • PATCH /api/timesheets/{id}
  • POST /api/timesheets

These endpoints accept a user-controlled project identifier through the TimesheetApiEditForm class and the FormTrait trait. When building the query used to validate and retrieve eligible projects, ProjectRepository::getQueryBuilderForFormType() places the user-supplied identifier in an unconditional OR branch of the query. This OR branch bypasses the team access criteria that would otherwise restrict the query to projects within the user's teams.

The root cause is CWE-639 (Authorization Bypass Through User-Controlled Key). The application trusts a client-supplied key (the project identifier) and fails to re-validate it against the authenticated user's authorization scope before persisting the association. Any authenticated user holding the edit_own_timesheet permission can therefore:

  1. Assign an owned timesheet to a project outside their teams.
  2. Persist that unauthorized project attribution.
  3. Retrieve project and customer metadata via GET /api/timesheets/{id}?full=true.

The fix in version 2.57.0 introduces a TimesheetTeamAccessValidator that checks changed project and activity associations against the user's current team access. No specific function-level details beyond those quoted from the advisory are available; the mechanism is an object-reference/authorization-scope validation gap rather than an injection or memory-safety flaw.

Exploitation Scenarios

No public PoC exists; the attack chain is inferred from the vulnerability class and the advisory description.

  1. Reconnaissance / target identification. The attacker identifies a Kimai instance (e.g., via Shodan dorks for the login page or application title). They authenticate with any low-privileged account holding the edit_own_timesheet permission.

  2. Triggering the flaw. Using the timesheet REST API, the attacker submits a POST /api/timesheets or PATCH /api/timesheets/{id} request that includes a project identifier for a project not belonging to any of the user's teams. Because the identifier is placed in an unconditional OR branch by ProjectRepository::getQueryBuilderForFormType(), the team access check is skipped and the identifier is accepted.

  3. Payload/execution method. At the vulnerability-class level, this is an insecure direct object reference / authorization bypass via a user-controlled key. The attacker enumerates or guesses project identifiers and supplies them directly in the API request body. No injection payload is required — the API accepts the parameter as designed.

  4. Post-exploitation impact. The malicious project attribution is persisted. The attacker then issues GET /api/timesheets/{id}?full=true to retrieve project and customer metadata that should have been outside their team scope. This enables data exfiltration of customer/project records and integrity corruption of timesheet records.

Impact Assessment

This is an authenticated authorization bypass with a partial confidentiality and integrity impact. An attacker with minimal privileges (edit_own_timesheet) can cross team boundaries, violating the tenant/team separation model Kimai relies on for multi-team deployments. Confidentiality is impacted because project and customer metadata become readable via the full=true timesheet query. Integrity is impacted because the attacker can persist false project attribution. Availability is not directly affected.

The blast radius is limited to data reachable via the timesheet and project/customer metadata APIs, but in organizations where Kimai segregates client data by team, this represents a serious confidentiality breach and potential billing/attribution fraud. CVSS is listed as N/A in the provided data; a representative vector consistent with CWE-639 would be AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N, though this is not an authoritative score.

Detection Guidance

Sigma Rule

title: Kimai Unauthorized Timesheet Project Association (CVE-2026-52820)
id: 8f1c2a04-5282-4c1e-9a7b-kimai52820
status: experimental
description: Detects attempts to assign timesheets to projects outside the user's team authorization scope via the Kimai API.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-52820
author: SOC Team
date: 2026/01/01
logsource:
  product: kimai
  service: api
detection:
  selection_endpoint:
    http.method:
      - POST
      - PATCH
    url.path|contains:
      - '/api/timesheets'
  selection_project:
    request.body|contains:
      - 'project'
  condition: selection_endpoint and selection_project
  falsepositives:
    - Legitimate timesheet edits by authorized users
  level: medium

YARA Rule

rule CVE_2026_52820_Kimai_Timesheet_Team_Bypass
{
    meta:
        description = "Detects HTTP request patterns targeting Kimai timesheet API project identifier abuse"
        author = "SOC Team"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-52820"
        date = "2026-01-01"
    strings:
        $ep1 = "/api/timesheets" ascii wide nocase
        $full = "full=true" ascii wide nocase
    condition:
        $ep1 and $full
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-52820 Kimai Timesheet Project Authorization Bypass Attempt"; flow:established,to_server; http.method; content:"POST"; http.uri; content:"/api/timesheets"; http.request_body; content:"project"; nocase; reference:url,nvd.nist.gov/vuln/detail/CVE-2026-52820; classtype:attempted-user; sid:5282001; rev:1;)

Elastic Detection

sequence by user.name
  [http where http.request.method == "POST" and url.path : "/api/timesheets"]
  [http where http.request.method == "GET" and url.path : "/api/timesheets*" and url.query : "full=true"]

Splunk SPL Query

index=web sourcetype=kimai OR sourcetype=access_combined
| search (uri_path="/api/timesheets" OR uri_path="/api/timesheets/*")
| search (http_method="POST" OR http_method="PATCH" OR http_method="GET")
| search (request_body="*project*" OR uri_query="*full=true*")
| stats count values(http_method) as methods values(uri_path) as paths by src_ip, user
| where count >= 1

Wazuh OSSEC Rule

<group name="kimai,cve-2026-52820,">
  <rule id="528200" level="10">
    <decoded_as>json</decoded_as>
    <field name="url">/api/timesheets</field>
    <regex field="method">POST|PATCH</regex>
    <description>CVE-2026-52820: Possible Kimai timesheet project authorization bypass attempt</description>
    <mitre>
      <id>T1190</id>
    </mitre>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 2/4 (CLAIMED — a single source, OSV, claims the patch; not independently confirmed).

  1. Immediate mitigations.

    • Restrict API access to the /api/timesheets endpoints to trusted networks or authenticated users who genuinely require it.
    • Audit user roles and remove the edit_own_timesheet permission from users who do not need it.
    • Monitor for anomalous project associations and full=true metadata retrieval activity.
  2. Patch / upgrade steps.

    • Upgrade Kimai to version 2.57.0 or later, which introduces the TimesheetTeamAccessValidator that re-validates changed project and activity associations against current team access.
    • Verify the upgrade against the vendor release notes and confirm the validator is active.
  3. Long-term hardening.

    • Enforce server-side authorization checks on all object references (defense against CWE-639 / IDOR).
    • Adopt a deny-by-default team-scoping model for project and customer metadata.
    • Log and alert on cross-team object access attempts.
    • Conduct a review of similar form/query-builder patterns across the application.

References

👁️ SHODAN DORKS (THREAT HUNTING)

What is this? Security researchers use these exact search queries on Shodan.io (a search engine for internet-connected devices) to find vulnerable systems globally. You can copy these dorks to see if your organization's IP space is exposed.

http.title:
◈ SOURCE Analysis & enrichment: valtersit.com/cve/CVE-2026-52820/ · CVE data: NVD/MITRE (public domain) · © 2026 ValtersIT Hub
>_ SYSTEM_CORE: INTEL_ACTIVE
90% TEAM-CURATED // 10% AUTOMATED INGESTION.
ALL PATCH REFERENCES AND VERSION DATA SOURCED FROM NVD + OSV OFFICIAL REGISTRIES.