GHSA-rhgj-6g2c-frmm
Fix: kerberosmansour/hulumi#178GHSA-rhgj-6g2c-frmm is a CWE-693 vulnerability in @hulumi/policies. O3 Security confirms whether GHSA-rhgj-6g2c-frmm is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
@hulumi/policies bypasses policy packs with a forged Pulumi-URN logical name
Exploitation Status
No confirmed exploitation observed yet
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for GHSA-rhgj-6g2c-frmm.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
Real-World Exposure
How broadly this vulnerability is actually deployed: weekly install volume shows current usage, and reverse-dependency count shows how many other packages break if it stays unpatched.
@hulumi/policiesnpmDescription
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/[email protected]. 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/.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | @hulumi/policies | all versions | 1.4.0 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for @hulumi/policies. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update @hulumi/policies to 1.4.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-rhgj-6g2c-frmm is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-rhgj-6g2c-frmm is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-rhgj-6g2c-frmm. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-rhgj-6g2c-frmm in your dependencies?
O3 detects GHSA-rhgj-6g2c-frmm across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.