GitHub source code leaked: why a Pwdly leak would change nothing for your vault

On May 20, 2026, GitHub confirmed that roughly 3,800 internal repositories were exfiltrated after an employee installed a malicious Visual Studio Code extension. The trojanized extension has been pulled from the Marketplace, the compromised endpoint isolated, and GitHub says its current assessment is that only GitHub-internal code was taken — not customer repositories or production systems.

Cybersecurity Dive frames it as the latest in a long string of supply-chain attacks targeting the developer toolchain itself. Cybernews notes the attackers are claiming the haul includes internal source code, infrastructure scripts and configuration data.

It is a serious incident. It is also a useful moment to ask a question we get a lot:

"What happens if Pwdly's source code leaks?"

Honest answer: nothing happens to your passwords. Here is why.

Yes, Pwdly uses GitHub

We are not going to pretend otherwise. Pwdly's web app, marketing site, infrastructure-as-code and internal tooling live in private GitHub repositories. We use GitHub Actions for CI. We use VS Code. We are exactly the kind of company that should be paying attention to this week's news.

We have already audited our own extension footprint, rotated the credentials that touch our build pipeline, and re-checked branch protection and signed-commit policies as a precaution. Standard hygiene.

But the more interesting question isn't did we get hit (we didn't). It's: what would actually be exposed if we did?

The thought experiment: Pwdly's entire repo gets dumped tomorrow

Imagine the worst-case scenario. An attacker walks away with:

• 100% of Pwdly's source code — frontend, backend, infrastructure
• Our complete list of cryptographic algorithms and parameters
• A raw, unredacted copy of our production database

What can they do with your vault?

Nothing. Not "very little." Not "it would be slow." Nothing.

That sounds like marketing. It isn't. It's a property of how we built the product, and it's worth unpacking.

What's actually in our database

If you opened our production database table for vault items, here is roughly what you'd see for a single password entry:

id:            01HXYZ...
user_id:       a7c4...
ciphertext:    XChaCha20-Poly1305 encrypted blob (base64)
nonce:         192-bit random value
created_at:    2026-05-12T09:14:00Z

That's it. No website name. No username. No notes. No URL. The label "Gmail" is inside the encrypted blob, not next to it. To anyone without the key, every row looks like uniform random noise — which, mathematically, is exactly what good ciphertext should look like.

What's not in our database

This is the part that matters: your encryption key is not stored anywhere on our servers. Not in the database. Not in a backup. Not in a Redis cache. Not in a log file. Not in a config file. Not in a .env. Not in source code.

When you set up Pwdly, we generate a 3-word mnemonic recovery phrase in your browser. That phrase, combined with your master password, is fed through Argon2id — a memory-hard key derivation function — to produce the symmetric key that encrypts and decrypts your vault with XChaCha20-Poly1305. All of that happens on your device, inside the browser tab, using libsodium.

The key exists for a few hundred milliseconds in memory while you're unlocked, then it's gone. We never see it. We can't see it. There is no admin panel, no "support override," no break-glass key escrow. If we wanted to read your data, we would have to ask you for your recovery phrase like anyone else.

This pattern has a name — zero-knowledge architecture — and it's the entire reason we built Pwdly the way we did.

Why source code leaking changes nothing

A common (and reasonable) instinct is: "If hackers know exactly how the encryption works, doesn't that make it easier to break?"

No. And it's worth saying clearly: modern cryptography assumes the attacker has the source code. This is Kerckhoffs's principle, formulated in 1883, and it's the foundation of every credible security system on the planet. The algorithms we use — XChaCha20-Poly1305, Argon2id, Ed25519 — are all public specifications, openly documented, and reviewed by thousands of cryptographers. There is nothing secret about how we encrypt your data. The only secret is the key. And the key lives on your device.

So if our entire repo was published on the front page of GitHub tomorrow, an attacker would learn:

• That we use XChaCha20-Poly1305 (we already say this on our Security page)
• That we use Argon2id for key derivation (also public)
• That our users table has a created_at column (riveting)

What they would not learn is your recovery phrase. And without it, the ciphertext they pulled from the database is, in the words of the field, computationally indistinguishable from random noise.

Compare that to how the rest of the industry would handle it

Not every password manager is built this way. Several breaches in the last few years have proven the difference matters:

• LastPass (2022): Attackers exfiltrated encrypted vault backups. Crucially, some vault metadata — including website URLs — was stored unencrypted, giving attackers a hit list to target with offline password-cracking. Customers with weaker master passwords were demonstrably exposed.
• A hypothetical "server-side decryption" product: If a vendor can decrypt your vault to show it to you in a web dashboard, the keys exist on their servers. A source code + database leak in that model is potentially catastrophic.

Pwdly stores zero plaintext metadata. There is no URL list, no item-name index, no recovery key fragment on our infrastructure. That is a design choice, made specifically so that the answer to "what if you got breached?" is boring.

What we still take seriously

To be very clear: "a leak wouldn't expose your vault" is not a license to be sloppy with the rest of our infrastructure. A source code leak could still:

• Expose internal business logic, roadmap, or unreleased features
• Reveal vulnerabilities in non-cryptographic code (auth flows, billing, etc.)
• Embarrass us

Which is why we treat repo security as a real concern — branch protection, mandatory code review, hardware-key signed commits, scoped CI credentials, regular extension audits, and limited contributor access. The GitHub incident this week is a useful nudge to tighten all of that further, and we are.

But the point of zero-knowledge encryption is precisely this: the security of your passwords should not depend on us being perfect. We will make mistakes. Our vendors will make mistakes. Browsers, operating systems, and developer tools will keep getting compromised. The right response is to design a system where none of those mistakes can hand over your secrets.

TL;DR

• GitHub had ~3,800 internal repos exfiltrated via a malicious VS Code extension. Not customer code.
• Yes, Pwdly uses GitHub. We're taking the usual precautions.
• If Pwdly's source code, algorithms and raw database leaked tomorrow, your passwords would still be safe.
• The reason is simple: your 3-word recovery phrase, which derives your encryption key, is never stored on our servers. Without it, your vault is random noise.

Security shouldn't rely on the absence of breaches. It should assume them — and still hold.

Sources

• GitHub confirms breach of 3,800 repos via malicious VSCode extension — BleepingComputer
• Compromised coding tool helped hackers breach thousands of GitHub repositories — Cybersecurity Dive
• GitHub VS Code extension breach exposes source code — Cybernews
• RFC 8439 — ChaCha20 and Poly1305 for IETF Protocols
• RFC 9106 — Argon2 Memory-Hard Function for Password Hashing
• Notice of recent security incident — LastPass