u/acorn222

I found an RCE requiring user interaction (clicking ok to a popup) which can be triggered by any site and spammed until the user clicks okay.

This RCE is in a security tool and it's been reported through a bounty platform, but with an expected payout of €250, this feels like a waste of time.

The value here is in the blog post which I'm going to write to build credibility for my company, but this just feels wrong that they're trying to get away with such low bounties.

The RCE allows native code execution on the host machine and the platform has downgraded the vuln to a 8.6 as the scope is "unchanged" which it just isn't.

I'm seeing this more and more often where platforms downgrade vulns and payments just get put down to the point where it makes more sense to just not report them as it feels like a waste of time, they've now asked me to provide more information (after downgrading it) for step by step PoC instructions, but I've included the PoC code and a demo video.

I'm OP here, feel free to ask questions!
$250 bounty which I need to follow them up on here, this is not a good payout but they're a smaller company based in Kazakhstan with no official bounty

I built Chrome extension for PGP and I think the cryptographic approach is interesting enough to share here.

The extension uses WebAuthn PRF to derive a master key from a passkey, which encrypts/decrypts the user's PGP private keys and contacts at rest. No passwords if you don't want them, no key files - the passkey handles both authentication and key derivation in one step. As far as I know, nobody else is doing PGP key management this way, especially not on the Chrome Web Store.

PGP operations use SequoiaPGP compiled to WASM with the Zeroize crate. The reason for keeping everything in WASM rather than JS where possible is that JS gives you zero guarantees about when memory gets freed, so private key material can just hang around in the GC. WASM with Zeroize gives explicit control over that.

The extension also requires zero browser permissions. No content scripts, no host permissions, nothing. So even if there was a vulnerability in the extension itself, the blast radius is significantly reduced - there's no ambient authority to abuse. Most other PGP extensions on the store request a bunch of permissions that massively expand their attack surface.

The main thing this doesn't protect against is a fully compromised browser process - if someone has code execution in your browser, it's game over regardless. But short of that, you get convenient PGP encryption/decryption/signing/verification without trusting a server, without exposing keys to garbage collection, and without granting unnecessary permissions.

I should also point out that if you're using the CWS install, you'd have to trust me not to bake in some fetch for the decrypted content - although you can build and install it from the source (which does mean there's no integrity checks iirc). There's no great solution to this, but if anyone has ideas here then let me know!

Why did I build it? Because I wanted it. Most of my PGP usage is encrypting vulnerability reports for coordinated disclosure via email, and I got tired of context-switching to the CLI every time. I looked at what was on the Chrome Web Store and nothing hit the combo of zero permissions, passkey-based key management, open source, and good UX - so I made it.

Video demo & CWS link.

Feedback on the crypto approach is very welcome, especially around the PRF key derivation. Happy to answer questions!