Loading vulnerability…
Forgejo versions before 13.0.2 improperly handle symbolic-link destinations outside a template repository. An attacker can exploit an out-of-repository symlink destination to write to unintended files and may be able to obtain server shell access. The issue also affects the Forgejo 11 LTS branch before 11.0.7.
Mallory correlates every CVE against your assets, your vendors, and active adversary campaigns. Know which vulnerabilities matter for you, not just which ones are loud.
What it means. What to do now. Patch path, mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
If you can’t patch tonight, do this now.
Patch, then assume compromise.
1 valid exploit after Mallory filtered fakes, detection scripts, and README-only repos (1 hidden).
This repository is a small standalone Python proof-of-concept for CVE-2025-68937 affecting Gitea and Forgejo. It contains three files: a README describing the vulnerability and usage, a single executable exploit script (exploit.py), and a minimal requirements.txt listing requests. The exploit is not part of a larger framework. The exploit automates a multi-step authenticated attack chain against the Gitea/Forgejo REST API and SSH service. It first authenticates to /api/v1/user using attacker-supplied credentials, optionally queries /api/v1/version, then generates two local ed25519 keypairs using ssh-keygen. One key is uploaded to the target account with a comment containing the template variable ${REPO_DESCRIPTION}; the second key is the attacker shell key intended to be injected into the server's git user's authorized_keys file. Per the README and visible code structure, the script then creates a malicious template repository and a child repository. The template repository contains a .gitea/template file and an authorized_keys symlink pointing at the server-side git account's real authorized_keys path, defaulting to /data/git/.ssh/authorized_keys but configurable with --git-home (for example /home/git). When the child repository is generated from the template, the repository description is set to include the attacker-controlled shell public key. Vulnerable template expansion follows the symlink, reads the real authorized_keys file, expands ${REPO_DESCRIPTION} inside the previously uploaded poisoned key comment, and writes the modified content back through the symlink. This results in an unrestricted SSH key being inserted into the git service account's authorized_keys. After triggering the overwrite, the script repeatedly attempts SSH access to git@<target-host> on the configured port (default 22, often 2222 in Docker examples) and runs id to confirm shell access. If successful, it reports the SSH command to use and can optionally execute an arbitrary command via SSH. A cleanup mode removes the created repositories and uploaded SSH keys through the API. Overall capability: authenticated remote code execution as the git service user via SSH key injection, with optional command execution and artifact cleanup. The exploit is operational rather than a mere detector because it performs end-to-end exploitation and delivers shell access, but it uses a fixed attack flow rather than a highly modular framework payload.
Products and vendors Mallory has correlated with this vulnerability. Open in Mallory to drill down to specific CPE configurations and version ranges.
Vendor-confirmed product mapping. Mallory continuously reconciles this list against your asset inventory.
6 sources tracked across advisories, community write-ups, and news. New activity surfaces here as Mallory finds it.
Query your assets running an affected version, and investigate the blast radius.
Every observed campaign linking this CVE to a named adversary.
Malware families riding this exploit, with evidence and IOCs.
YARA, Sigma, Snort, and vendor rules, auto-deployed to your SIEM.
Cross-references every affected SKU, including bundled OEM variants.
Community discussion across Reddit, Mastodon, and other social sources.