Which versions of @hulumi/policies are affected by CVE-2026-48033?

@hulumi/policies versions prior to 1.4.0 contain a policy enforcement bypass that allows infrastructure developers to deploy cloud resources that circumvent mandatory security hardening checks,…. A patch is available.

How to fix or mitigate CVE-2026-48033?

Within 24 hours: Assess the scope of Pulumi deployments currently using affected @hulumi/policies versions in production environments. Within 7 days: Update @hulumi/policies to version 1.4.0 or later across all development, staging, and production systems. Within 30 days: Audit all infrastructure deployed under affected policy versions to verify compliance with hardening requirements, particularly for S3 buckets, GitHub repositories, and DNS configurations.

@hulumi/policies CVE-2026-48033

HIGH

Protection Mechanism Failure (CWE-693)

2026-06-10 https://github.com/kerberosmansour/hulumi

GHSA-rhgj-6g2c-frmm

Authentication Bypass

Lifecycle Timeline

Source Code Evidence Fetched

Jun 10, 2026 - 14:15 vuln.today

Analysis Generated

Jun 10, 2026 - 14:15 vuln.today

DescriptionCVE.org

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 rules looked for a substring like hulumi:baseline:aws:SecureBucket$ _anywhere_ in the URN. That substring can also appear in the developer-controlled logical-name portion. A developer (or compromised PR) could simply name a raw resource so its logical name carried the trusted substring, and every rule that used this check would treat the resource as if it were inside the trusted parent and skip its hardening check.

Codex reported this for DEPLOY_GOV_1; the same anti-pattern existed in five more packs (unreported but identically exploitable): AWS H4/H5 sibling lookups, GitHub H1, GitHub H2, Cloudflare CF_DNS_1, Cloudflare CF_DNSSEC_1, and (advisory-level) CIS v5 §2.1.1 + §2.1.5.

Impact

Consumers using @hulumi/policies could ship raw aws:s3:Bucket, github:Repository, cloudflare:Zone, cloudflare:DnsRecord, and similar resources that bypassed mandatory hardening checks by naming themselves with a trusted substring. Every affected rule appeared to pass while the resource had none of the expected defaults.

Patches

Upgrade to @hulumi/policies@1.4.0. A new shared helper at packages/policies/src/urn.ts parses Pulumi URNs structurally and only looks for the trusted parent-type token inside the URN's type-chain segment - never inside the developer-controlled logical name. All six prior call sites have been migrated to it.

Workarounds

None reliable - a local lint that rejects logical names containing $ would catch the trivial form of the spoof but not crafted variants.

Resources

PR #178 (Cluster B); the URN-anchoring refactor and per-pack spoof-vector regression tests in packages/policies/tests/.

AnalysisAI

Policy enforcement bypass in @hulumi/policies versions prior to 1.4.0 allows infrastructure developers to ship raw cloud resources (AWS S3 buckets, GitHub repositories, Cloudflare zones and DNS records) that evade mandatory hardening checks by embedding a trusted parent-component substring inside the developer-controlled logical-name portion of a Pulumi URN. The flaw is a CWE-693 Protection Mechanism Failure spanning six policy packs (DEPLOY_GOV_1, AWS H4/H5, GitHub H1/H2, Cloudflare CF_DNS_1/CF_DNSSEC_1) where exemption logic used a naive substring match instead of structural URN parsing. No public exploit identified at time of analysis, though the spoofing technique is described in detail in the published advisory.

Technical ContextAI

Pulumi resources are identified by URNs structured as <stack>::<project>::<type-chain>::<logical-name>, where the type chain (e.g. hulumi:baseline:aws:SecureBucket$aws:s3/bucketV2:BucketV2) is derived from the component hierarchy and the logical name is freely chosen by the developer. The vulnerable rules in @hulumi/policies (npm package pkg:npm/@hulumi_policies) performed urn.includes('hulumi:baseline:aws:SecureBucket$') style checks to determine whether a raw resource was a child of a trusted parent component and could be exempted from a hardening rule. Because includes() scans the entire URN string, the same trusted token placed in the logical-name segment satisfies the check, conflating attacker-controlled data with the integrity-protected type chain. The 1.4.0 fix introduces packages/policies/src/urn.ts, a structural URN parser that restricts the token lookup to the type-chain segment only, and migrates all six prior call sites to use it.

RemediationAI

Vendor-released patch: upgrade @hulumi/policies to 1.4.0 or later, which replaces every substring-based URN check with the structural parser in packages/policies/src/urn.ts (see PR #178 at https://github.com/kerberosmansour/hulumi/pull/178 and advisory GHSA-rhgj-6g2c-frmm at https://github.com/kerberosmansour/hulumi/security/advisories/GHSA-rhgj-6g2c-frmm). The vendor states there is no reliable workaround; a local lint or pre-commit hook that rejects logical names containing the $ character would block the most obvious spoof shape but the advisory explicitly notes it does not catch crafted variants and should not be relied upon as a substitute for the upgrade. As an interim compensating control until the upgrade is rolled out, teams can add out-of-band drift detection (e.g. AWS Config rules for S3 public-access, GitHub branch-protection audits, Cloudflare DNSSEC checks) so that bypassed hardening is detected post-deploy, accepting the trade-off that this catches violations only after resources reach the cloud.