Confused Deputy File Read: Testing Attachment Paths for CVE-2026-81375

TL;DR

CVE-2026-81375 is a confused deputy flaw in the Email Task component of Google Cloud Application Integration: an authenticated user could supply a crafted attachment path and read files their account had no right to open. The root cause is a principal mismatch — the integration runtime resolved and opened the file under its own service identity, so the caller's permissions never entered the decision. Google's bulletin GCP-2026-066 states that Email Task versions prior to June 30, 2026 are affected and that the managed service was patched on that date. To prove impact in your own environment, plant a canary outside the intended attachment root, drive the attachment path from two accounts, and compare what each one retrieves. The finding holds when the canary bytes arrive in a delivered message next to an execution record showing the path resolved outside the configured root.

What this is

A confused deputy is an authorization defect in which a component holding more privilege than its caller performs an action on the caller's behalf and applies its own permissions rather than the caller's. The caller cannot read the file. The deputy can. The deputy reads it anyway, because nothing in the code path asked whose file it was.

In CVE-2026-81375 the deputy is the Email Task component. An email step carrying an attachment has to resolve a file reference at execution time, and that resolution happens server-side under the identity the integration runtime runs as — an identity with broader filesystem reach than the person who authored the integration. A crafted path (relative traversal, absolute path, encoded variant) escapes the directory the attachment was supposed to come from, and the runtime opens whatever it lands on.

This is worth separating from IDOR, which it superficially resembles. In an IDOR the authorization check is missing. Here a check exists — it was simply evaluated against the wrong principal. That distinction matters for detection: there may be no denied-access event to alert on, because from the runtime's point of view nothing was denied.

Why it matters

Three assumptions fail at once.

• "The caller is authenticated, so the blast radius is bounded." Authentication tells you who asked. It says nothing about what the deputy can reach. An account with the minimum role needed to author an integration inherits the runtime's read scope for the duration of that execution.
• "Path traversal is a web-tier problem." The path never touches a URL parser you control. It is a store → resolve → read pipeline inside a managed platform, exactly the kind of code path that gets skipped in review because it does not look like a request handler.
• "The recipient list is the data boundary." It is not. When the read primitive and the egress channel are the same feature, the exfiltration path is the application working as designed.

The affected population is anyone who ran Application Integration Email Tasks before June 30, 2026, plus every team that has written the same pattern themselves: a caller-supplied path handed to a file API under a service account. The platform fix covers the platform. It does not cover your copy of the pattern.

How it works

Affected versions. Email Task in Application Integration, versions prior to June 30, 2026, as stated in Google Cloud security bulletin GCP-2026-066 (bulletin index). Google patched the managed service on June 30, 2026 and published the bulletin on September 28, 2026; the vendor position is that no customer action is required for the service. Treat that as the vendor's position on the vendor's code, not as a reason to skip testing yours.

Mechanism. The email step accepts an attachment reference. At execution the runtime normalizes that reference and opens it using its own credentials. Traversal sequences, absolute paths, and encoding variants that survive normalization all resolve to locations outside the intended attachment directory. Because the read executes as the deputy, the caller's IAM policy is never consulted — there is no per-object authorization decision to log.

Validation, two accounts. The shape is the standard authorization test: one suspicion, two principals, a response comparison, then proof.

1. Prepare Account A and Account B in separate projects or tenants, each holding only the role needed to author and run an integration with an email step.
2. Plant a canary — a small text file containing a unique marker string and its own SHA-256 — in a location B can read and A cannot, outside the integration's configured attachment root.
3. As A, configure the attachment path to reach B's canary using several variants: ../ traversal, an absolute path, a percent-encoded sequence (%2e%2e%2f), and a doubled encoding (%252e%252e%252f).
4. Execute and capture both the delivered message and the execution record.
5. Repeat as B targeting a canary owned by A, to confirm the direction of the flaw rather than a one-off misconfiguration.
6. Run a benign path and a nonexistent path as controls, so you know what success and failure look like before you interpret the traversal result.

Reading the result. If A's execution returns B's canary bytes, A has demonstrated a read of data it holds no permission on, executed by a principal that does. If both directions succeed, the flaw is symmetric and belongs to the platform, not to one tenant's configuration. If only one direction succeeds, check whether the failure is an authorization denial or a path that simply did not resolve — those are different findings.

Evidence to attach. The marker string as it appears in the delivered attachment, the SHA-256 of the canary and of the received bytes, the execution log line showing the resolved path outside the configured root, the timestamp, both account identifiers, and the exact path variant that succeeded. That set survives handoff to a second researcher, which is the only test of evidence quality that matters.

Detection and response

For the managed service, the retro-hunt question is historical: was an email step in your project executed with an attachment path that escaped the configured storage scope, at any point before June 30, 2026? Pull execution history for the affected window and filter for attachment resolutions that are not simple filenames inside the expected root — traversal sequences, absolute paths, encoded separators, unexpected path depth. Correlate with who authored or last modified those integrations, and whether the recipient domain was internal or external. A traversal that resolves and mails out is both the read and the exfiltration in a single event.

For your own code, the telemetry is different. Instrument the file-resolution function to log the resolved absolute path, the service identity used for the read, and the caller identity that supplied the reference. Alert when the resolved path leaves the configured root — not when the input string looks suspicious, because input-string matching is a filter on syntax you do not control. Watch egress too: messages with attachments to newly seen external domains, and attachment sizes that do not match anything the integration was designed to send.

Finally, look for the absence of a signal. If your only detection is "access denied" events, a confused deputy produces none. The read succeeded under a legitimate identity. The anomaly lives in the path, not in the result.

What to do

1. Inventory the pattern. Grep your codebase and your integration definitions for any place a user- or config-supplied path is passed to a file API (open, read, attach, download, import) under a service identity. That list is your real scope.
2. Confirm the platform timeline. If you used Email Tasks before June 30, 2026, treat the historical window as unverified and hunt through execution history rather than assuming nothing happened.
3. Break the deputy chain in your own code. Canonicalize the path first, then verify the canonical result is a child of the allowed root, then read using a credential scoped to that root. Checking the raw string before canonicalization is not a control.
4. Scope the reader identity. The process that opens attachments should not be able to open anything else. If it can, the next traversal is not a vulnerability report — it is a repeat.
5. Run the two-account test on every attachment feature you own. One canary, two principals, both directions. Record the evidence before you fix: path variant, execution identifier, canary hash, resolved path, timestamp.
6. Retest after remediation with the identical canary and the identical path variants, and note which variant is now blocked — partial normalization fixes fail on the encoded cases. Do not probe provider-internal paths: prove the primitive with a file you control.

FAQ

Is CVE-2026-81375 exploitable without credentials? No. The bulletin describes an authenticated attacker. The severity comes from what the authenticated caller can reach through the deputy, not from pre-auth access.

Do I need to patch anything? The managed service was patched on June 30, 2026 and Google states no customer action is required. The action that remains is yours: verify no equivalent pattern exists in your own attachment handling, and hunt the pre-patch execution window if you used the component.

How is this different from ordinary path traversal? Plain path traversal (CWE-22) is about escaping a directory. The confused deputy element (CWE-441) is about who performs the read. The traversal is the technique; the privilege mismatch is why the impact is cross-tenant file disclosure rather than a leak of the caller's own files.

What counts as proof of impact? Reading one file the calling account holds no permission on, with the bytes and a hash, plus a log record showing the resolved path outside the intended root. A crafted path that produces an error proves nothing. A crafted path that returns another account's data proves everything.

Would a WAF or input filter have stopped it? Do not assume so, and do not assume it without testing. A filter that matches traversal syntax runs before the deputy resolves the path, and normalization differences between the filter and the file API are exactly where encoded variants survive. Only a post-canonicalization containment check is structurally sound.

Where this fits in a program

The two-account canary test is a repeating obligation, not a one-time CVE check: every attachment, import, and export feature that takes a caller-supplied path needs the same comparison, and the result needs to be a validated finding rather than a scanner hit. Trusteed is an AI workspace for security research built around that split — attack surface, investigation of the live application, and evidence a second person can check.

Sources

• Google Cloud security bulletin GCP-2026-066 (CVE-2026-81375, Email Task, Application Integration): https://docs.cloud.google.com/support/bulletins/index#gcp-2026-066
• NVD entry for CVE-2026-81375: https://nvd.nist.gov/vuln/detail/CVE-2026-81375
• CWE-441: Unintended Proxy or Intermediary ('Confused Deputy'): https://cwe.mitre.org/data/definitions/441.html
• CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'): https://cwe.mitre.org/data/definitions/22.html
• OWASP: Path Traversal: https://owasp.org/www-community/attacks/Path_Traversal
• Trusteed: https://trusteed.io