Cyber Roundup — Week of July 27th

Here are the main stories you missed last week.

1. Arista: A CVSS 10.0 zero-day in VeloCloud Orchestrator was already in use when the patch landed

The headline: Arista Networks published its advisory on July 28 for CVE-2026-16812, a maximum-severity unauthenticated OS command injection flaw in on-premises VeloCloud Orchestrator. Any attacker with network access to the VCO web interface can reach privileged internal functionality that was never meant to be externally accessible, without credentials, without configuration changes on the victim’s side, and without any user interaction. CISA added the CVE to its Known Exploited Vulnerabilities catalog on July 27 with a three-day federal remediation deadline. Arista confirmed active exploitation but has not shared when attacks began, who is behind them, or how many organizations are affected. The fix ships in VCO versions 5.2.3.14, 6.1.3.4, 6.4.2.4, and 7.0.0.1. Organizations running end-of-support versions have no patch path.

What we’re actually watching: VeloCloud Orchestrator is the single pane of glass for an entire SD-WAN deployment. It configures, monitors, and controls every VeloCloud edge device across every branch, datacenter, and cloud connection the network uses. When an attacker gets unauthenticated command execution on the orchestrator, they do not get access to one device. They get access to the management layer that manages every device.

The exposure-by-default detail is the part that matters most. Arista’s advisory states that VCO is exposed by default and that no configuration option can prevent this exposure. That sentence means that every organization running an on-premises VCO that has not applied the patch is internet-reachable, by design, right now. There is no compensating control that closes the attack vector short of patching or taking the orchestrator offline.

The active exploitation before the patch arrived is the standard playbook for SD-WAN orchestrator compromises. An attacker with early access to a vulnerability in a platform that sits above the network can reconfigure routing, exfiltrate traffic, or establish persistence across the entire WAN footprint before any endpoint security control can observe the activity. The orchestrator logs the very events that would reveal the intrusion. We monitor for exposed VCO management interfaces in customers’ external attack surface inventories because the exposure-by-default design makes them significantly easier to find than most enterprise management platforms.

The CISO question: For every VeloCloud Orchestrator deployment in your environment, including those managed by network service providers on your behalf, do you know whether the on-premises version is running, whether the July 28 patch has been applied, and whether active exploitation occurred before the patch was available?

2. JetBrains: TeamCity CVE-2026-63077 lets any unauthenticated user run OS commands on every on-premises build server

The headline: JetBrains disclosed CVE-2026-63077 on July 28, a critical remote code execution vulnerability in all on-premises versions of TeamCity. The flaw carries a CVSS score of 9.8 and allows unauthenticated attackers to execute arbitrary operating system commands on the TeamCity server without any credentials or user interaction. The fix ships in versions 2025.11.7 and 2026.1.3. TeamCity Cloud instances were patched before the advisory. JetBrains describes the issue as a code execution vulnerability that could result in a full server compromise.

What we’re actually watching: This is the third critical unauthenticated RCE in TeamCity in two years. CVE-2024-27198 and CVE-2024-27199 were exploited in 2024 by APT29 and other threat actors within days of disclosure to deploy backdoors, ransomware, and cryptominers across build pipelines. The pattern is documented, the target value is understood, and the time between disclosure and weaponization has consistently been measured in days.

TeamCity does not just run code. It builds and deploys code. A compromised TeamCity server gives an attacker the ability to modify build artifacts before they ship to production, inject malicious dependencies into the build pipeline, steal signing keys and deployment credentials, and push changes to every codebase the server touches. The blast radius is not the server. It is everything the server produces.

The third-party deployment risk is the part most security assessments miss. Development teams frequently stand up TeamCity on internal servers and connect it to cloud repositories, artifact registries, and production deployment pipelines. Security teams auditing the production environment often do not see the CI/CD layer as part of their scope. Those two assumptions together mean that TeamCity vulnerabilities regularly sit unpatched for longer than their CVSS score warrants. We scan for internet-exposed TeamCity instances in customer attack surface inventories because the history of their exploitation makes them among the highest-value unpatched targets an external attacker can find.

The CISO question: For every TeamCity on-premises deployment in your environment and your software supply chain, do you know whether it has been patched to 2025.11.7 or 2026.1.3, and if an attacker had unauthenticated command execution on your build server this week, would your security monitoring have detected artifacts being modified before they reached production?

3. Adform: Europe’s largest adtech platform was used to swap cryptocurrency wallet addresses across 1,800 websites for at least two days

The headline: Attackers modified trackpoint-async.js, Adform’s JavaScript tracking script served from s2.adform.net and embedded across Adform’s customer base, injecting a cryptocurrency clipper that polled visitor clipboards every four seconds and replaced Bitcoin, Ethereum, and Tron wallet addresses with attacker-controlled destinations. Security researcher Kevin Beaumont discovered the malicious code and confirmed that the altered file returned zero detections on VirusTotal at the time of discovery. The oldest archived malicious sample dates to July 26. Adform detected and removed the code on July 27, 2026 and reported the incident to authorities. The script also rewrote addresses entered directly into form fields, not just clipboard content. Adform serves approximately 1,800 customers and 1.5 billion ads daily across more than 180 countries. No official count of affected sites or users has been published.

What we’re actually watching: Adform did not get breached. One of their shared JavaScript files got modified. Every website that loaded that file became an attack vector without any breach of its own. That is the supply-chain attack pattern that security teams consistently underestimate: the compromise happens upstream, the impact lands downstream, and the downstream organization’s security controls never trigger because nothing in their environment was touched.

The cryptocurrency clipper is a particularly low-noise attack technique. It does not install software. It does not establish persistence. It operates only while the page is open and leaves no forensic evidence after the session ends. A user copies a wallet address. They paste it. The first and last characters look correct. The middle characters do not, but nobody reads 42 characters of a wallet address manually. The money moves to an attacker-controlled wallet. The transaction is irreversible. The victim may not notice for days, if ever.

CybelAngel’s analysis of the Miasma supply chain attack documented how compromised credentials appeared in stealer logs seven weeks before the attack executed, giving a monitoring window that conventional security controls would have missed entirely. The Adform incident follows the same structural pattern: the warning signal existed before the impact, in the modification of a shared resource rather than a new credential appearing in a dump, but the detection required monitoring the supply chain itself rather than the downstream systems it serves.

The CISO question: For every third-party JavaScript resource loaded by your organization’s websites and web applications, do you have monitoring that would detect an unexpected modification to a trusted script served from a vendor’s infrastructure, and would that detection happen in hours or would you learn about it from a security researcher’s blog post?

4. Revolut: A threat actor listed 75 million user records for $500 while Revolut found no evidence of a new breach

The headline: A threat actor listed a database on a cybercrime forum on July 29 claiming to contain 75 million Revolut customer records including partial card data, email addresses, full names, phone numbers, physical addresses, bank account numbers, user IDs, SWIFT codes, and bcrypt and argon2id-hashed credentials. The asking price was $500. Cybernews researchers who analyzed the sample confirmed the presence of those data types but found that the newest records date back to around May 2025, and found no evidence linking the dataset to any previously documented Revolut breach. Revolut stated it sees no indications of a security breach and that the dataset may be a compilation from various sources. Independent analysis suggests the data may include information tied to Revolut’s customer referral program.

What we’re actually watching: The $500 price tag is the most informative number in this story. Current, verified data from 75 million fintech customers would sell for orders of magnitude more on criminal marketplaces. The low price signals one of three things: the data is not current, the data is not from a single Revolut breach, or the seller is moving volume quickly before the listing is taken down. All three interpretations are more consistent with an aggregated compilation than with a fresh primary breach.

That does not make the listing irrelevant. An aggregated compilation of 75 million records with partial card data, contact details, and hashed credentials is genuinely dangerous for phishing, social engineering, and account takeover operations against Revolut users even if it is not a new breach. Revolut’s 2022 incident affected 50,150 customers. If any records from that event are in this dataset, their combination with records from other sources creates enriched profiles that are more actionable than any single source would be alone.

The CISO question: If a dataset containing your organization’s customer or employee records appeared on a criminal forum tomorrow, do you have a process for determining whether the data represents a new breach, an aggregation of older leaks, or data from a third-party vendor, and does your incident response plan distinguish between those scenarios in terms of notification obligations and public communication?

5. ShinyHunters: EY’s support ticket platform breach expands as the group claims the data and sets a release deadline

The headline: ShinyHunters publicly claimed responsibility for the EY data breach on July 29, warning that all stolen client tax data will be released unless EY meets an unspecified demand. The group told Cybernews: “Yes it was us.” EY had begun notifying clients on July 13 that attackers accessed a third-party IT service management platform between March 28 and April 12, 2026. ShinyHunters claims the stolen data covers multiple EY clients and includes tax filings, personal financial information, and Social Security numbers. The group has not published the data yet but set a public deadline. EY has not confirmed the ShinyHunters attribution.

What we’re actually watching: ShinyHunters turning a July 13 breach disclosure into a July 29 public extortion claim follows a pattern the group has run against every major target in 2026. They breach. They wait. They negotiate privately. When private negotiations fail or move too slowly, they go public with a deadline to force the victim’s hand.

The EY case is operationally interesting because the breach entry point was a third-party IT service management platform, not EY’s core systems. ShinyHunters claiming ownership of that breach suggests the group either directly compromised the third-party platform or purchased access from whoever did. The result is the same: the group now has tax documents and personal financial information for an unknown number of EY clients, and those clients have no direct notification obligation until EY determines which of their data was in scope.

The CISO question: If your organization is an EY client and your tax data was among the documents attached to support tickets on the breached platform, would you know before EY’s notification letter arrives, and do you have a process for assessing your own exposure when a professional services firm that holds your data announces a breach involving its IT support infrastructure

The pattern across all five stories

None of this week’s five incidents required a novel technique. Every one of them exploited something that was already known, already present, and already trusted.

Arista’s VCO was internet-exposed by design. TeamCity’s third critical unauthenticated RCE in two years arrived on the same platform that APT29 weaponized in 2024. Adform’s tracking script was a trusted third-party resource that every downstream site loaded without question. The Revolut dataset was assembled from records that were already in criminal hands. ShinyHunters exploited the same professional services supply chain entry point they have used against every major target this year.

CybelAngel watches the same inventory from the outside in, finding what is reachable, what is unpatched, and what is already in circulation before it becomes the call your team has to make at 2 a.m.