gitea

Gitea: disponibili PoC per lo sfruttamento di nuove vulnerabilità Alert AL07/260814/CSIRT-ITA Sintesi Disponibili Proof of Concept (PoC) per 8 nuove vulnerabilità presenti in Gitea Open Source Git Server, nota piattaforma open source utilizzata per l'hosting e la gestione di repository Git, la collaborazione sul codice sorgente, la distribuzione di pacchetti software e l'automazione di workflow di sviluppo tramite funzionalità CI/CD integrate. Tipologia Authentication Bypass Tampering Denial of Service Information Disclosure Security Restrictions Bypass Descrizione e potenziali impatti Sono stati recentemente resi pubblici diversi Proof of Concept (PoC) relativi a 8 nuove vulnerabilità che interessano Gitea Open Source Git Server. Di seguito sono riportati i dettagli: CVE-2026-42931: la vulnerabilità interessa l'endpoint NPM Package Tag e deriva dall'elaborazione non limitata del corpo delle richieste HTTP. Un eventuale sfruttamento potrebbe consentire ad un utente malintenzionato autenticato, tramite l'invio di richieste HTTP opportunamente predisposte, di compromettere la disponibilità del servizio sui sistemi interessati. CVE-2026-59763: la vulnerabilità interessa la gestione dei pacchetti Arch Linux e deriva dall'assenza di adeguati limiti sul numero e sulla dimensione cumulativa dei metadata estratti dagli archivi caricati. Un attaccante potrebbe caricare archivi .pkg.tar.gz opportunamente predisposti in grado di provocare un significativo consumo di risorse elaborative e di storage, con possibili impatti sulla disponibilità del servizio. CVE-2026-58511: la vulnerabilità interessa la gestione dei webhook e può consentire l'esposizione delle credenziali associate agli header di autorizzazione. A causa della restituzione in chiaro dei valori precedentemente decifrati dall'applicazione, un amministratore di repository potrebbe visualizzare token Bearer, credenziali Basic Authentication o API Key configurati da altri amministratori, ottenendo l'accesso a credenziali e informazioni riservate potenzialmente utilizzabili per compromettere sistemi o servizi terzi integrati. CVE-2026-58510: la vulnerabilità interessa la gestione dei watcher e deriva da meccanismi di sicurezza non adeguati durante la transizione da repository pubblico a privato tramite API REST. I record di sottoscrizione possono persistere anche dopo il cambio di visibilità, consentendo ad utenti non autorizzati di continuare ad accedere ad informazioni sensibili sui repository interessati. CVE-2026-56755: la vulnerabilità interessa il parser dei pacchetti Debian e deriva dalla combinazione di una decompressione non limitata dei file control.tar.* e dall'utilizzo di operazioni a complessità quadratica durante l'elaborazione dei metadata. Un attaccante con accesso al package registry potrebbe caricare pacchetti .deb opportunamente predisposti che, a fronte di dimensioni contenute, si espandono fino a occupare ingenti quantità di memoria e risorse CPU fino alla possibile compromissione della disponibilità del servizio. CVE-2026-57897: la vulnerabilità interessa gli endpoint organizzativi di Gitea Actions e deriva da meccanismi di controllo non adeguati delle ACL a livello di repository durante l'enumerazione di workflow e job. Un membro dell'organizzazione malintenzionato potrebbe ottenere informazioni relative a esecuzioni Actions appartenenti a repository privati per i quali non dispone delle necessarie autorizzazioni, determinando l'accesso non autorizzato a informazioni relative a workflow, job e attività CI/CD appartenenti a repository privati dell'organizzazione. CVE-2026-56657: la vulnerabilità interessa il meccanismo di importazione delle chiavi SSH in formato RFC4716 e deriva da controlli non adeguati durante la normalizzazione delle chiavi. Un utente autenticato malintenzionato attraverso il caricamento di chiavi SSH opportunamente predisposte, potrebbe compromettere la disponibilità del servizio sui sistemi interessati. CVE-2026-24791: la vulnerabilità interessa la gestione dei token e delle autorizzazioni OAuth configurati con restrizioni "public-only". A causa di controlli non adeguati sui percorsi /api/v1/user/*, potrebbe consentire ad un utente autenticato di accedere a informazioni e funzionalità riservate normalmente non consentite dal livello di autorizzazione assegnato, permettendo l'elusione delle restrizioni previste e l'accesso non autorizzato a risorse private della piattaforma. Prodotti e/o versioni affette Gitea Open Source Git Server, versioni precedenti alla 1.27.0 Azioni di mitigazione Ove non provveduto, si raccomanda di aggiornare tempestivamente i prodotti vulnerabili all’ultima versione disponibile.

An unauthenticated attacker can read any file the service account can access on Gitea, the self-hosted Git platform, in versions 1.22.1 through 1.27.0. No login, no repository write access. A public repository and crafted Org-mode markup are enough. The flaw is fixed in Gitea 1.27.1. The file-read flaw is tracked as CVE-2026-59774, rated Critical with a CVSS score of 9.8, and received its formal advisory on August 2. Gitea 1.27.1 also patches CVE-2026-60004, a separate remote code execution bug covered in a prior THN report. Gitea said Cloud instances would be upgraded automatically during the release maintenance window. Self-hosted administrators should move to 1.27.1 immediately. The file-read bug is not direct one-request remote code execution. Gitea says it can become command execution if an attacker reads app.ini, extracts INTERNAL_TOKEN, injects a Git hook through the internal logger, and triggers that hook during an anonymous clone. That chain is described in Gitea's advisory; The Hacker News found no independently published exploit demonstrating it. Upgrading is necessary but may not be sufficient after suspected exposure. If logs show the markup endpoint was reached on an affected build, treat credentials readable by the Gitea service account as exposed and rotate the internal token, OAuth material, JWT signing material, and database credentials before considering the instance clean. No badge required The file-read path runs through Gitea's markup rendering endpoint, POST /{owner}/{repo}/markup. The route allows optional sign-in, resolves the repository, and checks reader access. An anonymous request clears that check against any public repository with its code unit enabled. That precondition limits the unauthenticated exposure: an instance with no public repositories has no anonymous attack path through this endpoint. The break is in Gitea's Org-mode renderer. Gitea 1.27.0 initialized go-org with org.New() and did not replace the library's default ReadFile callback. In go-org 1.9.1, that callback is ioutil.ReadFile. Org-mode's #+INCLUDE directive accepts absolute paths and passes them to the callback. An attacker submits Org-mode markup, selects Mode: file, and receives files the service account can read. The fix landed in PR #38642 and was backported in PR #38645. Gitea now overrides ReadFile so an Org-mode include path is returned as plain rendered content instead of being resolved from the server filesystem. The patch added a regression test for include-path rendering. CVE-2026-59774 was found by XBOW Security, an autonomous offensive security system, and triaged by Guido Leo. Shai Rod, known online as NightRang3r, independently reported the same issue. What administrators should check Gitea did not publish formal detection guidance in the advisory. Review anonymous POST requests to /{owner}/{repo}/markup, especially requests selecting Org-mode rendering or submitting absolute filesystem paths. If the advisory's escalation path was attempted, check repository hook directories for unexpected executable files. Gitea's advisory reports no exploitation in the wild, and as of August 5, 2026, CVE-2026-59774 had not appeared on CISA's Known Exploited Vulnerabilities catalog. The file-read primitive was publicly previewed before its formal advisory, according to a prior THN report. The token-to-hook command-execution chain remains single-sourced to Gitea's advisory. The flaw follows a dense stretch of Gitea security work. In June, Gitea patched a critical reverse-proxy authentication bypass in Docker images, CVE-2026-20896, that threat actors were observed probing 13 days after disclosure. In May, a container-registry access-control flaw, CVE-2026-27771, was estimated to affect more than 30,000 deployments across over 30 countries.

Gitea, the self-hosted Git platform, has patched a critical remote code execution vulnerability. A user with ordinary repository write access can turn attacker-controlled patch content into a live Git hook and run shell commands as the Gitea service account. Tracked as CVE-2026-60004 (CVSS score: 9.8), the flaw affects Gitea versions 1.17 and later before 1.27.1 and is fixed in 1.27.1. The vulnerable API call requires authentication and repository write permission. But Gitea enables registration by default, so an outside visitor can create a normal account and repository on an unchanged installation, then exploit the bug without pre-existing credentials. Upgrading to 1.27.1 is the fix. Gitea said on July 27 that Gitea Cloud instances would be upgraded automatically. Gitea's July 28 advisory does not say the flaw has been exploited in the wild, but it includes public proof-of-concept (PoC) code. Disabling open registration can remove the public account-creation path while the update is deployed, but it does not fix the flaw or protect against existing users with repository write access. The flaw was reported by security researcher Shai Rod, who goes by NightRang3r. Gitea credits NightRang3r as the reporter in its advisory. Gitea's affected route invokes reqToken(), which rejects requests without a signed-in user. The no-prior-credentials path comes from the project's default configuration, which leaves registration open, requires neither email nor manual approval, does not mark new users as restricted, and imposes no default repository-creation limit. The bug sits in the POST /api/v1/repos/{owner}/{repo}/diffpatch endpoint. According to Gitea's security advisory, the endpoint applies a supplied patch inside a shared bare temporary clone. Vulnerable builds invoke git apply with --index, --recount, --cached, and --binary, adding the -3 three-way fallback option when the server runs Git 2.32 or later. An attacker submits the same patch twice to create an add/add collision. The three-way fallback then checks the indexed path out even though the operation uses --cached. Because the temporary clone is bare, its root is $GIT_DIR. An executable file placed at hooks/post-index-change therefore lands in Git's hook directory and becomes active. Git runs it while updating the index. The PoC signs in with a normal account, creates an initialized private repository, sends the malicious patch twice, and retrieves the command output. It needs no outbound callback. The hook stores the output in Git objects, creates a branch containing the result, and lets the attacker fetch it over authenticated smart HTTP. As of July 29, 2026, none of the cited primary sources reports whether the flaw was exploited before or after version 1.27.1 became available. Successful exploitation gives the attacker the privileges of the Gitea operating-system account. Depending on how the instance is isolated, Gitea said that could expose application and environment secrets, mounted repositories, database credentials and contents, OAuth credentials, and reachable internal services. Exploitation still requires repository write access, Git 2.32 or later, an enabled diffpatch route, and a writable, executable temporary filesystem. Default registration lets an outsider obtain the required write access on an unchanged installation. The fix is easy to miss in the changelog. Gitea changed the temporary clone from bare to non-bare. The code comment explicitly warns that Git commands using --index may operate on the working tree. The change was merged and backported on July 26, 2026. Version 1.27.1 shipped on July 27, and the security advisory followed on July 28. The release notes listed the change under MISC as "refactor: git patch apply," not under SECURITY. Rod had previewed the RCE alongside a separate file-inclusion issue, with a PoC retrieving /etc/passwd from a Gitea 1.27.0 host. That issue appears to correspond to a separate change included in 1.27.1 that altered Gitea's Org-mode renderer so #+INCLUDE paths are returned as plain text instead of being read from the server's filesystem. Gitea has not published a separate advisory or CVE for the file-inclusion issue.

Hackers are actively exploiting a critical vulnerability in the official Docker image for the Gitea self-hosted Git service that allows attackers to impersonate any user, including administrators. The security flaw is an authentication bypass vulnerability, tracked as CVE-2026-20896, that affects deployments using the default configuration, where reverse proxy authentication headers such as X-WEBAUTH-USER are enabled. Michael Clark, leading security researcher at Sysdig, confirmed that exploitation of the flaw started less than two weeks before the vulnerability was publicly disclosed. Currently, there are around 6,200 Gitea instances exposed on the public web, although it is unclear how many of them are vulnerable. “Gitea's official Docker image ships REVERSE_PROXY_TRUSTED_PROXIES=*. With reverse-proxy authentication enabled, Gitea then trusts the X-WEBAUTH-USER header from any source IP so an unauthenticated internet client becomes whoever it claims to be,” Clark warned. “No password. No token. One header. Sysdig sensors caught the first in-the-wild hit 13 days after the advisory, a VPN-exit scanner that grabbed access.” Gitea is an open-source self-hosted alternative to GitHub and GitLab, used to store source code, manage pull requests, collaborate, deploy, and perform CI/CD operations. Gitea's official Docker image configured reverse-proxy authentication to trust identity headers from any client IP address rather than only from trusted reverse proxies, allowing unauthenticated attackers to impersonate arbitrary users. The CVE-2026-20896 critical bug affects the official Gitea Docker images up to and including version 1.26.2 in the default configuration. The maintainer shared the steps to reproduce it, warning that "any process that can reach the Gitea container's HTTP port directly - not through the intended authenticating proxy - can impersonate any user whose login name is known or guessable. Admin accounts (admin, gitea_admin, etc.) are the obvious targets." Gitea released versions 1.26.3 and 1.26.4 that address CVE-2026-20896 and advised users to upgrade straight to the most recent release, which fixes an additional issue and a regression introduced in 1.26.3. Singapore’s cybersecurity agency (CSA) has also issued a warning about CVE-2026-20896 being actively exploited. If upgrading to a safe version is not possible, CSA recommends restricting the REVERSE_PROXY_TRUSTED_PROXIES setting to specific trusted IP addresses instead of the default wildcard (*). The agency also recommended reviewing access logs for any suspicious activity to determine if a compromise has already occurred. Overall prevention scores can hide what happens after initial access. Once attackers are using valid credentials, prevention drops sharply. The Blue Report 2026 measures defenses technique by technique across 338 million simulations run in customer production environments. Get the report

Threat actors are exploiting a vulnerability in Gitea’s reverse-proxy authentication mechanism to access internet-accessible instances by supplying only a valid username. Specific to Gitea’s official Docker images, the critical-severity security defect is tracked as CVE-2026-20896 (CVSS score of 9.8) and can be exploited with a single HTTP header, Sysdig Sr. Director of Threat Research Michael Clark says. The issue exists because, in Gitea Docker images before 1.26.3, the default settings allow connections from any source IP address instead of enforcing an allowlist, security researcher Ali Mustafa, who was credited for finding the bug, explains. If placed behind a proxy, Gitea should trust only a header set by the proxy when reverse-proxy authentication is enabled. Because of the flaw, anyone who could provide a valid username in a header could connect to a vulnerable instance, bypassing authentication. “Any process that can reach the Gitea container’s HTTP port directly — not through the intended authenticating proxy — can impersonate any user whose login name is known or guessable. Admin accounts are the obvious targets,” the researcher notes. The patch that was introduced in Gitea versions 1.26.3 / 1.26.4 makes reverse-proxy authentication an opt-in feature. According to Clark, CVE-2026-20896’s exploitation started 13 days after public disclosure. The attempt was associated with a “VPN-exit scanner that grabbed access”. “No password. No token. One header. Sysdig sensors caught the first in-the-wild hit 13 days after the advisory,” Clark notes. While Sysdig’s research revealed approximately 6,200 Gitea instances accessible from the internet, it is unclear how many of them are vulnerable. Users are advised to update their Gitea deployments as soon as possible, as the successful exploitation of the vulnerability could lead to the complete compromise of all the code and secrets Gitea holds. “A Gitea user can read and write their repositories, private ones included: the code they ship, the secrets developers committed by accident (API keys, DB credentials, deploy tokens), their CI/CD config, and deploy keys,” Clark notes. Related: Critical Adobe ColdFusion Vulnerability Exploited in Attacks Related: CISA Warns of Actively Exploited Microsoft SharePoint Vulnerability Related: Apple Patches Dozens of Vulnerabilities Across iOS, macOS, and Safari Related: Gitea Vulnerability Exposed 30,000 Deployments to Attacks

Threat actors have been observed attempting to exploit a recently patched critical security flaw in Gitea Docker images, according to Sysdig. The vulnerability in question is CVE-2026-20896 (CVSS score: 9.8), a vulnerability that stems from the DevOps platform trusting the "X-WEBAUTH-USER" header from any source IP address, effectively allowing an unauthenticated internet client to get elevated access. In a statement shared with The Hacker News via email, security researcher Ali Mustafa (@rz1027), who is credited with discovering and reporting the flaw, said the Gitea Docker images shipped an "app.ini" template that hard-codes "REVERSE_PROXY_TRUSTED_PROXIES = *" by default. The "app.ini" file is a core configuration file for managing server parameters, database connections, security behavior, and application settings. "With reverse-proxy login enabled, that wildcard trusts every source IP, so anyone who could reach the port could send an X-WEBAUTH-USER header and be authenticated as any user, with no password and no token," Mustafa explained. "With auto-registration on, an admin username gives admin." It's worth noting that the documented safe value for the "REVERSE_PROXY_TRUSTED_PROXIES" internal variable is "127.0.0.0/8,::1/128," meaning only localhost, aka the loopback interface, is allowed as a trusted proxy server. However, the official Docker image doesn't use this default, hard-coding "*" instead. In other words, the allowlist check is as good as not having it. Thus, when an admin sets "ENABLE_REVERSE_PROXY_AUTHENTICATION = true" to put Gitea behind an authenticating reverse proxy and leaves the "REVERSE_PROXY_TRUSTED_PROXIES" setting to its default value, it allows a X-WEBAUTH-USER custom HTTP header from any source IP that can reach the container. "Any process that can reach the Gitea container's HTTP port directly – not through the intended authenticating proxy – can impersonate any user whose login name is known or guessable," according to Gitea's advisory. "Admin accounts (admin, gitea_admin, etc.) are the obvious targets." The vulnerability affects Gitea Docker images versions before and including 1.26.2. It has been addressed in version 1.26.3 released late last month, with the "*" wildcard now removed and reverse-proxy authentication made opt-in. Cloud security company Sysdig has since revealed it detected the first in-the-wild exploitation attempt 13 days after public disclosure of the vulnerability. There are about 6,200 internet-facing Gitea instances. "So far, the activities have been related to initial investigation by the threat actor," Michael Clark, senior director of threat research at Sysdig, told The Hacker News. "While we saw the first action from an IP from the ProtonVPN service, 159.26.98[.]241, it has not so far progressed to any exploitation or attack progress. We think this is because we have seen this one early before it has had the chance to develop beyond that initial phase." Given the severity of the issue, it's essential that users apply the fixes as soon as possible for optimal protection.

The US cybersecurity agency CISA on Friday warned of attacks targeting a SolarWinds Serv-U vulnerability that had been patched a couple of days earlier. Tracked as CVE-2026-28318 (CVSS score of 7.5), the bug is described as a denial-of-service (DoS) issue that can be exploited via specially crafted POST requests to crash the Serv-U service. Successful exploitation of the security defect does not require authentication, SolarWinds warned on Thursday. The flaw was addressed in Serv-U 15.5.4 Hotfix 1. SolarWinds encourages all customers to download and install the hotfix, including those who recently upgraded to Serv-U 15.5.4. According to SolarWinds, the hotfix prevents attackers from crashing the Serv-U service via requests containing the ‘Content-Encoding: deflate’ header and some data. Users of Serv-U versions 15.4.2, 15.5, and 15.5.1, which have reached End-of-Life (EoL), are advised to upgrade to a supported release as soon as possible. While SolarWinds’s advisory makes no mention of CVE-2026-28318 being exploited in the wild, CISA on Friday added the bug to its Known Exploited Vulnerabilities (KEV) catalog. It’s unclear who is behind the attacks and whether the vulnerability has been exploited as a zero-day. In line with Binding Operational Directive (BOD) 22-01’s requirements, CISA urged federal agencies to patch the CVE by June 19 to keep their networks protected against active threats. While BOD 22-01 only applies to federal agencies, all organizations are advised to apply SolarWinds’ hotfix as soon as possible. The company’s advisory contains detailed instructions on installing the hotfix and on removing it if necessary. Related: Chrome 149 Patches 429 Vulnerabilities Related: Mirasvit Vulnerability Exploited to Execute Code on Magento Servers Related: Gitea Vulnerability Exposed 30,000 Deployments to Attacks Related: Half of the 6 Million Internet-Facing FTP Servers Lack Encryption

A vulnerability in open source, self-hosted Git service Gitea could have allowed unauthenticated attackers to pull private container images from over 30,000 deployments, AI pentesting firm NoScope warns. Tracked as CVE-2026-27771, the security flaw is described as an access control issue impacting Gitea’s built-in container registry. Forgejo, which shares the implementation, is also affected. Other Gitea-derived forks may be impacted as well. Due to the flaw, authentication requirements were not enforced on images marked as private, and the container registry still served them in response to standard, anonymous Docker/OCI pull requests to the registry API. The security defect lurked in Gitea’s code for approximately four years before being patched in version 1.26.2, which was released last week. “Gitea’s container registry has allowed any person on the internet, with no account, no password, and no prior access, to pull what would be considered private container images at first glance from affected instances as if they were public,” NoScope says. Because container images may contain sensitive information such as source code, secrets, and production infrastructure details, the impact from the bug is considerable, the security firm warns. According to NoScope, a Shodan search uncovered over 34,000 internet-facing Gitea instances. Of these, approximately 93%, or 31,750, were likely vulnerable. Analysis of the potentially affected deployments revealed that roughly 4,000 were production systems running on major cloud or VPS platforms. Approximately 7,000 instances, NoScope says, were running on Gitea’s default port. “The data is unambiguous. These aren’t hobby machines. These are organisations that made a deliberate decision to self-host their development infrastructure, running it on production-grade compute, for real workloads,” the AI pentesting firm notes. Organizations are advised to update to Gitea version 1.26.2 immediately, or to change the configuration settings to require authentication for all content access. “Note that this setting is not suitable for instances that intentionally expose some containers publicly; operators in that situation should weigh the trade-off carefully,” NoScope says. Related: Open Source DockSec Uses AI to Cut Through Vulnerability Noise in Docker Images Related: Ghost CMS Vulnerability Exploited to Hack Over 700 Websites

Cybersecurity researchers have disclosed a security flaw in Gitea, an open-source, self-hosted platform for version control, that allows unauthenticated remote attackers to pull private container images from Gitea deployments without requiring an account, password, or other credentials. The vulnerability, tracked as CVE-2026-27771 (CVSS score: 8.2), affects all versions of Gitea prior to 1.26.2, which addresses the issue. According to Noscope, the security defect likely impacts more than 30,000 deployments across over 30 countries and went undetected for close to four years. The vast majority of the exposures are in China, the U.S., Germany, France, and the U.K. Affected organizations span healthcare providers, aerospace manufacturers, retail infrastructure, and internet service providers. "On affected versions, the private designation on a container repository did not deliver the protection operators reasonably expected it to," Noscope said. "Gitea's container registry has allowed any person on the internet, with no account, no password, and no prior access, to pull what would be considered private container images at first glance from affected instances as if they were public." The U.K.-based security company also pointed out any fork of Gitea should be treated as potentially impacted by the vulnerability until it's been independently verified by the respective maintainers. In its own testing, Forgejo has been confirmed to be impacted. No additional technical details related to CVE-2026-27771 are currently available. In a statement shared with The Hacker News, Noscope co-founder Keval Jagani said the specifics have been intentionally held back to give the "broader Gitea ecosystem time to patch." Gitea users are advised to update to version 1.6.2 for optimal protection. If patching is not an immediate option, a temporary workaround is to set [service].REQUIRE_SIGNIN_VIEW=true in the Gitea configuration. However, it's worth noting that this approach isn't ideal if some containers are meant to be intentionally exposed publicly. (The story was updated after publication to include a response from Noscope.)