How should we interpret CVSS severity scores?

CVSS estimates technical severity, but it does not automatically equal business risk. Prioritize using context like internet exposure, asset criticality, known exploitation, and whether compensating controls exist. A Medium CVSS on an exposed production system can be more urgent than a Critical on an isolated non-production host.

Vulnerability Database

Q: What is a Vulnerability (CVE) and why does it matter?

A security vulnerability is a weakness in software, hardware, or configuration that can be exploited to compromise confidentiality, integrity, or availability. Many vulnerabilities are tracked as CVEs (Common Vulnerabilities and Exposures), which provide a standardized identifier so teams can coordinate patching, mitigation, and risk assessment across tools and vendors.

Q: What's the difference between a vulnerability, an exploit, and a zero-day?

A vulnerability is the underlying weakness. An exploit is the method or code used to take advantage of it. A zero-day is a vulnerability that is unknown to the vendor or has no publicly available fix when attackers begin using it. Risk increases sharply when exploitation becomes reliable or widespread.

Q: Why do vulnerabilities keep reappearing in our environment?

Recurring findings usually come from incomplete asset discovery, inconsistent patch management, inherited images, and configuration drift. In modern environments, you also need to watch the software supply chain: dependencies, containers, build pipelines, and third-party services can reintroduce the same weakness even after you patch a single host.

Q: How do we prioritize remediation without burning out the team?

Use a repeatable triage model: focus first on externally exposed assets, high-value systems (identity, VPN, email, production), vulnerabilities with known exploits, and issues that enable remote code execution or privilege escalation. Then enforce patch SLAs and track progress so remediation is steady, not reactive.

Q: How can SynScan help reduce vulnerability risk over time?

SynScan combines attack surface monitoring and continuous security auditing to keep your inventory current, flag high-impact vulnerabilities early, and help you turn raw findings into a practical remediation plan.

361,925

Total vulnerabilities in the database

CVE-2026-52820 — kimai / kimai

Authorization Bypass Through User-Controlled Key

Summary

The Timesheet API PATCH /api/timesheets/{id} and POST /api/timesheets endpoints accept a user-supplied project ID and resolve it through a Symfony EntityType whose query_builder allows the submitted ID to satisfy the access predicate via an unconditional OR branch. As a result, any authenticated user can re-assign their own timesheet to any project in the database — including projects that belong to teams or customers they have no membership in and cannot otherwise see. The user can then read serialized project/customer details via GET /api/timesheets/{id}?full=true, leaking metadata (name, currency, customer hierarchy) that would otherwise be filtered out by the team ACL.

Details

Entry point — only ownership is checked in `src/API/TimesheetController.php:317-355`

#[IsGranted(&#039;edit&#039;, &#039;timesheet&#039;)]
#[Route(methods: [&#039;PATCH&#039;], path: &#039;/{id}&#039;, name: &#039;patch_timesheet&#039;, requirements: [&#039;id&#039; =&gt; &#039;\d+&#039;])]
public function patchAction(Request $request, Timesheet $timesheet): Response
{
    ...
    $form = $this-&gt;createForm(TimesheetApiEditForm::class, $timesheet, [...]);
    $form-&gt;setData($timesheet);
    $form-&gt;submit($request-&gt;request-&gt;all(), false);
    if (false === $form-&gt;isValid()) { ... }
    $this-&gt;service-&gt;saveTimesheet($timesheet);
    ...
}

src/Voter/TimesheetVoter.php:134-142:

if ($subject-&gt;getUser()?-&gt;getId() === $user-&gt;getId()) {
    return $this-&gt;permissionManager-&gt;hasRolePermission($user, $permission . &#039;_own_timesheet&#039;);
}

if (!$this-&gt;permissionManager-&gt;checkTeamAccessTimesheet($subject, $user)) {
    return false;
}

For an own-timesheet, only edit_own_timesheet is required. The voter does not look at the new project being submitted; it only validates the existing record's ownership.

Form replays user-controlled project ID into the access query

src/Form/TimesheetEditForm.php:60-71:

$isNew = true;
if (isset($options[&#039;data&#039;]) &amp;&amp; $options[&#039;data&#039;] instanceof Timesheet) {
    ...
    if (null !== $entry-&gt;getId()) {
        $isNew = false;
    }
    ...
}
$this-&gt;addProject($builder, $isNew, $project, $customer);

src/Form/FormTrait.php:59-100:

$builder-&gt;addEventListener(
    FormEvents::PRE_SUBMIT,
    function (FormEvent $event) use ($builder, $project, $customer, $isNew, $options): void {
        $data = $event-&gt;getData();
        $customer = \array_key_exists(&#039;customer&#039;, $data) &amp;&amp; $data[&#039;customer&#039;] !== &#039;&#039; ? $data[&#039;customer&#039;] : null;
        $project = \array_key_exists(&#039;project&#039;, $data) &amp;&amp; $data[&#039;project&#039;] !== &#039;&#039; ? $data[&#039;project&#039;] : $project;

        $event-&gt;getForm()-&gt;add(&#039;project&#039;, ProjectType::class, array_merge($options, [
            &#039;group_by&#039; =&gt; null,
            &#039;query_builder&#039; =&gt; function (ProjectRepository $repo) use ($builder, $project, $customer, $isNew) {
                $project = \is_string($project) ? (int) $project : $project;
                ...
                if ($isNew &amp;&amp; \is_int($project)) {
                    $project = $repo-&gt;find($project);
                    if ($project !== null) {
                        if (!$project-&gt;getCustomer()-&gt;isVisible()) { ... $project = null; }
                        elseif (!$project-&gt;isVisible())            { $project = null; }
                    }
                }
                ...
                $query = new ProjectFormTypeQuery($project, $customer);
                $query-&gt;setUser($builder-&gt;getOption(&#039;user&#039;));
                $query-&gt;setWithCustomer(true);
                return $repo-&gt;getQueryBuilderForFormType($query);
            },
        ]));
    }
);

Two problems compound:

The visibility re-check on line 73 is gated on $isNew. For PATCH, $isNew = false, so the closure passes the attacker-supplied ID straight through.
Even when $isNew = true (POST), the re-check only validates isVisible() — it does not validate team membership.

The query-builder unconditionally accepts the submitted ID

src/Repository/ProjectRepository.php:150-208:

public function getQueryBuilderForFormType(ProjectFormTypeQuery $query): QueryBuilder
{
    ...
    $mainQuery = $qb-&gt;expr()-&gt;andX();
    $mainQuery-&gt;add($qb-&gt;expr()-&gt;eq(&#039;p.visible&#039;, &#039;:visible&#039;));
    $mainQuery-&gt;add($qb-&gt;expr()-&gt;eq(&#039;c.visible&#039;, &#039;:customer_visible&#039;));
    if (!$query-&gt;isIgnoreDate()) { ... }
    if ($query-&gt;hasCustomers()) { ... }

    $permissions = $this-&gt;getPermissionCriteria($qb, $query-&gt;getUser(), $query-&gt;getTeams());
    if ($permissions-&gt;count() &gt; 0) {
        $mainQuery-&gt;add($permissions);
    }

    $outerQuery = $qb-&gt;expr()-&gt;orX();
    if ($query-&gt;hasProjects()) {
        $outerQuery-&gt;add($qb-&gt;expr()-&gt;in(&#039;p.id&#039;, &#039;:project&#039;));     // &lt;-- unconditional
        $qb-&gt;setParameter(&#039;project&#039;, $query-&gt;getProjects());
    }
    ...
    $outerQuery-&gt;add($mainQuery);
    $qb-&gt;andWhere($outerQuery);
    return $qb;
}

The final WHERE clause is roughly:

WHERE (p.id IN (:project)) OR (p.visible AND c.visible AND &lt;date&gt; AND &lt;team-ACL&gt;)

Because :project is the submitted ID itself, the first branch matches unconditionally, completely bypassing the team-ACL applied by getPermissionCriteria. Symfony's EntityType happily resolves the foreign Project entity, the form passes validation, and the timesheet is persisted with the new project_id.

No downstream validation closes the gap

TimesheetService::saveTimesheet → updateTimesheet (src/Timesheet/TimesheetService.php:154-177) is explicitly documented as not validating.
TimesheetBasicValidator only validates begin/end and project/activity coherence.
TimesheetDeactivatedValidator::validateActivityAndProject (src/Validator/Constraints/TimesheetDeactivatedValidator.php:36-42) returns early for non-running existing timesheets.
No validator anywhere in the timesheet pipeline checks that the project's team membership intersects the acting user's teams.

A PoC was provided, but removed for security reasons.

Impact

Integrity: any authenticated user can attribute their own tracked time to any project ID in the database — including projects belonging to teams/customers they cannot see. This pollutes per-project budgets, billing exports and reports for other teams. There is no in-app warning that records belonging to outsiders have been added.
Confidentiality: by reading the timesheet back via ?full=true, the attacker obtains serialized project and customer details (name, currency, start/end dates, customer hierarchy) which would normally be filtered by the team ACL.
Privilege model: the edit_own_timesheet permission is part of the default ROLE_USER, so the bypass is reachable by every regular user without any administrator action.

The blast radius is bounded by what an attacker can persist (their own timesheet rows) and what the ?full=true serializer exposes — there is no direct ability to modify other teams' existing data.

Solution

The FormTrait was updated to only pass the project forward for new timesheets
A new TimesheetTeamAccessValidatorwas added, which checks if project or activity were changed. If that is the case, the team access permission is checked first

Find out more at https://www.kimai.org/en/security/ghsa-vrr2-g9gh-c3jc

Published: Jul 13, 2026
Updated: Jul 14, 2026
CVE: CVE-2026-52820
GHSA: GHSA-vrr2-g9gh-c3jc
Severity: Medium
Exploit:
CISA KEV:

No technical information available.

CWEs:

CWE-639

OWASP TOP 10:

A5 - Broken Access Control

Affected Software
References

Software	From	Fixed in
kimai / kimai	-	2.57.0

https://github.com/kimai/kimai/security/advisories/GHSA-vrr2-g9gh-c3jc

Deep Security Visibility Without the Complexity

SynScan provides clear, real-time security insights so you can monitor your attack surface, spot risks early, and act fast—without extra complexity.

No setup fees
5-min deployment
Cancel anytime

Book a Demo

Frequently Asked Questions

What is a Vulnerability (CVE) and why does it matter?

A security vulnerability is a weakness in software, hardware, or configuration that can be exploited to compromise confidentiality, integrity, or availability. Many vulnerabilities are tracked as CVEs (Common Vulnerabilities and Exposures), which provide a standardized identifier so teams can coordinate patching, mitigation, and risk assessment across tools and vendors.

CVSS (Common Vulnerability Scoring System) estimates technical severity, but it doesn't automatically equal business risk. Prioritize using context like internet exposure, affected asset criticality, known exploitation (proof-of-concept or in-the-wild), and whether compensating controls exist. A "Medium" CVSS on an exposed, production system can be more urgent than a "Critical" on an isolated, non-production host.

A vulnerability is the underlying weakness. An exploit is the method or code used to take advantage of it. A zero-day is a vulnerability that is unknown to the vendor or has no publicly available fix when attackers begin using it. In practice, risk increases sharply when exploitation becomes reliable or widespread.

Recurring findings usually come from incomplete Asset Discovery, inconsistent patch management, inherited images, and configuration drift. In modern environments, you also need to watch the software supply chain: dependencies, containers, build pipelines, and third-party services can reintroduce the same weakness even after you patch a single host. Unknown or unmanaged assets (often called Shadow IT) are a common reason the same issues resurface.

Use a simple, repeatable triage model: focus first on externally exposed assets, high-value systems (identity, VPN, email, production), vulnerabilities with known exploits, and issues that enable remote code execution or privilege escalation. Then enforce patch SLAs and track progress using consistent metrics so remediation is steady, not reactive.

SynScan combines attack surface monitoring and continuous security auditing to keep your inventory current, flag high-impact vulnerabilities early, and help you turn raw findings into a practical remediation plan.