CVE-2026-48035: Hulumi Pulumi Information Disclosure Flaw

CVE-2026-48035 Overview

CVE-2026-48035 affects Hulumi, an open-source toolkit that ships secure-by-default cloud and platform infrastructure components for Pulumi. Versions prior to 1.4.0 allow tampering with AWS CloudTrail and Config audit logs in accounts provisioned through the AccountFoundation component. Any principal with S3 delete permissions could remove audit records, while operators believed the startup-hardened tier guaranteed tamper-resistance. Sandbox-tier deployments shipped with no audit immutability at all. The flaw is a configuration and design defect classified under [CWE-1059].

Critical Impact
Attackers holding low-privilege AWS credentials with S3 delete rights can erase CloudTrail and AWS Config evidence, breaking forensic integrity and compliance guarantees in accounts provisioned by Hulumi below version 1.4.0.

Affected Products

Hulumi toolkit versions prior to 1.4.0
AWS accounts provisioned via AccountFoundation startup-hardened tier
AWS accounts provisioned via AccountFoundation sandbox tier

Discovery Timeline

2026-07-24 - CVE-2026-48035 published to NVD
2026-07-30 - Last updated in NVD database

Technical Details for CVE-2026-48035

Vulnerability Analysis

Hulumi's AccountFoundation module provisions AWS accounts with baseline logging via CloudTrail and AWS Config. The startup-hardened tier documents tamper-resistance for these logs, but the underlying S3 buckets storing audit data were not configured to enforce object immutability. Any IAM principal in the account granted s3:DeleteObject or s3:DeleteBucket permissions could remove audit records without triggering write-protection controls.

The sandbox tier compounded the issue by omitting audit-log immutability controls entirely. Operators using the toolkit had no signal that the security posture differed from the documented guarantee. The result is a breakdown in non-repudiation: attackers with existing footholds can erase the very telemetry needed to reconstruct their activity.

Root Cause

The root cause is a missing security constraint in the Infrastructure-as-Code (IaC) definitions shipped by AccountFoundation. S3 buckets holding CloudTrail and Config data lacked S3 Object Lock in compliance mode, bucket policies denying delete APIs, and MFA-delete enforcement. Because the module represents itself as secure-by-default, downstream consumers inherited the gap without additional review.

Attack Vector

An authenticated AWS principal with low privileges but S3 delete capability targets the CloudTrail or Config bucket created by AccountFoundation. The attacker issues DeleteObject or DeleteObjects calls against audit log prefixes, removing evidence of prior actions. No network-level exploitation is required; the vulnerability is exercised through standard AWS APIs. Because the affected buckets are the sinks the account itself trusts for compliance, tampering also undermines downstream SIEM ingestion and integrity monitoring built on those objects. See the GitHub Security Advisory GHSA-2mxr-p26x-mj73 for the maintainer's technical description.

Detection Methods for CVE-2026-48035

Indicators of Compromise

CloudTrail DeleteObject or DeleteObjects events targeting the CloudTrail or AWS Config log bucket.
Gaps or missing time ranges in CloudTrail log file delivery, or missing Config snapshot deliveries.
CloudTrail StopLogging, DeleteTrail, or PutBucketPolicy events against audit resources by non-administrative principals.

Detection Strategies

Alert on any S3 delete API call whose bucket name matches the CloudTrail or Config audit sinks provisioned by AccountFoundation.
Correlate CloudTrail log file integrity validation failures (aws cloudtrail validate-logs) with recent principal activity to identify tampering.
Baseline expected writers to audit buckets and flag any principal outside that set performing mutating operations.

Monitoring Recommendations

Forward CloudTrail management and data events to an out-of-account destination that the source account cannot modify.
Enable AWS Config rules cloud-trail-log-file-validation-enabled and s3-bucket-versioning-enabled on all audit buckets.
Continuously verify that Object Lock is present on audit buckets and alert when it is absent or disabled.

How to Mitigate CVE-2026-48035

Immediate Actions Required

Upgrade Hulumi to version 1.4.0 or later and re-deploy accounts previously provisioned by AccountFoundation.
Inventory existing AWS accounts created with prior Hulumi versions and manually apply Object Lock and restrictive bucket policies to CloudTrail and Config buckets.
Rotate credentials for any IAM principals that hold s3:Delete* on audit buckets and remove those rights where not required.

Patch Information

The issue is fixed in Hulumi 1.4.0. The maintainer's fix is described in the GitHub Pull Request #178 and released in Hulumi v1.4.0. The patched module configures audit log buckets with tamper-resistance controls across both sandbox and startup-hardened tiers.

Workarounds

Apply an explicit deny bucket policy on CloudTrail and Config buckets denying s3:DeleteObject, s3:DeleteObjectVersion, and s3:DeleteBucket to all principals except a break-glass role.
Enable S3 Object Lock in compliance mode with a retention period aligned to your audit retention policy on all existing audit buckets.
Replicate audit logs to a dedicated log archive account with Service Control Policies (SCPs) that block deletion.

bash

# Configuration example: enforce deny-delete on a CloudTrail bucket
aws s3api put-bucket-policy --bucket <cloudtrail-bucket> --policy '{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "DenyAuditLogDeletion",
    "Effect": "Deny",
    "Principal": "*",
    "Action": ["s3:DeleteObject", "s3:DeleteObjectVersion", "s3:DeleteBucket"],
    "Resource": [
      "arn:aws:s3:::<cloudtrail-bucket>",
      "arn:aws:s3:::<cloudtrail-bucket>/*"
    ]
  }]
}'