Dutch police (politie.nl, 21 October 2026) said Rotterdam's Team Cybercrime arrested two men, aged 23 from Vaassen and 25 from Ede, on 6 October in an investigation led by the Public Prosecution Service into a new form of bank-helpdesk fraud. According to the police, victims received calls playing AI-generated voice clips about suspicious activity on their account; those who pressed 1 were put through to a fake bank employee who pressured them to download an app and hold their bank card to their phone to 'block' it. The app relayed the card's NFC chip data to an accomplice standing at an ATM, who withdrew thousands of euros. In the three weeks the team had sight of the group's servers, police saw about 170 victims and about €380,000 in losses, with victims of all ages from across the Netherlands. Police had the servers taken offline. The 23-year-old is suspected of being the technical lead, the other of a coordinating role; on 20 October a Rotterdam court ordered them held for at least 90 more days. Security Affairs reported the case on 26 Oct.
Politie (Dutch police) — Twee verdachten aangehouden in onderzoek naar nieuwe vorm van bankhelpdeskfraude (21 Oct 2026)
Researcher Ovi published an analysis on 21 October 2026 of uCreator (the vendor's own name for the product is YingGai), which he describes as a commercial Android surveillance platform that customers can rent and deploy against different apps on a target device. According to Ovi, victims get it through repackaged copies of legitimate apps, including Telegram variants, WeChat and GCash, spread by sideloading or social engineering, or through the vendor's own container app, Onion Box; much of the target-specific code is downloaded after installation. He says the Telegram module can run database queries through the app's own live interface, capture the account's two-step-verification password in cleartext, and remove its own session from the victim's device list, which together could support account takeover and hiding the intrusion; the WeChat flow harvests and zips app data and uses a bundled login script to clone the account. Ovi says he found code-confirmed support for about 20 target apps and that the apparent (still unconfirmed) targets are users of mobile wallets and messaging apps across China and Southeast Asia. He stresses that his report is an analysis of technical capability, not a measurement of victim impact: a command server he accessed held victim-related data apparently from China and the United States, but no reliable victim count. With another researcher, Jurre, he found the operators' back-end source code on an exposed self-hosted GitLab server. He associates three companies in Changsha and Hunan, China with different parts of the operation and says a shared owner is plausible but unproven. On Android 17 he found the kit's bundled hooking engine fails a symbol lookup, which he calls compatibility work for the makers, not proof that Android 17 prevents the technique. Updated 26 Oct 2026 (The Hacker News): according to The Hacker News, the kit's Telegram part matches Baohuo, a backdoor Doctor Web reported in October 2025 in tampered copies of Telegram X. (sources: The Hacker News; Ovi)
Ovi — uCreator: virtualization-based Android spyware platform targeting WeChat, Telegram and other messaging apps (21 Oct 2026)
Symantec's Threat Hunter Team says attackers have built an autonomous offensive agent that searches the internet for exposed large language model (LLM) endpoints and hijacks them to run its own attacks, a form of LLMjacking in which the owner of the hijacked model pays for the computing power. Symantec says it captured the agent's full instruction set in the summer of 2026 through an AI honeypot that impersonates an unprotected, internet-facing AI service, because the operators sent the tool's entire working prompt to what they believed was a real model. Symantec says targets include self-hosted model servers left open by default, AI gateways and relays in front of an organisation's paid model accounts, hastily deployed internal test systems and Model Context Protocol (MCP) servers, and that because most AI tools use the same OpenAI-compatible interface, a single scanner can find many kinds of target. Symantec says the request was built in layers: a jailbreak that told the model to hide its real identity and to treat reading .env files, API keys and database schemas as routine development work, a companion persona that must never refuse, and around 74 offensive tool definitions, including internet-wide asset discovery through the FOFA search service, exploit modules aimed at VS Code, Django, Jupyter, Laravel, Supabase, Next.js and Flask/Werkzeug deployments, server-side request forgery tools (one naming cloud metadata services as a target), database dumping through Prisma Studio and botnet command-and-control. A final directive the operators called 'Skynet' mode authorised up to 100,000 unattended steps, told the model to run tools without asking permission and to deploy cryptocurrency miners quietly, in a loop that would scan, infect, deploy miners and reinfect hosts. Symantec says the honeypot did not run any of the tool calls; the captured request carried three earlier tool calls against a benign programming challenge from a legitimate training platform, which Symantec says suggests the operators may have been testing the tool against a safe target. A second request the next day, from a different address, asked the model to decode a gzip-compressed shell script that downloaded or compiled the XMRig Monero miner and hid it in directories used by go2rtc, a video streaming server found in smart camera gateways and Home Assistant setups; the honeypot captured but did not run it. Symantec says the honeypot recorded more than 127,000 external requests from tens of thousands of unique addresses over the period, mostly reconnaissance of model endpoints, spraying of stolen API keys and probing for exposed configuration files. According to The Register, Symantec threat hunter Priti More said 'We have no evidence yet that it got that far' when describing the servers the agent could break into, and that Symantec has not attributed the agent to a particular person or group; More told The Register the French-language indicators are weak. Updated 24 Oct 2026 (The Register, 24 October 9:02 pm Perth): The Register's report quoted Symantec's Priti More, as above. (source: The Register)
Symantec (Broadcom) Threat Hunter Team — Autonomous LLMjacking: ‘Skynet’ Agent Hijacks Exposed AI Models to Run Attacks (21 Oct 2026)
Group-IB Threat Intelligence and NyxLab published a joint investigation on 21 October 2026 into a large-scale campaign against internet-facing network edge devices by a threat actor known as k0t. The researchers say the operators enumerate exposed VPN and firewall appliances in bulk with attack-surface search engines such as FOFA and ZoomEye, then gain access by exploiting CVE-2025-64446 (a FortiWeb path traversal) with a custom script, CVE-2026-0257 (a GlobalProtect authentication bypass on vulnerable PAN-OS configurations) with a separate tool, or by brute-forcing exposed Fortinet devices. On FortiGate they download the configuration and decrypt its stored secrets offline with the default FortiOS AES key (CVE-2019-6693), recovering LDAP/Active Directory bind, administrator and local-user credentials. They then connect over OpenConnect VPN, move toward domain-administrator control with tools including NetExec, Impacket, noPac, Kerbrute, PetitPotam and Mimikatz, persist with MeshCentral/MeshAgent, Atera, AnyDesk and AdaptixC2, and exfiltrate with Rclone to Wasabi S3 and MEGA. Group-IB and NyxLab say they found more than 70,000 exposed credentials associated with network devices, LDAP dumps and the like that were not linked to any other threat actor, including the FortiBleed cluster; that many FortiGate compromises date from February to June 2026; that Asia-Pacific accounts for 37.6% of unique victim domains, which they say may reflect where exposed devices are rather than deliberate targeting; and that victims overlap with those of ransomware groups including Qilin and The Gentlemen, though any relationship is still unconfirmed. (source: Group-IB blog) Updated 23 Oct 2026: The Hacker News reported the research. (source: The Hacker News)
Group-IB — Stray Cat, Open Doors: How k0t Wanders Through the Network Edge (21 Oct 2026)
Google said on 21 October 2026 that Chrome now explicitly asks users for permission before making an insecure HTTP connection. Google says it enabled the feature earlier this year for users enrolled in Safe Browsing's Enhanced Protection mode and has now extended it to all users by default. Google says Chrome asks the user to approve HTTP the first time they visit a site and, once approved, will not warn again until the user has not visited the site for at least two weeks. By default warnings are not shown on sites that cannot get a publicly-trusted HTTPS certificate, such as single-label hostnames like intranet/ or local IP addresses like 192.168.0.1. Google says the change replaces reliance on the passive 'Not Secure' badge, which only notifies users after their data and connection have been exposed, and that early rollout data shows nearly 95% of Chrome users on desktop do not see any HTTP warnings in a given week, with less than 1% seeing three or more. (source: Google blog)
Google — Chrome Now Warns Before Insecure HTTP Connections (21 Oct 2026)
ISC published four BIND 9 security advisories on 21 October 2026, all rated High and remotely exploitable, after early notification to its support customers on 14 October. CVE-2026-94300 (CVSS 8.1, CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H): according to ISC, replaying GSS-TSIG-signed UDP messages can corrupt memory in named; an attacker who can capture a previously signed UDP message can replay it while the negotiated TSIG key is still valid, and by also sending crafted queries to a zone the attacker controls may potentially achieve remote code execution. ISC says it found the flaw in internal testing and thanks Dave Aitel of OpenAI, who independently found and reported it. CVE-2026-19630 (CVSS 7.5): ISC says inbound DNS messages with a particular structure trigger extra processing with no limit in a BIND resolver, so a message with a maliciously large number of them can exhaust CPU and memory. CVE-2026-96888 (CVSS 7.5): a resolver configured with both a 'redirect' zone and 'qname-minimization strict' may abort with an assertion failure. CVE-2026-97313 (CVSS 7.5): a recursive server with at least two RPZ zones, one with the default 'recursive-only yes' and one with 'recursive-only no', may exit with an assertion failure when a recursion-desired query is followed by a non-recursive one; ISC credits Vitaly Simonovich for the last two. ISC lists affected versions as 9.11.0 to 9.18.50 (9.16.0 onwards for CVE-2026-96888 and CVE-2026-97313), 9.20.0 to 9.20.29 and 9.21.0 to 9.21.26, plus the Supported Preview Edition from 9.11.3-S1; fixes are 9.20.30, 9.21.27 and 9.20.30-S1. ISC says there are no workarounds and it is not aware of active exploits. ISC's download page lists 9.18.50 as end of life and 9.20.30 as the current stable extended-support release, and no 9.18 fix is listed. Source: ISC advisories CVE-2026-94300, CVE-2026-19630, CVE-2026-96888 and CVE-2026-97313 (21 Oct 2026).
The Apache Traffic Server project announced on 21 October 2026 (02:07 UTC, 10:07 Perth, on its announce list, posted by Masakazu Kitajo) that 15 vulnerabilities are fixed in versions 9.2.16, 10.1.5 and 10.2.1. According to the announcement, affected versions are 9.0.0 to 9.2.15, 10.0.0 to 10.1.4 and 10.2.0 (some flaws affect only 10.x). The two rated critical are in experimental plugins: CVE-2026-111813 (CVSS 3.1 10.0) lets an unauthenticated client control ImageMagick convert arguments through the magick plugin in its default unsigned configuration, and CVE-2026-111804 (CVSS 3.1 8.2, 10.x only) is a use-after-free in the wasm plugin. Others, as described by the project: request smuggling where an origin connection still owed a request body is reused (CVE-2025-31699, 8.9) or an unread Expect: 100-continue body is parsed as a new request (CVE-2025-55702, 8.7); a malformed chunked 302 response being cached and served, allowing cache poisoning (CVE-2026-111816); HEAD-response smuggling (CVE-2026-111809); HTTP/2 worker-pool exhaustion (CVE-2026-111805 and CVE-2026-111808); session sharing that confuses mutual-TLS identities (CVE-2026-111814) and TLS session-ticket resumption bypassing per-SNI verify_client STRICT enforcement (CVE-2026-111815); unauthenticated cache access through the tsmemcache plugin (CVE-2026-111811); the origin_server_auth plugin signing client-controlled AWS headers with the proxy's IAM credentials (CVE-2026-111812); log flooding (CVE-2026-111810); a stalled passthrough transfer when chunked trailers are dropped (CVE-2026-111817); and a null-pointer dereference on a POST half-close with a chunked response (CVE-2026-112381). The announcement says 9.x users should upgrade to 9.2.16, 10.1.x to 10.1.5 and 10.2.x to 10.2.1 or later. The CVE record for CVE-2026-111811 also lists 8.0.0 to 8.1.11 as affected. No exploitation has been reported. Source: Apache Traffic Server security announcement (21 Oct 2026); CVE records.
Apache Traffic Server — [SECURITY] Multiple vulnerabilities fixed in Apache Traffic Server 9.2.16, 10.1.5 and 10.2.1 (announce list, 21 Oct 2026)
Toronto Crime Stoppers said in a statement dated 21 October 2026, on behalf of chair Sean Sportun, that it is pausing its program effective immediately: it has removed the Tip Submit feature from its website, advised its vendor Navigate360/P3 to suspend intake for Toronto Crime Stoppers, and directed Canada's National Anonymous Call Centre to stop accepting or processing new information meant for it. Toronto Crime Stoppers says hackers stole data in March from P3, the tip software it has used since 2018, which is owned by Navigate360. It says Navigate360 told it that 176,859 Toronto tips, dating from January 2022 to November 2025, were in the stolen data and that Navigate360 has found 14,973 names in those tips, without saying whether the names belong to tipsters, people named in tips, or both; its timeline says Navigate360 told it on 6 July that 12,392 of those tips 'potentially' contained personal information. Toronto Crime Stoppers says some original tips containing potentially identifying information were stolen, that Navigate360 has not given it the text of the stolen tips despite numerous requests through its legal counsel, and that Navigate360 told it in April that Toronto's data had not been taken before saying on 9 June that it was affected. It asks people not to send tips by phone, online or through the app until it has a safer way to protect them, and to call 911 if someone is in danger. Source: Toronto Crime Stoppers statement (21 Oct 2026). Updated 22 Oct 2026: The Record reported Toronto's pause, saying it came hours after Canada's CBC reported that more than 1.5 million tips from Crime Stoppers chapters across the country were exposed in the breach; according to The Record, about half of the 1.5 million leaked tips CBC studied, some dating back 25 years, contained personal information, and CBC reporters reviewed hacked data made available to them in March by Distributed Denial of Secrets (DDoSecrets). The Record says a hacktivist collective known as Internet Yiff Machine claimed responsibility for the March breach. (source: The Record, including its account of CBC's reporting)
Toronto Crime Stoppers — Statement from Toronto Crime Stoppers on the P3 data breach (21 Oct 2026; PDF with timeline)
Splunk published security advisories on 21 October 2026, following an advance notice on 14 October, for Splunk Enterprise 10.4.4, 10.2.8, 10.0.11 and 9.4.16 and Splunk SOAR 8.7.0. SVD-2026-1008 (Critical, highest CVSS 3.1 score 9.9) covers internally identified vulnerabilities in Splunk Enterprise 10.4.0 to 10.4.3, 10.2.0 to 10.2.7, 10.0.0 to 10.0.10 and 9.4.0 to 9.4.15, grouped by weakness class with one CVE per group: CVE-2026-76299 (improper access control, 9.9), CVE-2026-76300 (8.8), CVE-2026-76301 (7.6) and CVE-2026-76302 (improper neutralization, 9.9); each group's score is the highest among its findings, and Splunk gives no further detail. SVD-2026-1007 (High, highest 8.8) lists 12 CVEs. Splunk says that in CVE-2026-76298 (8.8) the PostgreSQL sidecar service derives a privileged database password from the search head cluster identifier, which appears in search job logs, so a user without the admin or power roles could derive the sidecar's superuser password and run operating-system commands as the Splunk Enterprise account on search head cluster members (versions below 10.4.4 and 10.2.8). CVE-2026-76291 (8.8) lets a user with the schedule_search capability bypass the SPL safeguards for risky commands, because the scheduler does not apply them to scheduled searches, and CVE-2026-76293 (7.2) lets a user with the edit_manager_xml capability run operating-system commands through Splunk Web Manager XML; the list also includes unauthenticated denial-of-service flaws in Splunk Web (CVE-2026-76288) and the Edge Processor package download endpoint (CVE-2026-76290), and two Splunk Secure Gateway issues (CVE-2026-76292, CVE-2026-76295). SVD-2026-1009 updates third-party packages in Splunk Enterprise. For Splunk SOAR, SVD-2026-1011 (Critical, highest 9.9) and SVD-2026-1010 (High) fix issues in versions below 8.7.0. Splunk's advisories do not report exploitation. This is a separate release from Splunk's 7 October advisories (Splunk Enterprise 10.4.3/10.2.7/10.0.10/9.4.15, CVE-2026-76268), which have their own card.
Splunk — SVD-2026-1008: Security Hardening in Splunk Enterprise, October 2026 (21 Oct 2026)
Railway's security disclosure, posted by Jacob Cooper on 21 October 2026, says Railway detected anomalous activity that morning involving systems that store customer environment variables, and that its investigation to date indicates an unauthorised third party may have accessed encrypted environment variables and, for some of them, obtained the decrypted contents. Railway notes environment variables may contain secrets such as API keys or database and registry credentials. Railway says it believes this is part of a series of attacks recently targeting platform companies with the aim of compromising AI inference providers, and that it has notified those upstream providers to revoke all keys proactively. Railway says its initial analysis suggests the impact may be limited to a subset of users, but it recommends that all users immediately roll every environment variable stored in Railway, including API keys, and any private registry credentials, and review logs for those services for unusual activity; it says it will email affected customers directly as it confirms which accounts were affected. Railway's status page carries the incident as 'Railway Platform Outage', first posted at 07:24 UTC on 21 October (3:24 pm Perth); at 09:28 UTC (5:28 pm Perth) Railway said its dashboard, API and CLI were unavailable and new builds paused in all regions, and at 21:59 UTC (5:59 am Perth 22 Oct) it linked the security notice. At 22:10 UTC (6:10 am Perth 22 Oct) Railway said it was rotating all Railway bucket credentials, with new credentials appearing in dashboards automatically but services unable to be redeployed to pick them up until builds are restored; at 22:45 UTC (6:45 am Perth 22 Oct) it said builds remained paused and that the credential revocations shown in customers' audit logs, carried out by a Railway employee, are expected. Railway has not said how the attacker gained access or how many accounts are affected. UPDATE 22 October (Railway status page): at 01:22 UTC (9:22 am Perth) Railway published guides on recommended next steps, covering checks for unexpected usage at OpenRouter, Anthropic, OpenAI, Grok and Stripe, checks for anomalous GitHub, AWS and GCP access, rotation of PostgreSQL, MySQL, MongoDB and Redis database credentials, and redeploying buckets and reconnecting GitHub after the credential reset; Railway says some steps require a redeploy and will have to wait until builds are available, but others can begin now. In its 03:00 UTC update (11:00 am Perth) Railway said builds remained paused and it expected to have an update for Enterprise users soon. UPDATE 22 October, later (Railway status page): at 03:32 UTC (11:32 am Perth) Railway said builds for Enterprise workspaces are now available, so Enterprise customers can complete the guide steps that require a redeploy, including applying new credentials, with Pro, Hobby, then Free and Trial plans to follow in stages. At 04:17 UTC (12:17 pm Perth) Railway said that, in accordance with its security disclosure, it has invalidated all Railway API tokens, so integrations using the Railway Public API need new tokens. From 04:39 UTC Railway reported deployments stalling at stages such as 'Running pre-deploy command'; at 06:01 UTC it said it was still working on enabling builds for Pro, Hobby, then Free and Trial, and at 06:12 UTC (2:12 pm Perth) it said Enterprise deployments were moving through each stage at normal speed. UPDATE 22 October, evening (Railway status page): at 06:29 UTC (2:29 pm Perth) Railway said builds are now available for Pro and Enterprise workspaces, so Pro customers can complete the guide steps that require a redeploy. At 10:15 UTC Railway said some builds were still failing more often than usual and many deployments remained queued; in its 11:47 UTC update (7:47 pm Perth) it said deployment wait times were coming down, though some deployments may still take longer than usual to start, and that it was still working on enabling builds for Hobby, then Free and Trial. UPDATE 23 October (Railway status page): at 21:08 UTC on 22 October (5:08 am Perth 23 Oct) Railway said builds are now available for Hobby workspaces and that new signups remain temporarily paused; at 21:59 UTC (5:59 am Perth) it said builds are enabled for Hobby, Pro and Enterprise workspaces, are generally completing successfully but may take longer than usual, and that it will update when it enables builds for Free and Trial workspaces. Correction (23 Oct 2026): an earlier version put Railway's 'dashboard, API and CLI unavailable' post at 11:33 UTC on 21 October, the security-notice link at 22:10 UTC and the bucket-credential rotation notice at 22:37 UTC; Railway's status page shows those posts at 09:28 UTC, 21:59 UTC and 22:10 UTC. (source: Railway status page) UPDATE (24 Oct 2026): Railway's preliminary report, published at 23:31 UTC on 22 October (7:31 am Perth 23 Oct), says the incident led to unauthorised access to a subset of internal Railway systems and that early investigation indicates the attacker was trying to obtain AI provider API keys to perform distillation attacks. Railway puts the attack between 13:58 UTC on 20 October and 03:32 UTC on 22 October, when it confirmed the attacker no longer had access to any internal systems. Railway says the attacker pulled secrets in encrypted form, later accessed credentials for its CI environment and decrypted artifacts holding additional API access, and ran an unauthorised query of encrypted environment variables, a subset of which were decrypted using the compromised credentials. Railway says at most 1.85% of all workspaces, about 100,000, had some environment variables potentially compromised; because it cannot tell which variables were decrypted, it is also contacting other users it considers high risk. Railway says the attacker did not access Railway user accounts, that it is not ruling out access to user source code until its final forensic report, and that it gave vendors such as GitHub and SpaceXSI all API keys on the platform, so a revocation notice from a vendor does not by itself mean a user's credentials were affected. Railway says existing deployments stayed online, builds for all tiers are restored, and it has engaged external incident response experts and the authorities. (source: Railway preliminary report)
Railway — Security Disclosure: Wednesday October 21st (21 Oct 2026)
In a notice on Onamae.com dated 21 October 2026 (status as of 4:00 Japan time, 3:00 am Perth), the operator of Onamae.com Desktop Cloud apologised and said a third party had gained unauthorised access to the service, and that on 20 October it confirmed malicious programs had been installed in some customers' server environments. The notice says information stored on the servers may have been viewed and puts the number of servers that may be affected at 26,739; it says that so far it has not confirmed any leak of customers' personal information it holds or any misuse of viewed information, and that it does not hold payment information, including credit card details. To prevent further damage, the operator says it began shutting down customers' servers in stages from 4:00 on 21 October, covering all Desktop Cloud plans, and will announce a restart date once it is decided; its investigation of customer servers continues. It asks customers who stored or used credentials such as IDs and passwords on their servers to change them promptly, including anywhere the same password is reused, and warns of phishing emails and suspicious contacts exploiting the incident, saying it never asks for passwords or card details by email or phone. According to BleepingComputer, Onamae.com is operated by GMO Internet, part of GMO Internet Group, and the Desktop Cloud service is marketed for running MetaTrader 4 automated FX trading. UPDATE (27 Oct 2026; GMO Internet): In its second and third reports (22 October, as of 16:59 JST, and 23 October, as of 15:30 JST), GMO Internet said customers had reported unauthorised operations on their trading accounts, that login details for trading tools such as MT4/MT5 saved on the servers may have been obtained and used illegally by a third party, that it is investigating with an external cybersecurity firm, and that it consulted the police on 22 October; it says 26,739 is the number of servers that may be affected, not the number of confirmed cases. In its fourth report (24 October, as of 11:50 JST, 10:50 am Perth), GMO said its investigation had confirmed that the service's systems had security vulnerabilities, that its environment was accessed without authorisation and that customer information was taken outside the company, and that some customers had reported transactions in their trading accounts that they did not recognise. GMO says it will pay every current customer a flat JPY 5,000 condolence payment, will compensate realised losses from transactions its investigation confirms were unauthorised, and will announce how to apply by 6 November; it says it has asked major exchanges and securities companies to block access via the service, forcibly terminate all active sessions and monitor for unauthorised transactions, and has asked government agencies to apply active cyber defence measures. GMO says it received a demand for money from a person believed to be the attacker, with threats that included further manipulation of customers' trading accounts at more than 70 securities and FX companies and publication of information about the company and its customers, and that it will not comply because paying would not guarantee the information is deleted or its misuse prevented. In its seventh report (26 October, as of 23:10 JST, 10:10 pm Perth), GMO said the threatening email arrived on 21 October and demanded approximately 8 billion yen, and that persons believed to be the attackers had told it they would publish customer information and carry out a ransomware attack at 12:00 on 27 October; it said it was collecting and analysing customers' devices. In its ninth report (Japanese, dated 27 October, as of 11:59, no time zone stated), GMO says no malware, including ransomware, has been found on the devices it has finished analysing, but that analysis continues and it has not confirmed that every customer's device is safe; it asked customers to back up their data and then disconnect and power off their PCs before 12:00, and says it will provide a new PC of equivalent performance to customers whose PCs are hit by ransomware. (source: GMO Internet) UPDATE (27 Oct 2026; GMO Internet): In its tenth report (Japanese, dated 27 October, as of 13:55, no time zone stated), GMO says it confirmed at 12:30 on 27 October that a person believed to be the attacker had published what it claims is information about GMO and its customers; GMO says it is still checking the content, which may include things that are not true, and that it will contact customers individually if it confirms their information is included. GMO warns people not to visit or spread the published material, saying the information of anyone who accesses that site is obtained by the attacker, and says it is preparing legal action, including criminal complaints, against people who spread it maliciously. GMO says no ransomware attack had been confirmed as of 13:55 on 27 October, that it has begun considering a further payment, separate from the JPY 5,000, for customers whose information it confirms was published, and that security companies including Trend Micro and AI companies have offered to help. In its eleventh report (as of 14:55 on 27 October, no time zone stated), GMO repeats that it will not meet the attacker's demands or pay, and says it has consulted the police and other authorities. (source: GMO Internet) UPDATE (28 Oct 2026, Perth; GMO Internet): In its twelfth report (Japanese, dated 27 October, as of 19:10, no time zone stated), GMO says it will never meet the attackers' demands and sets out a special payment for customers whose information it confirms was published by the attacker: JPY 10,000 for basic details such as name and contact information, JPY 15,000 for financial or authentication details such as trading-account IDs and passwords, and JPY 25,000 for sensitive or special-care personal information, added together per category up to JPY 3 million per publication, and separate from the flat JPY 5,000 payment and loss compensation announced earlier. GMO Internet Group is also creating a "GMO Cybercrime Bounty" of up to US$1 million in total (about JPY 150 million at JPY 150 to the dollar, GMO says) for specific, verifiable information that helps identify or arrest those involved; GMO says submissions open at 12:00 Japan time on 28 October (11:00 Perth) at cybercrimebounty.gmo, that the reward is not a ransom or a payment for the stolen data, and that people must not hack, contact or pay the attackers themselves. GMO again warns that anyone who accesses the site carrying the published data has their own information captured by the attacker, and asks anyone who has visited it to run a full antivirus scan. (source: GMO Internet)
Onamae.com — Desktop Cloud unauthorised access notice (Japanese, 21 Oct 2026, as of 4:00 JST)
GitLab said it released GitLab Community Edition and Enterprise Edition 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 and 18.11.13 on 21 October 2026 and strongly recommends that all self-managed installations upgrade immediately. GitLab says the critical flaw, CVE-2026-110264, could under certain conditions have allowed an unauthenticated user to execute arbitrary code on the GitLab server due to an integer overflow when compiling a specially crafted regular expression; it rates it CVSS 3.1 10.0 and lists all CE/EE versions from 7.0 as affected up to the fixed releases. GitLab says it backported the fix to 18.11.13, 19.0.10, 19.1.9 and 19.2.9 in addition to its standard patch releases, that GitLab.com is already running the patched version, and that GitLab Dedicated tenants on 19.3.5-internal0 and 19.4.2-internal0 or later already include the fixes. GitLab has released two threat detections for self-managed customers, 'Onigmo native worker crash' and 'Org mode render error burst'. Researcher joaxcar reported the flaw through GitLab's HackerOne bug bounty programme. GitLab's release also fixes 11 further security issues rated high, medium or low, including an account takeover flaw when OmniAuth SAML and LDAP auto-linking are both enabled (CVE-2026-15723, CVSS 8.2) and an OAuth/OIDC discovery cache-poisoning flaw (CVE-2026-112212, CVSS 7.5). GitLab says the patch includes database migrations, so single-node instances will have downtime during the upgrade, while multi-node instances can apply it without downtime using zero-downtime upgrade procedures. According to The Hacker News, GitLab's 12 October fix for the earlier regex-compiler flaw CVE-2026-97229 covered only 19.2 and later, so an instance updated then is in range again, and GitLab's advisory offers no interim workaround. (sources: GitLab Critical Patch Release 19.5.1; The Hacker News) UPDATE (24 Oct 2026): Ruby said on 23 October (03:11 UTC) that it has released Ruby 4.0.9, 3.4.12 and 3.3.13, which fix the bugs in Ruby's regular expression engine (Onigmo) behind GitLab's CVE-2026-89078, CVE-2026-93577, CVE-2026-97229 and CVE-2026-110264. Ruby says the fix for the bug behind CVE-2026-110264 (overflow of internal IDs in a pattern with many repeats) first ships in 4.0.9, so Ruby 4.0.8 does not contain it, while 3.4.12 and 3.3.13 contain all the fixes. Ruby says an application is affected only if it compiles a regular expression from a string an attacker controls, for example by passing it to Regexp.new, Regexp.union or Regexp.compile or interpolating it into a regexp literal such as /#{input}/; applications that only use regular expressions written by their own developers are not affected. Ruby says Regexp.timeout does not protect against these bugs and that limiting pattern length is not reliable because some can be triggered by short patterns. Ruby has not requested CVE identifiers of its own 'at least for now' and asks users to track the issues by GitLab's CVE numbers, for example in a security scanner. (source: Ruby)
