GHSA-9VC9-4JV3-RF86
Vulnerability from github – Published: 2026-06-10 13:38 – Updated: 2026-06-10 13:38Affected: @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/policies@1.4.0. 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
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "@hulumi/policies"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.4.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-48034"
],
"database_specific": {
"cwe_ids": [
"CWE-284"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-10T13:38:15Z",
"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-284 (Improper Access Control)**\n\n#### Summary\n\nHULUMI-H1 forbids raw `aws:s3:Bucket` outside of Hulumi\u0027s `SecureBucket` component, with one exemption: a raw bucket that\u0027s 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 \u2014 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.\n\nThe bug: H5 only checked the siblings\u0027 _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.\n\n#### Impact\n\nConsumers 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 \u2014 while the policy pack reported the stack as compliant.\n\n#### Patches\n\nUpgrade to `@hulumi/policies@1.4.0`. 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\u0027s `bucket` property \u2014 or, for the bucket policy, its `Resource` ARN list \u2014 to reference the exempted bucket explicitly. Five decoy siblings pointing at a different bucket no longer count.\n\n#### Workarounds\n\nNone \u2014 the exemption itself is the mechanism, so the value-binding check is the only fix.\n\n#### Resources\n\n- [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.",
"id": "GHSA-9vc9-4jv3-rf86",
"modified": "2026-06-10T13:38:25Z",
"published": "2026-06-10T13:38:15Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/kerberosmansour/hulumi/security/advisories/GHSA-9vc9-4jv3-rf86"
},
{
"type": "WEB",
"url": "https://github.com/kerberosmansour/hulumi/pull/175"
},
{
"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:N/PR:L/UI:N/VC:N/VI:H/VA:N/SC:H/SI:H/SA:L",
"type": "CVSS_V4"
}
],
"summary": "@hulumi/policies has a HULUMI-H5 bypass via decoy sibling resources targeting a different bucket"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.