feat: Vulnerability-Disclosure-Challenges-in-Open-Source-Projects.md

Author: zast-ai

_posts/2025-07-29-Vulnerability-Disclosure-Challenges-in-Open-Source-Projects.md

@@ -0,0 +1,193 @@
+---
+title: "Vulnerability Disclosure Challenges in Open Source Projects"
+description: "An in-depth exploration of the challenges encountered during the security vulnerability disclosure process in the Formidable library, using CVE-2025-46653 as a case study, and reflections on the current state of open source ecosystem maintenance."
+author: "Zast.ai"
+date: 2025-09-03
+categories: [Security, Open Source, Vulnerability Disclosure]
+tags: [CVE, Formidable, SBOM, Supply Chain Security, Responsible Disclosure, npm, GitHub]
+---
+
+## Introduction: vulnerability in SBOM (open source)
+
+Imagine this: One day, your application suddenly was hacked - customer data was leaked or even worse. Not because your code has a bug, but because of a critical vulnerability in a fundamental library buried deep in the dependency tree. In this blog, we will use <a href="https://www.cve.org/CVERecord?id=CVE-2025-46653" target="_blank" rel="noopener noreferrer">CVE-2025-46653</a> as a case study. What surprised us most was HOW MUCH EFFORT we had to pay to responsibly disclose this vulnerability. We had to tell the story, so that we as a community may collaborate better in such matter later on. 
+
+## Case study: CVE-2025-46653
+
+Our AI agent, Zast.ai, identified a zero-day vulnerability in Formidable while analyzing a popular content sharing platform. This dependency has over 10 million weekly downloads and shows signs of reduced maintenance activity. It also lacks documented security response processes. When examining the dependency tree with npm ls, this vulnerable component is located five levels deep in the dependency hierarchy. 
+
+To understand how a single vulnerable dependency can impact an entire application, let's look at a typical Node.js application architecture:
+
+![]({{'/assets/img/Vulnerability-Disclosure-Challenges-in-Open-Source-Projects/1.png' | relative_url }})
+
+<center><em>Architecture flowchart by our engineering team</em></center>
+
+As shown in the diagram, Formidable, sitting in the external services layer, can expose vulnerabilities that propagate all the way up to the user interface. 
+
+## Technical Analysis
+
+**Vulnerability Nature:** 
+
+CVE-2025-46653 is an "insecure design of file upload naming" vulnerability that allows malicious actors to predict the real names of arbitrarily uploaded files, potentially leading to sensitive file disclosure. This vulnerability has been assigned a CVSS score of 3.1. The score is intentionally conservative as it reflects the vulnerability's limited impact when considered in isolation, though it should still be addressed as part of comprehensive security measures.
+
+Additionally, during our evaluation of Formidable, we found that web applications using this dependency without proper security restrictions can be vulnerable to arbitrary file uploads. When combined with CVE-2025-46653, this could escalate to Stored XSS or even RCE vulnerabilities, you may refer <a href="https://github.com/zast-ai/vulnerability-reports/blob/main/formidable/file_upload/report.md" target="_blank" rel="noopener noreferrer">here</a> for more details.
+
+**Impact Scope:** 
+
+Formidable versions 2.1.0 - 3.5.2 are affected. 
+
+**The Discovery:**
+
+Zast.ai uncovered this vulnerability in Formidable when assessing a popular content sharing platform. The library is widely used and processes millions of file uploads daily.
+
+!Vulnerability Diagram
+
+![]({{'/assets/img/Vulnerability-Disclosure-Challenges-in-Open-Source-Projects/2.png' | relative_url }})
+
+### The Disclosure Journey
+
+Below is the complete timeline of our responsible disclosure attempts for the Formidable vulnerability:
+
+**Following Official Channels**
+
+- First we checked Formidable's GitHub SECURITY.md file, which directs vulnerability reports to security@tunnckocore.com
+
+![]({{'/assets/img/Vulnerability-Disclosure-Challenges-in-Open-Source-Projects/3.png' | relative_url }})
+
+- The document states that confirmed vulnerabilities would be synchronized with the npm security team and Tidelift security
+
+- When we sent emails, we discovered this address no longer exists; messages bounced back
+
+![]({{'/assets/img/Vulnerability-Disclosure-Challenges-in-Open-Source-Projects/4.png' | relative_url }})
+
+**Attempting Alternative Contact Methods**
+
+- Formidable's npm page suggests contacting @tunnckoCore or @3a1FcBx0 via Twitter
+
+![]({{'/assets/img/Vulnerability-Disclosure-Challenges-in-Open-Source-Projects/404.png' | relative_url }})
+
+- We found that the @3a1FcBx0 account no longer exists
+
+![]({{'/assets/img/Vulnerability-Disclosure-Challenges-in-Open-Source-Projects/5.png' | relative_url }})
+
+- When we attempted to reach out to the owner of the @tunnckoCore account, the account itself had already been inactive for an extended period—and we had no way to send direct messages to them at that time.
+
+- We left a comment under their last post, hoping to attract attention
+
+![]({{'/assets/img/Vulnerability-Disclosure-Challenges-in-Open-Source-Projects/6.png' | relative_url }})
+
+- When visiting <a href="http://tunnckocore.com" target="_blank" rel="noopener noreferrer">tunnckocore.com</a>, we discovered the domain had been taken over by a gambling website
+
+![]({{'/assets/img/Vulnerability-Disclosure-Challenges-in-Open-Source-Projects/7.png' | relative_url }})
+
+**Contacting Official Platforms**
+
+- We attempted to contact the npm security team <a href="mailto:security@npmjs.com">security@npmjs.com</a>, but our emails were rejected by the server
+
+![]({{'/assets/img/Vulnerability-Disclosure-Challenges-in-Open-Source-Projects/8.png' | relative_url }})
+
+- We contacted the Tidelift security team, who responded that they have no partnership with Formidable
+
+![]({{'/assets/img/Vulnerability-Disclosure-Challenges-in-Open-Source-Projects/9.png' | relative_url }})
+
+**Direct Contact with All Maintainers**
+
+- Using the npm show formidable command, we identified all official maintainers (5 in total)
+
+![]({{'/assets/img/Vulnerability-Disclosure-Challenges-in-Open-Source-Projects/10.png' | relative_url }})
+
+- We sent two rounds of emails to all maintainers, with most receiving no response
+
+![]({{'/assets/img/Vulnerability-Disclosure-Challenges-in-Open-Source-Projects/11.png' | relative_url }})
+
+- We specifically contacted Cyril, who had committed code 5 months prior, but received no reply
+
+![]({{'/assets/img/Vulnerability-Disclosure-Challenges-in-Open-Source-Projects/12.png' | relative_url }})
+
+- We contacted Nathanael, who was active on GitHub, but similarly received no reply
+
+![]({{'/assets/img/Vulnerability-Disclosure-Challenges-in-Open-Source-Projects/13.png' | relative_url }})
+
+**Last Hope**
+
+- We contacted Felix, the original developer of the project, who replied that he was no longer actively maintaining the project
+
+![]({{'/assets/img/Vulnerability-Disclosure-Challenges-in-Open-Source-Projects/14.png' | relative_url }})
+
+- He tried to confirm whether he still had commit rights and found that he could still merge code
+
+![]({{'/assets/img/Vulnerability-Disclosure-Challenges-in-Open-Source-Projects/15.png' | relative_url }})
+
+- Although he had no time to develop patches, he expressed willingness to help verify vulnerabilities and merge fixes provided by others
+
+- Unfortunately, the response was dismissive of the automated findings, expressing skepticism about AI-generated reports.
+
+![]({{'/assets/img/Vulnerability-Disclosure-Challenges-in-Open-Source-Projects/16.png' | relative_url }})
+
+**The Turning Point**
+
+Several weeks later, unexpectedly, tunnckoCore responded to our message, despite his official contact channels being defunct.
+
+![]({{'/assets/img/Vulnerability-Disclosure-Challenges-in-Open-Source-Projects/17.png' | relative_url }})
+
+**Final Outcome**
+
+After weeks of persistent effort, the result is: of Formidable's five official maintainers, three were completely unreachable, one (Felix) had merge permissions but no time for active development, and only one (tunnckoCore) eventually responded to security concerns. This situation reflects a challenge in the open source ecosystem, where maintainers may lack the resources or incentives to address security concerns promptly.
+
+## Addressing Supply Chain Security Challenges
+
+### 4.1 Licensing and Security
+
+License Terms: The MIT license does not require parties to assume responsibility for vulnerabilities. This results in a separation between adoption and maintenance responsibilities.
+
+**Corporate Expectation:**
+
+"We initially assumed that using 'popular' open source libraries would provide security benefits, but our experience showed that this assumption may not hold when maintainers are not actively responding."
+
+### 4.2 Ecosystem Support Mechanisms
+
+**Platform Design:**
+
+npm and GitHub do not mandate that projects maintain security contacts or response protocols. The ecosystem relies on trust and voluntary maintenance.
+
+**Commercial Coverage:**
+
+Some security vendors offer monitoring services, but they focus on projects with commercial partnerships, covering a subset of the ecosystem.
+
+### 4.3 Recommended Practices 
+
+Enterprise dependency management recommendations:
+
+1. Implement "heartbeat monitoring" for critical dependencies:
+- Track maintainer activity
+- Measure issue response times
+- Monitor security update frequency
+2. Establish a "backup library registry":
+- Maintain internal forks of critical dependencies
+- Create contingency plans for abandoned packages
+- Develop expertise in core dependencies
+3. Develop a dependency health assessment system:
+- Create a scoring model that evaluates maintainer engagement and code quality
+- Integrate health metrics into security reviews and procurement processes
+- Prioritize dependencies based on criticality to your infrastructure
+
+These approaches acknowledge differences between popularity metrics and long-term maintenance. Organizations may consider adjusting their dependency management strategies to include more active oversight of their software components.
+
+## Considerations on Dependency Management 
+
+A typical Node.js project analysis found: "node_modules directories often contain over 1,300 dependencies with diverse maintenance patterns." (From npm audit data)
+
+Action items:
+
+1. Audit critical dependencies for maintenance status
+2. Contribute to essential libraries in the stack
+3. Build organizational knowledge about the dependency chain
+
+![]({{'/assets/img/Vulnerability-Disclosure-Challenges-in-Open-Source-Projects/18.png' | relative_url }})
+
+**Key Consideration:**
+
+"How should organizations approach the maintenance variability of foundational open source modules like Formidable?"
+
+Enterprises may consider evolving their open source software practices toward more active oversight and collaborative responsibility.
+
+As an automated vulnerability assessment AI agent, Zast.ai is continuously exploring effective approaches to dependency vulnerability assessment. Follow us on X <a href="https://twitter.com/zast_ai" target="_blank" rel="noopener noreferrer">@zast_ai</a> to discuss advancing software supply chain security.