CyberSip™ — Issue 107 — August 13, 2026

Today's picture

A 153GB archive of credentials stolen in a March 2026 supply chain attack on LiteLLM versions 1.82.7 and 1.82.8 surfaced today, with Hudson Rock and CloudSEK attributing exposure across more than 2,500 organizations and 434,000 CI/CD pipelines containing AWS, Azure, GCP, and Kubernetes keys, SSH credentials, repository tokens, and AI provider secrets from NVIDIA, Samsung, Cisco, Salesforce, Siemens, and many others. VMware vCenter CVE-2026-59310, covered as a patch urgency in Issue 97, is confirmed actively exploited in a campaign QUIRSO traced to 361 victim IP addresses across 47 countries, with exploitation beginning five days after Broadcom published the advisory and attackers using reverse SSH to maintain persistent access. SAP released an emergency security note for CVE-2026-58231, a CVSS 10.0 code injection vulnerability in the SAP Commerce Cloud Data Hub Adapter that lets an unauthenticated attacker execute arbitrary code on affected systems with no workaround available.

Today's intelligence

3 items

01 CriticalLiteLLMAI Supply Chain

A 153GB archive of cloud keys and AI secrets stolen from 2,500 organizations in the March LiteLLM supply chain attack surfaced today

The compromised packages were on PyPI for roughly 40 minutes in March. Automated CI/CD systems downloaded them before they were removed. The stolen data includes AWS, GCP, Azure, and Kubernetes credentials, SSH keys, repository tokens, and AI provider keys. The credentials may still be active. The window to revoke them is open right now.

CVECVE-2026-33634
CISA KEV Mar 26

PackagesLiteLLM 1.82.7
LiteLLM 1.82.8

Attack dateMarch 24, 2026

Data surfacedAugust 13, 2026

Scope2,500+ orgs
434,000 pipelines
153GB archive

Sources The Hacker News Help Net Security

What happened

On March 24, 2026, a threat group tracked as TeamPCP compromised the Trivy security scanner used inside LiteLLM's CI/CD build pipeline. LiteLLM is an open-source gateway that developers use to route requests across AI models including OpenAI, Anthropic, Google, and other providers. It is downloaded roughly three million times per day. The compromise chain worked in three steps. The attackers had already compromised the Trivy scanner weeks earlier, obtaining a PyPI automation token that was rotated but not fully revoked. That 20-day window of partial credential validity gave the attackers access to publish to the Trivy project. When LiteLLM's pipeline ran its routine Trivy security scan, it installed the poisoned scanner from the system package manager. The compromised scanner then produced the two malicious LiteLLM releases, versions 1.82.7 and 1.82.8, and published them to PyPI. Those versions were available for roughly 40 minutes before removal. The malicious packages contained a .pth file that executes whenever the Python interpreter starts, regardless of whether LiteLLM is ever imported. This bypassed install-time lifecycle hook protections that most supply chain defenses rely on. The credential stealer the FBI identifies as SANDCLOCK escalated to root and swept SSH keys, AWS, GCP, and Azure credentials, Kubernetes service-account tokens, environment files, CI/CD secrets, and repository tokens from affected systems. Cloud keys were obtained directly from the instance metadata service using access the runner already had rather than through any additional exploit. AI provider keys and gateway configuration data were included in the haul. Stolen data was encrypted and exfiltrated to a typosquatted domain. A 153GB archive of this stolen data surfaced publicly today. Hudson Rock analyzed the archive and attributed 118,829 CI runner dumps to 2,488 corporate domains. CloudSEK placed the total at over 2,500 organizations and 434,000 pipelines. Named organizations in both analyses include NVIDIA, Samsung, Cisco, Salesforce, Siemens, S&P Global, ServiceNow, Deloitte, Vodafone, X Corp, Zscaler, FedEx, Volkswagen, Thales, and London Stock Exchange Group. The CISA KEV entry CVE-2026-33634 was added on March 26. The FBI issued a FLASH advisory in July 2026 warning that stolen credentials from this attack could still be active and weaponized for future attacks.

Why it matters

The 153GB archive surfacing today changes the operational status of this incident. From March through August, the stolen credentials existed in the hands of the attackers but had not appeared in any public or criminal marketplace. Organizations that identified their exposure in March and rotated credentials have done the right thing. Organizations that did not know they were affected now face a different situation: the stolen data is in a public archive, and any actor who obtains it can attempt to use those credentials against cloud infrastructure, source code repositories, Kubernetes clusters, and AI provider accounts. The credentials from March may still be valid today. Cloud provider sessions can persist for extended periods depending on configuration. Kubernetes tokens issued to service accounts may not have been rotated if the organization did not know to rotate them. The window to revoke and rotate before those credentials are weaponized by secondary actors is the current operational urgency.

Don't miss

Hudson Rock has set up a lookup tool at its Cavalier platform that allows organizations to check whether their domain appears in the stolen dataset and, for those that complete Hudson Rock's ethical disclosure process, to view their specific leaked data. CloudSEK published a similar lookup mechanism. Organizations that used LiteLLM, Trivy, or any downstream package that depended on LiteLLM between mid-March and late March 2026 should check both lookup tools. The attack specifically targeted CI/CD pipeline environments, meaning the affected credentials are the ones used to build and deploy software rather than end-user credentials. Repository tokens, package publishing credentials, and cloud deployment keys from those environments are the primary exposure, and those are precisely the credentials that could be used to conduct a second-order supply chain attack against any software the affected organization distributes.

Potential actions

Check whether your organization's domain appears in the LiteLLM stolen dataset using Hudson Rock's Cavalier lookup or CloudSEK's lookup tool. Any organization that used LiteLLM or had LiteLLM as a transitive dependency in CI/CD pipelines during the March 2026 window should treat this as a confirmed exposure and rotate credentials rather than waiting for lookup confirmation.
Rotate all cloud credentials, SSH keys, Kubernetes service-account tokens, repository tokens, package publishing credentials, and AI provider keys that were accessible in any environment that ran LiteLLM 1.82.7 or 1.82.8. This includes keys stored in environment variables, .env files, and instance metadata service credentials available to the CI runner. Do not stop at rotating keys that were explicitly configured for LiteLLM. The SANDCLOCK infostealer swept the full environment memory and file system, not just LiteLLM-specific configuration.
Audit any software your organization published between March 24 and March 26, 2026 that was built in a pipeline that ran the compromised LiteLLM packages. If package publishing tokens were swept by SANDCLOCK, your own published packages may have been tampered with through those tokens. Review the publish history for any packages or releases from that window.

The Sip

The data has been in attacker hands since March. Today it surfaced publicly. Every AWS key, Kubernetes token, and AI provider credential in that 153GB archive may still work. Check the lookup tool, then rotate everything. Not just the LiteLLM config. Everything that was on any runner that touched those packages.

02 CriticalVMware vCenterAPT Campaign

An APT campaign exploiting vCenter CVE-2026-59310 reached 361 victims across 47 countries within five days of the Broadcom advisory

QUIRSO confirmed the intrusions through an incident response engagement and linked victim telemetry across 47 countries to a single suspected APT actor using reverse SSH for persistence. The patch has been available since July 29. There are no workarounds. Every unpatched vCenter that was network-accessible on August 3 should be treated as potentially compromised.

CVECVE-2026-59310
CVSS 9.8

Part ofVMSA-2026-0006.1

ExploitationAugust 3, 2026
(5 days post-patch)

Victims361 IPs
47 countries

Persistencereverse_ssh
malicious cron job

Sources The Hacker News QUIRSO GmbH

What happened

QUIRSO GmbH published its exploitation campaign analysis on August 10 and 12, based on evidence from an incident response engagement that identified active exploitation of CVE-2026-59310 in VMware vCenter. CVE-2026-59310 is a directory-traversal vulnerability in vCenter's Syslog server component. An unauthenticated attacker with network access to vCenter can send a crafted request that traverses the path restriction in the Syslog server, reach the code execution path, and run arbitrary commands with system privileges. Broadcom published the advisory VMSA-2026-0006 on July 29, 2026, alongside CVE-2026-59309, the authentication bypass covered as an emergency patch in Issue 97. Exploitation of CVE-2026-59310 began on August 3, five calendar days after the advisory. QUIRSO observed 151 additional victim IPs on August 4, and 343 of the 361 total victim addresses, roughly 95 percent, had been observed phoning home to attacker-controlled infrastructure by August 5. The attack chain used by the confirmed APT actor follows a consistent pattern: exploit CVE-2026-59310 to gain initial code execution, deploy a malicious cron job for scheduled persistence, and install reverse_ssh, an open-source reverse shell framework that provides persistent outbound SSH connections to attacker-controlled servers. QUIRSO's COO Denis Szadkowski confirmed to The Hacker News that the observed activity represents successful compromise rather than merely exploitation attempts, and that forensic evidence strongly points to CVE-2026-59310 as the initial access vector. CVE-2026-59310 is distinct from CVE-2026-59309: CVE-2026-59309 is the authentication bypass covered in Issue 97, while CVE-2026-59310 is the code execution path through the Syslog server. Both are in VMSA-2026-0006.1. Fixed versions are vCenter 9.1.0.0300, 9.0.2.0100, 8.0 U3k, and 8.0 U2f.

Why it matters

vCenter is the management plane for VMware environments. Compromise of vCenter gives an attacker control over every virtual machine, every host, every snapshot, and every credential stored in the environment it manages. That is not hyperbole in this case: QUIRSO's CTO quoted by SC World described it exactly that way. The campaign's reach of 361 confirmed victim IPs across 47 countries in five days reflects an actor that had the exploit ready before the advisory published and began broad exploitation immediately upon disclosure, consistent with the exploitation window collapse this brief has documented throughout the year. Organizations that have not patched since July 29 and had vCenter accessible from any external or insufficiently segmented network segment should operate on the assumption that they may have been in that 361-IP count.

Don't miss

Reverse_ssh is a dual-use open-source tool. Its presence on a system is not by itself conclusive evidence of compromise, because legitimate administrators sometimes use it for remote access. QUIRSO flagged this specifically: detections of reverse_ssh on vCenter hosts should be validated against known administrative use before conclusive attribution. The indicators to treat as higher confidence are the presence of unexpected cron jobs added since August 3, unexpected outbound SSH connections from the vCenter appliance to external IP addresses, and the presence of reverse_ssh binaries in directories not associated with standard VMware tooling. QUIRSO published YARA rules to support threat hunting for this campaign.

Potential actions

Apply VMSA-2026-0006.1 immediately if not already done. The patched versions are vCenter 9.1.0.0300, 9.0.2.0100, 8.0 U3k, and 8.0 U2f. No workaround exists for CVE-2026-59310. Any vCenter not running one of these versions should be treated as unpatched and therefore potentially exploited if it was network-accessible from August 3 onward.
Hunt for indicators of compromise on all vCenter appliances that were accessible from external or inadequately segmented networks between August 3 and today. Review cron jobs for unexpected entries, check for reverse_ssh binaries in non-standard directories, and audit outbound SSH connections from the vCenter appliance. Use QUIRSO's published YARA rules to assist the hunt.
If compromise indicators are found, treat the investigation as a full incident rather than a patch-and-close event. An attacker who has had access to vCenter since August 3 may have moved laterally to managed virtual machines, changed snapshot schedules or backup configurations, or extracted vCenter credentials during the access window.

The Sip

Five days from patch to 361 confirmed victims. The actor had the exploit ready before the advisory published. Unpatched vCenter from August 3 onward is potentially compromised. Patch first, then check the cron jobs, check the outbound SSH connections, and check whether any snapshots or credentials changed since August 3.

03 CriticalSAPCommerce Cloud

SAP released an emergency CVSS 10.0 patch today for a code injection flaw in Commerce Cloud that lets an unauthenticated attacker execute arbitrary code

CVE-2026-58231 affects the Data Hub Adapter component of SAP Commerce Cloud. An unauthenticated attacker who can reach the affected endpoint can inject code and achieve remote code execution with no credentials and no user interaction. SAP released this as an emergency note outside its regular patch cycle, one day after August Patch Day.

CVECVE-2026-58231
CVSS 10.0

ComponentSAP Commerce Cloud
Data Hub Adapter

TypeCode injection
Unauthenticated RCE

WorkaroundNone available

Note typeEmergency release
outside patch cycle

Sources The Hacker News SAP Security Notes

What happened

SAP published an emergency security note for CVE-2026-58231 on August 13, 2026, one day after its August 2026 Security Patch Day. Emergency notes outside the regular second-Tuesday release cycle are rare for SAP and typically indicate a flaw assessed as requiring faster remediation than the next regular patch day would provide. CVE-2026-58231 is a code injection vulnerability in the Data Hub Adapter component of SAP Commerce Cloud. The Data Hub Adapter is the integration layer that connects SAP Commerce Cloud to external data sources, marketing platforms, product information management systems, and other enterprise applications through a centralized data synchronization pipeline. An unauthenticated attacker who can reach the affected endpoint can inject code into the adapter's processing context and achieve remote code execution on the affected system. No credentials, no user interaction, and no prior knowledge of the target environment beyond its network address are required. SAP assigned a CVSS score of 10.0, the maximum possible, and states that no workaround is available. The fix is available through SAP's Support Portal as an emergency note. Exploitation in the wild has not been confirmed, but the combination of maximum severity, unauthenticated access, and no workaround is the profile that historically drives rapid weaponization of SAP vulnerabilities after disclosure.

Why it matters

SAP Commerce Cloud is an enterprise e-commerce and order management platform used by large retailers, manufacturers, and distributors to run digital sales channels, process customer orders, manage pricing, and maintain product catalogs. The Data Hub Adapter specifically connects those commerce workflows to backend ERP systems, product information management platforms, and external marketing systems. An unauthenticated attacker with code execution inside the Data Hub Adapter has access to the data flows connecting SAP Commerce Cloud to those backend systems, which may include customer records, pricing data, order histories, and integration credentials for the connected systems. This is the same structural property as the Metabase vulnerability from Issue 105: the integration layer holds the credentials and access paths to multiple connected systems, making compromise of the adapter operationally significant beyond the adapter itself.

Don't miss

SAP released this note one day after August Patch Day, at a moment when enterprise security teams are already processing the regular SAP August patch batch, the Microsoft Patch Tuesday batch, and the ongoing incident response workloads from the Metabase zero-day, the vCenter campaign, and the LiteLLM credential disclosure. The timing is not controllable, but the operational risk of deprioritizing an emergency CVSS 10.0 SAP note because the team is already overloaded is real. A maximum-severity unauthenticated RCE in an internet-facing commerce integration layer released as an emergency note one day after a large regular patch release is exactly the kind of disclosure that gets missed in high-volume weeks. SAP historical exploitation patterns suggest that critical SAP NetWeaver and Commerce Cloud vulnerabilities are typically exploited within two to three weeks of public disclosure, occasionally faster.

Potential actions

Apply the emergency SAP security note for CVE-2026-58231 to all SAP Commerce Cloud deployments immediately. Retrieve the note and patch instructions from SAP's Support Portal under the security notes section. Emergency notes typically include specific instructions for the patch sequence and any post-patch configuration steps required for the Data Hub Adapter.
If immediate patching is not possible within the next 24 hours, restrict network access to the SAP Commerce Cloud Data Hub Adapter endpoint to known trusted internal IP ranges as a temporary mitigation. This does not close the vulnerability but reduces the attack surface until the emergency note can be applied.

The Sip

Maximum severity. No authentication required. No workaround. Released as an emergency note the day after regular SAP patch day, at the busiest security patching week of the month. The timing makes it easy to miss. That is exactly why it should not be missed.

Cross-source standouts

LiteLLM and the Trivy chain: how one un-revoked token three tools deep produces ecosystem-wide exposure

The LiteLLM supply chain attack did not compromise LiteLLM directly. It compromised Trivy, the security scanner LiteLLM used in its build pipeline, through a leaked automation token that was rotated but not fully revoked. That partial revocation left a 20-day window in which the attacker could push malicious code over Trivy's published version tags. When LiteLLM's pipeline ran its routine Trivy scan, it installed the poisoned scanner. The poisoned scanner built and published the malicious LiteLLM releases. The malicious releases reached 434,000 CI/CD pipelines. Each pipeline that ran those packages during the 40-minute window they were available executed the credential stealer. CloudSEK's description of the chain is precise: one un-revoked token, three tools deep, then ecosystem-wide. This is the structural argument for why supply chain security requires thinking about the full graph of tools a build pipeline touches, not just direct dependencies. Security scanning tools occupy a privileged position in build pipelines specifically because they are trusted to run with broad access to the build environment. A compromised security scanner has access to everything the pipeline does. Organizations that unpin their security scanning tools from version-specific hashes and pull from version tags rather than digest-pinned images are exposed to exactly this category of attack regardless of how well they have secured their first-party code.

vCenter, the 5-day exploitation window, and the management plane as the recurring highest-value target in enterprise infrastructure

This brief has covered vCenter vulnerabilities in Issues 97, 98, and now 107. Issue 97 covered VMSA-2026-0006 as an emergency patch with no workaround. Issues 98 through 106 tracked it in Still Watching. Issue 107 documents confirmed APT exploitation with 361 victims in 47 countries beginning five days after the advisory. The progression from patch urgency to confirmed mass exploitation in under two weeks, for a management plane product that has appeared on CISA KEV ten times previously, reflects a structural pattern that has repeated with Check Point SmartConsole in Issue 92, Cisco FMC in Issue 99, N-able N-central in Issue 100, and TeamCity in Issues 95 and 102. Management plane products are the highest-value initial access targets in enterprise infrastructure because they do not compromise one system. They compromise the system through which every other system is managed. The operational implication is not that management plane patches should be prioritized over other patches. They already are, in any reasonable triage framework. The implication is that the gap between advisory publication and patch application for management plane products must be measured in hours, not days, because the window before active exploitation begins is often exactly that narrow. Five days after the VMSA-2026-0006 advisory, 361 systems were already compromised. Organizations that applied the patch on day four were ahead of the exploitation wave. Organizations that were still planning their change management process on day five were not.

Still watching

Days 2–5

August Patch Tuesday CVE-2026-68820 (Issue 106 · Lazarus Group, FudModule rootkit) — WinSock driver actively exploited to deploy kernel-mode rootkit before today's patch. Deploy the August update to all Windows endpoints. Run Check Point's FudModule indicators on any endpoint in Lazarus Group target sectors before concluding the patch alone closes the exposure.

Day 2

Metabase GHSA-vwf4-m7j8-wcjf (Issue 105 · CVSS 10.0 zero-day, exploited August 3) — patch self-hosted instances. Rotate database credentials for every connected source. Add GHSA-vwf4-m7j8-wcjf to tracking tools; CVE-based scanners will not surface it. n8n, Framework, and Tally confirmed as downstream victims.

Day 3

Progress LoadMaster CVE-2026-8037 (Issue 104 · CISA KEV, deadline passed August 10) — update to GA 7.2.63.2 or LTSF 7.2.54.18. Follow CISA forensics triage guidance. Review /accessv2 endpoint logs from June 29. Six weeks of confirmed exploitation across 65 IP addresses.

Day 5

Atlassian Rovo content-borne prompt injection (Issue 104 · PromptArmor, reported May 2026) — URL parameter path patched July 8. Content-borne path status unconfirmed as of August 13. Scope Rovo access tightly and audit Rovo Connector connections to external platforms until Atlassian confirms both paths are closed.

Day 6