GHSA-2mxr-p26x-mj73
Fix: kerberosmansour/hulumi#178GHSA-2mxr-p26x-mj73 is a CWE-1059 vulnerability in @hulumi/baseline. O3 Security confirms whether GHSA-2mxr-p26x-mj73 is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
@hulumi/baseline: AccountFoundation audit-delivery S3 bucket could be silently weakened
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-2mxr-p26x-mj73.
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/baselinenpmDescription
Affected: @hulumi/baseline < 1.4.0 — Fixed in: 1.4.0 — Severity: High — CWE-1059 (Insufficient Technical Documentation / Behavioral Inconsistency)
Summary
The S3 bucket that AccountFoundation creates to receive CloudTrail and AWS Config audit logs is meant to be tamper-resistant — if someone with delete access can erase from it, the forensic trail is gone. There were three independent ways the protection could be silently weakened:
- No Write-Once-Read-Many on the startup-hardened audit bucket. The startup-hardened tier hard-coded
objectLock: falseon the audit bucket. (The reason was real — bucket-wide Object Lock blocks an AWS Config write-then-delete probe — but the fix was a sledgehammer that disabled WORM for all objects, not just the probe key.) forceDestroywas forwarded to the audit bucket. Nothing prevented a downstream stack from settinglogBucketForceDestroy: true, which madepulumi destroypurge every audit-log object on teardown.- Sandbox tier dropped everything. Sandbox-tier
AccountFoundationcreated its audit bucket withtier: "sandbox", which skipped Object Lock, server access logging, AND the CloudTrail-LakeEventDataStore(the independent immutable mirror) — leaving sandbox accounts with no audit immutability at all.
Impact
Consumers using AccountFoundation could ship an AWS account whose CloudTrail / Config audit logs were deletable by any S3-delete-capable principal — while believing the startup-hardened tier guaranteed tamper-resistance. Sandbox-tier deployments had no audit immutability at all (defects 1 and 3 compounded).
Patches
Upgrade to @hulumi/[email protected]. A single invariant in SecureBucket now fires whenever the bucket actually backs CloudTrail/Config delivery (i.e. awsServiceLogDelivery.cloudTrail === true || .config === true):
- refuses
forceDestroy: trueon the startup-hardened tier; - emits the CloudTrail-Lake
EventDataStoreregardless of parent tier (so sandbox accounts regain immutable audit capture); - adds a deny-
s3:DeleteObject*bucket-policy statement scoped to the CloudTrail and Config history/snapshot prefixes (a retention floor on the audit objects). The deny excludes the AWS ConfigConfigWritabilityCheckFileprobe key so Config's write-then-delete still works, which is why bucket-wide Object Lock is intentionally NOT re-enabled.
Workarounds
Replicating audit logs out-of-account to an Object-Locked archive bucket partially mitigates while you upgrade.
Resources
- PR #178 (Cluster C); see CHANGELOG
### Migrationfor theforceDestroybehaviour change.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | @hulumi/baseline | 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/baseline. 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/baseline to 1.4.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-2mxr-p26x-mj73 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-2mxr-p26x-mj73 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-2mxr-p26x-mj73. 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-2mxr-p26x-mj73 in your dependencies?
O3 detects GHSA-2mxr-p26x-mj73 across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.