7vulnerabilities
- Critical1 (14.3%)
- High6 (85.7%)
- Medium0 (0.0%)
- Moderate0 (0.0%)
- Low0 (0.0%)
hulumi-policies
Ecosystem: npm
Downloads: 250
- 1CriticalAffects 1 version
- 6HighAffects 6 versions
- 0MediumAffects 0 versions
- 0ModerateAffects 0 versions
- 0LowAffects 0 versions
Monthly breakdown
- Critical
- High
- Medium
- Moderate
- Low
- 3 vulnerabilities
- Critical: 0
- High: 3
- Medium: 0
- Moderate: 0
- Low: 0
- 4 vulnerabilities
- Critical: 1
- High: 3
- Medium: 0
- Moderate: 0
- Low: 0
Vulnerabilities (7)
Known vulnerabilities affecting hulumi-policies, based on data from OSV.
| ID | Severity | Summary | Affected versions | Published | Source |
|---|---|---|---|---|---|
| GHSA-9vc9-4jv3-rf86 | High | @hulumi/policies has a HULUMI-H5 bypass via decoy sibling resources targeting a different bucket**Affected:** `@hulumi/policies` `< 1.4.0` — **Fixed in:** `1.4.0` — **Severity:** High — **CWE-284 (Improper Access Control)** #### Summary HULUMI-H1 forbids raw `aws:s3:Bucket` outside of Hulumi's `SecureBucket` component, with one exemption: a raw bucket that's a child of a `SecureBucket` is allowed because the component is responsible for the hardening. HULUMI-H5 is the defence-in-depth check that closes the H1 exemption — for any raw bucket claiming it, H5 verifies the five hardening sibling resources a real `SecureBucket` always emits (public-access block, SSE-KMS, ownership controls, |
| GitHub (opens in a new tab) | |
| GHSA-g759-4pxw-6692 | High | @hulumi/policies bypasses IAM-role policy checks when the role trusts multiple OIDC providers**Affected:** `@hulumi/policies` `< 1.4.0` — **Fixed in:** `1.4.0` — **Severity:** High — **CWE-697 (Incorrect Comparison)** #### Summary AWS IAM trust policies can list more than one federated identity provider — for example, a role that accepts BOTH GitHub Actions OIDC and Google's 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). The bug: when the role's `Principal.Federated` field was a JSON array of multiple providers, |
| GitHub (opens in a new tab) | |
| GHSA-rhgj-6g2c-frmm | High | @hulumi/policies bypasses policy packs with a forged Pulumi-URN logical name**Affected:** `@hulumi/policies` `< 1.4.0` — **Fixed in:** `1.4.0` — **Severity:** High — **CWE-693 (Protection Mechanism Failure)** #### Summary Pulumi gives every cloud resource a structured URN that includes the resource's type chain (`hulumi:baseline:aws:SecureBucket$aws:s3/bucketV2:BucketV2`) and the _logical name_ the developer freely chose (anything after the final `::`). Several Hulumi policy rules used the URN to grant exemptions — for example, "if this raw bucket is a child of `SecureBucket`, skip the raw-bucket rule because the parent component handles hardening." The bug: the ru |
| GitHub (opens in a new tab) | |
| GHSA-4xrh-5m3m-328w | High | @hulumi/policies: CIS 1.16 admin policy bypass for inline and attached IAM policiesImpact: @hulumi/policies versions before 1.3.2 did not fully inspect inline and attached IAM policy evidence for the administrator-policy guardrail, so some admin-equivalent policy paths could pass policy evaluation. Patched in 1.3.2: the validator inspects the affected policy shapes and includes regression tests. Remediation: upgrade @hulumi/policies to 1.3.2 or later. |
| GitHub (opens in a new tab) | |
| GHSA-59f3-7227-wmh4 | High | @hulumi/policies: Stack-wide evidence bypassed Cloudflare and deployment-governance guardrailsImpact: @hulumi/policies versions before 1.3.2 used stack-wide evidence shortcuts in several Cloudflare and deployment-governance validators. Unrelated compliant-looking evidence could suppress violations for different zones, hostnames, origins, or repositories in the same stack. Patched in 1.3.2: validators now correlate evidence to the specific protected resource and include regression coverage for unrelated-evidence bypasses. Remediation: upgrade @hulumi/policies to 1.3.2 or later. |
| GitHub (opens in a new tab) | |
| GHSA-g43v-9x7q-83pq | High | @hulumi/policies: HULUMI-H1 SecureBucket parent spoof bypassImpact: @hulumi/policies versions before 1.3.2 could accept spoofed SecureBucket parent evidence for HULUMI-H1, allowing policy evaluation to miss an unsafe bucket shape. Patched in 1.3.2: the validator now correlates evidence to the expected component/resource relationship and includes regression coverage. Remediation: upgrade @hulumi/policies to 1.3.2 or later. |
| GitHub (opens in a new tab) | |
| GHSA-q2f7-m237-v562 | Critical | @hulumi/policies: GitHub OIDC trust policy bypass via AWS set-qualified condition operatorsImpact: @hulumi/policies versions before 1.3.2 only checked exact AWS IAM StringLike/StringEquals condition operator keys in G_OIDC_1. Set-qualified operators such as ForAnyValue:StringLike could hide wildcard GitHub Actions OIDC sub conditions from the mandatory guardrail. Patched in 1.3.2: the AWS trust-policy inspector now evaluates set-qualified string operators and rejects unsafe GitHub OIDC sub conditions. Remediation: upgrade @hulumi/policies to 1.3.2 or later. |
| GitHub (opens in a new tab) |
- GHSA-9vc9-4jv3-rf86High@hulumi/policies has a HULUMI-H5 bypass via decoy sibling resources targeting a different bucket
< 1.4.0
**Affected:** `@hulumi/policies` `< 1.4.0` — **Fixed in:** `1.4.0` — **Severity:** High — **CWE-284 (Improper Access Control)** #### Summary HULUMI-H1 forbids raw `aws:s3:Bucket` outside of Hulumi's `SecureBucket` component, with one exemption: a raw bucket that's a child of a `SecureBucket` is allowed because the component is responsible for the hardening. HULUMI-H5 is the defence-in-depth check that closes the H1 exemption — for any raw bucket claiming it, H5 verifies the five hardening sibling resources a real `SecureBucket` always emits (public-access block, SSE-KMS, ownership controls,
CVE: CVE-2026-48034
- GHSA-g759-4pxw-6692High@hulumi/policies bypasses IAM-role policy checks when the role trusts multiple OIDC providers
< 1.4.0
**Affected:** `@hulumi/policies` `< 1.4.0` — **Fixed in:** `1.4.0` — **Severity:** High — **CWE-697 (Incorrect Comparison)** #### Summary AWS IAM trust policies can list more than one federated identity provider — for example, a role that accepts BOTH GitHub Actions OIDC and Google's 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). The bug: when the role's `Principal.Federated` field was a JSON array of multiple providers,
CVE: CVE-2026-48032
- GHSA-rhgj-6g2c-frmmHigh@hulumi/policies bypasses policy packs with a forged Pulumi-URN logical name
< 1.4.0
**Affected:** `@hulumi/policies` `< 1.4.0` — **Fixed in:** `1.4.0` — **Severity:** High — **CWE-693 (Protection Mechanism Failure)** #### Summary Pulumi gives every cloud resource a structured URN that includes the resource's type chain (`hulumi:baseline:aws:SecureBucket$aws:s3/bucketV2:BucketV2`) and the _logical name_ the developer freely chose (anything after the final `::`). Several Hulumi policy rules used the URN to grant exemptions — for example, "if this raw bucket is a child of `SecureBucket`, skip the raw-bucket rule because the parent component handles hardening." The bug: the ru
CVE: CVE-2026-48033
- GHSA-4xrh-5m3m-328wHigh@hulumi/policies: CIS 1.16 admin policy bypass for inline and attached IAM policies
< 1.3.2
Impact: @hulumi/policies versions before 1.3.2 did not fully inspect inline and attached IAM policy evidence for the administrator-policy guardrail, so some admin-equivalent policy paths could pass policy evaluation. Patched in 1.3.2: the validator inspects the affected policy shapes and includes regression tests. Remediation: upgrade @hulumi/policies to 1.3.2 or later.
CVE: CVE-2026-82860
- GHSA-59f3-7227-wmh4High@hulumi/policies: Stack-wide evidence bypassed Cloudflare and deployment-governance guardrails
< 1.3.2
Impact: @hulumi/policies versions before 1.3.2 used stack-wide evidence shortcuts in several Cloudflare and deployment-governance validators. Unrelated compliant-looking evidence could suppress violations for different zones, hostnames, origins, or repositories in the same stack. Patched in 1.3.2: validators now correlate evidence to the specific protected resource and include regression coverage for unrelated-evidence bypasses. Remediation: upgrade @hulumi/policies to 1.3.2 or later.
CVE: CVE-2026-82855
- GHSA-g43v-9x7q-83pqHigh@hulumi/policies: HULUMI-H1 SecureBucket parent spoof bypass
< 1.3.2
Impact: @hulumi/policies versions before 1.3.2 could accept spoofed SecureBucket parent evidence for HULUMI-H1, allowing policy evaluation to miss an unsafe bucket shape. Patched in 1.3.2: the validator now correlates evidence to the expected component/resource relationship and includes regression coverage. Remediation: upgrade @hulumi/policies to 1.3.2 or later.
CVE: CVE-2026-82861
- GHSA-q2f7-m237-v562Critical@hulumi/policies: GitHub OIDC trust policy bypass via AWS set-qualified condition operators
< 1.3.2
Impact: @hulumi/policies versions before 1.3.2 only checked exact AWS IAM StringLike/StringEquals condition operator keys in G_OIDC_1. Set-qualified operators such as ForAnyValue:StringLike could hide wildcard GitHub Actions OIDC sub conditions from the mandatory guardrail. Patched in 1.3.2: the AWS trust-policy inspector now evaluates set-qualified string operators and rejects unsafe GitHub OIDC sub conditions. Remediation: upgrade @hulumi/policies to 1.3.2 or later.
CVE: CVE-2026-82856