⚡ Daily Global Cyber Threat Intelligence Digest | July 29, 2026

Coverage window: July 28, 2026, 08:00 to July 29, 2026, 08:00 (UTC+8)
Audience: CISOs, SOC teams, IT/Cloud Security, Network Security, DevSecOps, and APAC defence teams

This edition includes only events first disclosed during the coverage window, or developments that received significant exploitation, official confirmation, remediation, victim-scale, or operational-risk updates during the period.

Official vendor advisories, CISA, regulatory filings, and original research were prioritised. Research estimates, renewed media attention, attacker claims, and analyst inferences are presented separately from facts confirmed by vendors or government authorities.

---

📝 Executive Summary — 10-Second Read

• 🔴 Arista VeloCloud Orchestrator CVE-2026-16812 is under active exploitation and has been added to CISA KEV. An unauthenticated attacker can access privileged functionality intended only for internal use, potentially compromising the VCO host and the data it manages. The vulnerability has a CVSS score of 10.0, and CISA requires United States federal civilian agencies to remediate it by July 30.

• 🔴 JetBrains TeamCity CVE-2026-63077 enables unauthenticated remote code execution. All TeamCity On-Premises versions are affected. Fixed releases are 2025.11.7 and 2026.1.3. Deployments running TeamCity 2017.1 or later that cannot be upgraded immediately can install the official security patch plugin as an interim measure.

• 🟠 Lava identified 36,872 Internet-facing IPMI interfaces, of which 24,650 return password-derived RAKP material before authentication completes. More than 30% of responses were associated with passwords recoverable through common dictionaries or predictable factory-password formats.

• 🟠 Australia’s Origin Energy initially estimates that data belonging to approximately 900,000 current and former customers was accessed. The investigation remains ongoing, so 900,000 should not be treated as the final breach count. The exposed data is nevertheless sufficient to support highly personalised fraud and account-recovery attacks.

• 🟠 The MCBS healthcare-data breach affecting 1.26 million people is a carry-over event. HHS recorded 1,261,464 affected individuals on June 26. The new material during this window consists mainly of renewed media coverage of the incident scope and affected data types, rather than a new regulatory count.

---

🚨 Major Incidents

1. Arista VeloCloud Orchestrator CVE-2026-16812: Management-Plane Zero-Day Under Active Exploitation

Arista advisory date: July 27, 2026
CVE: CVE-2026-16812
Arista CVSS v3.1/v4.0: 10.0 — Critical
Exploitation status: Active exploitation confirmed by Arista
CISA KEV: Added July 27; remediation due July 30
Analyst operational priority: 🔴 Critical
Affected platform: VeloCloud Orchestrator On-Prem

Arista states that VCO On-Prem contains an unauthorised OS command-injection vulnerability. A remote attacker can access privileged functionality intended only for internal use, compromising the orchestrator host as well as the configurations and data managed by the platform.

Exploitation does not require VCO tenant or operator credentials. The attacker needs only network access to the VCO Web interface. Arista notes that the VCO Web interface is reachable by default and that no product setting can completely remove this exposure. Restricting access to trusted management networks can reduce exploitation risk but does not eliminate the vulnerability.

Why the Operational Impact Is Severe

VCO is the centralised management control plane for SD-WAN. A successful compromise may allow an attacker to:

• Access the VCO database, device inventory, credentials, certificates, or key material.
• Execute system commands, create files, or export databases.
• Modify management settings or perform unauthorised maintenance actions.
• Gain access capabilities affecting Edge devices managed by VCO.
• Use the orchestrator to push malicious or unauthorised configurations to downstream devices.

VeloCloud Edge is not directly vulnerable to CVE-2026-16812, but a compromised VCO may become a control path for affecting managed Edge devices.

Affected and Fixed Versions

Release train	Affected versions	Fixed version
VCO 5.2.x	Earlier than 5.2.3.14	5.2.3.14 or later
VCO 6.1.x	Earlier than 6.1.3.4	6.1.3.4 or later
VCO 6.4.x	Earlier than 6.4.2.4	6.4.2.4 or later
VCO 7.0.x	Earlier than 7.0.0.1	7.0.0.1 or later

Not directly affected:

• VeloCloud Orchestrator Hosted.
• VeloCloud Orchestrator Dedicated, which was patched before the advisory.
• VeloCloud Gateway.
• VeloCloud Edge.

End-of-support versions were not evaluated by Arista and should not be assumed to be secure.

Publicly Reported Source IPs

Arista published three source IP addresses observed in attacks:

8.19.75.217
206.72.242.124
206.72.242.162

These IP addresses represent only known observations and are not a complete compromise-indicator set. Blocking them does not replace patching or historical investigation.

Immediate Actions

1. Immediately upgrade every On-Prem VCO, including production, disaster-recovery, test, and standby nodes.

2. Restrict the VCO Web interface to VPN access, jump hosts, or trusted management networks.

3. Before patching, preserve:

   • Web access logs.
   • Backend application logs.
   • System logs.
   • Database logs.
   • File-system timestamps.

4. Hunt for:

   • Abnormal encoded paths.
   • Requests targeting localhost or internal services.
   • Unusually high-frequency Web requests.
   • Abnormal outbound HTTP/HTTPS traffic from the VCO host.
   • Unauthorised configuration changes.
   • Command execution, database exports, or archive artefacts.
   • Unexpected access to credentials, certificates, or keys.

5. Compare SD-WAN Edge configurations against a known-good baseline.

6. If compromise is suspected, rotate:

   • Administrator credentials.
   • API tokens.
   • Device certificates.
   • Database credentials.
   • Downstream secrets accessible to VCO.

7. If host compromise cannot be reasonably excluded, rebuild or replace the VCO from a trusted image rather than relying solely on an in-place patch.

Primary Sources

• Arista Security Advisory 0144
• NVD — CVE-2026-16812
• CISA Known Exploited Vulnerabilities Catalogue

---

2. TeamCity CVE-2026-63077: Unauthenticated Deserialisation Leads to Server RCE

Advisory date: July 27, 2026
CVE: CVE-2026-63077
CVSS v3.1: 9.8 — Critical
Analyst operational priority: 🔴 Critical
Exploitation status: JetBrains had not observed active exploitation when the advisory was published
Affected scope: All TeamCity On-Premises versions
Not affected: TeamCity Cloud

CVE-2026-63077 exists in the TeamCity agent-polling protocol. Any unauthenticated attacker able to reach the TeamCity server over HTTP(S) may bypass authentication and execute arbitrary operating-system commands with the privileges of the TeamCity server process.

Successful exploitation may expose:

• TeamCity data and configuration.
• Stored credentials.
• Build variables.
• Source-control tokens.
• Artifact-repository credentials.
• Cloud-deployment keys.
• Build artefacts.
• Downstream CI/CD pipelines.

Remediation Options

Preferred: Full Upgrade

• TeamCity 2025.11 series: upgrade to 2025.11.7
• TeamCity 2026.1 series: upgrade to 2026.1.3
• Older releases: migrate to a supported fixed version

If Immediate Upgrade Is Not Possible: Security Patch Plugin

TeamCity 2017.1 or later can install the security patch plugin provided by JetBrains.

Important considerations:

• The plugin fixes only CVE-2026-63077.
• It does not include other security fixes present in newer releases.
• TeamCity 2017.1 through 2018.1 requires a restart after installation.
• TeamCity 2018.2 or later can activate the plugin without restarting.
• A full upgrade remains the preferred remediation.

JetBrains has already applied the appropriate measures to TeamCity Cloud, so customers do not need to take action.

Immediate Actions

1. Upgrade to 2025.11.7/2026.1.3, or immediately install the applicable patch plugin.

2. Verify the actual running:

   • Server binary.
   • Container image digest.
   • VM image.
   • Kubernetes/Helm deployment.
   • Patch-plugin status.

3. Until remediation is complete, restrict TeamCity access to VPNs, internal networks, or trusted reverse proxies.

4. Hunt for the TeamCity process launching:

   • cmd.exe.
   • PowerShell.
   • /bin/sh/bash.
   • curl/wget.
   • Python, Perl, or other script interpreters.

5. Review:

   • New build agents.
   • New administrator accounts.
   • Abnormal build configurations.
   • New access tokens.
   • SSH keys.
   • Unknown plugins.
   • Unexpected artefact modification.

6. If TeamCity was publicly exposed and exploitation cannot be ruled out, rotate every high-value secret accessible to TeamCity.

7. After patching, verify build-artefact integrity and review whether downstream deployments were modified without authorisation.

Upgrading closes the vulnerability, but it does not revoke credentials already read or restore build artefacts that were tampered with.

Primary Sources

• JetBrains — CVE-2026-63077 Security Advisory
• JetBrains — TeamCity 2026.1.3 and 2025.11.7
• NVD — CVE-2026-63077

---

🛠️ Vulnerability and Management-Plane Risk

3. More Than 24,000 Public BMCs Return RAKP Authentication Material Suitable for Offline Cracking

Update during this window: Major figures reported by media on July 28
Full original research: Published by Lava on July 29, outside the coverage window, as a supplementary primary source
Related vulnerability: CVE-2013-4786
Analyst operational priority: 🟠 High; an Internet-facing BMC is a 🔴 Critical architectural exposure

Lava scanning identified 36,872 Internet-facing IPMI endpoints. Of these, 24,650 return at least one password-derived RAKP response before client authentication completes.

Technically, this does not directly leak a stored password hash from a password database. IPMI 2.0 RAKP authentication returns an HMAC-SHA1 authentication code calculated using the account password and session values already known to the attacker. The attacker can then test password candidates locally and offline without attempting a new BMC login for every guess.

Research Data

Finding	Count
Internet-facing IPMI hosts	36,872
Returned RAKP material before authentication	24,650
Empty username with recoverable weak password	6,240
Named accounts using common passwords	2,340

Lava states that more than 30% of the responses were associated with passwords recoverable through common dictionaries or predictable factory formats.

The research also shows that even where each device uses a unique chassis-sticker password, GPU-based password recovery against a single target may remain practical if the password format is constrained and can be tested offline.

Why BMC Compromise Is Particularly Serious

A BMC can commonly:

• Power servers on or off remotely.
• Access the system console.
• Mount virtual media.
• Update firmware.
• Modify underlying platform settings.
• Manage servers through IPMI, Redfish, or a Web interface.

A BMC operates outside the operating system, kernel, containers, and most EDR controls. Successful compromise can establish a low-visibility, persistent management-plane foothold and may enable lateral impact across other servers sharing the out-of-band management network.

Correct Mitigation Priorities

CVE-2013-4786 results from IPMI 2.0 protocol behaviour, so organisations should not assume that a routine firmware update will fully eliminate the issue.

The core controls are:

1. Block Internet access to UDP 623.

2. Place BMCs on a separate private management network.

3. Permit access only through VPNs, bastion hosts, or designated management systems.

4. Replace all factory-issued, default, reused, and predictable passwords.

5. Disable:

   • IPMI 1.5.
   • Cipher suite 0.
   • Anonymous accounts.
   • NONE authentication.
   • Unnecessary legacy IPMI functions.

6. Use separate BMC credentials that are not shared with:

   • The operating system.
   • Active Directory.
   • The hypervisor.
   • Other management platforms.

7. On the dedicated management network, monitor:

   • SOL console access.
   • Virtual-media mounting.
   • Firmware changes.
   • Redfish/IPMI API calls.
   • Unexpected power-on or power-off actions.
   • Administrator and credential changes.

8. Apply vendor firmware and hardening guidance, but do not treat a firmware update as the sole remediation.

9. Where supported, prefer Redfish over TLS within a controlled management network. Neither IPMI nor Redfish should be directly exposed to the Internet.

Primary Sources

• Lava — How We Hacked Thousands of Data Centers in Minutes Using a 20-Year-Old Vulnerability
• NVD — CVE-2013-4786
• BleepingComputer — Exposed BMC Research

---

🎯 Defensive Guidance

4. CISA and Australia Publish OT Guidance on “Isolating Vital Systems”

Publication date: July 28, 2026
Document: CI Fortify — Advice for Isolating Vital Systems
Analyst operational priority: 🟠 Medium to High
Nature: Resilience and incident-preparedness guidance, not a legally binding directive

Australia’s ASD/ACSC, CISA, and other international partners published new guidance urging critical-infrastructure operators to establish and test, in advance, the ability to isolate vital OT and enabling systems.

The objective is not to keep all OT permanently disconnected during normal operations. It is to enable operators to progressively or completely sever high-risk connections during a cyberattack, major supply-chain disruption, or period of elevated threat, while maintaining the minimum necessary service.

Core Principles of the Guidance

1. Identify the minimum systems and networks required to provide the critical service.

2. Document every connection path, including:

   • Corporate IT.
   • Vendor remote access.
   • The Internet.
   • Cloud services.
   • Peer OT/other utilities.
   • Carrier, radio, mobile, satellite, and Wi-Fi links.

3. Establish isolation points in advance.

4. Plan graduated isolation:

   • Disable remote-worker access.
   • Disable on-premises remote access.
   • Sever IT/OT connectivity.
   • Disconnect lower-priority OT peer links.
   • Fully isolate vital systems.

5. Retain the ability to reach complete isolation as the final state.

6. Eliminate shared dependencies that could prevent isolation, including:

   • Active Directory.
   • DNS/DHCP.
   • PKI.
   • NTP/PTP.
   • Shared storage.
   • Virtualisation.
   • Backup services.
   • Document/firmware repositories.

7. Ensure that isolation does not unintentionally interrupt safety-instrumented systems, emergency shutdown, or essential control functions.

Recommended Actions

• Build an isolation matrix covering IT, OT, identity, vendor access, and cloud connections.
• Define a technical trigger, business trigger, and decision owner for each isolation stage.
• Prepare local alternatives for DNS, time synchronisation, identity, backup, and monitoring.
• Preserve validated offline configurations, firmware, recovery images, and administrative credentials.
• Exercise complete isolation rather than testing only a single firewall rule.
• Include isolation, manual operation, minimum-service mode, and reconnection criteria in incident-response playbooks.
• Coordinate service dependencies in advance with vendors, utility partners, and critical customers.

Primary Sources

• Cyber.gov.au — CI Fortify: Advice for Isolating Vital Systems
• CISA — Joint Guidance Announcement

---

🔐 Data Breaches

5. Origin Energy: Initial Estimate Indicates Data for Approximately 900,000 Customers Was Accessed

Official update during the window: July 28, 2026
Company statement: Initial review phase completed; investigation remains ongoing
Current estimate: Approximately 900,000 current and former customers
Analyst impact assessment: 🟠 Medium to High
APAC relevance: High

Origin Energy states:

we believe approximately 900,000 current and former customers’ information was accessed.

The 900,000 figure should therefore be described as the company’s current estimate following completion of its initial review, rather than a final confirmed victim count.

Potentially Affected Data

• Names.
• Addresses.
• Dates of birth.
• Contact telephone numbers.
• Customer account information.
• The last four digits of credit cards.
• The last three digits of bank accounts.

Incomplete financial data cannot independently be used to conduct a transaction or access an account. However, when combined with names, addresses, dates of birth, and account context, it can support:

• Origin or bank customer-service impersonation.
• Refund scams.
• Payment-change fraud.
• Account-recovery abuse.
• SIM-swap social engineering.
• Highly credible phishing or vishing.

Evidence Tiers

• Origin’s initial estimate: Approximately 900,000 current and former customers.
• Earlier attacker claim: Approximately two million people.
• Primary figure to use at present: Origin’s company estimate of approximately 900,000.
• Final breach count: Not yet published.

Recommended Actions

For Customers

• Do not click unsolicited Origin refund or account-update links.
• Even if a caller knows your address, date of birth, or bank-account suffix, end the call and contact the organisation again through an official channel.
• Change any password reused on the Origin account.
• Enable MFA on personal email, banking, and telecommunications accounts.
• Enable alerts for bank transactions, credit-report activity, and telecommunications-account changes.

For Enterprises and Financial Institutions

• Do not treat names, addresses, dates of birth, or account-number suffixes as sufficient verification factors.
• Use out-of-band verification for payment details, contact information, MFA enrolment, and credential resets.
• Monitor phishing, vishing, and payment fraud that uses the Origin brand or genuine customer information.

Primary Sources

• Origin Energy — Further Update on Data Security Incident
• Origin Energy — Customer Incident Updates

---

6. MCBS: Healthcare-Data Breach Affecting 1.26 Million Receives Renewed Media Attention

Status: Carry-over breach
Formal HHS filing date: June 26, 2026
Individuals affected: 1,261,464
Update during this window: Widely reported by media on July 28
Analyst impact assessment: 🟠 Medium to High

Medical Computer Business Services (MCBS) provides medical billing, coding, accounts-receivable, and administrative services.

The HHS Office for Civil Rights Breach Portal had already listed the following on June 26:

• Entity: MCBS, LLC.
• Individuals affected: 1,261,464.
• Breach type: Hacking/IT Incident.
• Location: Network Server.
• Business associate present: Yes.

The new information during this window is therefore not a new formal victim-count filing, but renewed media coverage of the incident scope and data risk.

Potentially Affected Data

The affected fields may differ between individuals. Public reporting lists:

• Names.
• Addresses.
• Social Security numbers.
• Dates of birth.
• Health-plan beneficiary numbers.
• Insurance policy/subscriber IDs.
• Medical histories.
• Physical or mental health conditions.
• Diagnosis information.
• Treatment information.

Recommended Actions

For Notified Individuals

• Activate the provided credit-monitoring or identity-protection service.
• Consider placing a credit freeze if Social Security numbers were involved.
• Monitor Explanation of Benefits statements, medical claims, and abnormal bills.
• Be alert to messages impersonating clinics, insurers, Medicare/Medicaid, or billing departments.
• Do not trust someone merely because they know genuine medical information.

For Healthcare Organisations

• Confirm that the data held by MCBS or other billing vendors complies with the minimum-necessary principle.
• Review third-party access, data-retention, and breach-notification terms.
• Use out-of-band verification for account recovery, benefit changes, and payment requests.
• Monitor false claims, identity impersonation, and credential-stuffing activity.

Primary Sources

• HHS OCR Breach Portal
• BleepingComputer — MCBS Data Breach

---

👀 Developments to Watch

• CVE-2026-16812: The complete initial-access timeline, threat-actor identity, victim scope, and whether VCO compromise was used to modify downstream Edge configurations.
• CVE-2026-63077: Whether a public PoC, mass scanning, or confirmed in-the-wild exploitation emerges.
• BMC/IPMI: Whether credential lists based on Lava’s data appear, whether GPU providers are targeted, or whether attackers move laterally across BMC management networks.
• Origin Energy: Whether the ongoing investigation changes the estimate of approximately 900,000 affected customers, and whether the initial-access vector is disclosed.
• MCBS: The full list of affected healthcare organisations, data fields, and incident attribution.
• MAI-Cyber-1-Flash: Public performance data currently comes mainly from known-vulnerability benchmarks such as CyberGym. The broader MDASH system has helped identify new Microsoft vulnerabilities, but this does not mean a single model can independently and generally discover zero-days or automatically produce patches that are safe to deploy.

---

✅ Today’s Priority Actions

P0 | Immediate

1. Identify every On-Prem VCO and verify its version, Web exposure, and historical management activity.
2. Preserve VCO logs before patching, then upgrade to a fixed version and review official indicators of compromise.
3. Upgrade TeamCity to 2025.11.7/2026.1.3. If upgrading is not possible, immediately install the applicable patch plugin.
4. Scan all public IP addresses and block direct Internet access to UDP 623, IPMI, BMC Web interfaces, and Redfish.
5. Begin compromise assessments for VCO, TeamCity, and BMC systems that were publicly exposed.

P1 | Next 24–72 Hours

1. Compare SD-WAN Edge configurations against a known-good baseline.
2. Hunt for TeamCity child processes, build-configuration changes, and artefact tampering.
3. Rotate high-value credentials accessible to VCO, TeamCity, and BMC systems.
4. Establish phishing, vishing, healthcare-fraud, and payment-change monitoring arising from the Origin and MCBS incidents.
5. Inventory the AD, DNS, NTP, PKI, backup, cloud, and vendor connections on which OT environments depend.

P2 | Within This Week

1. Build a complete management-plane asset inventory covering:

   • SD-WAN orchestrators.
   • CI/CD platforms.
   • BMC/IPMI/Redfish.
   • OT jump hosts.
   • Vendor remote-access systems.

2. Record the following for every management plane:

   • Owner.
   • Version.
   • Internet exposure.
   • MFA.
   • Source restrictions.
   • Stored secrets.
   • Downstream privileges.
   • Recovery procedure.

3. Make “patching + historical investigation + secret rotation + downstream-state verification” the standard procedure for control-plane vulnerabilities.

4. Conduct a graduated-isolation tabletop exercise for OT, followed by a controlled technical drill.

5. Treat healthcare, energy-account data, and other genuine personal information as weaponisable trust signals rather than proof of identity.

---

📌 Final Assessment

The incidents in this coverage window point to a shared problem:

The enterprise management planes with the greatest privileges are often the systems with the weakest monitoring and least justifiable exposure.

VCO can manage an entire SD-WAN estate. TeamCity can access source code, secrets, and deployment pipelines. BMCs can control physical servers outside the operating system. OT enabling systems determine whether critical services can continue operating during a crisis.

Today’s defensive conclusion therefore goes beyond “update the version”:

Whenever a management plane may have been compromised, organisations must verify the trustworthiness of the host, credentials, configurations, downstream devices, and recovery sources at the same time. Patching the vulnerability closes the entry point, but it does not automatically revoke control the attacker may already have obtained.