**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, versioning, TLS-only bucket policy) are actually present. The bug: H5 only checked the siblings' _types_. It never verified that those siblings actually applied to the bucket being exempted. A consumer (or compromised PR) could pair an unhardened raw bucket with five hardening sibling resources whose `bucket` property pointed at a _completely different_ bucket, and H5 would report no violation while the actual bucket shipped with zero hardened defaults. #### Impact Consumers using `HulumiHardeningPack` could ship a raw S3 bucket with no public-access block, no SSE-KMS, no ownership controls, no versioning, and no TLS-only bucket policy — while the policy pack reported the stack as compliant. #### Patches Upgrade to `@hulumi/[email protected]`. The H5 sibling check now requires both (a) the sibling to share the same parent `SecureBucket` instance via the anchored URN helper from GHSA-2, AND (b) the sibling's `bucket` property — or, for the bucket policy, its `Resource` ARN list — to reference the exempted bucket explicitly. Five decoy siblings pointing at a different bucket no longer count. #### Workarounds None — the exemption itself is the mechanism, so the value-binding check is the only fix. #### Resources - [PR #178](https://github.com/kerberosmansour/hulumi/pull/178) (Cluster B); decoy-sibling regression cases in `packages/policies/tests/hulumi-hardening-pack.test.ts`. Supersedes [PR #175](https://github.com/kerberosmansour/hulumi/pull/175), which had addressed the value-binding half but on a stale base.
**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, versioning, TLS-only bucket policy) are actually present. The bug: H5 only checked the siblings' _types_. It never verified that those siblings actually applied to the bucket being exempted. A consumer (or compromised PR) could pair an unhardened raw bucket with five hardening sibling resources whose `bucket` property pointed at a _completely different_ bucket, and H5 would report no violation while the actual bucket shipped with zero hardened defaults. #### Impact Consumers using `HulumiHardeningPack` could ship a raw S3 bucket with no public-access block, no SSE-KMS, no ownership controls, no versioning, and no TLS-only bucket policy — while the policy pack reported the stack as compliant. #### Patches Upgrade to `@hulumi/[email protected]`. The H5 sibling check now requires both (a) the sibling to share the same parent `SecureBucket` instance via the anchored URN helper from GHSA-2, AND (b) the sibling's `bucket` property — or, for the bucket policy, its `Resource` ARN list — to reference the exempted bucket explicitly. Five decoy siblings pointing at a different bucket no longer count. #### Workarounds None — the exemption itself is the mechanism, so the value-binding check is the only fix. #### Resources - [PR #178](https://github.com/kerberosmansour/hulumi/pull/178) (Cluster B); decoy-sibling regression cases in `packages/policies/tests/hulumi-hardening-pack.test.ts`. Supersedes [PR #175](https://github.com/kerberosmansour/hulumi/pull/175), which had addressed the value-binding half but on a stale base.
Update @hulumi/policies to 1.4.0 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scan@hulumi/policies has a HULUMI-H5 bypass via decoy sibling resources targeting a different bucket affects @hulumi/policies (npm). Severity is high. **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, versioning, TLS-only bucket policy) are actually present. The bug: H5 only checked the siblings' _types_. It never verified that those siblings actually applied to the bucket being exempted. A consumer (or compromised PR) could pair an unhardened raw bucket with five hardening sibling resources whose `bucket` property pointed at a _completely different_ bucket, and H5 would report no violation while the actual bucket shipped with zero hardened defaults. #### Impact Consumers using `HulumiHardeningPack` could ship a raw S3 bucket with no public-access block, no SSE-KMS, no ownership controls, no versioning, and no TLS-only bucket policy — while the policy pack reported the stack as compliant. #### Patches Upgrade to `@hulumi/[email protected]`. The H5 sibling check now requires both (a) the sibling to share the same parent `SecureBucket` instance via the anchored URN helper from GHSA-2, AND (b) the sibling's `bucket` property — or, for the bucket policy, its `Resource` ARN list — to reference the exempted bucket explicitly. Five decoy siblings pointing at a different bucket no longer count. #### Workarounds None — the exemption itself is the mechanism, so the value-binding check is the only fix. #### Resources - [PR #178](https://github.com/kerberosmansour/hulumi/pull/178) (Cluster B); decoy-sibling regression cases in `packages/policies/tests/hulumi-hardening-pack.test.ts`. Supersedes [PR #175](https://github.com/kerberosmansour/hulumi/pull/175), which had addressed the value-binding half but on a stale base.
AI coding agents often install or upgrade packages automatically in npm. A high vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| @hulumi/policiesnpm | <1.4.0 | 1.4.0 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL GuardUpdate @hulumi/policies to 1.4.0 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scan@hulumi/policies has a HULUMI-H5 bypass via decoy sibling resources targeting a different bucket affects @hulumi/policies (npm). Severity is high. **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, versioning, TLS-only bucket policy) are actually present. The bug: H5 only checked the siblings' _types_. It never verified that those siblings actually applied to the bucket being exempted. A consumer (or compromised PR) could pair an unhardened raw bucket with five hardening sibling resources whose `bucket` property pointed at a _completely different_ bucket, and H5 would report no violation while the actual bucket shipped with zero hardened defaults. #### Impact Consumers using `HulumiHardeningPack` could ship a raw S3 bucket with no public-access block, no SSE-KMS, no ownership controls, no versioning, and no TLS-only bucket policy — while the policy pack reported the stack as compliant. #### Patches Upgrade to `@hulumi/[email protected]`. The H5 sibling check now requires both (a) the sibling to share the same parent `SecureBucket` instance via the anchored URN helper from GHSA-2, AND (b) the sibling's `bucket` property — or, for the bucket policy, its `Resource` ARN list — to reference the exempted bucket explicitly. Five decoy siblings pointing at a different bucket no longer count. #### Workarounds None — the exemption itself is the mechanism, so the value-binding check is the only fix. #### Resources - [PR #178](https://github.com/kerberosmansour/hulumi/pull/178) (Cluster B); decoy-sibling regression cases in `packages/policies/tests/hulumi-hardening-pack.test.ts`. Supersedes [PR #175](https://github.com/kerberosmansour/hulumi/pull/175), which had addressed the value-binding half but on a stale base.
AI coding agents often install or upgrade packages automatically in npm. A high vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| @hulumi/policiesnpm | <1.4.0 | 1.4.0 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL Guard