Bug Report: KDBX Export Produces Invalid XML, Cannot Open in KeePass or KeePassXC

[silvyyuliana]

Component: KDBX Export (Web Vault / Desktop App)
Severity: Critical — Data export is completely broken for affected users

---

Summary

Keeper's KDBX export feature produces files containing invalid XML control characters — specifically Unicode U+0010 ("Data Link Escape") — making the exported .kdbx file completely unreadable by both KeePass 2.x and KeePassXC. This effectively blocks users from exporting their vault data, including critical file attachments, in the only encrypted export format Keeper offers.

Environment

• Keeper Web Vault / Desktop App (latest version, March 2026)
• Exported file: .kdbx format (~300 MB, containing significant file attachments)
• Tested with: KeePass 2.x (Windows), KeePassXC (Windows)
• OS: Windows

Steps to Reproduce

1. Log into Keeper (Web Vault or Desktop App)
2. Go to Settings → Export → Select KDBX format
3. Set a KeePass master password
4. Export the vault
5. Attempt to open the exported .kdbx file in KeePass 2.x or KeePassXC

Expected Behavior

The exported .kdbx file should open successfully in any standard KeePass-compatible application, with all records, custom fields, and file attachments intact.

Actual Behavior

KeePass 2.x error:

Failed to load the specified file!
'', hexadecimal value 0x10, is an invalid character. Line 2, position 375583.

KeePassXC error:

Error while reading the database: XML error:
Unexpected ''.
Line 2, column 375583

Both applications fail at the exact same position (Line 2, position/column 375583), confirming the issue is in the exported file, not the applications.

Root Cause Analysis

The character U+0010 (Data Link Escape) is a C0 control character that is explicitly forbidden in XML 1.0 documents. Per the W3C XML 1.0 specification, the only permitted characters below U+0020 are:

• U+0009 (Tab)
• U+000A (Line Feed)
• U+000D (Carriage Return)

All other control characters (0x00–0x08, 0x0B–0x0C, 0x0E–0x1F) are invalid. Keeper's KDBX serialization does not sanitize or escape these characters before writing them into the XML payload inside the KDBX container. The offending byte likely originates from a record's Notes field, custom field content, or file attachment metadata.

KeePass 1.x historically had this same problem and resolved it by adding a filter to strip invalid control characters during export.

Impact

• This bug makes the KDBX export feature completely non-functional for affected users
• KDBX is the only encrypted export format Keeper offers — CSV, JSON, and PDF exports are all plaintext
• Users who need to migrate away from Keeper, or whose subscriptions are expiring, cannot export their data in a secure, standard format
• File attachments are only included in KDBX exports (not CSV); users with significant attachment data (mine is ~300 MB) have no viable export path for their files
• Re-exporting produces the same corrupted file every time, since the invalid character lives in the vault data itself
• This is a data portability issue — users are effectively locked in

Community Reports

This issue has been reported/discussed by multiple users on Reddit's r/KeeperSecurity:

• KDBX Export Format Question (March 2025) — Users asking about KDBX export reliability and limitations
• Keeper Password Vault Backup File Format (March 2026) — Users discussing export format reliability
• Trouble Importing Large KDBX File (October 2025) — Related KDBX data loss issues with large files
• Cancelled Keeper and Export File Disappeared (October 2025) — Export reliability concerns

The Stack Overflow community has extensively documented that 0x10 is an invalid XML character: SO #19739043

Workarounds Attempted

Workaround	Result
Re-export from Keeper	Same corrupted file (bad character persists in vault data)
KeePassXC (more lenient parser)	Same failure, different error message
KeePass Repair Mode	Not yet confirmed for this corruption type
Commander CLI (export --format=keepass)	Untested — may use same serialization

Recommended Fix

Keeper's KDBX serializer should strip or escape XML-invalid control characters (U+0000–U+0008, U+000B–U+000C, U+000E–U+001F) from all string fields before writing them into the KDBX XML payload. This is the same approach KeePass 1.x adopted to fix this exact class of bug.

Specifically:

1. Before serializing any string value to the KDBX XML, strip characters in ranges 0x00–0x08, 0x0B–0x0C, 0x0E–0x1F
2. Optionally replace stripped characters with a safe placeholder (empty string or space)
3. Apply this filter to: record titles, usernames, passwords, URLs, notes, custom fields, and attachment metadata

Request

Given that this bug prevents legitimate data export, I respectfully request that Keeper:

1. Fix the KDBX serializer to sanitize invalid XML characters
2. Consider extending subscriptions for affected users until the fix is deployed, so they can export their data properly
3. Provide interim guidance — confirm whether Commander CLI's --format=keepass export is also affected

---

Filed by a Keeper user. Vault contains ~300 MB of data including file attachments. Happy to provide additional diagnostic information or a sanitized sample of the corrupted region upon request.

PDF report version to share outside github (management for example): https://nskha.fra1.cdn.digitaloceanspaces.com/ShareX/2026/03/qGV94h24VA.pdf

[silvyyuliana]

Update: Source Code Analysis Confirms Bug in Commander's Export Path Too

After filing this issue, I inspected Commander's KDBX export source code directly. The bug is confirmed to exist in both the Web Vault export and Commander's --format=keepass export.

---

Commander Source Code Analysis

File: keepercommander/importer/keepass/keepass.py
Class: KeepassExporter (line 256)

Commander uses pykeepass (a Python KeePass library) to build the KDBX file. The export flow is:

1. Opens a template KDBX file (line 291)
2. Iterates through vault records (line 295)
3. Calls kdb.add_entry() with raw, unsanitized field values (line 318):

entry = kdb.add_entry(node, title=r.title or '', username=r.login or '',
                      password=r.password or '', url=r.login_url or '',
                      notes=r.notes or '')

4. Sets custom properties with raw values (line 350):

entry.set_custom_property(title, self.to_keepass_value(BaseExporter.export_field(cf.type, cf.value)))

No control character sanitization occurs at any point in the export pipeline.

The XmlUtils.escape_string() is Insufficient

Commander defines an XmlUtils class (line 36) with an escape_string() method, but it only calls Python's xml.sax.saxutils.escape():

class XmlUtils(object):
    @staticmethod
    def escape_string(plain):
        if not plain:
            return ''
        output = escape(plain)
        return output.replace('\'', ''').replace('\"', '"')

I tested this directly — xml.sax.saxutils.escape() only handles &, <, and >. It does not strip or escape control characters:

>>> from xml.sax.saxutils import escape
>>> escape('Hello\x10World')
'Hello\x10World'   # U+0010 passes through untouched

Additionally, escape_string() is never called during the export process anyway — KeepassExporter.do_export() does not reference it. The raw vault values go directly into pykeepass, which writes them into the KDBX XML payload without any validation.

The pykeepass Library Also Doesn't Sanitize

pykeepass uses lxml under the hood. While lxml is stricter than some XML parsers, the data flows through its API without character validation at the point of entry insertion. The invalid character only surfaces when another application (KeePass, KeePassXC) tries to parse the resulting XML.

---

Updated Workarounds Table

Workaround	Result
Re-export from Keeper Web Vault	Same corrupted file (bad character persists in vault data)
KeePassXC (more lenient parser)	Same failure, different error message
KeePass Repair Mode	Not yet confirmed for this corruption type
Commander CLI (export --format=keepass)	Confirmed affected — same unsanitized code path (source code verified)
Commander CLI (export --format=json --zip)	Potential workaround — JSON export bypasses XML serialization entirely, --zip bundles attachments

---

Suggested Fix (Specific to Commander)

In keepercommander/importer/keepass/keepass.py, add a sanitization function and apply it before writing any string field:

import re

_INVALID_XML_CHARS = re.compile(
    '[\x00-\x08\x0b\x0c\x0e-\x1f\x7f-\x84\x86-\x9f'
    '\ud800-\udfff\ufdd0-\ufddf\ufffe\uffff]'
)

@staticmethod
def sanitize_xml_string(value):
    """Strip characters that are invalid in XML 1.0."""
    if not value:
        return value
    return _INVALID_XML_CHARS.sub('', str(value))

Then wrap the field values in do_export():

entry = kdb.add_entry(
    node,
    title=self.sanitize_xml_string(r.title) or '',
    username=self.sanitize_xml_string(r.login) or '',
    password=self.sanitize_xml_string(r.password) or '',
    url=self.sanitize_xml_string(r.login_url) or '',
    notes=self.sanitize_xml_string(r.notes) or ''
)

This is a minimal, non-breaking change that aligns with how KeePass 1.x resolved the same issue.

Note: The Web Vault's KDBX export (JavaScript/TypeScript, closed-source) will need a parallel fix — the same sanitization logic should be applied before any string value is written into the KDBX XML payload.

[aaunario-keeper]

both clients should now have this fixed upon next release

[aaunario-keeper]

Hi, It looks like that fix won't be available in Web Vault until 17.7.0 (next release after currently scheduled release), as that product takes a bit longer to go through testing and approval for new features/fixes, but should be available in Commander sooner (if not already there). Please try that route for now instead, and if that doesn't include this specific fix, wait for the next release which should come out at the end of week at the very latest.

…

On Tue, Apr 7, 2026 at 5:16 AM silvy yuliana ***@***.***> wrote: *silvyyuliana* left a comment (Keeper-Security/Commander#1913) <#1913 (comment)> Hey @aaunario-keeper <https://github.com/aaunario-keeper>, I tried to use the web right now: image.png (view on web) <https://github.com/user-attachments/assets/da764f63-c46c-4fec-adcf-8a5b688dd661> On the first try, the output was 203 KB (original 230 MB). On the second try, the output is correct (230 MB). The bot shows an error in both cases: Error while reading the database: XML error: Unexpected ''. Line 2, column 394977 Either the update isn’t delivered to the web version yet, or there are more characters unescaped. — Reply to this email directly, view it on GitHub <#1913 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AZDPG4LDZL2DPV3QONDVZLD4UTIQNAVCNFSM6AAAAACXH63SDGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DCOJYGI2DKMJZGU> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- Ayrris Aunario | Senior Software Engineer Mobile 773.986.1194 ** This email is confidential and is intended for the recipient(s) addressed herein **