At GNU Wget2, we take security seriously and appreciate the efforts of security researchers in identifying and disclosing vulnerabilities responsibly. If you believe you've discovered a security vulnerability in GNU Wget2, we encourage you to disclose it to us as confidential issues and work with us to ensure it is addressed promptly and appropriately.
To report vulnerabilities, open confidential issues at https://gitlab.com/gnuwget/wget2/issues .
In case, it can't be avoided to send an email: The names and contact details of the current maintainers is always available via the AUTHORS file in this repository. In order to send an encrypted email, please use the keyring available at the following URL: https://savannah.gnu.org/project/release-gpgkeys.php?group=wget
Please include the following information in your report:
- A detailed description of the vulnerability
- The version(s) of GNU Wget2 that are affected.
- Steps to reproduce the vulnerability.
- Any proof-of-concept or exploit code, if applicable.
- Your contact information for coordination and follow-up.
Once we receive your report, we will acknowledge receipt and work with you to investigate the issue. We work on GNU Wget2 on a volunteer basis and as such may face delays in responding immediately. We aim to respond to initial reports within 5 working days and will keep you informed of our progress throughout the resolution process.
Please refrain from disclosing the vulnerability publicly until we have had an opportunity to investigate and address it. We appreciate your cooperation in helping to keep GNU Wget2 and its users secure.
Once a security vulnerability has been identified and confirmed, we will take the following steps:
-
Investigation: We will promptly investigate the reported vulnerability to verify its authenticity and determine its scope and impact.
-
Resolution: Once validated, we will develop and test a fix for the vulnerability. We will strive to address the issue as quickly as possible and prepare a patch for release.
-
Coordination: We will work with the reporter to ensure that the vulnerability is disclosed responsibly and coordinated with the release of the fix.
-
Release: Upon completion of the fix and any necessary testing, we will release a new version of GNU Wget2 that addresses the vulnerability. We will provide appropriate credit to the reporter in the release notes, unless otherwise requested.
-
Public Disclosure: We will coordinate the public disclosure of the vulnerability with the reporter and other relevant stakeholders. Once the fix is widely available, we will publish an advisory detailing the vulnerability and its resolution.
We strive to follow these steps in a timely and transparent manner, while prioritizing the security and stability of GNU Wget2 and its users.
In order to protect our users and systems, we ask that security researchers adhere to the following guidelines when reporting vulnerabilities to GNU Wget2:
-
Responsible Disclosure: Please disclose vulnerabilities to us privately and allow us a reasonable amount of time to investigate and address them before disclosing them publicly.
-
Cooperation: We appreciate your cooperation and collaboration throughout the disclosure process. We will do our best to keep you informed of our progress and coordinate the release of information with you.
-
Respect: Please respect our users' privacy and refrain from any actions that could cause harm or disrupt our systems. We ask that you do not exploit or disclose vulnerabilities before they have been resolved.
By following these guidelines, you can help us maintain the security and integrity of GNU Wget2 for the benefit of all users. We thank you for your contributions to our project and for helping to make the internet a safer place.
With the rise of AI-assisted vulnerability research, we receive an increasing number of reports generated by Large Language Models (LLMs). While we appreciate all security contributions, please note:
Findings that can be trivially generated by anyone using public LLMs without deep domain knowledge (e.g., generic "potential buffer overflow" patterns, standard CWE listings without project-specific context, or automated SAST-style output) are not treated as confidential. These may be disclosed or discussed publicly at any time by the project maintainers.
For LLM-assisted reports to receive confidential handling and coordinated disclosure:
- The report must demonstrate project-specific understanding (code paths, configuration, threat model)
- Include verified reproduction steps on a supported version
- Show impact analysis beyond generic CWE descriptions
- False positives and unverified theoretical issues will be closed without coordinated disclosure
LLM-generated reports should still be submitted via our confidential issue tracker, but maintainers reserve the right to reclassify commodity findings as non-confidential immediately upon triage.