What is a cloud vulnerability?
A cloud vulnerability is a weakness in a cloud-based service, configuration, identity, or operational process that can let an attacker reach data or systems they should not. It isn’t limited to an unpatched server. Public exposure, embedded secrets, excessive permissions, and data retained in a provider’s support systems can all open a path.
That last category is easy to overlook. Companies often picture their cloud footprint as the production database and application. In practice, information also travels through management consoles, diagnostic logs, service tickets, and vendor tooling. A weakness there can matter just as much as a flaw in the workload itself. The TiDB/PingCAP incident is a useful warning, though the details reported by attackers should be treated cautiously. Dark Reading
AI cloud vulnerabilities and the vendor data trail
On Oct. 19, PingCAP, the maker of the TiDB SQL database, disclosed a breach. Dark Reading reported that the company served major US businesses including Atlassian, Square, and Pinterest, as well as companies in China’s AI sector. The attackers, a group calling itself Fulcrum Security, claimed access to a range of PingCAP’s cloud management, financial, analytics, and storage systems.
The central customer risk wasn’t necessarily a direct intrusion into each customer’s primary database. The article said early evidence suggested the vendor-held information about customers might itself be sensitive, while investigations were still ongoing. That distinction matters: a customer can avoid a direct database compromise and still face exposure through the provider that operates or supports the service. Dark Reading
Dark Reading described claims that the attackers accessed Jira tickets, SQL histories, and other internal data. It also reported that attackers alleged they had replicated PingCAP’s service management system and pulled fresh copies of an internal database every six hours for 22 days. These are reported attacker claims, not independently confirmed findings; the article explicitly cautioned readers about that uncertainty. Keep that caveat attached to the story. Dark Reading
Why vendor data becomes an attacker’s map
Operational records can reveal more than companies expect. A query history or error message may contain a pasted connection string; a support ticket can capture internal context; metadata can show which systems and teams are connected. Dark Reading cited examples of exposed SQL statements that appeared to include a clinic’s patient roster and a list of medical professionals. That doesn’t prove every log contains secrets. It does show why logs deserve the same care as other sensitive records. Dark Reading
Security practitioners quoted in the report warned that attackers can use upstream credentials rather than break into a customer’s main database. Metadata, API keys, and diagnostic query logs collected through routine service operation may help an intruder understand where to go next. If a vendor account or administrative token is compromised, that accumulated context can become a practical route toward customer systems. Dark Reading
This is why “we didn’t put secrets there” isn’t enough. People paste commands into consoles while debugging. Errors get recorded. Convenience features retain history. Vendor systems can become quiet repositories for data nobody intentionally classified as a credential store. The point is not to assume every provider is unsafe; it’s to find out what the service captures, where it keeps it, and for how long. Dark Reading
Familiar cloud weaknesses still matter
Tenable reported that 54% of organizations in its research stored at least one secret directly in AWS Elastic Container Service task definitions; it reported similar findings for GCP Cloud Run (52%) and Azure Logic Apps workflows (31%). It also said 3.5% of AWS EC2 instances had secrets in user data. Those figures come from Tenable’s research and should not be read as universal rates for every cloud environment. Tenable
Tenable also described a “toxic cloud trilogy”: a workload that is publicly exposed, critically vulnerable, and highly privileged. Its reported prevalence fell from 38% to 29%, but the combination remained a meaningful risk. A weakness becomes more consequential when exposure, a critical flaw, and broad permissions overlap. Tenable
Identity controls need scrutiny too. Tenable said 83% of AWS organizations in its research used identity-provider services to manage cloud identities, while warning that permissive defaults, excessive entitlements, and standing permissions can still leave exposure. Using an identity provider is not the same as ensuring every identity has only the access it needs. Tenable See also how organizations govern non-human identities.
Shared responsibility doesn’t mean transferred risk
Cloud providers and customers divide security work; the boundary varies by service. AWS describes itself as responsible for components such as the underlying host operating system, virtualization layer, and physical facilities. Customers remain responsible for areas including guest operating systems, application software, and configuration of security groups, with responsibilities changing according to the services selected and how they are integrated. AWS Shared Responsibility Model
That model is useful, but it isn’t a promise that the provider absorbs every consequence. Customers still need to understand what their services store and how their own access is configured. And when a service provider retains operational records, those records can become part of the customer’s risk picture even if the customer’s primary database is untouched. The boundary deserves a conversation before an incident, not after one.
Questions to ask before choosing a provider
Start with the data trail. Ask what customer-provided content the vendor retains, including diagnostic data, query history, support attachments, and service tickets. Ask how long each category remains available, who can access it, and whether deletion is possible. Dark Reading quoted an expert recommending that customers understand retention practices and whether secrets are scanned at ingestion and redacted. Dark Reading
Then ask about credentials: Are service-account credentials and administrative API tokens short-lived? Are they narrowly scoped? How often are they rotated, and what alerts fire when use looks unusual? These are practical questions, not paperwork. A credential that sits around indefinitely or reaches more systems than needed makes a breach harder to contain. Dark Reading
Finally, ask how the provider demonstrates its controls. The report’s experts recommended continuous third-party risk assessment and independent certifications or attestations such as SOC 2 Type II and ISO 27001. These don’t eliminate risk, but they help make security practices something buyers can examine rather than simply take on faith. Dark Reading
What to do inside your own environment
Reduce the secrets that reach vendor systems in the first place. Rotate vendor-facing API keys, avoid hardcoded and long-lived credentials in developer workflows, and check whether troubleshooting habits put sensitive material into query histories or error output. Where a service offers redaction or retention controls, make sure they’re configured and test what gets captured. Dark Reading
Review cloud exposure and identity together. Look for publicly reachable workloads, critical vulnerabilities, secrets embedded in deployment configuration, and permissions that exceed the job. Tenable’s findings illustrate why these issues shouldn’t be reviewed in separate silos: public exposure combined with a flaw and privileged access creates a worse condition than any one factor alone. Tenable
The uncomfortable lesson is simple: data can come home to roost even when it left your systems as routine operational noise. Your provider may need some information to run the service. That doesn’t make every retained trace harmless. Treat vendor-held telemetry as part of the cloud environment, ask what it contains, and make sure credentials and permissions give an attacker as little room as possible.