Top 5 Cybersecurity News

This week’s Top 5 Cybersecurity News for October 30, 2026 is about assumptions nobody re-checked. A Japanese hosted-desktop service held customers’ saved trading logins on servers attackers could reach, after its own staff had flagged weaknesses. A VMware ESXi flaw scored 2.7 on the CVSS scale was used as a zero-day to keep administrator actions out of the logs. A PeopleSoft trust rule that welcomed the server’s own address turned one CVE into three flaws. A key committed to a public repository in May was never revoked and, five months later, helped publish a poisoned LiteLLM release. And Dahua cameras with no open port were still reachable through the vendor’s cloud. Five exposure layers, one question for every executive: which assumption in your environment has nobody tested since it was set up?

1) A Japanese Trading Desktop Cloud Went Dark, and the Attackers Went After Customers’ Broker Accounts

GMO Internet found on October 20 that a third party had installed malicious programs on customer servers of its Onamae.com Desktop Cloud, a service that hosts Windows desktops used for foreign exchange trading. It shut down the servers on every plan from October 21 and counts 26,739 servers as potentially affected, which is not the number of confirmed break-ins. On October 24 it confirmed unauthorized access and the exfiltration of customer information. It received a threatening email on October 21 demanding about 8 billion yen (roughly $50 million), says it will not pay, and on October 28 opened a reward programme of up to $1 million for tips that lead to an arrest. In its reports up to October 29, GMO had not said how the attackers got in.

The damage reaches past GMO. Anything customers stored on the servers may have been viewed, including logins saved in trading software, and customers began reporting unrecognised trades on October 21. OANDA Japan confirmed that a third party had logged in to some customer accounts using ID and password pairs it believes leaked from the GMO servers. GMO told customers to change passwords from a device never used for trading and to end every active session, because some trading apps keep sessions alive after a password change. The attackers also threatened accounts at more than 70 securities and FX firms. On October 28 GMO said its analysis of customer devices had so far found no traces of malware or ransomware.

GMO’s chief executive wrote on October 25 that the group’s own white-hat hackers had flagged areas for improvement and that the response lacked depth and speed. The attackers claim, according to ITMedia reporting relayed by The Hacker News, that one administrator account was shared across all servers; GMO has not confirmed this. Either way, the lesson applies to hosted desktops in general. A provider-run desktop is someone else’s computer holding your logins, so its weaknesses become yours. Ask what the provider shares across customers and how quickly it acts on its own findings, and make sure whoever holds saved credentials can revoke them fast.

Read more on: GMO Internet Disclosure · The Register

2) A VMware ESXi Flaw Rated 2.7 Was Used as a Zero-Day to Keep Administrator Actions Out of the Logs

CISA added CVE-2026-41709 to its Known Exploited Vulnerabilities catalog on October 28, with a federal deadline of November 11, according to the CISA catalog. The flaw is an insufficient-logging weakness in VMware ESX that lets an administrator perform certain operations without them being logged. Broadcom’s advisory VMSA-2026-0006, published on July 29, rates it Low at CVSS 2.7, offers no workaround and credits Ian Barton of CrowdStrike. According to CrowdStrike’s 2026 Legal Threat Landscape Report, the China-nexus group Warp Panda exploited it as a zero-day in intrusions at US entities, including several law firms, during 2025 and as late as early 2026. Fixed builds include ESXi 8.0 U3j (ESXi80U3j-25429389) and ESXi-9.0.2.0100-25595025.

The flaw gives no access by itself; its value is concealment. In the chain CrowdStrike describes, attackers enter through an exposed edge appliance, settle into the virtualization layer, blind the logs with this flaw, then use stolen session tokens to reach Microsoft 365 environments and, in at least one intrusion, enrol their own MFA device. For a mid-sized organisation the practical consequence is that a hypervisor’s own audit trail may be incomplete for the period before patching, so an investigation cannot rely on it alone. Patching ESX comes first. Checking MFA registrations and revoking cloud sessions for sensitive accounts belongs on the same list.

A severity score rates a flaw in isolation, while attackers rate it by what it does for the chain. A 2.7 that removes the evidence can be worth more to an espionage actor than a loud critical that triggers an alert. In our reading, vulnerability programmes that sort by CVSS alone will leave this class of flaw at the bottom of the queue, and forwarding logs to an external system cannot recover events that were never generated. What remains is patch discipline that treats the visibility layer, meaning logs, audit settings and detection tooling, as assets to protect as carefully as the systems they watch.

Read more on: Broadcom Advisory VMSA-2026-0006 · GBHackers

3) One PeopleSoft CVE Hid Three Flaws, and a Default Trust Rule Did the Rest

The PeopleSoft flaw that ShinyHunters has exploited since May is three flaws, not one, according to Bobby Gould of the Zero Day Initiative, whose team reported it to Oracle. Oracle fixed all three under one identifier, CVE-2026-35273 (CVSS 9.8, PeopleTools 8.61 and 8.62), in an out-of-band alert on June 10; ZDI says it is working with Oracle on separate CVEs. The chain starts with a server-side request forgery in the Integration Gateway, which reaches an internal management interface, PSEMHUB, because its default trusted-hosts file lists the loopback address 127.0.0.1. Mandiant attributes exploitation from May 27 to June 9, mostly against universities, to ShinyHunters.

Mandiant later reported a renewed wave in September across technology, IT services, healthcare, agriculture, transport and government, affecting dozens of systems worldwide. Attackers slipped past web application firewall rules that blocked the /PSEMHUB/ path by url-encoding a single character. ZDI describes two routes to code execution: a web shell written through a logging command, and a malicious XML file read at the next service start, which leaves less for standard detection to catch. The guidance relayed by The Hacker News is to patch, treat any host with a web shell as compromised, rotate credentials reachable from the PeopleSoft tier and prepare for extortion. Whether patching evicts an intruder already inside is not settled.

A trust check that admits the server’s own address holds only until some feature can be made to send requests from that server, and ZDI says the loopback default made the check ineffective once the forgery existed. DIESEC covered the exploitation in June; what has changed since is how much of the picture a single CVE number hid. In our reading, a patch tracker that records one identifier for three flaws cannot show whether each path was closed. The data behind the application is what ShinyHunters monetises through extortion, per Mandiant, so the cost of a missed path is paid later.

Read more on: Oracle Security Alert · The Hacker News

4) LiteLLM’s Poisoned Release Began With a Key That Was Committed in May and Never Revoked

On May 27, a configuration file containing an administrative key for an internal LiteLLM Agent Platform was committed to a public repository. The file was deleted about three hours later, but the key was never revoked. On October 10, an attacker used it to read the platform’s API, which returned the GitHub CLI token of a GitHub organization owner. With owner rights the attacker took the tokens of two maintainers through throwaway workflows. On October 21 the release workflow was pointed at a lookalike fork, one token triggered the release and another approved it, and a poisoned litellm 1.107.0 reached PyPI at 11:39 UTC, followed by container registries. PyPI quarantined it by 13:23 UTC.

LiteLLM’s root-cause report lists the weak points. The stolen token was not scoped to a few repositories; it was the owner’s command-line login, which GitHub does not subject to the re-authentication it requires for other sensitive organization actions. A rule that normally required approval from an account locked to a physical device had been relaxed earlier that week, so any two engineers could release. The attacker overrode branch protection with the owner token, deleted run records and force-pushed the history clean. The compromised artifacts were live for about two hours. LiteLLM says it is revoking every token on every internal system, and that its first explanation, tokens stolen from logs, was wrong.

The attack needed no software vulnerability. It needed a secret that stayed valid for more than four months after the company knew it had been exposed. LiteLLM’s own report calls this a strong illustration of the risk of failing to rotate an exposed key. It is also the second time this year that a LiteLLM package release was compromised; DIESEC covered the March incident. Organisations that consume AI gateways and similar packages should pin and verify what they install. For anything they publish, “deleted from the repository” and “revoked” are different events.

Read more on: LiteLLM Root-Cause Report · The Hacker News

5) Dahua Cameras With No Open Port Were Still Reachable, Because the Camera Dials Out to the Vendor’s Cloud

Ukraine’s CERT-UA warned in an alert published on October 23 that Dahua IP cameras and video recorders were being accessed without authorisation. Attackers viewed the video stream, changed device configuration and created accounts of their own. The entry point is Easy4IP, Dahua’s peer-to-peer cloud access feature, in which a device dials out to the vendor’s cloud and registers by serial number. CERT-UA says the serial numbers have a predictable structure and are probably harvested by mass enumeration and then checked against the cloud, so every device with P2P enabled is at risk. Login then relies on weak or known passwords, or on the old authentication-bypass flaws CVE-2021-33044 and CVE-2021-33045 in outdated firmware. The alert does not name victims, device counts or attackers.

“No open port” therefore did not mean “not reachable”. CERT-UA’s own wording is that assuming the serial number is secret is no reason to consider a device secure. Indicators include unknown accounts, changed settings and audit-log entries for the vendor’s native protocol coming from the local address 127.0.0.1, a sign of P2P access. Hunt.io, which tracked a similar campaign in the summer, reported 14,530 compromised Dahua cameras, 1,923 of them with a backdoor account that survives password changes and, on most firmware, factory resets; no link to the CERT-UA cases has been established. CERT-UA advises disabling P2P if it is not needed, keeping devices off the internet and updating firmware.

For mid-sized companies the exposure sits in places nobody inventories: cameras at plants, warehouses and branch offices, installed by a contractor and often absent from IT asset lists. That is our assumption; the alert does not say how organisations manage these devices. The broader point is that a vendor’s relay can turn a device behind a firewall into an internet-reachable service, and a firewall rule review will not show it. The Dutch intelligence services warned in July that Russian state actors compromise IP cameras to gather military intelligence, so cameras are also a collection tool. Device inventories need to record what each device connects out to.

Read more on: CERT-UA · The Record

If this week tells us anything, it’s this:

Each of the five incidents turns on something that was configured once and trusted afterwards. A hosted desktop was assumed to be isolated from the logins stored inside it. A hypervisor log was assumed to be complete. A loopback address was assumed to be friendly. A leaked key was assumed to be dead because the file was deleted. A camera was assumed to be private because no port was open. None of this needed a new class of attack, only someone who tested the assumption before its owner did. The structural exposure is the gap between “we set this up correctly” and “we have checked it since”.

For boards and CISOs the useful question is not whether these five products are in the estate. It is which assurances, such as provider isolation, log completeness, default trust lists, key revocation and network reachability, have a named owner and a date of last test, and which rest on the original setup alone. A short list of assumptions, reviewed the way a risk register is reviewed, answers that at a fraction of the cost of an incident.

Each of these assumptions has a way to be tested. A penetration test or red team exercise checks whether what you believe is isolated, protected or unreachable actually is. Continuous monitoring shows whether your logs and detections are doing what you think. A risk and compliance review gives every assumption an owner and a date of last test. And because many assumptions live in people, such as who revokes a key or who reports an odd email, security awareness keeps those habits current.

If any of these assumptions sounds familiar from your own environment, the DIESEC team is glad to talk it through via our contact page.