CVE-2026-48035High▾ Twilight@hulumi/baseline: AccountFoundation audit-delivery S3 bucket could be silently weakened
▾ Twilight zone — High severity, or a signal on a lesser flaw
impact 41.3 · likelihood 0.1 · exploitation 0
Need a working PoC? Pro members can cast a request and our team develops one — it lands right here.
Exploit-prediction probability, daily snapshots since Jul 25.
Disclosure to exploitation, from the record and what we observed since indexing it.
Disclosed via GHSA
0.3%
0.3% → 0.3%
Affected: @hulumi/baseline < 1.4.0 — Fixed in: 1.4.0 — Severity: High — CWE-1059 (Insufficient Technical Documentation / Behavioral Inconsistency)
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:
objectLock: false on 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.)forceDestroy was forwarded to the audit bucket. Nothing prevented a downstream stack from setting logBucketForceDestroy: true, which made pulumi destroy purge every audit-log object on teardown.AccountFoundation created its audit bucket with tier: "sandbox", which skipped Object Lock, server access logging, AND the CloudTrail-Lake EventDataStore (the independent immutable mirror) — leaving sandbox accounts with no audit immutability at all.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).
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):
forceDestroy: true on the startup-hardened tier;EventDataStore regardless of parent tier (so sandbox accounts regain immutable audit capture);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 Config ConfigWritabilityCheckFile probe key so Config's write-then-delete still works, which is why bucket-wide Object Lock is intentionally NOT re-enabled.Replicating audit logs out-of-account to an Object-Locked archive bucket partially mitigates while you upgrade.
### Migration for the forceDestroy behaviour change.@hulumi/baseline < 1.4.0Upgrade to a patched release:
@hulumi/baseline 1.4.0Connected by shared product, vendor, weakness, or advisory.
CVE-2026-48037Medium@hulumi/baseline: AccountFoundation reuse paths silently downgrade GuardDuty / Security Hub posture
CVE-2026-48032High@hulumi/policies bypasses IAM-role policy checks when the role trusts multiple OIDC providers
CVE-2026-48033High@hulumi/policies bypasses policy packs with a forged Pulumi-URN logical name
CVE-2026-48034High@hulumi/policies has a HULUMI-H5 bypass via decoy sibling resources targeting a different bucket
CVE-2026-48036High@hulumi/drift: Drift classifier fails open on adapter errors and over-promotes Mixed verdicts