NVIDIA is dedicated to the security and trust of our software products and services, including source code repositories managed through our organization.

If you believe you have found a security vulnerability in NVIDIA Warp, report it privately. Do not open a public GitHub or GitLab issue, pull request, discussion, or merge request for security vulnerabilities.

To report a potential security vulnerability in Warp:

• Web (preferred): Use the NVIDIA Vulnerability Disclosure Program.
• Email: Send details to psirt@nvidia.com. NVIDIA encourages using the NVIDIA public PGP key for secure email communication.
• Repository private reporting: Use this repository's Security tab to submit the report privately.

Please include the following information:

• Product/project name and affected version, branch, or commit.
• Vulnerability type, such as code execution, denial of service, memory corruption, privilege escalation, or information disclosure.
• Step-by-step reproduction instructions.
• Proof-of-concept code or exploit details, if available.
• Potential impact, including how an attacker could exploit the vulnerability.
• Relevant platform details, including operating system, Python version, CUDA Toolkit and driver version, GPU model, compiler/toolchain version, and whether the issue affects CPU, CUDA, or both.

NVIDIA PSIRT will coordinate intake, validation, severity assessment, remediation, and disclosure. NVIDIA strives to follow coordinated vulnerability disclosure and may publish security bulletins, remediations, and acknowledgements as appropriate. For current program details, see the NVIDIA Product Security portal.

Warp is a Python framework and native runtime for GPU-accelerated simulation, robotics, geometry processing, graphics, and machine-learning workloads. The published Python package is warp-lang; the core runtime combines Python APIs, ctypes bindings, native C++/CUDA libraries, and JIT compilation for user-defined Warp kernels.

Warp operates at the library/SDK level inside the caller's Python or C++ process. It is not a network service, authentication layer, database, or sandbox. The tracked code does not expose HTTP routes, gRPC services, network listeners, credential stores, or TLS configuration. Applications and services embedding Warp are responsible for their own authentication, authorization, request validation, tenant isolation, transport security, logging policy, and secrets handling.

The main security boundaries in this repository are:

• Native runtime boundary: warp/_src/context.py loads native libraries from warp/bin/ such as warp.so, warp.dll, libwarp.dylib, and the optional warp-clang backend through ctypes. These libraries implement memory allocation, CUDA interaction, CPU/CUDA kernel launch, graph capture, sparse data structures, geometry queries, and other performance-critical operations.
• JIT compiler boundary: warp/_src/codegen.py, warp/_src/build.py, and warp/_src/context.py translate trusted Python kernel definitions into C++ or CUDA source, compile them with LLVM/Clang, NVRTC, nvJitLink, and optional libmathdx components, then load the resulting CPU object files, PTX, or CUBIN modules into the current process or CUDA context.
• Kernel cache boundary: compiled sources, object files, PTX/CUBIN files, LTO artifacts, and metadata are cached under warp.config.kernel_cache_dir. The default location is a per-user cache directory. Callers may override it with warp.config.kernel_cache_dir or WARP_CACHE_PATH.
• External memory boundary: Warp accepts and exports arrays through NumPy, PyTorch, JAX, Paddle, DLPack, __array_interface__, and __cuda_array_interface__. Many conversions are zero-copy, so Warp may launch kernels against memory allocated and owned by another framework.
• Serialized-data boundary: public APIs and examples can load local assets such as NanoVDB buffers through warp.Volume.load_from_nvdb(), APIC graph files through warp.capture_load(), CUBIN/AOT artifacts, USD stages in examples, and image files in examples.
• Build and release boundary: source builds and CI use build_lib.py, setup.py, pyproject.toml, Dockerfiles, Packman manifests, CUDA Toolkit paths, LLVM/Clang paths, and optional dependency extras to build Python wheels and native libraries.

Warp's primary security responsibility is to keep its public APIs, native runtime, compiler pipeline, cache loading, memory management, and supported file loaders robust when used according to these trust boundaries. Warp does not make untrusted Python code, untrusted native snippets, untrusted compiled artifacts, or untrusted local users safe to execute in the same process.

The following scenarios represent the primary security concerns for Warp:

1. Untrusted kernel or native snippet execution: Warp compiles user-defined @wp.kernel functions and @wp.func_native C++/CUDA snippets into executable CPU or GPU code. If an application accepts kernel definitions, native snippets, generated Python modules, or C++ example inputs from an untrusted party and compiles them with Warp, that party can execute code with the privileges of the hosting process and GPU context.

2. Kernel cache or compiled artifact tampering: Warp loads cached object files, PTX/CUBIN modules, LTO artifacts, and .meta files from the configured kernel cache. If WARP_CACHE_PATH or warp.config.kernel_cache_dir points to a shared or writable-by-untrusted-users location, another local user or compromised process could replace cached artifacts and affect later kernel loads.

3. Native memory corruption through malformed inputs or pointer metadata: Warp passes ctypes structures, raw pointers, external-array metadata, device pointers, strides, shapes, and kernel launch parameters into native C++/CUDA code. Incorrect device selection, malformed __cuda_array_interface__ or DLPack producers, stale external buffers, or validation gaps in native bindings can cause process crashes, data corruption, GPU faults, or memory disclosure within the caller's process boundary.

4. Unsafe loading of serialized graph and volume data: warp.capture_load() reads APIC .wrp graph files and, for CPU replay, loads object modules from the associated _modules directory through the warp-clang backend. warp.Volume.load_from_nvdb() parses and decompresses NanoVDB buffers before exposing them to native volume code. Malformed or hostile serialized inputs can target parser bugs, decompression resource exhaustion, object loading, or native replay paths.

5. Toolchain and dependency substitution during source builds: build_lib.py discovers CUDA through WARP_CUDA_PATH, CUDA_HOME, CUDA_PATH, and nvcc, can use LIBMATHDX_HOME or --libmathdx-path, and can consume existing or built LLVM/Clang installations. Build and CI tooling also downloads packages through Packman, uv, PyPI, and CUDA-related channels. A compromised toolchain, dependency source, or environment variable can compromise generated native libraries and wheels.

6. Cross-framework memory and stream misuse: PyTorch, JAX, Paddle, DLPack, CUDA array interface, CUDA graph capture, peer access, memory pools, and custom allocators share memory and stream ownership across libraries. A producer that misreports metadata or violates lifetime and synchronization rules can make Warp kernels access stale, inaccessible, or incorrectly typed memory. The default launch array access mode is permissive for performance; callers can enable stricter diagnostics with warp.config.launch_array_access_mode.

7. Auxiliary example and visualization inputs: Warp examples load USD, NVDB, image, CUBIN, and APIC graph artifacts, and C++ examples may dynamically load warp-clang or link against warp.so from local paths. These examples are intended for local developer use, not for processing attacker-supplied assets in a privileged service.

• The Python process executing Warp code is trusted. Warp does not isolate tenants, authenticate callers, authorize actions, or sandbox untrusted Python, C++/CUDA snippets, kernels, or compiled artifacts.
• The host operating system enforces process isolation, filesystem permissions, dynamic loader policy, and user separation. Warp assumes native libraries under warp/bin/ and configured build toolchain paths are controlled by trusted users.
• The CUDA driver, GPU hardware, CUDA memory manager, MMU/UVA behavior, peer access configuration, and memory pool implementation correctly enforce device memory access rules.
• The kernel cache directory is per-user or otherwise protected from untrusted writers. Shared cache directories must be explicitly hardened by the embedding application or deployment environment.
• External array producers correctly report pointer, dtype, shape, stride, device, stream, ownership, and lifetime metadata. Warp cannot fully verify every custom allocator or externally wrapped allocation.
• Serialized inputs such as .wrp, .nvdb, USD, image, CUBIN, PTX, and CPU object files are trusted unless the embedding application validates or sandboxes them before calling Warp APIs.
• Services that expose Warp functionality to remote users must validate and constrain inputs before invoking Warp. Network transport security, rate limiting, authentication, authorization, request logging, and secrets handling are outside Warp's built-in responsibilities.
• Source builds trust the selected package indexes, Packman configuration, CUDA Toolkit, LLVM/Clang installation, compilers, linkers, environment variables, and CI runners used to produce native libraries and wheels.

Security reports are in scope when they affect Warp's tracked source, packaged Python APIs, native libraries, JIT compilation pipeline, kernel cache behavior, supported interop APIs, APIC graph loading, Volume/NanoVDB loading, memory management, release artifacts, or build/release tooling.

The following are generally out of scope unless they demonstrate a vulnerability inside Warp itself:

• Expected code execution from intentionally running untrusted Python code, untrusted @wp.kernel definitions, untrusted @wp.func_native snippets, or untrusted compiled object/PTX/CUBIN artifacts.
• Denial of service caused only by intentionally launching extremely large kernels, allocating excessive memory, or running examples with unrealistic local inputs.
• Misconfigured deployments where a service exposes Warp compilation or asset loading to unauthenticated users without upstream validation.
• Issues in third-party frameworks or drivers that can be reproduced without Warp and do not involve a Warp-specific integration path.
• Public disclosure through issues, pull requests, discussions, or merge requests before NVIDIA PSIRT has had an opportunity to coordinate remediation.

Warp declares its Python packaging contract in pyproject.toml and maintains uv.lock for repository development, CI, documentation, examples, optional extras, and release workflows. A vulnerability reported only from uv.lock should identify whether the affected package is used by the default runtime install, an optional extra such as a framework integration, docs or test tooling, CI, or release-build infrastructure.

Maintainers triage lockfile findings based on reachability, affected artifact, and whether the dependency is declared by published wheel metadata, used to build or validate release artifacts, or only used during development. For example, a scanner finding against an optional PyTorch, JAX, Paddle, docs, or examples dependency may have a different impact than a finding against a dependency required by the default warp-lang install.

Warp dependency minimums are compatibility requirements, not a complete security blocklist for historical third-party releases. Maintainers do not raise package minimums solely because an older allowed version of a dependency has a CVE. Dependency CVEs are triaged based on whether the vulnerable behavior is reachable through Warp, whether the affected version is selected by Warp's normal development or release workflows, and whether the dependency is part of the default runtime contract or an optional extra. Users and downstream distributors remain responsible for applying dependency constraints when their environments require patched third-party versions.

Security fixes may be delivered through repository commits, release branches, Python wheels, documentation updates, GitHub or GitLab advisories, CVEs, and NVIDIA security bulletins, depending on severity and affected artifacts. Consumers should keep Warp, CUDA drivers, CUDA Toolkit components, Python dependencies, and downstream framework integrations current according to their deployment requirements.

For source builds, use trusted toolchain paths and package sources, avoid world-writable build and cache directories, and review build logs when overriding CUDA, LLVM/Clang, libmathdx, or package index settings.