CVE-2026-24058 is a critical authentication bypass (CVSS 9.8) in Soft Serve, the self-hosted Git server. In versions up to 0.11.2, an attacker who knows a victim's public key can impersonate that user, including an admin, over SSH. Version 0.11.3 fixes it and there is no workaround. Upgrade at once.
What's affected
Soft Serve 0.11.2 and below. The advisory says every Soft Serve instance is affected and that 0.11.3 is the patched version. It also states plainly that you need to upgrade, because no workaround exists.
How to check if you're exposed
Find the version of the running server. If you use the container image, check the tag. If you installed a binary or package, check your package manager or the version output of the binary:
docker ps --format "table {{.Names}}\t{{.Image}}"
Then check where the SSH port is reachable from. Public keys are not secret, since they are often published, for example on code hosting sites. The attacker needs to know a victim's public key, not to have the private one.
What to do now
- Upgrade Soft Serve to 0.11.3 or later.
- Restrict SSH access to the server with a firewall, VPN or allowlist until you have upgraded.
- Review the repositories and admin settings for changes you did not make, such as new keys, new users, changed collaborators or altered repository visibility.
- Review the server logs for SSH logins with unusual patterns, such as several key offers before a successful login.
- Check repositories for commits or pushes you cannot explain, and consider verifying the integrity of the main branches from a trusted copy.
Why it matters
The record lists CWE-289, authentication bypass by alternate name. The advisory describes the mechanism at a high level: during the SSH handshake, a client can offer several public keys before it authenticates with one. Soft Serve stored the identity from the offered key in the session context and did not clear it when that attempt failed. The later, valid login by the attacker then ran under the victim's identity.
An authentication flow has stages, and state set in an early stage has to be reset when the stage fails. A Git server holds source code and often deployment keys, so a takeover of an admin account is a supply chain risk and not only a data leak. The record does not list this CVE as known exploited.
Reading the severity score
The record gives a CVSS base score of 9.8, published 2026-01-22. In the vector, the attacker works over the network, needs no account, and the attack is low in complexity. User interaction is not needed. Impact on confidentiality is high, on integrity high and on availability high.
A base score describes the flaw in general, not your risk. Weigh it against how exposed your instance is and what it can reach. The Gold page for the CVE keeps the score, weakness and references together.
Hardening beyond the patch
A Git server is a root of trust for your software supply chain, so a bypass like this is worth a wider review than one upgrade.
First, assume the worst for a moment and check what an administrator could have done. Look at the list of users and their public keys, and remove any you do not recognize. Review repository settings, collaborators and webhooks. Check for deploy keys and tokens stored on the server, and rotate any that were reachable. If the server is used by CI, review the credentials that CI uses to clone and push.
Second, check integrity. Compare the tips of important branches and tags against a clone you trust, such as a developer machine or backup made before the exposure window. Signed commits and tags make this easier, and they are worth turning on for release branches. Look for force pushes and history rewrites in the logs.
Third, reduce exposure. SSH access to a Git server rarely needs to be open to the internet. A VPN, a bastion or a source address allowlist cuts the number of people who can attempt a handshake. Where the server must be public, run an SSH log monitor and alert on repeated key offers and failures from one address.
Fourth, use defense in depth for the repositories themselves. Require code review for merges to protected branches, and keep release signing keys off the Git server. That way a compromised account does not directly become a compromised release.
Fifth, plan your updates. Soft Serve is a small project that moves fast, and the advisory notes there is no workaround. Subscribe to its releases, and pin the version in your deployment so you know what runs. Keep a recent backup of the data directory, and test a restore.
Finally, note the detail that made this bug work: public keys are public. Any design that treats knowing a public key as a secret is fragile, and the fix is correct state handling in the server.
Find it across your own code
To see which of your packages are affected, the free in-browser dependency scan at gold.safeguard.sh/scan takes a manifest and lists known vulnerabilities. Reachability analysis then helps you judge whether your code calls the vulnerable path, so you can order the work.
Quick check
Do I need the victim's private key?
No. The advisory says the attacker offers the victim's public key and then authenticates with their own valid key. That is why the score is so high.
Is there a configuration workaround?
The advisory says there is not. You need to upgrade, and you can limit network reach in the meantime.
Sources
Last reviewed: 19 October 2026.
