Submit #932001: Dominik Reichl KeePass 2.61.1 Uncontrolled Memory Allocation

KeePass 2.61.1 – KDBX Header Size Uncontrolled Memory Allocation

KeePass 2.61.1 is affected by uncontrolled memory allocation when parsing a malformed KDBX header field. An attacker-controlled 32-bit field length is passed to BinaryReaderEx.ReadBytes() and subsequently to MemUtil.Read(), where a byte array of the declared size is allocated before the stream is checked for EOF or whether the declared field data is actually available.

A 23-byte malformed KDBX file can declare a 1 GiB (0x40000000) header field while providing only one byte of field data. KeePass consequently attempts to allocate approximately 1 GiB before discovering that the input is truncated. The allocation occurs before the parser detects the short read and subsequently rejects the file as corrupted.

The vulnerable path is reached without successful database authentication. After the normal credential/key-provider dialog is submitted with an arbitrary credential, KeePass proceeds to parse the malformed header and performs the attacker-controlled allocation.

The issue is not that KDBX permits large header fields. The security issue is that the attacker-controlled declared size is used for allocation before the parser establishes that the corresponding data exists, allowing a very small malformed file to induce disproportionate memory consumption and potentially cause memory pressure, allocation failure, process failure or system degradation.

Vendor response: The KeePass developer, Dominik Reichl, was contacted before disclosure and reviewed the issue. He does not consider it a security vulnerability, stating that KDBX permits header fields of approximately 2 GB, that modern desktop systems can generally tolerate such allocations, and that .NET can reclaim the allocated memory.

The researcher disagrees with this assessment. The reported issue is not the existence of a large permitted KDBX field size, but that an attacker-controlled length is passed to the allocator before the parser establishes that the declared data exists. The supplied 23-byte PoC demonstrates this behaviour.

Affected code path:
KdbxFile.Read.cs → ReadHeaderField() → BinaryReaderEx.ReadBytes() → MemUtil.Read() → new byte[nCount]

PoC input: 23 bytes
Declared allocation: 1 GiB (0x40000000)
Actual field data: 1 byte
Result: large allocation occurs before truncated input is detected.

• Source: ⚠️ https://github.com/KSecur1ty/KDBX-Header-Size-Mirage-POC
• User: ksecur1ty (UID 100600)
• Submission: 08/15/2026 18:00 (2 months ago)
• Moderation: 09/27/2026 20:15 (1 month later)
• Status: Duplicate
• VulDB entry: 401648 [KeePass up to 2.61.1 ReadHeaderField allocation of resources]
• Points: 0