Summary

Problem: Three Google OAuth modules read HTTP response bodies without size limits, creating OOM risk when upstream services return oversized or malicious payloads. Additionally, gunzipSync in the Vertex ADC parser lacks a decompressed-output cap, so a small compressed payload can still inflate past the wire limit.

Solution: Replace all unbounded response.arrayBuffer(), .json() calls with bounded SDK helpers (readResponseWithLimit, readProviderJsonResponse). Add maxOutputLength to gunzipSync to cap decompressed output at the same 1 MB bound.

What changed: extensions/google/vertex-adc.ts, extensions/google/oauth.token.ts, extensions/google/oauth.project.ts — 3 files, +27/-12 lines.

• Wire reads bounded via SDK helpers (7 call sites)
• gunzipSync bounded via maxOutputLength: GOOGLE_OAUTH_TOKEN_RESPONSE_MAX_BYTES
• Token, project, and onboarding response paths all covered

What did NOT change: No behavior change for well-formed responses under the size limits. No API or config surface changes. No dependency additions.

What Problem This Solves

7 call sites across 3 files consume unbounded HTTP response bodies. This is the same unbounded-read class fixed across 30+ providers via the Plugin SDK, but the Google OAuth paths were missed.

Additionally, the Vertex ADC gzip decoder could amplify a small compressed payload (under the 1 MB wire cap) into an arbitrarily large decompressed buffer, leaving an OOM path open even after the wire cap.

Why This Change Was Made

The existing readProviderJsonResponse and readResponseWithLimit helpers already ship in the Plugin SDK with a default 16 MB cap. Using them here aligns with the established bounded-read pattern. The maxOutputLength option on gunzipSync (Node 15+) closes the decompression amplification path that the wire cap alone cannot address.

Real behavior proof

Behavior addressed: Bounded HTTP response reads and bounded gzip decompression for Google OAuth HTTP paths.

BEFORE FIX — unbounded response.arrayBuffer() reads entire body into memory:

const bytes = Buffer.from(await response.arrayBuffer());

AFTER FIX — bounded read with 1 MB cap and overflow error:

const bytes = await readResponseWithLimit(response, GOOGLE_OAUTH_TOKEN_RESPONSE_MAX_BYTES, {
  onOverflow: ({ maxBytes }) =>
    new Error(`Google OAuth token response exceeds ${maxBytes} bytes`),
});

BEFORE FIX — unbounded gunzipSync allocates full decompressed output:

return gunzipSync(bytes).toString("utf8");

AFTER FIX — bounded decompression with maxOutputLength:

return gunzipSync(bytes, { maxOutputLength: GOOGLE_OAUTH_TOKEN_RESPONSE_MAX_BYTES }).toString("utf8");

Real environment tested: Linux x86_64, Node v24.13.1.

Exact steps or command run after this patch:

# Unit tests
pnpm test extensions/google -- --reporter verbose
pnpm test:changed

# L2 proof: bounded gzip prevents decompression bomb
node evidence/pr-99812/bounded-gzip-proof.mjs

# L2 proof: loopback HTTP shows oversized response rejection
node evidence/pr-99812/bounded-http-proof.mjs

After-fix evidence: L2 runtime proof with loopback HTTP server and decompression bomb:

=== Bounded gzip decompression proof ===
Normal token response: 76 bytes uncompressed
  ✓ bounded: decompressed 76 bytes, parsed OK
Decompression bomb: 2068 bytes compressed → 2097153 bytes uncompressed
  unbounded gunzipSync: allocated 2097153 bytes (OOM risk)
  bounded gunzipSync: rejected — Cannot create a Buffer larger than 1048576 bytes

=== Bounded HTTP read proof ===
Normal response: 46 bytes — ✓ bounded read OK, parsed
Oversized response: caught — Response exceeds 1048576 bytes
  ✓ bounded read correctly rejected the oversized response

Unit tests:

 ✓ |extension-providers| extensions/google/... (28 test files, 378 tests passed)
 ✓ |extension-providers| test:changed (15 test files, 228 tests passed)

Observed result after the fix: All tests pass. Both loopback proof scripts confirm oversized responses and decompression bombs are safely rejected at the 1 MB boundary. Normal-sized responses pass through unchanged.

What was not tested: Actual Google OAuth HTTP round-trips (requires live credentials). The SDK helpers readResponseWithLimit and readProviderJsonResponse are integration-tested in src/agents/provider-http-errors.test.ts and packages/media-core/src/read-response-with-limit.test.ts. This PR only swaps the call sites and adds a maxOutputLength option, preserving all existing error handling and test seams.

Risk checklist

merge-risk: Low

• Low risk — bounded-read wrapper replaces unbounded call with same return type and compatible error semantics
• Decompression bomb path closed via maxOutputLength on gunzipSync
• No behavior change for normal-sized responses under the cap
• No API, config, or dependency changes
• L2 runtime proof with loopback HTTP server (oversized response rejection) and decompression bomb (gzip amplification blocked)
• Existing tests green (28 test files, 378 tests; 15 test:changed files, 228 tests)