ShutterGap Exposes Millions of AWS Cloud Resources Between Security Scans

A critical blind spot in cloud security tooling, dubbed “ShutterGap,” in which millions of AWS resources are briefly and publicly exposed, only to disappear before traditional monitoring tools can detect them.

Researchers Ariel Litmanovich, Tom Tsabar, and Ido Dar found that Cloud Security Posture Management (CSPM) and Cloud-Native Application Protection Platform (CNAPP) tools, which typically scan environments once every 24 hours, fundamentally cannot detect exposures that appear and vanish within minutes.

While monitoring public RDS snapshots in AWS’s us-east-1 region, the team observed the snapshot count fluctuate 12 times within just 90 minutes, with six creations and six deletions of publicly shared resources occurring in that short window.

ShutterGap Exposes Millions of AWS Cloud Resources

The exposed resource types include RDS and DocumentDB snapshots, EC2 AMIs, EBS snapshots, SSM documents, and public ECR repositories.

When misconfigured, these resources become fully accessible to any AWS account, bypassing network restrictions entirely and requiring only simple enumeration to discover.

The data reveals just how narrow these windows have become. Twenty percent of public RDS snapshots existed for less than two minutes, while 99% of deleted RDS and DocumentDB snapshots vanished within 30 minutes of creation.

Roughly 30% of exposed SSM documents and AMIs disappeared within 24 hours, a timeframe faster than many CNAPP scan cycles complete.

Despite these brief windows, attackers don’t need much time to cause damage, since copying a snapshot to an external AWS account takes only seconds, after which the data can be restored and analyzed at leisure, entirely independent of how long the original exposure lasted.

To validate real-world risk, researchers built an automated pipeline that restored 24 sample public snapshots, dumped their contents, and scanned them using TruffleHog alongside custom detection rules.

Every single snapshot contained AWS account IDs, and many exposed secrets, private keys, email addresses, and even credit card numbers, confirming that this isn’t a theoretical concern but an active data-leakage vector.

Aryon’s core argument is that the “detect, then remediate” model central to most CNAPP platforms is structurally incapable of addressing exposures that live and die between scan cycles.

By the time an alert fires, gets triaged, and reaches a human responder, the attacker has often already copied the data and moved on. The report emphasizes prevention over detection, using AWS Service Control Policies (SCPs) as guardrails across each affected resource type.

For RDS and DocumentDB, organizations can deny ModifyDBSnapshotAttribute actions outright or enforce storage encryption, since encrypted snapshots cannot be shared publicly in the first place.

For AMIs, teams should lock in AWS’s default “Block Public Access for AMIs” setting via SCP to prevent it from ever being disabled. For SSM documents, which are not protected by default, administrators must first enable the account-level public-sharing block and then lock it in place using deny rules against ssm:UpdateServiceSetting.

Organizations are also advised to audit CloudTrail logs from the past 90 days for ModifyDBSnapshotAttribute, ModifyImageAttribute, and ModifyDocumentPermission events to check for historical exposure.

The research builds on earlier findings from Mitiga around exposed RDS snapshots but diverges sharply on remediation strategy, arguing that detection-first approaches are inadequate for threats that materialize and disappear in seconds.

Importantly, Aryon notes this isn’t an AWS vulnerability but a widespread customer misconfiguration issue that AWS documentation already explicitly warns against.

Cut SOC investigation blind spots and contain threats earlier to reduce response costs and business disruption with ANY.RUN.