The KeePass Extractor Fight: Memory Beats Crypto

Quick Answer — In May 2023, a security researcher published a proof-of-concept KeePass master-password extractor: a rogue DLL planted beside the vault app that siphons the cleartext master password from memory as the user types it. Maintainers classified it “working as designed” — if malware runs on your box, no password manager can save you. The fracas that followed taught the same lesson to a wider audience: memory access is total compromise; endpoint hygiene is the password manager’s real perimeter.

What happened

• The technique: KeePass composes the master password character-by-character in managed memory as keystrokes arrive. A malicious DLL injected into the process can hook those events and rebuild the password in cleartext — no crypto broken, no bug in the classic sense.
• The disclosure flame-war: The researcher filed it as a vulnerability; the maintainer rejected the report with variants of “not a bug — any app’s memory is readable by code already running as the user.” Both were right: technically accurate maintainer, pedagogically valuable researcher.
• The ecosystem echo: Competing “was it a backdoor?” discourse swept forums; the durable takeaway was quieter: every credential store shares this boundary condition, from of browser password managers to enterprise vaults guarded only by process integrity.

The threat model, stated plainly

Timeline

Defensive lessons

• Endpoint compromise is game over — plan the boundary, not the fantasy. The real control-set is upstream: EDR on the host, application allow-listing, DLL-load restrictions per process.
• Credential-material in memory needs a lifecycle. Scrub keystroke buffers, minimize cleartext residency, use OS keystroke encryption where offered; every resident second is attack surface.
• Classify trust boundaries honestly. “Attacker has code on the box” is not a tail risk to wave off — infostealers make it the median enterprise incident. Extractor PoCs simply demo what that median implies.
• MFA the crown jewels separately. A vault unlock and the resources it guards should not share one fallen boundary; hardware-backed keys and step-up auth blunt memory-scraping’s payoff.
• Respect the maintainer’s point — and the researcher’s. “Not a bug” is correct threat-modeling; publishing the PoC was correct awareness-raising. Security teams need both reflexes.

Why it still matters in 2026

The extractor episode remains the cleanest popular explainer of a boundary most users still find counterintuitive: encryption protects data at rest and in transit, never from the machine that legitimately uses it. In 2026, with infostealers industrialized and MFA-fatigue kits matured, credential defense has consolidated around layers the 2023 debate foreshadowed — passkeys pushing secrets into hardware, attested vaults with per-launch integrity checks, and EDR signatures for the exact injector patterns the PoC used. KeePass itself ships hardening guidance in that lineage; the working-as-designed doctrine is now boilerplate across every vault vendor’s documentation. The argument ended; the adversary’s position — get code next to the secret — didn’t move an inch.

The disclosure etiquette question

Beyond the tech, the episode became a referendum on how to disagree in public. The researcher coordinated disclosure, waited, then published with working code; the maintainer responded with technically precise rejections that read as dismissive to lay audiences. The security community’s takeaway hardened into norms now quoted in CVE disputes: state the threat model explicitly, acknowledge mitigations that merely raise cost, and never let “by design” become “by default” — a shrug that teaches readers nothing. Vendors learned the mirror lesson: when you reject a report, publish the reasoning, because the vacuum otherwise fills with “backdoor” headlines that outlive the facts.

Is KeePass unsafe, then?

No — and yes, conditionally. Its file encryption remains sound; the PoC exploited the machine, not the math. The honest read: KeePass inherits the security of whatever host runs it, which is true of every password manager ever shipped. Choose it knowingly: ideal where the threat model is device theft or cloud-account compromise, weakest against active malware on the box.

Why did the maintainer refuse to “fix” it?

Because the proposed boundary is impossible: a process cannot keep secrets from code already executing within its own privileges. Mitigations exist (obfuscating in-memory composition, DLL allow-listing, secure desktop entry), and some were adopted — but each raises cost for the attacker, not an absolute wall. Declining to call it a vulnerability kept the threat model honest instead of marketing a false fix.

Companion piece — the export trap

Readers of this series will recall the KeePass export story from our January 2023 entry: a similar in-memory weakness around plaintext exports. Together the two stories bracket the year’s vault-hardening curriculum: extractors on the way in, exports on the way out. Both answers end identically — the endpoint is the perimeter.

Part of the hmmnm.com security-timeline series — one event per month, 2021–2024, indexed here.

Detection and response playbook

CVE-2023-36684 was not a cryptography failure — KeePass’s encryption remains sound — but a memory-exposure flaw: the master key’s derived bytes transited process memory in a recoverable way, so any malware already running as the user could siphon the vault’s keys without ever crashing or guessing anything. The playbook therefore splits into what you do about the bug, and what you do about the assumption underneath it.

1. Patch, and treat unpatched installs as assumes-breached. Versions before 2.54 leave recoverable key material in memory. The realistic threat model is an infostealer with user-level access — which is precisely what commodity malware already does at scale. Inventory KeePass versions across the fleet (it is often user-installed, invisible to server-centric tooling).
2. Detect the extraction pattern. The proof-of-concept reads process memory of KeePass.exe from another process context — behavior EDR can flag. Strong signals: OpenProcess+ReadProcessMemory sequences targeting password-manager PIDs from unfamiliar parent processes, and any non-debugger attaching to the manager while a vault is unlocked.
3. Engineer for “malware is on the box” instead of against it. The extractor only matters if code execution precedes it. Compensating controls: keep vaults locked except during use, disable or restrict KeePass’s unprotected export paths, and separate secret retrieval from daily-browsing processes — a dedicated VM or dedicated browser profile for vault access breaks the colocation the attack requires.
4. Re-examine the browser-password-manager adjacency. The same argument applies to every secret store readable from userland: browser-stored passwords, SSH agents with forwarding, cloud CLI credential files. The CVE is one instance of a class — userland secrets are readable by userland malware — and defense-in-depth means not keeping long-lived crown jewels in process-readable form at all.
5. For disclosure practitioners: note the etiquette precedent. The researcher published working code against KeePass 2.x after disputed coordinated disclosure. The defensive takeaway is to monitor exploit publication itself — the day a PoC drops, your detection window for the pattern above shrinks from research-luxury to operational-urgent.

The plain-language summary of the whole episode: memory beats crypto, but segmentation beats memory. The vault that matters least is the one an infostealer can reach.

Where this sits in the broader pattern

The KeePass extractor sits in the memory-versus-secrets lineage that includes the LSASS-dumping tradition on Windows, the SSH-agent forwarding abuses long documented for Unix estates, and the modern infostealer epidemic whose entire business model is reading every secret in userland. Nothing about CVE-2023-36684 surprised anyone who had watched Mimikatz evolve; the contribution was precision — a named CVE proving that even the tool whose whole purpose is secret-keeping left the master key readable in process memory.

The ecosystem response is visible in product architecture: password managers moved toward brokered secret access (per-request retrieval rather than vault-wide unlock), OS vendors shipped privileged secret stores that refuse plain process reads, and hardware isolation — TPM-sealed keys, secure enclaves — became the default recommendation for master-key protection. Each shift exists to answer the same question the extractor asked: what stops already-running malware from reading this?

For enterprises, the practical consolidation is a secrets-hygiene program: inventory every secret store reachable from a standard workstation (password managers, browser stores, cloud CLI profiles, SSH keys, service-account caches), assume userland malware reads all of them, and shorten the lifetime of whatever remains. The Genesis Market analysis shows who buys what the stealers find; the combo-list economy piece shows what it is worth. Defense is architectural, not a matter of choosing the right vault brand.

The bottom line. The vault held; the memory did not. Any secret that exists unencrypted in a process your malware can coexist with is a secret on loan, and CVE-2023-36684 simply put a CVE number on the loan terms. Patch the manager, yes — but spend the real effort on the architecture: shorter secret lifetimes, brokered retrieval, separation between vault access and daily-browsing processes, and detection that watches who reads the memory of the password manager. The next extractor will not need a CVE to teach this again.

Frequently Asked Questions

{“@context”:”https://schema.org”,”@type”:”FAQPage”,”mainEntity”:[{“@type”:”Question”,”name”:”What is CVE-2023-36684 in KeePass?”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”A memory-disclosure flaw (fixed in KeePass 2.54) allowing malware running as the same user to extract the master key from KeePass process memory while a vault is unlocked — without breaking the encryption itself.”}},{“@type”:”Question”,”name”:”Does KeePass encryption remain safe?”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”Yes. The vulnerability does not weaken the cryptography; it requires the attacker to already have code execution as the user. Patching and limiting malware exposure are the fixes, not a different cipher.”}},{“@type”:”Question”,”name”:”How can I detect KeePass master-key extraction attempts?”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”Monitor for ReadProcessMemory/OpenProcess calls targeting password-manager processes from unexpected parents — modern EDR platforms can alert on this pattern, especially post-PoC-publication.”}}]}

Related Reading

• What Studying 33 Historic Cyberattacks Taught Me About Defending Systems Today
• Passwordless in 2026: Why Passkeys Are Finally Killing the Password (and How Attackers Are Adapting)
• 2022–2024: Lapsus$, Change Healthcare & the XZ Backdoor
• Authoritative reference: CISA Known Exploited Vulnerabilities

More on this topic

• KeePass Plaintext Export ‘Flaw’: The Trust-Boundary Debate
• Crypto.com’s $34M Lesson: The 2FA Bypass Blueprint
• Solana’s 9,000-Wallet Drain: Who Logged the Seed Phrases?

Published by Hmmnm

Hands-on cybersecurity tutorials, CVE breakdowns, and guided learning paths — written and lab-tested by the Hmmnm team.

Learning Paths · About Hmmnm · Editorial policy