How severe is GHSA-3m6q-h5gj-7mrw?

No CVSS score has been assigned to GHSA-3m6q-h5gj-7mrw yet. Review the advisory details and affected package list to assess your exposure.

Which packages are affected by GHSA-3m6q-h5gj-7mrw?

GHSA-3m6q-h5gj-7mrw affects the following packages: code.gitea.io/gitea (Go). Ecosystems affected: Go.

How do I fix GHSA-3m6q-h5gj-7mrw?

Update code.gitea.io/gitea to 1.25.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-3m6q-h5gj-7mrw is resolved across your whole dependency graph.

How do I detect GHSA-3m6q-h5gj-7mrw in my Go dependencies?

Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for code.gitea.io/gitea. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.

How do I mitigate GHSA-3m6q-h5gj-7mrw if there is no patch (or I can't update yet)?

If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

How does O3 Security protect against GHSA-3m6q-h5gj-7mrw?

O3 pinpoints whether GHSA-3m6q-h5gj-7mrw is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Is GHSA-3m6q-h5gj-7mrw actively exploited in the wild?

No public exploit code has been indexed for GHSA-3m6q-h5gj-7mrw yet. This does not mean the vulnerability cannot be exploited — absence of public exploits does not imply safety. Apply the recommended fix and use O3 Security to monitor your exposure.

When was GHSA-3m6q-h5gj-7mrw published, and has it been updated?

GHSA-3m6q-h5gj-7mrw was published on April 22, 2026 and was last updated on April 22, 2026. Advisory data evolves as severity scores, affected ranges, and exploit intelligence are revised — always check the latest version of the advisory before acting.

🐹 Go

GHSA-3m6q-h5gj-7mrw

Gitea has insecure default SSH settings

Published

Apr 22, 2026

Updated

Apr 22, 2026

Affected

1 pkg

Patched

1 / 1

Exploits

None indexed

Blast Radius

1 pkg affected

🐹code.gitea.io/gitea

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.

Description

Summary

The built-in SSH server currently advertises a number of key exchange, MAC, and host key algorithms that are considered weak or broken. The defaults should be tightened so a fresh installation passes a baseline SSH security audit out of the box.

Details

Running ssh-audit against a default deployment flags the following as fail:

Key exchange
- ecdh-sha2-nistp256
- ecdh-sha2-nistp384
- ecdh-sha2-nistp521
MAC
- hmac-sha1
Host key
- ssh-rsa

Reproduction

docker run -it --rm positronsecurity/ssh-audit -p 2222 gitea.local

Impact

Default deployments expose algorithms that are known-weak or deprecated upstream. The current workaround requires manually setting several GITEA__server__SSH_SERVER_* variables, which most users will never do.

Workaround

[server]
SSH_SERVER_KEY_EXCHANGES = curve25519-sha256, diffie-hellman-group14-sha256
SSH_SERVER_CIPHERS       = [email protected], aes128-ctr, aes192-ctr, aes256-ctr, [email protected], [email protected]
SSH_SERVER_MACS          = [email protected], hmac-sha2-256

There is no exposed option to restrict host key algorithms, so ssh-rsa remains advertised.

Acceptance criteria

Default SSH_SERVER_KEY_EXCHANGES, SSH_SERVER_CIPHERS, and SSH_SERVER_MACS updated to the secure list above.
New SSH_SERVER_HOST_KEY_ALGORITHMS option added, with a default that excludes ssh-rsa.
Documentation updated to reflect the new defaults.
ssh-audit against a fresh install reports no [fail] entries.

Affected Packages

1 total 1 fixed

Ecosystem	Package	Vulnerable range	Fix
🐹Go	`code.gitea.io/gitea`	all versions	1.25.0

Detection & mitigation playbook

Open-source dependency

Detect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for code.gitea.io/gitea. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update code.gitea.io/gitea to 1.25.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-3m6q-h5gj-7mrw is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-3m6q-h5gj-7mrw is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Tailored to GHSA-3m6q-h5gj-7mrw. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

## Summary The built-in SSH server currently advertises a number of key exchange, MAC, and host key algorithms that are considered weak or broken. The defaults should be tightened so a fresh installation passes a baseline SSH security audit out of the box. ## Details Running `ssh-audit` against a default deployment flags the following as `fail`: - **Key exchange** - `ecdh-sha2-nistp256` - `ecdh-sha2-nistp384` - `ecdh-sha2-nistp521` - **MAC** - `hmac-sha1` - **Host key** - `ssh-rsa` ## Reproduction ```sh docker run -it --rm positronsecurity/ssh-audit -p 2222 gitea.local ``` ##

O3 Security · Impact-Aware SCA

Is GHSA-3m6q-h5gj-7mrw in your dependencies?

O3 detects GHSA-3m6q-h5gj-7mrw across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.

Scan my dependencies How O3 SCA works