CVE-2026-48827: Apache MINA SSHD sshd-git Path Traversal Vulnerability (CVSS 7.1)

Technical summary

CVE-2026-48827 is a path traversal flaw (CWE-22) in the sshd-git bundle of Apache MINA SSHD. The git-upload-pack, git-receive-pack, and related git command handlers fail to properly validate and sanitize paths supplied by authenticated SSH users. This permits directory traversal attacks using standard path traversal sequences (e.g., '../') to navigate outside the configured repository root and interact with arbitrary git repositories on the filesystem. The vulnerability requires valid SSH authentication, limiting the attack surface to authenticated sessions. The CVSS 3.1 score of 7.1 (HIGH) reflects high confidentiality impact (read access to unauthorized repositories) and low integrity impact (potential modification of repositories outside intended scope), with no availability impact.

Business impact

Organizations deploying Apache MINA SSHD with the sshd-git module as a git server face exposure of sensitive repositories and potential unauthorized modification of git history or code. Multi-tenant deployments are particularly at risk: an authenticated user in one project or team could access or alter repositories belonging to other teams. For development environments hosting proprietary source code, intellectual property exposure is a significant concern. The integrity risk is particularly acute in CI/CD pipelines where a compromised or malicious authenticated user could inject code into unintended repositories. Remediation is straightforward (upgrade), making this a high-priority patch for affected deployments.

Affected systems

Any application that explicitly imports and uses the org.apache.sshd:sshd-git artifact from Apache MINA SSHD is affected. Vulnerable versions include MINA SSHD 2.17.x and earlier, and pre-release versions 3.0.0-M1 through 3.0.0-M3. Applications using Apache MINA SSHD for SSH functionality but not leveraging the sshd-git module are not affected by this vulnerability. Verify your application's dependencies (Maven pom.xml, Gradle build files, etc.) to confirm sshd-git usage.

Exploitability

Exploitation requires valid SSH credentials and therefore cannot be executed by unauthenticated external attackers. However, the barrier is modest: any user with legitimate SSH access to the git server can exploit the vulnerability. The attack is straightforward—no complex payload or race condition required—making it a practical threat in environments where SSH access is broadly provisioned or where compromised SSH keys exist. The lack of active exploitation in public KEV data suggests this vulnerability has not yet been weaponized at scale, but the simplicity of the attack vector means exploitation could accelerate rapidly once awareness increases.

Remediation

Upgrade Apache MINA SSHD to version 2.18.0 or later for the 2.x branch. For organizations using the 3.0.0 pre-release milestones, upgrade to 3.0.0-M4 or later. Organizations on older 2.x versions should prioritize this update. Beyond patching, Apache's vendor advisory emphasizes that a robust git server should not rely solely on filesystem permissions and directory structure—implement additional access controls and authorization logic within the application to validate that authenticated users can only access repositories they are entitled to access. This defense-in-depth approach mitigates both this vulnerability and similar authorization bypasses.

Patch guidance

1. Audit your application's dependency tree to confirm use of sshd-git (e.g., run 'mvn dependency:tree' and search for 'sshd-git'). 2. If using the 2.x branch, upgrade to Apache MINA SSHD 2.18.0 or later. If on pre-release 3.0.0, upgrade to 3.0.0-M4 or later. 3. Recompile and test the patched application in a staging environment, paying particular attention to git operations (clone, push, pull, fetch) to confirm backward compatibility. 4. Deploy the patched version to production and monitor for SSH authentication and git operation anomalies. 5. Review and strengthen repository access control policies independent of the patch—implement per-repository authorization checks within your application logic.

Detection guidance

Monitor SSH access logs for authenticated users attempting path traversal patterns (sequences containing '/../', '..\') in git command arguments or repository path specifications. Look for git-upload-pack or git-receive-pack operations targeting paths outside the configured repository root. Correlation of SSH access logs with filesystem audit logs can reveal unauthorized repository access. If your git server exposes operational metrics, track any spike in 'repository not found' errors or access denials, which may indicate reconnaissance attempts. Implement log aggregation and alerting rules to flag SSH sessions that attempt multiple failed git operations in rapid succession, a sign of directory traversal probing.

Why prioritize this

This vulnerability should receive HIGH priority patching attention. Although exploitation requires SSH authentication (reducing external risk), the impact is significant in multi-tenant or restricted-access environments. The ease of exploitation once authenticated means that insider threats or users with compromised credentials can quickly exfiltrate or sabotage repositories. The availability of a simple, low-risk patch (upgrade to 2.18.0 or 3.0.0-M4) and the HIGH CVSS score both argue for rapid deployment. Organizations should prioritize this in their monthly patching cycle, ideally within 30 days of confirming sshd-git usage.

Risk score, explained

The CVSS 3.1 score of 7.1 reflects: (1) Network-accessible attack vector—the vulnerability is reachable over SSH from any network where SSHD listens; (2) Low attack complexity—no special conditions or timing required; (3) Low privilege requirement—any authenticated SSH user can exploit this, and SSH key provisioning is often broad in development environments; (4) High confidentiality impact—unauthorized read access to sensitive repositories is likely; (5) Low integrity impact—the vulnerability permits modification but is not the primary concern; (6) No availability impact—the service remains operational. The HIGH severity classification is appropriate for a confidentiality-focused vulnerability affecting code repositories, where unauthorized access often precedes data theft or supply chain compromise.

Frequently asked questions