CVE-2026-19759: Testing an Internal-Only Task Type With Two Accounts

TL;DR

Google's GCP-2026-064 bulletin describes CVE-2026-19759, an incorrect authorization flaw in Application Integration task configuration patched on June 17, 2026: an authenticated user could use an internal-only task type to execute arbitrary internal RPCs from the Google-internal production network under a privileged identity. The class matters more than the ID — an allowlist enforced where a task is configured but not where it executes. You test it with two accounts, one create request, one execute request, and a comparison of the two responses plus the identity the audit log attributes the run to. If the standard-permission account's integration executes and the log names the runtime instead of the user, impact is proven.

What this is

Incorrect authorization here means a function-level decision made in the wrong layer. An "internal-only" task type is a workflow step the platform reserves for its own callers: internal RPC bridges, billing hooks, service-to-service connectors. The restriction exists because the step does not take a tenant-supplied target — it dials something a tenant should never reach directly, using an identity the tenant does not control.

The flag can be enforced badly in at least three places. These are generic patterns seen across workflow and iPaaS platforms, not claims about Google's code:

• Config layer only. The console filters the task type out of the picker. The create/update API still accepts the identifier in the request body.
• Create but not update. The type is validated when an integration is first written, then accepted unvalidated when a later revision changes the task.
• Tenant-scoped, not principal-scoped. The allowlist attaches to the project rather than the calling identity, so every authenticated user in a tenant that has the type enabled inherits it.

The distinguishing question is not "does the UI show it" but "does the executor consult the caller's permissions before dispatching." That is an authorization test on one endpoint, with two principals, ending in a response comparison — not a payload spray.

Why it matters

The affected population is anyone running a workflow platform where a task registry, connector list, or action allowlist gates privileged execution: managed iPaaS, orchestration engines, low-code integration tools, and every in-house "run this step by name" dispatcher.

Three things fail at once:

• The role model is wrong. You believe a standard-permission user cannot reach the privileged path. They can.
• The audit trail is wrong in the same direction. The action is recorded against the runtime's service identity, not the caller. Reviewers see a legitimate system account doing something system accounts do.
• Nobody gets an alert. There is no malformed request, no blocked signature, no authentication failure. The request is well-formed, authenticated, and authorized for something.

Post-authentication makes this an insider and third-party risk problem as much as an external one: a compromised low-privilege integration author, a contractor account, an OAuth token issued to a partner. If you have written the same pattern yourself — a caller-supplied step name handed to a registry lookup — the platform patch does not cover your copy.

How it works

Affected versions. Application Integration, task configuration, versions prior to June 17, 2026, as stated in Google Cloud security bulletin GCP-2026-064 (bulletin index). Google patched the managed service on June 17, 2026 and published the bulletin on September 28, 2026; the vendor position is that no customer action is required. Treat that as the vendor's position on the vendor's code — it is not a reason to skip testing your own integrations, revisions, and self-built dispatchers.

Mechanism. The integration definition carries a task type identifier inside the task configuration. At execution, the runtime resolves that identifier against a handler registry and invokes the handler as the integration's runtime service identity. When the internal-only flag is evaluated at configuration time only, the authorization decision belongs to a screen the attacker does not have to use. A direct write to the integration config — create or update — puts the reserved type into the definition, and the executor runs it because the executor was never asked who was calling.

Validation shape. Two principals, same tenant, same payload:

1. As an admin, create an integration that contains the internal-only task type. Capture the exact request body and the 200 response.
2. As a standard-permission account, replay that body against create, then against update on an integration the standard account owns.
3. Execute both. Compare status codes, execution IDs, and the creator / lastModifiedBy fields.
4. Read the execution log and the audit log for the run and note which identity is recorded.

Three artifacts make the finding: the request/response pair, the identity recorded for the execution, and a downstream side effect — an RPC or call that arrived at a target the calling account could not reach directly. The status code is the suspicion; the side effect is the proof.

Detection and response

Telemetry that matters here is identity-correlated execution, not request volume:

• Integration execution logs — task type per run, plus the runtime identity and the initiating principal side by side. Many platforms record only one of the two.
• Cloud Audit Logs — CreateIntegration, UpdateIntegration, and execute methods, filtered to principals whose role should not permit internal-only task types.
• Task-type drift — a per-principal or per-project allowlist of task types actually used, diffed against the approved set. New internal-only types appearing in tenant-owned integrations are the signal.
• Runtime egress — RPC destinations reached by the runtime service identity that no approved integration justifies.

A defender's first check after this class of advisory is a query, not a scan: list executions where the initiating principal differs from the executing identity and the task type is on the reserved list. On a healthy tenant that result is empty or explained. Log labels are the fix — if the line carries only the deputy, the comparison is impossible and detection has to come from the task-type diff instead.

What to do

1. Enumerate the reserved surface. List every task type, connector, or action flagged internal-only, and write down where the flag is checked: render, create, update, or execute.
2. Stand up two accounts in a test project. One admin, one with the standard integration-author role your business actually grants. Never run this test against a tenant you do not own.
3. Capture the privileged request. As admin, create and execute an integration using the reserved type. Save the raw request body, not a screenshot of the form.
4. Replay as the standard account. Create, then update an existing integration with the same task configuration. Note 403 versus 200 — a 403 on create followed by a 200 on update is a finding, not a partial result.
5. Execute and compare. Diff the responses. If both return an execution ID, pull the execution record and identify the identity that ran it.
6. Prove the side effect. Show that the call reached a destination or identity the standard account cannot reach on its own. That artifact is what survives review.
7. Fix at the executor, not the form. Deny-by-default in the handler registry, re-check the caller's role at dispatch time, and log both the initiating principal and the executing identity on every run.
8. Re-test after the patch. The regression to look for is a UI fix with no server-side equivalent; the replay from step 4 is your retest.

FAQ

Is my tenant still vulnerable if Google says no customer action is required? For the managed service, the vendor patched on June 17, 2026. That statement covers the vendor's runtime. It does not cover integrations you wrote that dispatch caller-supplied step names yourself, and it does not cover your own revisions if you are testing against an older deployment.

How is this different from BOLA or IDOR? BOLA is object-level: the same function with a different record ID. This is function-level: the same request shape, but the action is reserved for a class of caller. The test still uses two accounts, but you are comparing which operation was allowed, not whose data came back.

Why did the audit log not flag the attacker? Because the operation executed as the runtime's service identity. The deputy is real and the call is legitimate from the platform's point of view. Without a field recording the initiating principal next to the executing identity, there is nothing in the log to correlate.

Can I test this with a scanner? Not meaningfully. The request is authenticated, well-formed, and returns 200. What you need is a second account and a diff between two responses plus the execution record — a manual authorization test with saved evidence.

What is the cheapest control that catches the class? Deny-by-default in the task registry, with the caller's role checked at dispatch. It closes config-layer gaps, stale revisions, and the tenant-scoped allowlist mistake at the same point.

Sources

• Google Cloud security bulletin GCP-2026-064 (CVE-2026-19759): https://docs.cloud.google.com/support/bulletins/index#gcp-2026-064
• Google Cloud security bulletins index: https://docs.cloud.google.com/support/bulletins/index
• MITRE CWE-863: Incorrect Authorization: https://cwe.mitre.org/data/definitions/863.html
• OWASP API Security Top 10 (2023), API5: Broken Function Level Authorization: https://owasp.org/API-Security/editions/2023/en/0xa5-broken-function-level-authorization/
• OWASP Web Security Testing Guide, Testing for Authorization Bypass: https://owasp.org/www-project-web-security-testing-guide/
• Trusteed, on validation and exploitability context for findings: https://trusteed.io