Upstream Library Vulnerability Policy

Last updated: 1 September 2026

1. Purpose and scope

Audacity, like most software, is built on a foundation of third-party open-source libraries — for audio codecs, file I/O, plugin hosting, networking, and more. When a CVE (Common Vulnerabilities and Exposures) is published against one of these upstream libraries, it does not automatically mean Audacity is affected.

This policy explains how the Audacity Team assesses upstream CVEs and decides whether — and how — they impact Audacity users.

This policy covers vulnerabilities in libraries Audacity depends on. It does not cover vulnerabilities in Audacity’s own code, or in unrelated third-party services (such as audio.com).

2. Upstream libraries in scope

Audacity links against a number of third-party libraries. Based on the current master branch build system (audacity/audacity, plus the shared muse_deps dependency set), these include:

This list reflects libraries referenced in the build system’s target_link_libraries/find_package calls and the muse_deps recipe manifest. muse_deps is shared across Muse Group products, so some platform-specific dependencies may be missing here and some listed entries may not ship in every Audacity build. We don’t maintain a single published manifest with pinned versions; when a CVE report needs precise version information, we check the build configuration for the Audacity release in question.

3. How we evaluate a CVE

Not every CVE in a library we use is a vulnerability in Audacity. A CVE in an upstream library only affects Audacity if the vulnerable code path is actually reachable through how Audacity uses that library. We assess each reported CVE against three questions:

  1. Is the vulnerable code compiled into Audacity at all? Some libraries are optional or built with a subset of their features enabled. A CVE in a feature Audacity doesn’t build or link against does not apply.
  2. Is the vulnerable code path reachable from how Audacity uses the library? A library can expose many features through its API; Audacity may only exercise a few. For example, a CVE in libcurl’s FTP handling does not affect Audacity, which does not use libcurl for FTP.
  3. Is the vulnerable input attacker-controlled in Audacity’s context? We distinguish between code paths that process untrusted input (an opened project file, an imported audio file, a network response) and those that only ever see trusted, local input.

A CVE that passes all three checks is treated as an application-level vulnerability and handled accordingly. A CVE that fails any of them is documented as not applicable to Audacity, with the reasoning recorded.

A report must identify the CVE and affected Audacity release, build, and platform; demonstrate that the vulnerable code is included and reachable; and explain the Audacity-specific security impact. Include reproduction steps or a proof of concept where practical. Automated scans, dependency-version matches, and unverified generated analysis are insufficient on their own. Reports or pull requests without evidence of plausible impact may be closed without further action.

4. Severity and response

Once a CVE is confirmed to apply to Audacity, we assess its severity using the upstream CVSS score as a starting point, adjusted for Audacity’s exposure. We also consider reachability, attacker preconditions, affected versions, available mitigations, and evidence of active exploitation. We may update the dependency, mitigate the vulnerable code path, or address the issue through the ordinary release process. Response and release timing depend on the circumstances; this policy does not guarantee a response or remediation timeline.

5. Bug bounties and compensation

Audacity does not operate a bug bounty program or offer payment for vulnerability reports or pull requests.

6. Policy review

This policy is reviewed periodically and updated as Audacity’s dependencies change.