What happened
In the disclosed scenario, a low-privileged user edits a shared agent and a later interaction by a higher-privileged user causes that agent to carry out privileged operations under the victim's identity.
2026-09-26
HighVendor postKibana Agent Builder Could Spend a Privileged User's Authority Through a Shared Agent
Analysis of CVE-2026-72668, where a user who could edit a shared Kibana agent could cause later privileged interactions to execute under the victim's identity.
Kibana Agent BuilderGovernance bypassConfused-deputy privilege escalation through editable shared-agent configurationElastic Kibana 9.4.0 through 9.4.6 with Agent Builder shared agents
Why it matters
Potential unauthorized privileged operations in Kibana and, where workflow authoring is available, administrative control of Kibana and the connected Elasticsearch cluster.
Missing authorization check
A use-time authorization decision binding the authenticated requester, agent configuration version, workflow, exact privileged operation, target resource, and approving principal.
Would PP block it?
Editing the shared agent would not create a valid receipt for later privileged operations. At execution time, the operation, resource, agent configuration, requesting identity, and policy decision must match the signed authority or the action fails closed.
Incident analysis
Timeline and technical read
Timeline
2026-09-26
Elastic publishes ESA-2026-85 and CVE-2026-72668 for the Agent Builder confused-deputy vulnerability.
2026-09-26
Elastic identifies Kibana 9.4.7 and 9.5.0 as fixed releases.
Technical breakdown
- A non-administrative user has permission to edit an agent shared with other users.
- The attacker changes the shared agent so a later interaction can select privileged operations.
- A higher-privileged user interacts with that agent, and the operations execute under the higher-privileged identity.
- When the attacker can also author workflows, Elastic says the escalation can reach administrative control of Kibana and the Elasticsearch cluster.
Authorization boundary
Where the authorization boundary should have been
This incident is categorized as Governance bypass. The relevant Permission Protocol gate is Tool-Call Gate. The read is conditional: the block only applies where the real action boundary is routed through a gate.
- If enforced at
- Kibana and Elasticsearch privileged-operation boundary immediately before side effects
- Still needs
- Permission Protocol does not patch Kibana, prevent malicious shared-agent edits, or replace least-privilege roles and upgrade management.
- Receipt required for
- Executing the exact privileged Kibana or Elasticsearch operation selected by a shared agent under a named principal
A Tool-Call Gate can require fresh, payload-bound authority for each privileged Kibana or Elasticsearch action instead of treating the interacting user's session as blanket permission for a shared agent.
Start small
Put the relevant gate at this action boundary.
This incident maps to Tool-Call Gate. Start with the boundary that controls the actual action, then require a signed receipt before execution.