Database/AI/ML frameworks & serving
TrustyAI Service Operator: unauthenticated access to AI guardrail and orchestrator APIs
Impact
Guardrail and orchestrator APIs are reachable without authentication from anywhere on the cluster network. An attacker who can reach them reads or reconfigures the guardrails meant to constrain model behaviour, so the safety layer a deployment depends on can be turned off without touching the model itself.
Who can reach it
Any workload with cluster network access to the operator's services.
What to do
Upgrade the TrustyAI Service Operator to the fixed release from Red Hat, then put a NetworkPolicy in front of the guardrail and orchestrator services and require mTLS between them. The operator restart is a rolling one; no node work.
References
Related entries
- llama.cpp: oversized seq_id in a saved slot file leaks heap memory past the cells arrayCVE-2026-43630 · llama.cpp server (recurrent memory state slot-restore path)Medium
- vLLM: race in the prompt_embeds sparse-tensor guard reopens the CVE-2025-62164 crash pathCVE-2026-73557 · vLLM prompt_embeds loader (safe_load_prompt_embeds sparse-tensor guard)Medium
- Eclipse Che dashboard backend (POST /dashboard/api/data/resolver): The dashboard backend passes a user-supplied URLCVE-2026-86590 · Eclipse Che dashboard backend (POST /dashboard/api/data/resolver)Medium
- vLLM: allowed_token_ids validated against tokenizer length, corrupting shared GPU logit-bias stateCVE-2026-93840 · vLLM (SamplingParams allowed_token_ids validation / LogitBiasState)Medium
- vLLM: unbounded prompt token ids write out of bounds in the penalty bincount Triton kernelCVE-2026-93841 · vLLM (Triton _bincount_kernel, penalty prompt-presence bitset)Medium
- OpenLLM: Local file inclusion via the web applicationCVE-2024-8982 · OpenLLMMedium
This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.