CVE-2023-43809: My experience with my first CVE

Not all vulnerabilities are found through brute force.


Everything in this post is my perspective, opinions and experience, and does not represent anyone else but myself. Also, I will be using Markdown URL texts for non-vulnerability-related links, but please, always check what link you’re about to click on or visit, as part of general internet safety practices.

About Soft Serve (my opinions)

Simple but very effective self-hosted Git server (and now local browser!), with an amazing TUI and CLI over SSH.

I selfhost Soft Serve on my home Kubernetes cluster, for private projects.

Vulnerability Info

Soft Serve Public Key Authentication Bypass Vulnerability when Keyboard-Interactive SSH Authentication is Enabled

My tl;dr: if public key needs client-side verification, and allow-keyless is enabled which turns on keyboard-interactive, public key can match an account but bypass (fail) client-side validation and successfully login on Soft Serve servers.

Find out more on the GHSA page or the MITRE page or my GitHub issue on it

Experience with Developers (Good!)

The Charm team have been professional about handling this with minimal friction during the disclosure process, with regular progress updates and swift responses as they confirmed the vulnerability and worked to find the root cause and fix it.


So here comes what I consider the most unexpected way to find a vulnerability ever. I won’t be surprised if you think it’s a fake story, but I know for sure it was real. Else I wouldn’t have got my lazy ass to write a post about it, would I?

I am aboard a public bus, and my destination is only a few stops away, within 10 minutes.

I tapped my Android phone, which has a virtual wallet card registered to the NFC, to board the bus. Found a seat, opened Termux.

“Hmm, what should I do?” Undecided, I fiddle with k9s to look at the list of pods, wondering which app to mess with. “Ah, I got it, I need to reconfigure my Soft Serve after screwing around with making sure the PostgreSQL support was fully working on the latest release.”

“Damn, HelmRelease didn’t update, lemme fix that… okay, good to go.” ssh softserve “Now, need my YubiKey to authenticate Soft Serve’s SSH with my YubiKey’s PGP SSH key…”

“Shit, it’s my stop, doors are about to close!” I literally jump up from my seat with one foot launching me forward, one hand grabbing onto my YubiKey, and one hand holding my Android phone with OpenKeychain prompt open.

And, the moment: taps phone’s NFC card to alight bus, foreground app switches from Termux with OpenKeychain prompt to virtual wallet app, alights and switches back to Termux “Wait… why am I logged in? I don’t remember even plugging the YubiKey in…”

I kill the SSH session, ssh softserve again, and when OpenKeychain prompt came up this time, I intentionally clicked “Cancel”. To my shock, I was logged in again, YubiKey having never been plugged in. This was no accident nor was I seeing things.

Side note: Funny enough, I had filed an issue on the bus ride back home for not being able to change allow-keyless and anon-access settings when PostgreSQL was used, which led to 0.6.1 being released, and opted to properly test and report this vulnerability when I got home. I didn’t know at the time that it would be the very setting that would mitigate this vulnerability if Soft Serve users couldn’t yet update to a patched version of 0.6.2 and above. So if you look at it a certain way, I was basically the reason for all the patch versions of the 0.6.x version family being released. All done from an Android phone. Oops!

Timeline (GMT+8)

12 September 2023: I found the potential vulnerability.

15 September 2023: I reported the vulnerability in a thread on the Charm Discord server with a description and listing the environments that I used to reproduce the vulnerability. Devs acknowledged and stated they would look into it.

16 September 2023: I screen recorded a PoC video using my Android, and reported my further discovery that turning allow-keyless off seemed to mitigate the vulnerability, amongst other details.

17-22 September 2023: Further communications between me and dev to identify the root cause.

27 September 2023: PR with patched code opened and merged.

28 September 2023: I tested that the nightly build with the patch PR merged does fix the issue, and opened the GitHub issue for public transparency.

3 October 2023: v0.6.2 patch version released with verified fix, GitHub Security Advisory (GHSA) filed and I accepted credit. GitHub issue closed as completed.

5 October 2023: CVE-2023-43809 was published.