Audit log tamper-resistance failure in @hulumi/baseline versions prior to 1.4.0 allows any S3-delete-capable principal in the AWS account to silently erase CloudTrail and AWS Config forensic records that the AccountFoundation construct was advertised to protect. Three compounding defects - hard-coded objectLock:false on the startup-hardened tier, unrestricted propagation of forceDestroy/logBucketForceDestroy to the audit bucket, and a sandbox tier that omitted Object Lock, server access logging, and the CloudTrail-Lake EventDataStore entirely - left consumers believing they had immutable audit capture when they did not. No public exploit identified at time of analysis, no CVSS or EPSS published, and the issue is a defense-in-depth/forensic-integrity weakness rather than a remote code execution path.
Policy bypass in @hulumi/policies versions prior to 1.4.0 allows an unhardened raw AWS S3 bucket to pass the HULUMI-H5 defence-in-depth check by pairing it with five decoy sibling hardening resources that reference a different bucket. Consumers of HulumiHardeningPack can ship S3 buckets with no public-access block, no SSE-KMS encryption, no ownership controls, no versioning, and no TLS-only bucket policy while the policy pack reports the stack as compliant. No public exploit identified at time of analysis, though the upstream fix and regression tests publicly document the bypass technique.
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.
Detection bypass in @hulumi/policies versions prior to 1.4.0 allows IAM trust policies that list multiple OIDC federated providers to evade the G_OIDC_1 and G_OIDC_2 policy checks for GitHub Actions OIDC roles. Consumers of HulumiHardeningPack or HulumiGithubHardeningPack can therefore ship roles with wildcard sub: conditions - assumable by untrusted forked-PR workflows - while the validator falsely reports compliance, including missing the AdministratorAccess blast-radius flag. No public exploit identified at time of analysis, and there is no CISA KEV listing.