Articles

Capital One disclosed a data security incident affecting approximately 100 million individuals in the United States and Canada, including personal information, customer status data, 140,000 Social Security numbers, about 80,000 linked bank account numbers and approximately 1 million Canadian Social Insurance Numbers.

A production configuration failure exposed highly sensitive data at scale to users who were authenticated but not authorised to access it, creating a clear access control and governance breakdown in a regulated environment.

A contractor-maintained GitHub repository associated with CISA publicly exposed plaintext passwords, tokens, logs and high-privilege AWS GovCloud credentials, with Seralys validating that at least three exposed AWS accounts were still accessible at a high privilege level.

PocketOS lost its production database and associated backups after a Cursor agent powered by Claude located an API token in a file and used it to delete the Railway volume holding the data. The incident is most useful as a credential governance failure: a token intended for limited operational use was discoverable, broadly permissive and apparently persistent enough to remain available for misuse.

CERT-EU attributed the European Commission cloud breach to TeamPCP, which used a compromised AWS API key stolen in the Trivy supply-chain attack to access the Commission’s Amazon cloud environment and exfiltrate data affecting up to 71 Europa web hosting service clients.

Grafana confirmed its breach stemmed from a compromised CI/CD environment after malicious TanStack npm packages exfiltrated GitHub workflow tokens and one token missed during rotation was later used to access private repositories.

A copy of the Mexican National Electoral Institute voter database containing 93 million records was exposed from a MongoDB deployment on Amazon EC2 after being left reachable from the internet with no authentication and no encryption.

Microsoft disclosed an incident where a blob storage URL containing an overly permissive Azure Shared Access Signature token was posted by an employee in a public GitHub repository, allowing Wiz to access internal data in a Microsoft storage account.

Railway’s reported outage is best understood as an operational dependency failure with direct security and governance implications. The core lesson is not a classic intrusion scenario, but the concentration risk of running a business on a single cloud provider account that can be suspended or deleted, taking the product offline with it.

Cisco Talos reported that UAT-10608 exploited the React2Shell vulnerability, tracked as CVE-2025-55182, to gain remote code execution on publicly reachable Next.js applications and harvest credentials at scale across at least 766 hosts.

ADT confirmed unauthorised access to customer and prospective customer data after detecting the intrusion on April 20 and later determining that personal information had been stolen. The key aspect is not just that data was taken, but that a reportedly single vishing event against an employee’s Okta SSO account may have provided a path into Salesforce, showing how one compromised identity can traverse linked enterprise systems and expand blast radius quickly.

Poland’s railway disruption demonstrates a core control failure: safety-critical operational commands were accepted without authentication or authorization, allowing unauthorised actors to trigger emergency stops with cheap radio equipment.

Whilst only affecting smaller hobby accounts both scenarios identify a clear cloud security failure pattern: public Google Maps API keys are intentionally exposed to browsers, yet they can create unnecessary blast radius when reused inside GCP projects that also enable non-public or back-end Google services.

Mazda reported the matter to Japan’s Personal Information Protection Commission, investigated with external specialists and implemented remediation including reduced internet exposure, patching, increased monitoring and stricter access policies. The exposed data included user IDs, names, email addresses, company names and business partner IDs. Mazda said it found no confirmed misuse, no malware, no ransomware and no direct operational impact. The clear lesson is not breach magnitude but asset rationalisation and visibility: organisations need enough inventory and context to decide whether niche systems should remain online, be segmented or be decommissioned before they create unnecessary disclosure, compliance and reputational risk.

UpGuard identified a publicly accessible AWS S3 repository operated by NICE Systems, a Verizon third-party vendor, that exposed customer call-centre logs containing names, addresses, phone numbers, account details and some unmasked Verizon account PINs.

UpGuard reported that Deep Root Analytics exposed 1.1 TB of downloadable data for up to 198 million potential U.S. voters through an Amazon Web Services S3 bucket with no access protections.

This incident is a classic misconfiguration leading to total data breach - Elasticsearch deployed on EC2 without authentication on port 9200 and left reachable from the public internet. This is not just a service hardening issue; it is an architectural failure in network placement, exposure control and access design.

Imperva disclosed that its Cloud WAF data exposure stemmed from unauthorised use of an administrative API key in a production AWS account, leading to access to a database snapshot containing email addresses, hashed and salted passwords, API keys and TLS keys for a subset of customers.

Microsoft disclosed that an internal customer support case analytics database was exposed after a network security group change on December 5, 2019 introduced overly permissive security rules and the issue was not remediated until December 31, 2019.

In a typical incident where S3 buckets have been left exposed to the internet, UpGuard reported that Accenture left four AWS S3 buckets publicly accessible on the internet, allowing anyone with the bucket URLs to download sensitive data tied to the Accenture Cloud Platform and related environments.

Code Spaces shut down after an unauthorised party accessed its AWS account and permanently deleted most customer data, including Apache Subversion repositories, Elastic Block Store volumes and all virtual machines, leaving the company unable to restore service.

Dow Jones exposed customer and Risk & Compliance data after an Amazon S3 bucket was misconfigured to permit access to AWS “authenticated users,” which UpGuard identified as effectively open to anyone with a free AWS account.

Due to the diminished activity in Private Equity over the last couple of years, PricewaterhouseCoopers has highlighted a shift from calendar-driven IPO planning to readiness-driven execution, with successful 2025 issuers investing 18 to 24 months in advance in governance, reporting infrastructure and institutional preparation.

BleepingComputer reports that Stryker needed roughly three weeks to return to a broadly similar level of operation after attackers allegedly stole 50TB of data and wiped nearly 80,000 devices. Even then, recovery was not complete: production was still moving toward peak capacity rather than fully restored.

BleepingComputer reports that Aura confirmed unauthorised access to nearly 900,000 records after a voice phishing attack against an employee. Aura says the exposed dataset came from a marketing tool inherited through a 2021 acquisition and that only about 35,000 records related to current or former Aura customers. The rest were legacy marketing contacts carried forward from the acquired company. Have I Been Pwned found the leaked data also included customer service comments and IP addresses, while ShinyHunters claimed to have stolen 12GB of customer and corporate data.

Socket, Wiz, and Aqua Security report that attackers compromised Trivy’s build pipeline and GitHub Actions, distributing trojanized binaries and workflows that harvested sensitive credentials across cloud and CI/CD environments.

The AWS Password Policy dictates the security standards and management of AWS IAM User passwords used for access to the AWS Console. We extend the default policy to increase security and minimise additional processes providing the most efficient password management configuration we can design.

An AWS security assessment evaluates the security posture of an AWS account, analysing the cloud resources contained in an account and their configuration. The goal of this assessment is to find any resources or vulnerabilities that can be maliciously utilised to compromise any services hosted in the AWS Account. Minimising these vulnerabilities will result in the hosted services being more resilient to attack and therefore adopting a stronger security posture.

In our previous article, we explored the benefits of adopting a multi-cloud architecture. In this article, we’ll deliver as promised some introductory architectures that can serve as your starting point for adopting a multi-cloud infrastructure.

Leveraging multi-cloud technologies and architectural patterns is becoming an increasingly important part of modern technology architecture. Whilst multi-cloud approaches offer numerous advantages, they also add complexity resulting in an expanded knowledge burden, additional access controls and an absence of replicable patterns.

If you are hosting applications on Amazon Web Services (AWS), it is important to consider the impact to AWS from your penetration testing. A key aspect of this consideration is determining whether what penetration testing can be safely conducted on the AWS platform without advanced permission and which testing should be abstained from without prior agreement.

Cloud providers come with built-in firewalls and firewall rules that control traffic routes and access to cloud resources. Proper configuration management of these firewall rules is absolutely critical, as they determine who or what is able to access your resources at a basic level. In our experience, improperly configured firewall rules are often involved in cloud security compromises.

Firewalls can take many forms such as Web Application Firewalls. For this article we consider AWS Security Groups and Azure Security Groups as “firewall rules” as they represent firewall rule functionality that is often found on network equipment such as pfsense Firewall Rules or Cisco Access Rules.

Cloud penetration testing is a specialised form of penetration testing that focuses on identifying vulnerabilities in the infrastructure, configuration, and accessibility of cloud resources. Regular penetration testing is focused on testing an application directly by identifying vulnerabilities that malicious actors might exploit directly in the application.

However, when applications are hosted in the cloud, the security of the cloud infrastructure itself becomes crucial. Tools and services provided by the cloud environment play a key role in safeguarding applications, potentially nullifying application level vulnerabilities. At the same time, this cloud configuration introduces a level of complexity that is not usually present in traditional hosting environments.

Automated penetration testing differs from regular penetration testing by utilising a set of tools and services that continuously test applications to identify and exploit both new and old vulnerabilities. Most tools available in the cloud and application security space have some level of automation, with some tools operating entirely automatically, requiring a small number of initial commands and configuration. These automated tools handle various components of the testing process, such as discovery, identification, scanning, and simulated attacks.