Skip to content

Security policy #8006

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 5 commits into from
Aug 21, 2025
Merged

Security policy #8006

Show file tree
Hide file tree
Changes from 2 commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
69df998
Add security policy
andyleiserson Jul 25, 2025
d7d306c
Add security in the issue type chooser
andyleiserson Jul 25, 2025
6343eb2
Apply suggestions from review
andyleiserson Jul 31, 2025
595038a
Additional edits
andyleiserson Jul 31, 2025
e5ae204
Additional review suggestions
andyleiserson Aug 21, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 4 additions & 1 deletion .github/ISSUE_TEMPLATE/config.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,5 +1,8 @@
blank_issues_enabled: false
contact_links:
- name: Question about wgpu
url: https://github.com/gfx-rs/wgpu/discussions/new
url: https://github.com/gfx-rs/wgpu/discussions/new/choose
about: Any questions about how to use wgpu should go here.
- name: Security concerns
url: https://github.com/gfx-rs/wgpu/security
about: Information about reporting possible vulnerabilities.
79 changes: 79 additions & 0 deletions SECURITY.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,79 @@
# WGPU Security Policy

This document describes what is considered a security vulnerability in WGPU and
how vulnerabilities should be reported.


## Vulnerability Definition

WebGPU introduces a different threat model than is sometimes applied to
GPU-related software. Unlike typical gaming or high-performance computing
applications, where the software accessing GPU APIs is proprietary or
obtained from a trusted developer, WebGPU makes GPU APIs available to
arbitrary web applications. In the threat model of the web, malicious
content should not be able to use the GPU APIs to access data or interfaces
outside the intended scope for interaction with web content.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this paragraph could benefit from spelling out its point more explicitly, because the following text could be taken as limiting the scope of what is a vulnerability (“we mostly care about JavaScript WebGPU”), rather than expanding it (“we care about protection from misuse, not just doing the wrong thing in response to valid-according-to-the-spec input”). So, how about saying something like:

Suggested change
outside the intended scope for interaction with web content.
outside the intended scope for interaction with web content.
Therefore, `wgpu` seeks to prevent undefined behavior and data
leaks even when its API is misused, and failures to do so may be
considered vulnerabilities.
(This is also in accordance with the Rust principle of safe vs. unsafe code,
since the `wgpu` library exposes a safe API.)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems reasonable to me, but I'll wait for some more input before changing it.

The scope as I wrote it was intentionally narrow, because I didn't want to sign the project up for more work than necessary. But that concern aside, I agree that UB or data leaks reachable from the API ought to be considered a vulnerability.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think kpreids suggestion is fine and we should adopt it.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about the experimental APIs? They explicitly call out they may have UB and should be used with caution. Would these still get vulnerability reports? If so what would happen?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Vecvec I don't think the intent is to make a firm rule that UB in an experimental API is a vulnerability. It's more a statement that the sentiment of the project is that UB is always bad, so it would always be a bug if you can get UB by misusing the API. (Arguably that should be a given for a safe API, but in this context it's worth stating a position on arguable points.)

It doesn't show up in this comment thread, but the paragraph immediately following this should help to provide some clarity that experimental APIs are not held to the same standard.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, it's not the paragraph immediately following. It's the one a bit later starting "The WGPU Rust API offers some functionality, both supported and experimental...".

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To give some examples, I'd say that a simple RCE of the form "I give wgpu this carefully crafted buffer and it executes part of it with no sandbox" is a vulnerability, even in an experimental API. RCE of the form "if you have X and Y in memory for use as ROP gadgets and I can guess the stack canary and it's a particular phase of the moon" might not be a vulnerability in an experimental API. A DoS using a core API might be a vulnerability, a DoS using an experimental API is unlikely to be considered a vulnerability.

But fundamentally, it's often not possible to anticipate what will go wrong; the goal here is just to have some security policy in place to make it clear that we do care about security, and to explain how to report vulnerabilities. Severity (on a scale down to "not a vulnerability at all") has to be assessed on a case-by-case basis.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It doesn't show up in this comment thread, but the paragraph immediately following this should help to provide some clarity that experimental APIs are not held to the same standard.

Ah yes, I see it now.


While the WGPU maintainers have discretion in assigning a severity to
individual vulnerabilities, it is generally considered a security vulnerability
in WGPU if Javascript or WebAssembly code running with privileges of ordinary
web content is able to:

- Access data associated with native applications other than the user agent,
or associated with other web origins.
- Escape the applicable sandbox and run arbitrary code or call arbitrary system
APIs on the user agent host.
- Consume system resources to the point that it is difficult to recover
(e.g. by closing the web page).

The WGPU Rust API offers some functionality, both supported and experimental,
that is not part of the WebGPU standard and is not made available in Javascript
environments using WGPU. Associated vulnerabilities may be assigned lower
severity than vulnerabilities that apply to a Javascript WebGPU implementation
based on WGPU.


## Supported Versions

The WGPU project maintains security support for serious vulnerabilities in the
[most recent major release](https://github.com/gfx-rs/wgpu/releases). Fixes for
security vulnerabilities found shortly after the initial release of a major
version may also be provided for the previous major release.

Mozilla provides security support for versions of WGPU used in [current
versions of Firefox](https://whattrainisitnow.com/).

The version of WGPU that is active can be found in the Firefox repositories:

- [release](https://github.com/mozilla-firefox/firefox/blob/release/gfx/wgpu_bindings/Cargo.toml),
- [beta](https://github.com/mozilla-firefox/firefox/blob/beta/gfx/wgpu_bindings/Cargo.toml), and
- [nightly](https://github.com/mozilla-firefox/firefox/blob/main/gfx/wgpu_bindings/Cargo.toml),

We welcome reports of security vulnerabilities in any of these released
versions or in the latest code on the `trunk` branch.


## Reporting a Vulnerability

Although not all vulnerabilities in WGPU will affect Firefox, Mozilla accepts
all vulnerability reports for WGPU and directs them appropriately. Additionally,
Mozilla serves as the CVE numbering authority for the WGPU project.

To report a security problem with WGPU, create a bug in Mozilla's Bugzilla
instance in the [Core ::
Graphics :: WebGPU](https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&component=Graphics%3A+WebGPU)
component.

**IMPORTANT: For security issues, please make sure that you check the box
labelled "Many users could be harmed by this security problem".** We advise
that you check this option for anything that is potentially
security-relevant, including memory safety, crashes, race conditions, and
handling of confidential information.

Review Mozilla's [guides on bug
reporting](https://bugzilla.mozilla.org/page.cgi?id=bug-writing.html) before
you open a bug.

Mozilla operates a [bug bounty
program](https://www.mozilla.org/en-US/security/bug-bounty/). Some
vulnerabilities in this project may be eligible.