{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@hulumi/policies"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.4.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-48032"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-697"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-10T13:37:08Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "**Affected:** `@hulumi/policies` `\u003c 1.4.0` \u2014 **Fixed in:** `1.4.0` \u2014 **Severity:** High \u2014 **CWE-697 (Incorrect Comparison)**\n\n#### Summary\n\nAWS IAM trust policies can list more than one federated identity provider \u2014 for example, a role that accepts BOTH GitHub Actions OIDC and Google\u0027s OIDC. The `G_OIDC_1` and `G_OIDC_2` policy rules are supposed to flag IAM roles whose GitHub-OIDC trust is too permissive (e.g. wildcard `sub:` conditions that would let any branch or any pull request assume the role).\n\nThe bug: when the role\u0027s `Principal.Federated` field was a JSON array of multiple providers, the rules failed to recognise that GitHub Actions was one of them. The providers list was coerced into a single comma-joined string, the matcher only looked at the start, and the GitHub OIDC hostname was lost in the join. Both rules concluded \"this isn\u0027t a GitHub-OIDC role\" and skipped the wildcard check.\n\n#### Impact\n\nA trust policy that listed the real GitHub OIDC provider ARN alongside any second provider would slip past both detectors. Consumers using `HulumiHardeningPack` or `HulumiGithubHardeningPack` could ship an IAM role with wildcard `sub:` conditions (allowing untrusted PRs from forks to assume the role) while their policy validation reported the stack as compliant. The G_OIDC_2 detector also failed to mark such roles for the cluster-admin / `AdministratorAccess` blast-radius check.\n\n#### Patches\n\nUpgrade to `@hulumi/policies@1.4.0`. The shared GitHub-OIDC-provider matcher now correctly walks lists of providers \u2014 if any element of the list is the real GitHub OIDC ARN, the role is treated as GitHub-OIDC-assumable and the wildcard / blast-radius checks apply.\n\n#### Workarounds\n\nNone reliable \u2014 upgrade is the fix.\n\n#### Resources\n\n- [PR #178](https://github.com/kerberosmansour/hulumi/pull/178) (Cluster A); regression tests at `packages/policies/tests/github/{g-oidc-2,github-oidc-issuer}.test.ts`.",
  "id": "GHSA-g759-4pxw-6692",
  "modified": "2026-06-10T13:37:08Z",
  "published": "2026-06-10T13:37:08Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/kerberosmansour/hulumi/security/advisories/GHSA-g759-4pxw-6692"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kerberosmansour/hulumi/pull/178"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/kerberosmansour/hulumi"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:L/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "@hulumi/policies bypasses IAM-role policy checks when the role trusts multiple OIDC providers"
}