Gitea

PoeLLM: a cryptomining botnet that reads its C2 address out of a GitHub poem compromises exposed LiteLLM, Ollama, Gotenberg and Gitea servers and turns them into scanners

Lumen's Black Lotus Labs says PoeLLM has been active since at least April 2026, deploys XMRig and Iron cryptocurrency miners that connect to a Kryptex mining pool, and is deployed through vulnerability exploitation of publicly exposed services, mainly LiteLLM and Ollama and, in the hundreds, the Gotenberg PDF converter and Gitea, with other products such as Ivanti Sentry possibly targeted (Lumen, 2026-10-07). It counts more than 3,400 impacted servers, a figure it raised after first circulating the report (BleepingComputer, 2026-10-07), predominantly in the United States and Western Europe, and assesses that PoeLLM is associated with an Italian-speaking threat actor (Lumen, 2026-10-07).

The command channel is the unusual part: the malware derives its current C2 server from keywords in a poem hosted in a GitHub repository, so the operator rotates servers by editing the poem, which Lumen counts 11 edits of since the first commit on 2026-04-13 (Lumen, 2026-10-07). Several C2 servers were routers with exposed administration pages, which Lumen reads as the operator repurposing compromised routers (Lumen, 2026-10-07). Infected servers become scanners and exploit launchers that sweep ports 3000 and 4000, the primary ports of Gotenberg and LiteLLM, and send a crafted POST that makes the target fetch a payload from the C2; the payload is a single ELF binary that bundles a remote shell, the miners, HTTP and HTTPS scanning and exploit deployment, and beacons back to the C2 (Lumen, 2026-10-07). For LiteLLM, Lumen says the endpoint /mcp-rest/test/connection, which the CVE-2026-42271 command injection references, was likely the exploitation path (Lumen, 2026-10-07), and BleepingComputer adds that Horizon3 showed it can be chained with CVE-2026-48710 for unauthenticated remote code execution (BleepingComputer, 2026-10-07). Lumen met the infrastructure while investigating the Ivanti Sentry flaw CVE-2026-10520, when a compromised Sentry victim contacted a PoeLLM C2 and began scanning for other vulnerable devices; it states no further link between that flaw and the botnet (Lumen, 2026-10-07).

Builds on: CVE-2026-42271, BerriAI LiteLLM: low-privilege command injection to host RCE, added to CISA KEV · CVE-2026-48710 "BadHost", Starlette (FastAPI / vLLM / LiteLLM / MCP SDK): Pre-Auth Auth Bypass… · Three unrelated AI platforms, three intrusions, one pattern: gateways and orchestrators… · CVE-2026-10520 / CVE-2026-10523, Ivanti Sentry: pre-auth OS command injection to root (CVSS…

CVE-2026-60004: Gitea's diffpatch endpoint turns an attacker-supplied patch into a live Git hook, giving command execution as the service account; KEV-listed after miner deployment

CISA added CVE-2026-60004 to the Known Exploited Vulnerabilities catalog on 2026-08-25. The flaw is in services/repository/files/patch.go, the code behind Gitea's diffpatch endpoint, which applies an attacker-controlled patch inside a shared bare temporary clone. The maintainers describe the chain precisely: "submitting the same patch twice creates an add/add collision. Git's three-way fallback checks the indexed path out even though the operation is performed with --cached" (Gitea maintainers, 2026-07-28). In a bare clone the repository root is $GIT_DIR, so a checked-out executable entry whose path matches a Git hook name is not a file sitting next to the hooks directory, it is a hook. Git then invokes it while writing the index, and it runs as the Gitea OS account.

The precondition is the part worth reading twice. The advisory states it plainly: "an attacker with ordinary write access to a repository can execute arbitrary shell commands as the Gitea OS user. With default open registration, an unauthenticated visitor can obtain the required write access by registering an account and creating a repository" (same advisory). Ordinary write access is not a privileged role, it is what every user of a Git forge has by definition, and Gitea's shipped default hands it to anyone who can reach the login page. So on a default-configured instance this is a pre-authentication flaw in every sense that matters operationally, separated from an anonymous visitor only by a registration form. Fixed in Gitea 1.27.1. The advisory carries a working proof-of-concept, which arrived with it.

Exploitation is opportunistic and automated. Help Net Security reports the incident write-up of an operator whose self-hosted instance was compromised: "because the server ran an outdated version of Gitea, with open user registration and no email confirmation or CAPTCHA, an automated scanner was able to register an account, create its own repository, and trigger the exploit chain" (Help Net Security, 2026-08-26). The chain wrote a proof of execution into a Git branch, then pulled a shell loader followed by a miner; the operator was alerted not by security tooling but by the hosting provider flagging sustained CPU. That is a mass-scanning profile against a default configuration, not targeted intrusion, and it means exposure is a function of being reachable rather than being interesting.

The blast radius is broader than the payload suggests. Depending on container isolation and the privileges of the Gitea OS user, exploitation can expose the main configuration file, application and process-environment secrets, database credentials and contents, and OAuth and integration credentials (same reporting). A miner is the noisy outcome; the quiet one is a set of credentials into whatever the forge is wired to, which for a public-sector development estate typically means CI runners, artefact registries and identity providers.

Where the activity surfaces. The exploitation itself looks like ordinary API traffic, so the durable signal is what the service account does immediately afterwards. Watch for the Gitea service account spawning a shell or an interpreter within seconds of a patch or diff API call, on a host whose normal process tree is a Go binary plus git. On the repository side, the artefact is a Git hook whose content arrived through patch application rather than through an administrator action, so an executable object at a hook path in a repository nobody manages is the thing to hunt for. Registration and repository-creation events are the leading indicator: on an instance with real users, a self-registered account creating a single repository and immediately exercising the diff endpoints is not a normal usage pattern.

Triage: the benign lookalike is a legitimate developer using diffpatch to apply a patch, which is what the endpoint is for and which will be the overwhelming majority of hits on that route. Two things separate exploitation from it. First, the same patch applied twice in quick succession, which is the collision the attack requires and which a human working normally has no reason to produce. Second, and more reliably, what happens next: a legitimate patch application ends with a commit, while this one ends with the service account executing something. Alert on the process behaviour, use the endpoint traffic to explain it.

CVE-2026-20896: Gitea's official Docker image trusted the reverse-proxy login header from any source, so where reverse-proxy authentication is enabled anyone can impersonate any user

Gitea 1.26.3 (2026-06-20) fixes a large set of security flaws and 1.26.4 (2026-06-21) adds one more, and Gitea recommends upgrading directly to 1.26.4 (Gitea, 2026-06-21). The critical flaw, CVE-2026-20896 (CVSS 9.8) (NCSC-CH Cyber Security Hub, 2026-07-10), is in the official Docker images, whose app.ini template hard-codes REVERSE_PROXY_TRUSTED_PROXIES = * instead of the documented loopback-only default (GitHub Security Advisory GHSA-f75j-4cw6-rmx4, 2026-06-21). When an administrator enables ENABLE_REVERSE_PROXY_AUTHENTICATION = true to put Gitea behind an authenticating reverse proxy, the image trusts the X-WEBAUTH-USER header from any source IP, so anyone who can reach the container's HTTP port directly can impersonate any user whose login name is known or guessable, with admin accounts the obvious targets (GitHub Security Advisory GHSA-f75j-4cw6-rmx4, 2026-06-21). Binary and self-built deployments that follow app.example.ini keep the loopback-only default and are not affected (GitHub Security Advisory GHSA-f75j-4cw6-rmx4, 2026-06-21). Version 1.26.3 removes the wildcard (The Hacker News, 2026-07-06) and makes reverse-proxy authentication opt-in and admin-configured (Gitea, 2026-06-21).

The same release fixes, among others, CVE-2026-27775, where the pre-receive hook cached the first ref's permission result and let a per-branch maintainer-edit grant escalate to full repository write (Gitea, 2026-06-21), CVE-2026-20779, a TOTP race and replay window across web login, password reset and the X-Gitea-OTP Basic-Auth surface (Gitea, 2026-06-21), and CVE-2026-22874, an incomplete SSRF protection in webhooks and migrations (Gitea, 2026-06-21). Germany's BSI issued WID-SEC-2026-2027 on 2026-06-22 rating the set "hoch" (BSI WID, 2026-06-22 · BSI WID CSAF, 2026-06-22). NCSC-CH set the exploitation status of CVE-2026-20896 to "Actively Exploited, Proof of Concept Available" on 2026-07-10 (NCSC-CH Cyber Security Hub, 2026-07-10), while the Sysdig telemetry behind the public reporting shows a first attempt that had not progressed beyond initial investigation (The Hacker News, 2026-07-06).