Quick Answer — In January 2023, a proof-of-concept for CVE-2023-24055 reignited an old argument: an attacker who can modify a KeePass 2.x configuration file can plant a trigger that silently exports the whole vault in plaintext the next time the user unlocks it. The maintainer’s initial response — that this is working-as-designed, since anyone with local write access can already steal passwords other ways — split the community. The lesson: configuration files are trust roots, and “the attacker is already on the box” is a threat-model boundary every product team must draw deliberately, not by accident.
What the PoC actually did
- The target: KeePass 2.x (before 2.54) on Windows — the open-source password manager whose XML config (KeePass.config.xml) supports powerful automation via triggers: events, conditions, and actions executed by the app itself.
- The attack: Modify the user’s config so that on the next successful database unlock, a trigger fires that exports every entry — passwords included — to a plaintext file (TXT/CSV/HTML/XML; any format the export engine supports) at a path the attacker can read.
- Activation: The user unlocks normally, sees nothing unusual, and keeps using the app. The export happens inside the legitimate process, after correct master-password entry — so the vault’s encryption never “fails”; the plaintext simply walks out through a sanctioned feature.
- The prerequisite: attacker already has the ability to write files in the user’s context — malware on the endpoint, a shared machine, or any foothold short of full code execution.
Why “vulnerability or not” was the whole story
| Position | Argument |
|---|---|
| “It’s a flaw” camp | A user expectation exists: unlocking is required before secrets leave the vault. Silent config-driven export violates it; requiring write access isn’t the same as requiring the master password. |
| “Working as designed” camp | Triggers are a documented feature; an attacker with file-write can equally install a keylogger, dump process memory, or swap the executable. The OS sandbox is the boundary, not the app. |
| Maintainer’s stance (initial) | Rejected the report as a non-vulnerability; the config is as trusted as KeePass.exe itself — tampering with program files is outside the product’s threat model. |
| Maintainer’s follow-through | KeePass 2.54 (Jan 2023) shipped transparency measures so config-defined triggers and export actions become visible to the user — an accountability fix rather than a “fix.” |
| Bystanders | KeePassXC noted it was unaffected (no trigger system); security writers used the episode to teach trust-boundary analysis. |
The real lesson: config files are code
The debate obscures a cleaner takeaway for defenders. An application’s configuration is executed state: declarative code the product runs without question. Trigger autostart, export actions, plugin loading, update URLs — all of it is capability. Once you accept that, the KeePass question stops being “is this a CVE?” and becomes “what integrity controls guard the config?” Enterprises running KeePass at scale have a real answer already in the box: enforced configuration — an admin-owned global config file that users cannot override, which can lock triggers off entirely. On multi-user machines, ACLs on the profile directory, application allowlisting, and tamper monitoring do the rest. The attack’s prerequisite (attacker file-write in your user context) is the same prerequisite as a dozen worse attacks — which is exactly why endpoint hygiene, not CVE-label debates, decides the outcome.
Timeline
| Date | Event |
|---|---|
| 2023-01 (early) | Proof-of-concept published (GitHub) demonstrating plaintext export via KeePass 2.x trigger modification |
| 2023-01-11 → 13 | CVE-2023-24055 assigned; security press coverage; maintainer’s “not a vulnerability” response circulates; debate peaks |
| 2023-01 (later) | KeePass 2.54 releases trigger/export visibility changes; guidance documents enforced configuration for lockdown |
| 2023 H1 | The episode enters the canon of trust-boundary case studies alongside browser-password-manager and memory-scraping debates |
Hardening guidance that survives either side of the debate
- Adopt enforced configuration. Admin-controlled KeePass config disables user-defined triggers and unattended export actions — the clean enterprise fix.
- ACL and monitor the profile. Tamper alerts on config files catch trigger planting before the next unlock does the exfiltration for the attacker.
- Treat “attacker on endpoint” as your planning assumption. If that’s true in your env, memory scrapers and keyloggers dominate the KeePass question; invest in EDR, allowlisting, and privileged-access hygiene.
- Use dedicated machines for vault access. Administrators opening crown-jewel vaults on general-purpose workstations convert every toolbar bug into vault risk.
- Check your other apps for trigger-like config. Automation hooks, update endpoints, and plugin paths in everyday software have the same shape — audit them like attack surface.
Why it still matters in 2026
The KeePass export debate aged well because its underlying question — where does the product’s trust boundary end and the OS’s begin? — recurs yearly: clipboard managers, browser autofill, token brokers, AI-agent config files, and IDE settings have each re-run the same argument. The industry’s maturing answer is structural: integrity protections for config (signed configs, admin enforcement, change visibility) rather than semantic fights over the word “vulnerability.” In 2026’s agentic-tooling wave, where automation triggers read richer secrets than any password manager ever held, the case remains the one to cite: declare your trust roots, protect them explicitly, and never let a sanctioned feature become a silent exfiltration path.
Was KeePass actually “hacked”?
No vaults were breached in the wild through this mechanism as far as public reporting shows. What existed was a proof-of-concept demonstrating that config tampering could turn a feature into an exfiltration path on machines where the attacker already had a foothold. Headlines reading “KeePass passwords can be stolen in plaintext” were technically accurate and practically misleading without the prerequisite — a recurring pattern in security coverage worth calibrating.
What did version 2.54 change?
Per the maintainer’s release notes, 2.5x-line updates increased visibility of trigger and export behavior defined outside the app’s UI, so users can notice planted automation instead of trusting silence. It deliberately did not remove triggers, which remain a core enterprise automation feature — the fix target was detection, not capability removal.
Does this apply to KeePassXC or Bitwarden-style managers?
KeePassXC, which shares the database format but not the .NET trigger engine, was reported unaffected at the time. Cloud-sync managers face an analogous-but-different question: server-side settings and client auto-update paths play the config-integrity role there. The universal check: enumerate every file or setting your password manager executes without asking, and give those artifacts master-password-grade protection.
Part of the hmmnm.com security-timeline series — one event per month, 2021–2024, indexed here.
