Preface: NVIDIA FLARE allows research and data scientists to adapt existing ML/DL workflow to federated learning paradigm.

Background: A critical Insecure Direct Object Reference (IDOR) vulnerability was identified in the NVIDIA NVFlare Dashboard (CVE-2026-24178). In federated learning environments—where privacy is paramount (e.g., HIPAA-compliant medical research)—this flaw allowed unauthorized users to bypass access controls and interact with data belonging to other participants.

The Dashboard’s RESTful API previously relied on user-supplied identifiers (such as job_id or user_id) to retrieve records. While the system verified that a user was logged in (Authentication), it failed to verify if that user actually owned or was authorized to access the specific record requested (Authorization). This allowed an attacker to simply change a numeric ID in an API request to view, modify, or delete sensitive information outside their scope.

Vulnerability details: NVIDIA NVFlare Dashboard contains a vulnerability in the user management and authentication system where an unauthenticated attacker may cause authorization bypass through user-controlled key. A successful exploit of this vulnerability may lead to privilege escalation, data tampering, information disclosure, code execution, and denial of service.

Remediation: The Patch
The vulnerability is fully addressed in NVIDIA FLARE SDK v2.7.2. The fix implements Attribute-Based Access Control (ABAC) by:

• Decoupling Trust: The backend no longer trusts the ID provided in the request URL/body as the sole source of authority.
• Enforcing Ownership: Every database query now automatically injects an owner_id or org_id filter derived from a secure, server-side session.
• Silent Rejection: Unauthorized requests now correctly return a 403 Forbidden error, ensuring data isolation between collaborating parties.

Official announcement: Please refer to the link for details –

https://nvidia.custhelp.com/app/answers/detail/a_id/5819

Preface: Self-service AI is a technology that uses AI techniques (such as chatbots, natural language processing (NLP), and machine learning) to enable customers to solve problems or find information themselves anytime, anywhere, without interacting with human customer service. It acts as a digital agent, providing instant assistance through channels such as websites, instant messaging applications, and voice systems.

Background: In the context of Amazon Content Designer, the result of using static-eval depends entirely on the AST (Abstract Syntax Tree) generated from your string and the Context (variables) you provide. The primary goal of static-eval is to return a plain JavaScript value without using the dangerous eval() function.

An Abstract Syntax Tree (AST) in the context of static evaluation (static-eval) is a hierarchical, tree-structured representation of source code that captures its logical and structural meaning without requiring the code to be executed.

In static analysis, the code is parsed into this tree format, allowing tools to traverse, analyze, and manipulate the structure to find potential bugs, security vulnerabilities, or styling issues before runtime.

Vulnerability details: Improper use of the static-eval npm package in the open source solution qnabot-on-aws versions 7.2.4 and earlier may allow an authenticated administrator to execute arbitrary code within the fulfillment Lambda execution context by injecting a crafted conditional chaining expression via the Content Designer interface, which bypasses the intended expression sandbox through JavaScript prototype manipulation. This may grant direct access to backend resources (Lambda environment variables, OpenSearch indices, S3 objects, DynamoDB tables) that are not exposed through normal administrative interfaces. We recommend you upgrade to version 7.3.0 or above.

Official announcement: Please refer to link for details –

https://nvd.nist.gov/vuln/detail/CVE-2026-7191

Preface: When a Pod’s spec[.]schedulerName is set to kai-scheduler, the default scheduler will completely ignore the Pod, and only the KAI Scheduler’s ServiceAccount permissions will intervene to handle the scheduling and resource binding of the task.

Background: The vulnerability stems from how the scheduler tracks and authorizes GPU resources across different namespaces when using the Reservation Pod mechanism .

1.Improper Isolation: In a multi-tenant environment, the scheduler is supposed to enforce strict isolation between namespaces .

2.Cross-Namespace References: The flaw allows an attacker with access to one namespace to craft a pod definition (such as by manipulating annotations or references) that points to or impacts a PodGroup or reservation in a different, unauthorized namespace .

3.Data/Resource Tampering: By setting nvidia[.]com/gpu (an integer resource) while KAI is managing the same physical card via fractional annotations (like gpu-fraction: “0.5”), you could cause the scheduler to miscalculate or “lose track” of the actual hardware state .

Exploitation: An attacker could use these cross-namespace references to “poach” GPUs reserved for other tenants, leading to data tampering (modifying scheduling state) or unauthorized resource access .

Vulnerability details:  NVIDIA KAI Scheduler contains a vulnerability where an attacker could cause improper authorization through cross-namespace pod references. A successful exploit of this vulnerability might lead to data tampering.

Remedy: To mitigate this risk, you should immediately update to NVIDIA KAI Scheduler v0.13.0 or later .

Official announcement: Please refer to link for details –  https://nvidia.custhelp.com/app/answers/detail/a_id/5818

Preface: NVIDIA CUDA-Q is an open-source, hybrid quantum-classical computing platform designed for simulating and controlling quantum processors (QPUs) using GPU acceleration. It acts as a unified programming model, allowing developers to write code in C++ or Python that seamlessly integrates CPUs, GPUs, and various QPU hardware.

Background: The Relationship: Client API vs. Kernel

1. CUDA-Q Client API (The “Host”)

•       Where it runs: On the CPU (Host).

•       What it does: It manages the overall application logic, classical data processing, and the orchestration of quantum tasks. It “calls” the quantum kernels and handles the results.

•       Language: Typically Python or standard C++.

2. CUDA-Q Kernel (The “Device”)

•       Where it runs: On the QPU (Quantum Processing Unit) or a GPU/CPU Simulator.

•       What it does: This is the code marked with __qpu__ (in C++) or @cudaq.kernel (in Python). It contains the actual quantum circuit instructions (Hadamard gates, CNOTs, measurements).

•       Execution: It is compiled into a specific intermediate representation (like QIR) that the backend target understands.

Vulnerability details: NVIDIA CUDA-Q contains a vulnerability in an endpoint where an unauthenticated attacker may cause an out-of-bounds read by sending a maliciously crafted request. A successful exploit of this vulnerability may lead to denial of service and information disclosure.

Official announcement: Please refer to link for details –

https://nvidia.custhelp.com/app/answers/detail/a_id/5820

Ref: To securely manage API keys and mitigate the risk of development environment theft in CUDA-Q projects, consider the following industry-standard practices. This prevents keys from being leaked in the code and provides a buffer in case the laptop environment is compromised.

1. Use Environment Variables This is the most basic and important rule: Never write API keys directly in the code.

• Local development: Edit your [.]bashrc or [.]zshrc file on your system (such as Linux or macOS):

bash export NVQC_API_KEY=”your_secret_key_here”