How to Turn a Leaked Git Password Into Root on a Linux Server

Before you continue:_ this write-up combines exposed source-control infrastructure, credential reuse, an authenticated file-upload RCE, and a path traversal bug in a root-owned automation script. Some links in this chain are extremely common in real environments; others exist purely to teach a specific technique. Throughout the text, each critical step is tagged:_

• Real — a pattern you'll actually encounter in pentests and bug bounty engagements.
• Lab — a CTF-specific design choice, rare or unlikely in production.

1. Attack Surface Mapping and Initial Enumeration

nmap -sC -sV -p- -T4 --min-rate 1000 10.129.100.88 -oN nmap_initial.txt

nmap -sC -sV -p- -T4 --min-rate 1000 10.129.100.88 -oN nmap_initial.txt

The important thing at this stage isn't simply collecting ports — it's identifying which services can provide the next piece of the attack chain. Nexus redirects to a base domain that fans out into virtual hosts once fuzzed, exposing a self-hosted Gitea instance and a Krayin CRM application.

The presence of Gitea immediately stands out: source-control platforms frequently leak credentials, .env files, API tokens, internal hostnames, and deployment configuration.

Real: vhost enumeration turning up an internal Git server is one of the most consistent "high-value target" signals in real recon — source control is part of the attack surface, not just a dev convenience.

2. Gitea: Credentials in Commit History

The Gitea instance sits at http://git.nexus.htb. Browsing the public repositories and reviewing commit history — not just the current file tree — reveals a commit where database credentials had been removed in a later commit, but were still visible in the diff of an earlier one.

A Git repository isn't just source code — it's a historical database of how the application was deployed. Credentials accidentally committed and later "removed" don't actually disappear; they persist in every prior commit unless the history itself is rewritten and force-pushed.

Real: this is one of the most common real-world findings in source-control audits. "Removing" a secret in a new commit without rewriting history (git filter-repo, BFG) is a mistake made constantly, even by experienced teams.

3. Krayin CRM — Initial Access (CVE-2026–38526)

The recovered credential authenticates against Krayin CRM v2.2.x, which is vulnerable to:

CVE-2026–38526 — an authenticated arbitrary file upload (CWE-434) in the TinyMCE media-upload endpoint, /admin/tinymce/upload. The endpoint doesn't validate file type or extension and stores the result in a web-accessible directory.

Gitea
  ↓
leaked credentials (commit history)
  ↓
Krayin CRM login
  ↓
authenticated PHP upload via TinyMCE
  ↓
GET request → RCE

Gitea
  ↓
leaked credentials (commit history)
  ↓
Krayin CRM login
  ↓
authenticated PHP upload via TinyMCE
  ↓
GET request → RCE

Exploitation:

1. Authenticate to the CRM with the recovered credentials.
2. Upload a PHP webshell to /admin/tinymce/upload, spoofing Content-Type as an image.
3. The server returns the stored file's path.
4. A GET request to that path executes the payload — shell as www-data.

Real: unrestricted file upload in an admin-only rich-text editor is a classic, still-common finding — CVSS 9.9 here specifically because it only needs low privileges (any authenticated user), not admin.

At this point the machine is compromised, but www-data isn't the objective. The mindset shifts from external enumeration to local privilege escalation / credential discovery.

4. Krayin Configuration Files → SSH Pivot