Most people picture a breach as something broken: a missing patch, weak password or coding mistake. Some of the most serious problems we find are none of those. Every part is doing what it was built to do, and the risk lives in what those parts add up to.
In this assessment, the starting condition was one standard tenant API key. By the end of the authorized proof, that key had enabled operating-system command execution on a customer-controlled server at the highest available privilege and exposed a path into the vendor’s wider multi-tenant environment. No traditional vulnerability was required.
A feature, not a flaw
Platforms compete on flexibility: bring your own code, connect your own systems and automate your workflows. The platform we assessed included a module that let customers upload and run their own scripts on the vendor’s infrastructure.
On paper, that was the point of the product. In practice, it was the first link in a chain that ended in privileged server control.
Following the thread
Nothing was obviously unpatched or misconfigured, and authentication was enforced at the front door. Instead of hunting for a single broken component, we examined how the intended features connected.
The platform ran customer-supplied code. When that code executed, it received credentials for a downstream business system as plaintext environment variables so the integration could operate. Those credentials belonged to a powerful administrative service account, and that account could invoke operating-system commands through a built-in function of the connected system.
Each decision appeared reasonable in isolation. Connected end to end, anyone holding the tenant API key could control the server, access business data and run commands as the machine’s most privileged account.
A strong password would not have closed the path
A natural first reaction was to strengthen the downstream account password. That would not address this route. The platform passed the password directly to the customer-supplied code; it never had to be guessed or cracked.
A long random password would have been disclosed and used in exactly the same way. Password policy still matters, but it was not the control separating this design from compromise.
Code execution was the beginning, not the end
A server is rarely an island. Privileged command execution can become a route to internal services, more credentials and persistence. A product feature that gives a tenant credential a route into a customer’s internal environment therefore requires a threat model extending beyond the feature’s intended workflow.
Reading past the obvious
The proof could have stopped at command execution. We continued, within the authorized boundary, to determine what an adversary would see next. The reached server exposed cloud credentials associated with the account behind it. Those credentials allowed enumeration of tenant metadata across the shared cloud environment.
The evidence boundary mattered. We read metadata such as names and timestamps, confirmed where platform controls prevented access to customer data, and demonstrated cross-tenant reach only against a vendor-controlled internal account. No unrelated customer data was accessed.
Threat-model what the feature makes possible.
The useful outcome was not another item on a patch list. It was a change in how the team understood the product: credential handling, tenant isolation, downstream privilege and customer-supplied code formed one control problem.
Automated scanning is valuable for the patterns it knows. This route became visible only by understanding how the product was meant to work and testing what those same design decisions allowed an adversary to connect.