CVE-2026-19274: IBM Instana Agent Operator RBAC Hijacking in Kubernetes — Detection and Remediation Guide

On the surface, CVE-2026-19274 is a narrowly scoped operator bug. In practice, it is a tenant-isolation failure in one of the most sensitive layers of any multi-tenant Kubernetes platform: cluster-scoped RBAC. NVD has published CVE-2026-19274 with a CVSS score of 9.6 (CRITICAL), network-exploitable, affecting the IBM Observability with Instana Agent Operator, builds 1.0.303 through 1.0.323. Any authenticated tenant with permission to create a custom resource in their own namespace can hijack or permanently destroy the cluster-level RBAC permissions belonging to another tenant's Instana agent — blinding security and observability teams exactly where they depend on telemetry most.

If you run Instana agents in a shared or multi-tenant cluster — and most enterprise observability deployments are exactly that — you should treat this as an urgent remediation item. The vulnerability requires only namespace-level write access to exploit, and the blast radius is cluster-wide.

Technical Analysis

Affected Products and Versions

• Product: IBM Observability with Instana (Agent) — specifically the Instana Agent Operator
• Affected builds: 1.0.303 through 1.0.323 (inclusive)
• Platform: Any Kubernetes distribution running the vulnerable operator; multi-tenant clusters are at highest risk
• CVE: CVE-2026-19274 — CVSS 9.6 (CRITICAL), attack vector NETWORK

Root Cause: Cluster-Scoped Objects Keyed by Bare CR Name

The flaw is a classic namespace-confusion design error. When the Instana Agent Operator reconciles an InstanaAgent custom resource (CR), it creates and manages cluster-scoped RBAC objects — ClusterRole and ClusterRoleBinding resources — that grant the agent the permissions it needs to monitor the cluster. The defect: those cluster-scoped objects are named and keyed solely by the bare CR name, with no namespace disambiguation.

In a correctly designed operator, the generated cluster-scoped resource name would incorporate the CR's namespace (e.g., instana-agent-<namespace>-<name>), guaranteeing uniqueness across tenants. Here, two InstanaAgent CRs named prod-agent in two different namespaces both map to the same ClusterRoleBinding.

Attack Chain (Defender's View)

1. Prerequisite: The attacker holds an authenticated identity with permission to create/update/delete InstanaAgent CRs in any namespace they control. In multi-tenant environments (internal platform teams, managed Kubernetes offerings, shared dev clusters), this is routine tenant access — not a privileged position.
2. Reconnaissance: The attacker enumerates existing InstanaAgent CRs cluster-wide (or guesses a conventional name such as instana-agent or default) and inspects the resulting ClusterRoleBinding names.
3. Exploitation — Overwrite path: The attacker creates an InstanaAgent CR with the same name in their own namespace. The operator reconciles it and silently overwrites the shared ClusterRoleBinding's subjects/roleRef, repointing the binding at the attacker's service account. The attacker inherits the victim agent's cluster-level monitoring permissions — typically broad read access across the cluster.
4. Exploitation — Destruction path: Alternatively, the attacker deletes their same-named CR (or crafts the reconcile to fail), causing the operator to delete the ClusterRoleBinding outright. The victim tenant's agent loses cluster monitoring access — a denial of observability that can mask subsequent attacker activity from the very tooling meant to catch it.

The second path is the one that should worry incident responders most: destroying an agent's cluster visibility is an ideal precursor move before acting on other objectives in the cluster.

Exploitation Status

As of publication, there is no confirmed in-the-wild exploitation and the CVE has not been added to CISA's Known Exploited Vulnerabilities catalog. Exploitation requires authenticated CR-write access, which limits remote opportunistic abuse — but in shared-cluster environments the pool of potential attackers includes every tenant. Do not wait for a KEV listing; the privilege-escalation and observability-kill primitives are too useful in post-compromise tradecraft.

Detection & Response

The strongest telemetry source here is the Kubernetes audit log from the API server. Ensure audit logging is enabled and captures create, update, patch, and delete verbs on clusterrolebindings, clusterroles, and the instanaagents custom resource (agent.instana.io group). Ship those logs to your SIEM before you need them.

Sigma Rules

---
title: Kubernetes ClusterRoleBinding Deleted or Modified Outside Instana Operator Reconcile
description: Detects deletion or modification of ClusterRoleBindings referencing Instana agent RBAC by identities other than the expected operator service account. May indicate CVE-2026-19274 exploitation where a tenant hijacks or destroys another tenant's cluster-level RBAC.
id: 9c1e4a72-3b58-4f6d-a921-7d5e2c8b3041
status: experimental
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-19274
  - https://attack.mitre.org/techniques/T1078/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.privilege_escalation
  - attack.defense_evasion
  - attack.t1078
logsource:
  product: kubernetes
  service: audit
detection:
  selection_verb:
    verb:
      - delete
      - update
      - patch
  selection_resource:
    objectRef.resource: clusterrolebindings
  selection_target:
    objectRef.name|contains: instana
  filter_operator:
    user.username|contains:
      - 'system:serviceaccount:instana-agent'
      - 'instana-agent-operator'
  condition: selection_verb and selection_resource and selection_target and not filter_operator
falsepositives:
  - Cluster administrators legitimately modifying Instana RBAC during upgrades or migrations
level: high
---
title: InstanaAgent Custom Resource Created in Non-Standard Namespace
description: Detects creation of an InstanaAgent CR in a namespace outside the approved operator/agent namespaces. A same-named CR in an attacker-controlled namespace is the exploitation vector for CVE-2026-19274 RBAC hijacking.
id: 2f7b8d14-6c49-4e31-b805-9a3c1d6e5278
status: experimental
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-19274
  - https://attack.mitre.org/techniques/T1078/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.privilege_escalation
  - attack.persistence
logsource:
  product: kubernetes
  service: audit
detection:
  selection_verb:
    verb:
      - create
      - update
      - patch
  selection_resource:
    objectRef.resource: instanaagents
  filter_approved_ns:
    objectRef.namespace:
      - instana-agent
      - instana-operator
  condition: selection_verb and selection_resource and not filter_approved_ns
falsepositives:
  - Legitimate agent deployments to new namespaces; maintain the approved-namespace list as your environment evolves
level: medium

Tune filter_approved_ns to the namespaces where your organization legitimately deploys InstanaAgent CRs. In most environments that list is one or two entries — anything outside it deserves a look.

KQL — Microsoft Sentinel (kube-apiserver audit via Syslog ingestion)

This query hunts for the two exploitation primitives: RBAC tampering on Instana ClusterRoleBindings by non-operator identities, and duplicate InstanaAgent CR names appearing across multiple namespaces (the collision condition that enables the hijack).

// Hunt 1: Instana ClusterRoleBinding modified/deleted by non-operator identities
Syslog
| where Facility == "local0" or ProcessName has "kube-apiserver"
| where SyslogMessage has "clusterrolebindings" and SyslogMessage has "instana"
| extend Audit = parse_json(SyslogMessage)
| extend Verb = tostring(Audit.verb),
         User = tostring(Audit.user.username),
         ObjName = tostring(Audit.objectRef.name),
         SourceIP = tostring(Audit.sourceIPs[0])
| where Verb in ("delete", "update", "patch")
| where User !has "instana-agent" and User !has "system:serviceaccount:instana"
| project TimeGenerated, Verb, User, ObjName, SourceIP
| sort by TimeGenerated desc;

// Hunt 2: Same-named InstanaAgent CRs reconciled across multiple namespaces (collision condition)
Syslog
| where SyslogMessage has "instanaagents"
| extend Audit = parse_json(SyslogMessage)
| extend Verb = tostring(Audit.verb),
         User = tostring(Audit.user.username),
         CRName = tostring(Audit.objectRef.name),
         Namespace = tostring(Audit.objectRef.namespace)
| where Verb in ("create", "update", "patch") and isnotempty(CRName)
| summarize Namespaces = makeset(Namespace), Users = makeset(User), LastSeen = max(TimeGenerated) by CRName
| where array_length(Namespaces) > 1
| project CRName, Namespaces, Users, LastSeen;

Hunt 2 is your high-fidelity tripwire: the same CR name live in two namespaces is the precondition for this attack and has almost no legitimate reason to exist.

Velociraptor VQL — Node-Level Hunt

For endpoint coverage on cluster nodes or admin workstations, hunt for interactive kubectl activity touching Instana CRs or clusterrolebindings — exploitation from a compromised developer or CI identity will frequently traverse a shell session.

-- Hunt for kubectl usage targeting InstanaAgent CRs or ClusterRoleBindings (CVE-2026-19274 precursors)
SELECT Pid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE Name =~ '(?i)kubectl'
  AND CommandLine =~ '(?i)instanaagent|clusterrolebinding'
  AND CommandLine =~ '(?i)create|apply|delete|patch|edit'

Remediation and Verification Script

Run this from a context with cluster-admin read access. It reports operator build version, flags duplicate InstanaAgent CR names across namespaces (the exploitable collision), and lists the current state of Instana ClusterRoleBindings so you can verify subjects point at the correct tenant service accounts.

#!/bin/bash
# CVE-2026-19274 verification script — Instana Agent Operator RBAC collision check
set -euo pipefail

NS="${INSTANA_NS:-instana-agent}"
echo "=== [1] Instana Agent Operator image/build ==="
kubectl get deployments -A -l app.kubernetes.io/name=instana-agent-operator \
  -o jsonpath='{range .items[*]}{.metadata.namespace}{"/"}{.metadata.name}{" -> "}{.spec.template.spec.containers[0].image}{"\n"}{end}' 2>/dev/null || \
  kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.namespace}{"/"}{.metadata.name}{" -> "}{.spec.containers[0].image}{"\n"}{end}' | grep -i instana || true

echo ""
echo "=== [2] Duplicate InstanaAgent CR names across namespaces (EXPLOITABLE COLLISION) ==="
kubectl get instanaagents.agent.instana.io -A --no-headers 2>/dev/null \
  | awk '{print $2"\t"$1}' | sort | uniq -w 40 -D || echo "No instanaagents CRs found or CRD absent."

echo ""
echo "=== [3] Instana ClusterRoleBindings and their subjects ==="
kubectl get clusterrolebindings -o name | grep -i instana | while read -r crb; do
  echo "--- $crb"
  kubectl get "$crb" -o jsonpath='{.metadata.name}{"  roleRef="}{.roleRef.name}{"  subjects="}{range .subjects[*]}{.kind}{"/"}{.namespace}{"/"}{.name}{"  "}{end}{"\n"}'
done

echo ""
echo "=== [4] Identities that can write InstanaAgent CRs (attack prerequisite) ==="
kubectl get clusterroles,roles -A -o json 2>/dev/null | \
  python3 -c "
import json,sys
d=json.load(sys.stdin)
for i in d.get('items',[]):
    for r in i.get('rules',[]):
        if 'instanaagents' in (r.get('resources') or []) and any(v in (r.get('verbs') or []) for v in ['create','update','patch','delete','*']):
            m=i['metadata']
            print(f\"{i['kind']}/{m['name']} ns={m.get('namespace','-')} verbs={r['verbs']}\")
" || echo "Review RBAC manually: who can create/update instanaagents?"

echo ""
echo "ACTION REQUIRED:"
echo " - If operator build is 1.0.303-1.0.323, upgrade to the fixed build per the IBM security bulletin for CVE-2026-19274."
echo " - If section [2] shows duplicate CR names, treat as potential active compromise: audit subjects in [3] and review API audit logs."
echo " - Restrict create/update/delete on instanaagents CRs to platform admins only (see section [4])."

Any duplicate names in section [2] or unexpected subjects in section [3] should be treated as a potential active hijack and escalated to IR — pull API server audit logs for the reconcile window immediately.

Remediation

1. Upgrade the operator. Builds 1.0.303 through 1.0.323 are vulnerable. Upgrade to the fixed build published after 1.0.323 per IBM's security bulletin for CVE-2026-19274. Verify the running image digest after upgrade — Helm releases and GitOps controllers can silently pin old images.
2. Audit for existing compromise before and after patching. Patching stops new abuse; it does not undo an already-hijacked ClusterRoleBinding. Run the verification script above, confirm every Instana ClusterRoleBinding's subjects reference the intended tenant service account, and diff against your IaC/source-of-truth definitions.
3. Lock down CR write access (immediate workaround). Until patched, restrict create/update/delete on instanaagents.agent.instana.io to platform administrators via RBAC. The vulnerability requires an authenticated tenant to write a CR in their own namespace — removing that permission removes the attack surface entirely.
4. Enforce naming uniqueness as policy. Deploy an admission control policy (OPA Gatekeeper or Kyverno) that rejects any InstanaAgent CR whose name collides with an existing CR in another namespace, and confines CR creation to approved namespaces. This kills the collision precondition even on unpatched builds.
5. Enable and centralize Kubernetes audit logging. If API server audit logs aren't flowing to your SIEM today, that gap is why this class of attack is quiet. Prioritize clusterrolebindings, clusterroles, and CRD writes.
6. Monitor for observability gaps. A destroyed ClusterRoleBinding manifests as an agent going dark. Alert on Instana agents that stop reporting for a tenant — treat unexplained telemetry loss in a multi-tenant cluster as a security event, not an ops ticket.

References: NVD — CVE-2026-19274. Check IBM's security bulletin portal for the official fix build and advisory; if CISA adds this CVE to the KEV catalog, federal remediation deadlines will apply.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub