AWS Amplify API: the query resolvers generated for SQL-backed data models let an authenticated user read other users' records (CVE-2026-108096, CVSS 3.1 6.5 / 4.0 7.1); fixed on npm 2026-07-01, bulletin 2026-10-09, and the fix only takes effect on redeploy

View raw markdownEdit on GitHub ↗

TL;DR

AWS bulletin 2026-133 (2026-10-09) discloses that the GraphQL query resolvers Amplify generates for SQL-backed data models did not enforce owner authorization correctly, so a signed-in user of an Amplify app could craft queries that return records belonging to other users of the same app. The CNA record (AMZN) scores it CVSS 3.1 6.5 (low privileges, high confidentiality impact) and CVSS 4.0 7.1. The fix is @aws-amplify/graphql-index-transformer 3.1.2, carried by @aws-amplify/data-construct 1.17.4 and @aws-amplify/graphql-api-construct 1.21.4, all published to npm on 2026-07-01, one hundred days before the bulletin. These are build-time CDK packages: upgrading changes nothing until the backend is redeployed, and AWS lists no workaround. For a vibe-coded app this is the Amplify twin of the Supabase row-level-security failure class, except that here the generator's own authorization layer was the thing that was wrong.

What happened

AWS published bulletin 2026-133-AWS at 11:00 PDT on 2026-10-09 and the CNA record for CVE-2026-108096 at 18:10 UTC the same day. The description: "Improper authorization in the query resolvers generated by @aws-amplify/graphql-index-transformer in AWS Amplify API Category before 3.1.2 might allow an authenticated remote user to read records owned by other users of the same application via crafted queries." Affected ranges, as the bulletin and CNA record print them: @aws-amplify/graphql-index-transformer >= 2.2.0 and < 3.1.2; @aws-amplify/graphql-api-construct >= 1.4.0 and < 1.21.4; @aws-amplify/data-construct < 1.17.4. The vendor advisory on the aws-amplify/amplify-category-api repository (GHSA-69c4-mvf5-5xm3, published 2026-10-09, severity Moderate, no credit listed) narrows the scope: the affected APIs are those that combine a SQL data source, owner or group authorization rules, and secondary indexes, and the path is an authenticated user crafting secondary-index queries with keys that belong to another tenant. Neither source goes further than that, so this advisory does not either.

Two things the dates tell you. First, the fix shipped silently: all three fixed versions have an npm time of 2026-07-01 and nothing public marked them as a security release until the October bulletin, which is the pattern this corpus records for Payload and the AWS agent-plugin bulletins of 2026-10-08. Teams that pin Amplify's CDK packages have been building vulnerable resolvers for three months after the fix existed. Second, the vulnerable code is not in the running app's dependencies but in the resolvers the transformer emitted at the last deploy. AWS's recommended action is to upgrade, patch any forked or derivative code, and redeploy the backend; a project that upgraded package.json on 2026-07-02 and never ran npx ampx deploy or its pipeline since is still serving the old resolvers. @aws-amplify/data-construct had 136,199 weekly downloads in the week to 2026-10-08.

Scope note: the bug is in the resolvers generated for models whose data source is a SQL database (Amplify's RDS and Aurora integration), not the default DynamoDB-backed models, and only where those models carry owner or group rules and a secondary index. The vendor advisory says the flaw triggers "under certain circumstances" without listing them, so treat every SQL-backed model with owner or group rules and a secondary index as exposed until redeployed.

Am I affected?

# Which Amplify API packages built the last deploy?
npm ls @aws-amplify/data-construct @aws-amplify/graphql-api-construct @aws-amplify/graphql-index-transformer 2>/dev/null
# Fixed: index-transformer >= 3.1.2, data-construct >= 1.17.4, api-construct >= 1.21.4 (all on npm 2026-07-01)

# Do any models use a SQL data source, owner/group rules, and a secondary index?
grep -rn -iE 'sql|rds|aurora' amplify/data/ amplify/backend/api/ 2>/dev/null | head
grep -rn -E 'secondaryIndexes|@index|allow\.(owner|group)' amplify/data/ amplify/backend/api/ 2>/dev/null | head

# When was the backend last deployed? A deploy before 2026-07-01, or one that used an older lockfile, is still vulnerable.
aws cloudformation describe-stacks --query 'Stacks[?contains(StackName,`amplify`)].[StackName,LastUpdatedTime]' --output table

If the app has no SQL-backed models, the bulletin does not apply. If it does and the last deploy predates the fixed packages in your lockfile, assume every signed-in user could have read every other user's records in those models.

If you are affected

  1. Upgrade the three packages, regenerate the lockfile, and redeploy the backend; verify the deployed resolvers changed by checking the stack's update time.
  2. Review AppSync and CloudWatch logs for queries against SQL-backed models that returned rows outside the caller's owner scope, as far back as the model has existed; the bulletin gives no exploitation statement either way.
  3. If the records held personal data, treat it as a disclosure to every authenticated user and follow if-your-webapp-was-compromised.md.
  4. If you forked or vendored the transformer, port the fix: AWS says derivative code must be patched separately.

Prevention

Generated authorization is still authorization you own: write one test per model that signs in as user B and asks for user A's record, run it after every deploy, and keep that test for the SQL-backed path separately from DynamoDB (auditing-a-vibe-coded-repo.md). Pin Amplify's build packages with a tool that surfaces security releases, and treat "no release note" as no information, not as safety (supply-chain-attack-surface.md). The sibling class on the other popular generated backend is Supabase's row-level security.

Sources