Oracle’s 1,295 Security Patches and GMO’s Cyberattack: What Japanese Businesses Need to Reassess

Oracle's October 20 Critical Patch Update contains 1,295 security patches covering 1,209 distinct CVEs. A patch count is not a count of unique vulnerabilities. The release spans Oracle Database, Fusion Middleware, E-Business Suite, Java SE, MySQL and other widely used enterprise platforms. [1][2]

Fusion Middleware received 206 patches, including 134 issues Oracle lists as remotely exploitable without authentication. E-Business Suite received 194 patches, including 31 potentially exploitable over a network without credentials. Such components can sit under finance, procurement, order processing and other essential business workflows. [1]

One example is CVE-2026-101809 in E-Business Suite's Workflow Notification Mailer, rated CVSS 3.1 10.0. Oracle lists E-Business Suite versions 12.2.3–12.2.15 as affected and identifies an HTTP attack path requiring no authentication. The score describes technical severity; it does not mean every deployment is directly exposed to the public internet. Version, configuration and network reachability still matter. [1]

Patch management is therefore an architectural task, not just a software download. A stable application may run on older database or middleware components, and changing one layer may require compatibility testing and vendor coordination. Oracle explicitly warns that E-Business Suite may also be exposed through its Database and Fusion Middleware dependencies, which are not fully represented by the E-Business Suite risk matrix alone. [1]

GMO Internet began investigating after a customer report on October 19 and confirmed unauthorized software in part of its Onamae.com Desktop Cloud environment on October 20. At 4 a.m. on October 21, it started suspending servers across all service plans to limit the damage. Some customers use this remote-desktop infrastructure to run automated foreign-exchange trading software. [3]

The company identified 26,739 servers as potentially affected, not confirmed compromised. By October 24, GMO confirmed customer information had been taken out of its systems and had received reports of transactions account holders did not authorize. Trading-account login details stored in the service environment were among the categories potentially exposed. [3][4]

GMO reported an extortion demand of roughly ¥8 billion. On October 27, people believed to be behind the attack published information they claimed belonged to the company and its customers. GMO was still validating the material; attacker claims are not verified facts. The same group had threatened to publish data and deploy ransomware on customers' devices. [5]

By October 28, GMO said analyses of customer devices received so far had found no evidence of ransomware, while investigations continued. It also reported suspension of a domain used by the attackers to publish information. The company opened a reward program of up to US$1 million on October 28 and said on October 29 that it had received 270 tips and was sharing promising leads with authorities. Neither update establishes that every customer device is safe. [6][7]

GMO offered a ¥5,000 support payment to customers using the service and a conditional compensation framework for verified losses from unauthorized trades. The episode shows how incident costs can extend far beyond restoring servers: outages, forensics, customer support, claims handling and potential misuse of credentials in systems outside the original provider. [4]

On October 27, Sony Network Communications reported unauthorized access to So-net's membership database. The incident occurred on October 19 and was identified on October 23. Up to 2,585,481 records concerning So-net and plala (S course) members were affected, with details including contact information and identifiers. Passwords were also exposed for 54,401 addresses in certain email services, prompting password resets. [8]

On October 26, Rakuten Travel reported two separate incidents. An intrusion detected on September 10 concerned overseas hotel booking sites managed by Rakuten Travel Xchange, with access affecting information relating to up to around 2.6 million login accounts and a smaller group of reservation records. A second incident, detected on October 20, involved a multilingual booking website and up to around 860,000 accounts. These are scope figures, not counts that can simply be added to obtain unique affected customers. [9]

JAL reported on October 28 that approximately 92,000 passengers had indications of access to reservation data via supplier Amadeus's systems. For around 90,000 people, that involved items such as names, reservation codes, dates and routes; for approximately 2,000, the possible scope included email addresses, telephone or passport numbers. JAL said credit-card details and passwords were not involved and flight operations were unaffected. [10]

The events differ in cause, discovery date, public disclosure and exposure. They should not be described as one attack campaign. Their shared management lesson is that data sensitivity, vendor access and post-incident containment matter as much as headline record counts.

Automize views these cases through three connected layers. First is software and technical infrastructure: identify deployed products, versions, dependencies and paths reachable from outside networks. This is the direct task created by the Oracle update.

Second is the outsourced technology stack: cloud platforms, SaaS services and integration partners. Moving an application outside the company does not transfer away all consequences of an outage or breach. Businesses need to understand access rights, incident notification obligations, provider responsibilities and alternatives when a service becomes unavailable.

Third is the information and operational continuity layer. A service may remain online while sensitive credentials are exposed; alternatively, it may need to be taken offline before the full extent of data loss is known. Risk assessment must cover the nature of the data, potential credential abuse, disruption time and impact on customers.

This perspective aligns with Japan's METI Cybersecurity Management Guidelines version 3.0, which emphasize executive responsibility, supply-chain risk and response and recovery. The decision to patch immediately or schedule controlled maintenance should account for exposure, business impact and interim protections, not CVSS alone. [11]

Start with an inventory of Oracle systems and dependencies, mapped to the October CPU: affected versions, exposed interfaces, critical workloads and named remediation owners. Prioritize externally reachable and business-critical systems. If immediate patching is not possible, limit unnecessary access, segment networks and strengthen monitoring; temporary controls do not replace fixes. [1]

Map the data and privileges held by cloud and outsourcing partners. Apply multi-factor authentication where feasible, remove unneeded administrative privileges and prepare to rotate passwords or tokens if exposure is suspected. Crucially, decide what operations can continue if a key vendor has to suspend service.

A backup is useful only if restoration has been tested. Practice recovery times and coordination among IT, operations, vendors and customer support. An incident procedure should cover evidence preservation, assessment of notification obligations and precise communication rather than premature conclusions.

For executives, effective cyber reporting should answer five business questions: which critical system is exposed, what interruption would cost, who owns remediation, when it will finish and who accepts any residual risk.

Oracle reveals the scale and complexity of enterprise software maintenance. GMO illustrates how a provider incident may trigger operational interruption, credential risk and costly customer support. So-net, Rakuten Travel and JAL show that customer information sits across systems and suppliers, with different exposure profiles.

No business can eliminate every attack possibility. But understanding dependencies, limiting the blast radius and testing recovery can reduce preventable harm. For Japanese companies, cybersecurity must become part of technology governance, operations and vendor decisions—not merely a task handed to IT when a patch arrives.