CVE-2026-13236: Tool and Field Authorization in Drupal AI Agents

TL;DR

Drupal SA-CONTRIB-2026-056 states that AI Agents did not sufficiently check required permissions when a tool loaded content entities. Exploitation required an agent to be configured with the affected tool and an attacker to have access to that agent.

The affected ranges are below 1.1.4, 1.2.0–1.2.4, and 1.3.0. Upgrade to 1.1.4, 1.2.5, or 1.3.1 as appropriate. The Drupal advisory credits Kuniyoshi Noguchi (kuninogu) under both Reported By and Fixed By.

JVN#20592637 classifies the issue as incorrect authorization (CWE-863) and states that a user's password could be obtained, enabling account takeover. This makes field-level output control a security boundary, not merely a privacy or presentation concern.

Why it matters

An AI agent adds an indirect path to application data:

user -> agent -> selected tool -> entity loader -> fields -> model/user output

A user may legitimately be allowed to open an agent while remaining unable to read a particular entity or sensitive field. Likewise, an agent may expose many tools but be configured to use only a subset. Treating “can use the agent” as a blanket authorization for everything reachable through its tools turns the agent into a confused deputy.

This matters beyond Drupal. Agentic systems often concentrate capabilities that were previously split across UI routes and APIs. Each tool invocation must preserve the acting principal and reapply the target application's normal authorization at the point of data access and again when shaping output.

Trust Boundary

There are at least four independent decisions:

1. Agent access: may this principal interact with the agent?
2. Tool access: may this agent invoke this particular tool?
3. Entity access: may the acting principal view this entity?
4. Field access: may the acting principal view every field selected for the tool result?

The trust boundary is crossed when an agent/tool request becomes a Drupal entity load and then a serialized result. The original principal's authority must remain attached to that operation. Loading an entity successfully is not proof that every field is safe to return, and hiding a field in the UI is not an authorization check.

The public advisories do not identify the exact affected tool name, route, prompt, method, or patch hunk. This article therefore describes the verified authorization class and defensive invariants without inventing an exploit path.

Root Cause

Drupal's published root-cause statement is intentionally concise: the module did not sufficiently check the required permissions when a tool loaded content entities. JVN describes the class as CWE-863, Incorrect Authorization.

At minimum, the content-loading path failed to preserve or enforce every access decision required for the returned data. Because JVN identifies possible password disclosure, a complete regression strategy must test sensitive-field access as well as whole-entity access.

The failure can be modeled as an invalid authorization implication:

can_use_agent = true
does NOT imply can_use_every_tool
does NOT imply can_view_every_entity
does NOT imply can_view_every_field

Whether the implementation error was a missing entity check, a missing field check, an incorrect acting account, or a combination is not specified at function level in the cited public advisory. No narrower code-level claim is made here.

Safe reproducer

Use only a local or isolated Drupal environment with synthetic data. Never test with a real user's password or ask a production agent to retrieve secrets.

1. Install the fixed branch appropriate to the environment: 1.1.4, 1.2.5, or 1.3.1.
2. Create a synthetic entity or test account containing a canary such as CANARY-NOT-A-REAL-SECRET in a field that the test user is explicitly denied permission to view.
3. Create a least-privileged test user who may access the test agent, but may not access the protected entity or field through Drupal's normal application path.
4. Enable only the required test tool for the agent and invoke it against only the synthetic record.
5. Confirm that the tool denies the operation or filters the protected field, the canary never enters model context or output, and the denial is logged.
6. Grant the missing permission and repeat. The authorized value should now be returned, proving that the test exercised authorization rather than a broken tool.
7. Delete the synthetic record, conversation, and test account according to the lab's retention policy.

This validates the fixed security property without disclosing a product-specific prompt, route, or real secret. Version inventory—not an attempt to exploit an old production instance—should be used to determine historical exposure.

Fix assessment

Drupal lists three fixed versions because the module had multiple supported branches: 1.1.4, 1.2.5, and 1.3.1. The public advisory names multiple fix contributors, including the reporter, but does not publish a line-by-line security patch explanation. The assessment should therefore focus on observable authorization outcomes.

A complete fix should:

• evaluate access using the real acting principal, not a default, ambient, or privileged service identity;
• deny a tool that the agent is not configured to use;
• enforce entity access before reading or serializing content;
• enforce access for every returned field, including computed or referenced data;
• keep authorization/cache metadata attached to the result so one user's result cannot be reused for another user;
• fail closed when identity or access information is missing;
• exclude denied values from model context, logs, traces, and error messages—not only from the final chat response.

The last point is important: filtering the visible answer after a secret has already entered the model prompt does not undo disclosure to the model provider or observability pipeline.

Regression tests

Use an authorization matrix rather than only “administrator” and “anonymous” tests:

Repeat the matrix for referenced entities, revisions, translations, computed fields, and cached responses. Also assert that the canary is absent from LLM request bodies, tracing systems, exception logs, and conversation history in every denied case.

Detection

Telemetry required

For each tool call, record a correlation or run ID plus the acting user ID, agent ID, tool ID, entity type and ID, requested fields, returned fields, and entity/field authorization result. Do not log field values or prompts containing secrets. Drupal's standard logs may not provide all of this context, so explicit tool-boundary audit events may be required.

A high-signal invariant is:

returned_fields INTERSECT denied_fields MUST equal empty_set

If audit events are normalized with counts, the following illustrative SPL finds violations. Replace the index and field names with the deployed schema:

index=YOUR_DRUPAL_INDEX event_type=ai_agent_tool_result
| where returned_field_count > 0 AND denied_field_count > 0
| stats count values(entity_type) as entity_types
        values(tool_id) as tools values(run_id) as run_ids
  by user_id agent_id
| sort - count

Also hunt for access to account/user entities, bursts of entity reads from one agent session, tools invoked by users who cannot reach the equivalent normal route, and sensitive canary identifiers in model gateway or DLP telemetry. The query above is useful only after the application emits an authorization-aware event; it is not a claim about default Drupal field names.

Incident Response

1. Disable affected tools or restrict access to the affected agents while preserving logs and configuration.
2. Record module versions and the agent-to-tool configuration for every Drupal instance.
3. Preserve Drupal logs, agent conversations, tool-call audit events, model gateway metadata, reverse-proxy logs, and relevant database audit records.
4. Identify the exposure window and enumerate principals, agents, tools, entities, and fields involved. Compare each observed read with the principal's authorization at that time where records permit.
5. Because JVN identifies possible password disclosure, force reset or rotate any credential that may have been returned, revoke sessions, and investigate subsequent account activity. Rotate other secrets according to their scope.
6. Upgrade to the fixed branch, invalidate authorization-sensitive caches, and execute the regression matrix before re-enabling tools.
7. Review data sent to external model or tracing providers and apply contractual notification and deletion procedures where necessary.

Avoid copying sensitive tool output into incident tickets. Preserve hashes, identifiers, and access metadata when the raw value is not required.

Disclosure Timeline

• Researcher report date: not published in the cited public advisories.
• 2026-06-24: Drupal published SA-CONTRIB-2026-056, listed 1.1.4, 1.2.5, and 1.3.1 as fixed releases, and credited Kuniyoshi Noguchi (kuninogu) as both reporter and fix contributor.
• 2026-07-21: JVN published JVN#20592637 and credited Kuniyoshi Noguchi (@KuniNogu) for reporting the issue to the developer and IPA.
• Private coordination and patch-review dates: not disclosed in the cited public advisories.

Primary sources

• Drupal SA-CONTRIB-2026-056: AI Agents — Access bypass
• JVN#20592637: Drupal plugin “AI Agents” vulnerable to incorrect authorization
• CVE-2026-13236 record