GIVE YOUR AGENT THE EVIDENCE

Set up in your agent.

One prompt to get started. Paste it into your coding agent to connect cve.new through MCP and bring vulnerability context into your workflow.

Your agent needs remote MCP support and access to https://cve.new/mcp.

Read the setup guide

GIVE YOUR AGENT THE EVIDENCE

Investigate in your agent.

Turn this advisory into a focused investigation. Ask your agent to check your project’s versions, explain the evidence, and suggest a compatible fix.

Your agent needs remote MCP support and access to https://cve.new/mcp.

Read the setup guide

Check your stack
GHSA-h5fh-7hwr-97mwmedium4.1

Kimai has an arbitrary file read in its invoice PDF renderer (admin)

Impact

Users with the role System-Admin (ROLE_SYSTE_ADMIN) and the permission upload_invoice_template can upload PDF invoice templates, which can call pdfContext.setOption('associated_files', ...) inside the sandboxed Twig render.

Source excerpt · OSV

Affected packages

Start with the recorded fix for your release branch. Check your installed version and test compatibility before upgrading. Fixing this advisory does not rule out other vulnerabilities in the release.

kimai/kimai Packagist
Affected rangeRecorded fix
From 2.32.0 before 2.56Ecosystem versions2.56

Version evidence: OSV · GHSA-h5fh-7hwr-97mw

View original version evidence (26 explicit versions)

Original source description

Summary

Users with the role System-Admin (ROLE_SYSTE_ADMIN) and the permission upload_invoice_template can upload PDF invoice templates, which can call pdfContext.setOption('associated_files', ...) inside the sandboxed Twig render.

This is forwarded to mPDF's SetAssociatedFiles(), whose writer calls file_get_contents($entry['path']) during PDF output and embeds the bytes as a FlateDecode stream in the PDF. Any file readable by the PHP worker is returned to the attacker inside the rendered invoice.

Root cause

  1. src/Twig/SecurityPolicy/StrictPolicy.php:123-128 explicitly whitelists PdfContext::setOption():

    if ($obj instanceof PdfContext) {
        if ($lcm !== 'setoption') { throw ...; }
        return;
    }
    
  2. src/Pdf/MPdfConverter.php keeps associated_files in the pass-through allowlist:

    $allowed = ['mode','format','default_font_size','default_font', ... , 'associated_files','additional_xmp_rdf'];
    

    and then forwards it to mPDF:

    if (array_key_exists('associated_files', $options) && is_array($options['associated_files'])) {
        $associatedFiles = $options['associated_files'];
        unset($options['associated_files']);
    }
    ...
    $mpdf->SetAssociatedFiles($associatedFiles);
    
  3. mPDF 8.3.1 MetadataWriter::writeAssociatedFiles() calls file_get_contents, which respects PHP stream wrappers:

    if (isset($file['path'])) {
        $fileContent = @file_get_contents($file['path']);
    }
    ...
    $filestream = gzcompress($fileContent);
    $this->writer->write('<</Type /EmbeddedFile');
    

The sandbox and the option allowlist were both written defensively (short whitelists, not blacklists), but neither side considered that associated_files is a PDF/A file-embedding feature whose path key is a sink.

Fix

The implemented fix has two aspects:

  1. The PdfContext now works with a strict allow-list, that excludes associated_files
  2. The MPdfConverter now removes any path from the $associatedFiles array, which can still be used by plugins:
        if (\count($associatedFiles) > 0) {
            // remove "path" so mPDF will not use file_get_contents() on local files
            // callers must pre-read and pass the bytes via "content"
            $associatedFiles = array_map(static function ($entry): array {
                if (!\is_array($entry)) {
                    return [];
                }

                if (\array_key_exists('path', $entry)) {
                    unset($entry['path']);
                }

                return $entry;
            }, $associatedFiles);
            $mpdf->SetAssociatedFiles($associatedFiles);
        }

References