The city of Columbia, the capital of South Carolina (about 150,000 residents), said it is responding to a cyberattack that has shut down several government systems, according to The Record from Recorded Future News (22 Oct). A city spokesperson told The Record that the city's IT department recently identified suspicious activity and contacted the South Carolina Law Enforcement Division (SLED), which is now leading the investigation. According to The Record, the affected systems include the MyColaSC platform residents use to pay utility bills, report non-emergency issues and reach other city services, as well as Geographic Information Systems and systems supporting animal services; residents were asked to phone in concerns such as potholes, fallen trees and broken streetlights while MyColaSC is down. A city official told The Record that critical public safety and utility systems remain operational, including the Columbia Police Department, Columbia-Richland Fire Department, 911 communications, Columbia Water systems and the Payment Center, including online payment services. The city has not said what kind of attack it was, and The Record says no hacking group had taken credit for the incident as of Wednesday. No Australian impact. Source: The Record (22 Oct).
The Record (Recorded Future News) — South Carolina officials offer assistance after state capital hit with cyberattack (22 Oct 2026)
INTERPOL announced on 22 October 2026 the results of Operation Serengeti III, which it describes as one of Africa's largest cybercrime enforcement operations. INTERPOL says investigators from 21 countries, under its coordination, targeted cyber-enabled fraud, ransomware, business email compromise, online scams and digital extortion between 29 June and 31 August 2026, arresting 1,462 suspects, disrupting 10,909 malicious networks and recovering more than US$105 million in illicit funds. INTERPOL says authorities identified 65,929 victims and linked the criminal activity to losses exceeding US$385 million. INTERPOL's highlights: in Uganda, two transnational fraud rings were dismantled and 365 foreign nationals arrested over online investment and pension fraud targeting victims across Asia; in Angola, two illegal cryptocurrency mining centres were dismantled, nine suspects arrested and more than 2,000 mining devices seized; in Nigeria, a suspect was arrested over a large-scale phishing and business email compromise operation that harvested software credentials and amassed about 2.1 million email addresses. INTERPOL says partners including Group-IB, Kaspersky, Fortinet, Team Cymru, Uppsala Security, Cybercrime Atlas, Meta and the Global Anti-Scam Alliance supported the operation, and that several investigations remain active. The participating countries INTERPOL lists are 20 African nations and the United States; INTERPOL names no Australian victims.
INTERPOL — Cybercrime crackdown in Africa nets 1,462 arrests, recovers over USD 105 million (22 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. Primary: 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. Primary: Google blog (Chrome Secure Web and Networking Team).
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).
Cisco published a critical advisory (cisco-sa-vcs-static-cred-hr7EWZ8t) on 21 October 2026 at 16:00 GMT (22 Oct 00:00 Perth) for CVE-2026-76466 in the database service feature of Cisco Expressway Series. According to Cisco, an unauthenticated, remote attacker with network access to an Expressway device could run arbitrary operating system commands as root. Cisco says the flaw is due to the use of persistent cookies, and that client certificates are not validated when TLS Verify Mode is set to Enabled for clustering; an attacker who has the cookies could connect to the database service and invoke specific remote procedure call (RPC) commands. Cisco rates it CVSS 9.8 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H), CWE-798 (use of hard-coded credentials), bug CSCww27732. It affects Expressway-C and Expressway-E, virtual and appliance, only when the devices are configured in a cluster. Cisco lists X15.5.20 as the first fixed release for X15.5.3 and earlier, says X14 and earlier must migrate to a fixed release, and says there are no workarounds; the fix is also part of the 'Cisco Expressway Series Security Hardening Release: October 2026'. Cisco's PSIRT says it is not aware of any public announcements or malicious use. Cisco credits Stefan Aleksic of Jane Street. The advisory is part of Cisco's 21 October 2026 bundled publication. Source: Cisco security advisory cisco-sa-vcs-static-cred-hr7EWZ8t (21 Oct 2026).
Cisco — Cisco Expressway Series Remote Code Execution Vulnerability (cisco-sa-vcs-static-cred-hr7EWZ8t, 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: https://status.railway.com/) 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)
Oracle published Security Alert CVE-2026-91403 (Rev 1) on 21 October 2026 for a vulnerability in the JSSE component of Oracle Java SE, Oracle GraalVM for JDK and Oracle GraalVM Enterprise Edition. Oracle says the flaw is remotely exploitable without authentication over multiple protocols and scores it CVSS 3.1 9.1 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N); Oracle's CVE record says successful attacks can result in unauthorised creation, deletion or modification of critical data or all data accessible to these products, as well as unauthorised access to critical data or complete access to all accessible data. The supported versions Oracle lists as affected are Oracle Java SE 8u511, 8u511-perf, 11.0.33, 17.0.21, 21.0.13, 25.0.5 and 27.0.1, Oracle GraalVM for JDK 17.0.21 and 21.0.13, and Oracle GraalVM Enterprise Edition 21.3.20. Oracle says the flaw can be exploited through APIs in the component, for example through a web service that supplies data to them, and also applies to sandboxed Java Web Start applications or applets that load and run untrusted code. Oracle's alert credits no reporter and points to its Java SE Patch Availability Document for patches; the alert page does not list fixed build numbers or say whether the flaw has been exploited. Correction (25 Oct 2026): Oracle's alert page, as read on 25 October (still Rev 1 of 21 October), says the Security Alert addresses CVE-2026-91403 by providing Java updates that distrust the set of impacted intermediate CA certificates related to eMudhra, and tells customers to update to the latest Java version or apply the recommended mitigations. This card earlier said the alert did not describe the bug; that was wrong and has been removed. (source: Oracle Security Alert Advisory - CVE-2026-91403) UPDATE (25 Oct 2026): Oracle published a second Security Alert, CVE-2026-114820 (Rev 1, 24 October), which it says provides Java updates that remove the set of impacted root CA certificates related to eMudhra. Oracle again places the issue in the JSSE component, scores it CVSS 3.1 9.1 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N) and lists as affected Oracle Java SE 8u511-b32, 8u511-perf-b32, 11.0.33.0.2, 17.0.21.0.2, 21.0.13.0.2, 25.0.5.0.2 and 27.0.1.0.2, Oracle GraalVM for JDK 17.0.21.0.2 and 21.0.13.0.2, and Oracle GraalVM Enterprise Edition 21.3.20.0.2. Oracle says to update to the latest Java version or apply the recommended mitigations; the alert does not list fixed build numbers. (source: Oracle Security Alert Advisory - CVE-2026-114820)
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.
Onamae.com — Desktop Cloud unauthorised access notice (Japanese, 21 Oct 2026, as of 4:00 JST)
