The Amazon Q Developer advisory describes the vulnerability as a cross-tenant credential exposure affecting third-party repository analysis. The CVE -- which Amazon has not yet assigned a tracking number to in the public NVD record as of this filing -- documents a prompt injection path in which a malicious repository's README or inline comments cause Amazon Q to exfiltrate the developer's AWS credentials to an attacker-controlled endpoint during a routine code review session.

The structural problem is not the injection vector, which is well-documented in MITRE ATT&CK T1059 and its agentic extensions. The structural problem is the trust boundary Amazon drew: a developer invoking Q against an external repository had no documented indication that credential forwarding was in scope for that session, and Amazon's own threat model for Q Developer -- published in the service's security whitepaper -- does not list third-party repository content as a trust boundary requiring sanitisation. The concurrent BleepingComputer report on poisoned GitHub repositories weaponising AI coding agents confirms this is not a single vendor's gap. The Polymarket supply-chain incident, which closed at $3 million in customer losses, ran the same playbook against a different surface: trusted distribution channels carrying unsigned or tampered artefacts to downstream consumers who had no reason to inspect them. The common thread is that AI-augmented developer tooling has extended the trust perimeter into content the tool retrieves autonomously, and neither MAS TRM guidelines nor HKMA's published supervisory expectations for cloud-native development environments address autonomous credential forwarding by AI coding assistants -- a gap that HKMA's next round of TRM guidance, expected in Q4 2026, will need to close explicitly or leave to individual institutions to paper over with their own cloud policy frameworks.