CVE-2025-47943: Stored XSS in Gogs via PDF
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 webInstall 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
