CVE-2025-47943: Stored XSS in Gogs via PDF
好的,我现在需要帮用户总结这篇文章的内容,控制在100字以内。首先,我得仔细阅读文章,理解主要信息。 文章讲的是Gogs这个开源的Git服务软件存在一个XSS漏洞。这个漏洞存在于0.13.2及之前的版本中,原因是使用了过时的pdfjs库。攻击者可以通过上传恶意PDF文件,在其他用户浏览时执行JavaScript代码,导致安全问题。漏洞已经被修复,升级到0.13.3即可。 接下来,我需要将这些关键点浓缩成一句话。要包括Gogs是什么、漏洞类型、原因、影响和解决方法。 最后,确保语言简洁明了,不超过100字。 </think> Gogs是一款开源的自托管Git服务,在版本0.13.2及之前存在存储型XSS漏洞,源于使用过时的pdfjs-1.4.20组件。攻击者可上传恶意PDF文件,在用户浏览时执行JavaScript代码。该漏洞已修复于版本0.13.3。 2026-2-24 17:48:11 Author: www.hacktivesecurity.com(查看原文) 阅读量:0 收藏

TL;DR

Gogs is an open source self-hosted Git service. In the version 0.13.2 and prior, there is a stored Cross-Site Scripting (XSS) vulnerability, which allows client-side Javascript code execution. The vulnerability is caused by the usage of a vulnerable and outdated component: pdfjs-1.4.20 under public/plugins/. This issue has been fixed for gogs.io/gogs in version 0.13.3.

What is Gogs

Gogs is a lightweight, self-hosted Git service written in Go, designed to be easy to install and run anywhere. It’s a fully open-source product, you can check the source code on GitHub: https://github.com/gogs/gogs (about 47k stars at the time of writing).

Some of its key features:

  • User dashboard, user profile and activity timeline.
  • Access repositories via SSH, HTTP and HTTPS protocols.
  • User, organization and repository management.
  • Repository and organization webhooks, including Slack, Discord and Dingtalk.
  • Repository Git hooks, deploy keys and Git LFS.
  • Repository issues, pull requests, wiki, protected branches and collaboration.
  • Migrate and mirror repositories with wiki from other code hosts.
  • Web editor for quick editing repository files and wiki.
  • Jupyter Notebook and PDF rendering (😏).
  • Authentication via SMTP, LDAP, reverse proxy, GitHub.com and GitHub Enterprise with 2FA.
  • Customize HTML templates, static files and many others.
  • Rich database backend support, including PostgreSQL, MySQL, SQLite3 or any database backend that speaks one of those protocols.

Vulnerability Details

Stored Cross-Site Scripting (XSS) is a security flaw where attackers store malicious JavaScript code inside a web application, which is later served and executed in the browser of other users. This can lead to session hijacking, data exfiltration, defacement of pages, and other attacks executed in the context of the victim’s session. To prevent stored XSS, developers must properly sanitize all untrusted data before rendering it in the browser, escaping any HTML/JavaScript context as needed, and avoid using outdated libraries with known vulnerabilities.

In this specific case, Gogs (<= 0.13.2) uses a vulnerable and outdated version of PDF.js (pdfjs-1.4.20) to render PDF files in the web interface. The PDF.js version mentioned contains a stored XSS vulnerability tracked as CVE-2024-4367.
Quoting the CVE page from Codean Labs:

“pdf.js before 2.5.207 is vulnerable to cross-site scripting (XSS) via crafted PDF files. This allows attackers to execute arbitrary JavaScript when such a file is viewed in the browser.”

When a malicious PDF exploiting this vulnerability is uploaded to a repository and previewed in the Gogs web interface, the attacker’s JavaScript is executed in the victim’s browser.

You can read more about this vulnerability here: CVE-2024-4367 – Arbitrary JavaScript execution in PDF.js by Codean Labs.

Proof of Concept

Set up a vulnerable version of gogs using the official documentation (we’re using version 0.13.2).

wget https://github.com/gogs/gogs/releases/download/v0.13.2/gogs_0.13.2_linux_amd64.zip
unzip gogs_0.13.2_linux_amd64.zip
cd gogs_0.13.2_linux_amd64.zip/gogs
./gogs web

Install Gogs (we’re using SQLite for convenience)

Create a user and login in the dashboard

Create a repository

Upload the malicious PDF

mkdir test && cd test
git init
mv /home/edoardottt/Downloads/poc_generalized.pdf .
git add poc_generalized.pdf
git commit -m "poc uploaded"
git remote add origin http://localhost:3000/gogs/test.git
git push -u origin master

Click on the PDF file to be previewed

Impact

An attacker could upload a malicious file into the repository. This can be achieved by a developer with repository access or by an external actor who convinces a developer to upload a seemingly benign PDF (since the malicious payload is not visible in the PDF itself).
When other developers or reviewers view it through the web interface, their accounts could be compromised, allowing the attacker to spread further within the organization.
Since Gogs is often used in internal or private deployments, the impact can vary based on the sensitivity of the hosted code and the privileges of affected users, potentially exposing proprietary source code, deployment secrets, or other confidential data.

Remediation

Update your gogs instances to version 0.13.3.

This is the Pull Request that solves the vulnerability: https://github.com/gogs/gogs/pull/7966.
This PR substitutes the old version with PDF.js v5.2.133.

Conclusions

It’s recommended to update gogs to version 0.13.3.
Using the query http.favicon.hash:-449283196,917966895 on Shodan (https://www.shodan.io/search?query=http.favicon.hash%3A-449283196%2C917966895) it’s possible to see the gogs instances exposed on the Internet.
It’s highly likely that the vast majority of gogs instances are not exposed on public networks.

The elephant in the room

This shouldn’t be a CVE.

If you have ever read the CVE Numbering Authority (CNA) Operational Rules, you already know that this issue should not have been assigned a CVE ID.
Below there’s the interesting section:

4.1.12 The act of updating Product dependencies MUST NOT be determined to be a Vulnerability, regardless of whether the dependencies have Vulnerabilities. For example, updating a library to address a Vulnerability in that library MUST NOT be determined to be a new Vulnerability in a Product that uses the library, and a Vulnerability advisory for the Product SHOULD reference the CVE ID for the Vulnerability in the library.” (https://www.cve.org/ResourcesSupport/AllResources/CNARules#section_4-1_Vulnerability_Determination)

In this case, as you can see from the GitHub Pull Request I’ve submitted and was accepted as vulnerability patch, the only action performed was the vulnerable library update.
However, GitHub which in this case is the CNA requesting the CVE, seems not to have performed all the necessary checks to determine if the issue was eligible for inclusion in the CVE database.
This CVE is marked as GitHub Reviewed on the GitHub Security Advisory Database.

This CVE is currently marked with the label This CVE record has been marked for NVD enrichment efforts (as usual) on the NIST National Vulnerability Database and it may be eventually marked as REJECTED.

I won’t bore you with all the considerations about CVE issues, it’s a topic that has been discussed a lot during these months.

References


文章来源: https://www.hacktivesecurity.com/blog/2025/07/15/cve-2025-47943-stored-xss-in-gogs-via-pdf/
如有侵权请联系:admin#unsafe.sh