Adversarial Robustness Toolbox (Kubeflow component, robustness_evaluation_fgsm_pytorch.py): The ART Kubeflow evaluation

Impact

The ART Kubeflow evaluation script passes the --clip_values and --input_shape arguments through eval(), so whoever controls those strings executes arbitrary Python inside the pipeline pod. On a GPU cluster that pod usually holds the pipeline service account and mounted dataset volumes, which is the payoff. This is the third of a family whose two siblings, CVE-2026-31228 and CVE-2026-31229, are already in the database.

Who can reach it

Anyone who can influence the pipeline configuration or the automated scripts that invoke the ART robustness evaluation step - so a tenant with pipeline-authoring rights, or an upstream component that builds the argument list from user-supplied data.

What to do

Upgrade the adversarial-robustness-toolbox package past 1.20.1 wherever the Kubeflow ART component is deployed. Note this is a pip package pulled into pipeline images, so patching Kubeflow itself does not fix it - you have to rebuild the component images.

References

Related entries

• llama.cpp (RPC `deserialize_tensor`): RPC backend skips all bounds validationCVE-2026-34159 · llama.cpp (RPC `deserialize_tensor`)Critical
• Apache OpenNLP: model archive manifest names any classpath class and runs its static initializerCVE-2026-42027 · Apache OpenNLP ExtensionLoader (model archive manifest.properties)Critical
• LiteLLM proxy: SQL injection in a database query pathCVE-2026-42208 · LiteLLM proxyCritical
• PyTorch Lightning: Reintroduced unsafe deserialization in 2.6.2CVE-2026-44484 · PyTorch LightningCritical
• LiteLLM proxy: Host-header parsing flaw in the proxyCVE-2026-49468 · LiteLLM proxyCritical
• SGLang (`/v1/rerank`): RCE via a malicious `tokenizer.chat_template` rendered as Jinja2CVE-2026-5760 · SGLang (`/v1/rerank`)Critical