Football Australia Exposed AWS Access Key and Public S3 Buckets Containing Player and Fan Data

A long-term AWS key was embedded in public website assets for roughly 681 days, enabling discovery of 126 accessible S3 buckets while at least one bucket was publicly exposed without credentials

Football Australia exposed a long-term AWS access key in the source code of its public website and, according to the incident details, that key granted access to 126 S3 buckets containing sensitive player and fan information.

The reported exposure lasted from approximately March 2022 until responsible disclosure on February 1, 2024. CyberNews reported that at least one S3 bucket was also completely unprotected and publicly accessible without credentials, with exposed contents including player passports and contracts. Football Australia stated the exposed data included personally identifiable information, ticket purchase information, internal infrastructure details, source code and infrastructure scripts. The incident reflects multiple overlapping failures: secrets delivered directly to the public frontend, excessive access tied to a long-term key, insecure S3 bucket configuration independent of the key leak and a production implementation reportedly involving Cognito in a way that did not require shipping AWS credentials to users. The combined lesson is clear: cloud identity, storage controls and deployment governance failed together, increasing breach impact, discovery speed and potential compliance exposure.

What went wrong

What Happened Cause Action
Public website assets contained a long-term AWS access key Sensitive credentials were embedded in frontend source code and delivered directly to any website visitor Validate that no cloud access keys, tokens or secrets are present in client-side code, build artefacts, repositories or static assets. SkySiege assesses present IAM access keys, identify which long-term credentials are in use and allows for visibility into common and regular usage patterns which allows visibility into implementing explicit controls over unusual usage patterns.
The leaked key could enumerate accessible buckets, making discovery trivial The exposed key reportedly had permission to access 126 S3 buckets indicating excessive access scope Validate IAM policies attached to application identities for least privilege, especially S3 list and read permissions. SkySiege maps identities and usage patterns allowing for maximum visibility of each identity’s blast radius.
At least one S3 bucket was publicly accessible even without the key S3 access controls were misconfigured, leaving sensitive data reachable by standard internet requests Validate S3 public access block settings, bucket policies, ACLs and object exposure. SkySiege checks specifically for internet-accessible buckets, public object exposure and whether sensitive data is accessible anonymously regardless of credential compromise.
Sensitive player, fan and infrastructure data were exposed from storage Data classification and storage governance were insufficient for the sensitivity of the content stored in S3 Validate where PII, contracts, passports, source code and infrastructure scripts are stored and whether access is segmented by data sensitivity. SkySiege searches for tagging appropriate for data and environment classification and flags up controls for missing classifications.
The implementation appears to misuse Cognito-related access patterns The incident details indicate a bad production design because AWS credentials were reportedly exposed to end users in a scenario that did not require that model Validate application authentication and federation design to ensure frontend users are not issued unnecessary backend cloud credentials.
Ticket purchase information was reportedly exposed, creating possible payment compliance issues Sensitive purchase-related data was reportedly present in exposed storage, suggesting weak control over payment-adjacent data flows Validate whether payment-related data is stored in cloud buckets, whether scope includes PCI-relevant systems and whether storage paths meet retention and access requirements.
The exposure remained in place for roughly 681 days Secret scanning, storage exposure monitoring and deployment governance did not detect or stop the issue in a reasonable timeframe Validate continuous detection for leaked credentials, public buckets and drift in storage policies across production environments. SkySiege offers results the same day allowing for full control over the picture and the ability to protect and remediate before external notification.

Why this matters

This incident is not a single control failure. It is a stacked failure across identity, storage, application design and governance.

From a detection standpoint, the most important lesson is that a leaked key in a public web asset should have been rapidly discoverable through secret scanning, external attack surface review or CI/CD controls. Key exposure is more dangerous when the identity behind it has broad enumeration and storage permissions. Once an attacker has a working AWS key, bucket discovery can become clear rather than speculative.

The public S3 bucket materially worsens the risk. Even if the access key had never been exposed, at least one bucket was reportedly accessible without credentials. That indicates an independent storage security failure and a visibility gap in internet-exposed data assets. For due diligence and enterprise governance, this matters because it suggests the issue is architectural, not accidental.

The reported exposure of PII, passports, contracts, source code, infrastructure scripts and ticket purchase information creates business risk beyond technical compromise. Likely impacts include breach response cost, legal notification obligations, regulatory scrutiny, reputational harm and potential contractual fallout. The mention of ticket purchase information also raises possible PCI exposure. While the available facts do not confirm cardholder data exposure, storing payment-related information in publicly accessible buckets is a strong indicator of weak control design around regulated data flows.

The broader enterprise lesson is clear: if a production web stack is shipping cloud credentials to users and exposing storage directly organisations should expect adjacent weaknesses in IAM design, bucket governance and deployment review. SkySiege would treat this as a signal to assess not just the leaked key and bucket policies, but the surrounding cloud architecture for systemic privilege, exposure and compliance failures.

References

Original Article