On October 19, an attacker used a hijacked contributor account on GitHub to swap the download files on five existing releases of the OVHcloud command-line tool. The source code, however, remained untouched. And the build pipeline was not triggered at all. Interestingly, what the attacker did was simply replace files that customers already trusted. This is useful to understand because it shows how little an attacker needs once that trust is in place. And OVHcloud confirmed the new build aimed to steal secrets from any machine that ran it.
If you think about it, why go after the source code at all? It’s simple, why break in when you can simply swap what people already download? The swap simply worked because the releases were editable after publication, so any account with upload rights could change what customers installed. The files remained live for about 94 minutes. And in the end, a downstream user caught it only because their CI job checked each download against a pinned hash and failed when the hash no longer matched.
That contributor account never had production access, and it never needed any. It only needed the ability to change something production systems were flagged to trust. Exploiting that gap, between the access an account holds and what it can actually influence, is what Trevor Horwitz now looks for in every cloud-native assessment.
Horwitz is co-founder and CISO of TrustNet, with more than two decades of rich experience in cybersecurity. As a PCI Qualified Security Assessor, he helped shape PCI’s work on virtualization and cloud security. In today’s issue, he walks through why compliant cloud-native environments still break, from privileges that pass between systems and secrets that end up in logs to shared pipeline identities that defeat segmentation.
Let’s dive in.
THIS WEEK’S TECHNICAL SESSION
GitHub Actions supply chain attacks, walked through in code.
Magno Logan, Partner and CTO at GoHacking, shows how attackers abuse GitHub Actions workflows to reach a software supply chain, and how to secure each step in code. It pairs well with this issue, since a pipeline identity is often the shortest route between a pull request and production.
THE INSIDER VIEW
Compliant Cloud Environments Still Break Along Their Attack Paths
Featuring Trevor Horwitz, Co-founder and CISO of TrustNet.
Horwitz has assessed security programs for more than two decades, long enough to watch the security boundary move with each new generation of infrastructure. “I think the biggest change we’ve seen is that the security boundary is no longer primarily the network perimeter,” he shares. A decade ago, an assessment covered hosts, network segmentation, patching, firewall rules, and fairly static administrative access. Kubernetes, serverless workloads, SaaS integrations, and CI/CD systems now change the environment constantly, and the attack surface has become “much more identity, API, and configuration driven.”
And the questions changed with it. “An assessor used to just ask, ‘Is the system configured securely?’” he reflects, looking back at how much wider the assessor’s job has grown since then. “Now we have to ask questions that are much deeper. We have to ask what identities can modify the configuration, what automation can deploy to it.” And evidence collection has had to change just as much. A screenshot of a firewall rule records a point-in-time control state, and Horwitz points out that “that doesn’t necessarily tell you today whether an attacker can chain multiple legitimate permissions.”
So stop treating a passing control as proof of a safe environment. For every system in scope, list the identities that can modify it and the automation that can deploy to it. That list describes the attack surface better than the configuration does.
Ephemeral infrastructure moves the audit upstream
A network diagram is still the first thing Horwitz asks for, but he treats it as a starting point rather than an answer. Containers spin up and disappear within minutes, and that leaves every assessor with the problem he puts plainly. “So how do you audit something that’s constantly changing and evolving?”
In our interview session, he tells us about a seasonal client that grows from 1,000 servers to 10,000 servers “literally overnight” and keeps assessors away during its busy season. And by the time an engagement starts, the environment under review may look nothing like the one that was running six or nine months earlier.
That is why he makes a strong case for auditing the factory rather than the product. “Our focus becomes much more on what is actually producing those systems and what standards they have for secure deployment,” he explains. So put your deployment templates, base images, and pipeline definitions in front of the assessor early. Those artifacts outlast any single container and decide what every new workload looks like.
Effective privilege outruns assigned privilege
Most access reviews check one account at a time and confirm that each account has the access it should. Cloud environments strain that model because privileges pass from one system to the next. Horwitz sees this transitive privilege as the point where frameworks written for data centers struggle most. He frames it with a hypothetical user named Alice. “Our questions used to be about, does Alice have production access? But now we’re saying, can Alice influence anything that has production access?” he argues.
That shift matters because influence reaches further than access. In cloud environments, Horwitz adds, “the effective privilege of a user or a system is often greater than the assigned privilege.” An environment can pass its access review while a service account is one hop from admin, because nobody assigned that hop. The OVHcloud contributor account from this week’s opening note fits the pattern, since it had no production role yet could change what customers installed.
Closing that gap means looking past the review itself. Horwitz’s team assesses “the actual privileges associated with each one of those accounts” and then chains permissions between systems to see where they lead. So run your next access review against effective privilege. For each identity with write access to a pipeline, repository, registry, or release, trace what that access can ultimately change, and treat anything that reaches production as production access.
Secrets leak through the engineering cycle
Secrets show the same gap between what an audit checks and what an attacker finds. Most teams can point to a vault, and an assessment could easily stop there. Horwitz looks further, because “the weakness is usually how the secrets are moving through the engineering cycle.” He wants to know how secrets originate, who can retrieve them, where they appear in CI/CD, and whether developers can pull production credentials. “I don’t just want to assess whether or not a vault exists for the secrets,” he stresses. “I really want to look at whether the architecture actually minimizes the possession of those reusable credentials.”
Logs are where those secrets most often turn up. Horwitz describes it as “an accepted risk today that the logging has become so sophisticated that we’ll end up logging pretty much everything within those streams.” That means a well-configured vault can coexist with log streams that contain the very credentials it protects.
So scan your log streams and repositories for secrets with the same rigor you apply to the vault configuration. And where you can, replace long-lived credentials with short-lived workload identities, the architectural improvement Horwitz sees most often.
Shared identities defeat network segmentation
Segmentation is where audit posture and real attack surface drift furthest apart. PCI DSS requires it, cloud-native networks start flat, and teams often meet the requirement with separate VPCs, subnets, namespaces, and Kubernetes network policies. Horwitz counts that as network segmentation, which he separates from security domain isolation. Those separate networks can still leave weak isolation when the environments share “an identity provider or a CI/CD runner or container registry, Kubernetes control plane, or privileged automation.”
The pipeline is the clearest example of how that happens. “You could have two workloads maybe completely isolated at layer three, while the same CI/CD identity can deploy arbitrary code to both,” he cautions. That is why he tests segmentation from the attacker’s position and asks which boundary would actually stop someone who compromises a workload or an identity from reaching the next environment.
It is also why he treats CI/CD as production infrastructure. Pipelines hold cloud credentials, sign artifacts, publish containers, and deploy workloads. The pattern that worries him most is a pipeline with broad, persistent cloud credentials granted “simply because your automation needs to work.”
So map every identity, runner, and registry shared across environments you treat as separate, and test segmentation through those shared paths as well as through the network. For pipelines, move to federation and short-lived credentials, which he says “let the organization reduce that risk substantially.”
Prioritize findings by what they connect to
All of this turns up as findings, and Horwitz sees the same ones year after year, whatever the stack. Excessive permissions, long-lived credentials, and weak separation between development and production recur across his cloud-native clients. So do secrets in workflows and logs, unintended internet exposure, and vulnerabilities left open because nobody owns the fix.
With that much to fix, the order matters. Severity scores alone can send a team after the wrong problem first, so Horwitz weighs each finding by what it touches. “If you had a high vulnerability and it was connected to a system that had a low value, you want to deprioritize that against a medium vulnerability that was connected to a highly sensitive resource,” he reasons. That context does not always come from the assessor either, and he admits that “not every assessor when they’re doing a pen test or looking at a security assessment is going to understand all of that.”
So tell your testers which systems matter most before the engagement begins, and rank remediation by the sensitivity of what each finding connects to. And treat testing as a cycle of assessment, remediation, and retest rather than an annual snapshot. PCI DSS already requires service providers to test segmentation controls every six months, and Horwitz expects that cadence to tighten over the next five years.
Vector databases are a target teams underrate
AI brings a newer version of the same blind spot. Horwitz notes that every client he works with now integrates some aspect of AI into its business processes or backend systems. Most of the security attention goes to the model. The vector database behind it gets far less, because many teams see it as low-value storage.
“I think it’s a mistake to have that mindset, because clearly vectors can have and do have meaning, and they could become targets for attackers,” he says. Those embeddings come from an organization’s own internal data, which is why he ranks the risk above the model itself. “Yes, we need to worry about AI models, but I’d be more concerned, frankly, about things like vector databases and embeddings.”
So bring vector stores and embedding pipelines into scope with the same access controls, logging, and data classification you apply to the source data they came from.
Watch the full session below.
THIS WEEK’S PERSON OF INTEREST
Brendan Dolan-Gavitt, Distinguished Engineer and AI Researcher at XBOW
Brendan Dolan-Gavitt was working on AI and vulnerability research well before agents started building exploits. His academic work in NYU’s Department of Computer Science and Engineering included PANDA, an open-source platform for dynamic analysis. In 2022, he received an NSF CAREER award to use large language models trained on code to create realistic synthetic vulnerabilities. He is now a Distinguished Engineer and AI Researcher at XBOW.
This August, he turned that experience on Chrome. Working alongside AI agents running OpenAI’s publicly available GPT-5.6 Sol model, he built a full exploit chain in six days. The chain linked three previously unknown bugs and crossed both of Chrome’s nested sandboxes, so a user only had to load a web page for code to run on their Windows machine. Google paid XBOW $250,000 for it, against a compute bill of about $40,000. Chrome has since patched all three bugs, and XBOW says nobody used them against Chrome users.
In his own write-up, he compares that timeline with how long this work used to take. “Pre-LLMs a Chrome full chain would take a team of four around 6-9 months to be produced, our first submission took 2 months,” he writes. The awarded chain took six days, and his conclusion for everyone else is to “defend accordingly.”
Read: AI Agents Help Build a $250,000 Chrome Exploit in 6 Days
THIS WEEK’S SECURITY BRIEFS
Stolen service account credentials gave a month of access at PingCAP
PingCAP says an unauthorized party used stolen service account credentials to reach internal systems from September 9 to October 7. The intruder copied TiDB Cloud account data, SQL editor content, contract terms, pricing, and a table of encrypted API-key values. PingCAP began disabling the affected credentials on October 7, then removed excessive permissions between cloud projects and fixed four vulnerabilities that an outside firm reported. The company reports no evidence of impact to data stored in TiDB itself.
GitLab patches a maximum-severity flaw reaching back to version 7.0
GitLab released fixes on October 21 for CVE-2026-110264, a CVSS 10.0 flaw that could let an unauthenticated user run arbitrary code on a self-managed GitLab server. An integer overflow when compiling a specially crafted regular expression causes it, and it affects every unpatched version back to 7.0. GitLab.com already runs the patched version, and GitLab has published two detections for exploitation attempts. Self-managed instances should move to 19.5.1, 19.4.3, 19.3.6, or the matching fix for their branch.
OpenCode Console breach puts stored AI provider keys at risk
OpenCode says an intruder reached a legacy system on the night of October 16. The breach may have exposed the OpenAI, Anthropic, and Google API keys that users saved in OpenCode Console, its optional hosted service. The company puts the affected share at 1.4 percent of Console users and told them to revoke and replace their keys. Keys stored locally in the CLI and desktop apps never reach OpenCode, according to co-founder Dax Raad. Deleting a key from Console does not revoke it with the provider.
Autonomous agents broke into company websites for roughly $50 per success
NorForge researchers found an operator running Cairn, an open-source agent framework built for authorized penetration testing, against more than 1,200 sites with little human help. The agents planted web shell uploaders through flaws such as unauthorized write access to a memcached session store and old Zend Framework code. Reuters reported breaches at more than 100 companies. Successful intrusions averaged just under 23 hours, and exposed agent panels leaked hundreds of victim secrets.
Thank you for reading Offensive Engineering, a newsletter from InfoSec Relations. We will be back next week.
Stay curious, stay secure.
Shant Ebenezer Jena
Volunteer Host, Offensive Engineering