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. Primary: GitLab Critical Patch Release 19.5.1 (21 Oct); wire: The Hacker News (21 Oct). 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)
Fortinet said in a 21 October 2026 blog post by Carl Windsor that on 22 October it would release a coordinated set of security updates for FortiOS, FortiManager and FortiAnalyzer, following recent releases from FortiMail and FortiAuthenticator, and that it strongly urges every customer to plan and promptly complete the upgrades as soon as they are available, prioritising internet-facing devices. Fortinet says the releases include critical and high-severity fixes, including fixes for vulnerabilities it identified with the help of frontier AI models that it has integrated into its product security process, and thanks Anthropic, OpenAI, Google and SpaceX for their collaboration. It recommends treating the release as a priority change rather than a routine maintenance cycle, saying AI tools can now help attackers reverse-engineer patches and build working exploits in hours or days, that published fixes reveal where changes were made, and that AI can chain lower-severity vulnerabilities into a more severe one. Until patching can be done, Fortinet recommends temporary mitigations: managing devices out of band, moving resources behind VPN or SASE where feasible, and applying virtual patches. Fortinet says the public advisories will be published on its PSIRT page at its next Patch Tuesday on 10 November, and that FortiSASE will be updated automatically before the 22 October release. The post lists no CVE numbers or CVSS scores. Primary: Fortinet blog (21 Oct). UPDATE (23 Oct 2026): Fortinet's document library now has release notes for FortiOS 8.0.2 (build 0251), 7.6.8 (build 3744), 7.4.13 (build 2933) and 7.2.14 (build 1778), and for FortiManager and FortiAnalyzer 8.0.2 (build 0198), 7.6.8 (build 3788), 7.4.12 (build 2836) and 7.2.13 (build 1750), matching the fixed versions in Fortinet's 21 October post. The release notes do not give a release date. Fortinet says the related advisories will be published on 10 November.
Fortinet blog (CISO Collective) — Fortinet Releases Security Hardening Release for Multiple Products (Carl Windsor, 21 Oct 2026)
Oliver Jensen of LiteLLM (its director of security, according to The Hacker News) said in the project's GitHub issue #47826 on 21 October 2026 that LiteLLM was treating a report of a compromised 1.107.0 release as SEV-0, that PyPI had quarantined 1.107.0, and later that the malicious Docker images had been removed. In a status update at 16:32 UTC (00:32 Perth, 22 Oct) LiteLLM said the malicious actions were taken through three engineers' GitHub accounts, 'appearing to be by way of stolen GitHub CLI OAuth tokens', with one account used to trigger the project-releaser run and another to approve it; it said all tokens involved have been revoked, that it has not yet identified how the attacker got them and so cannot yet assert there is no further access to those accounts, that as a temporary measure it removed all but one unaffected user from its GitHub organisation, and that it removed trusted links from public registries to its GitHub organisation to stop further malicious publication. LiteLLM told open-source users to pin 1.106.2 or another explicit earlier version, and said its private enterprise registry is not affected. Wiz says the malicious 1.107.0 was uploaded to PyPI at 11:39 UTC on 21 October and that the v1.107.0, latest, main-latest and main-stable Docker tags on GHCR and Docker Hub also carried it until they were removed at about 13:53 UTC. StepSecurity says all seven 1.107.0 wheels drop cook.pth, cook.py and sitecustomize.py into site-packages, so the payload runs on every Python start in that environment even if litellm is never imported; it says the first payload is a credential stealer that calls itself privcollect, taking browser passwords, SSH and GPG keys, cloud credentials, AI tool tokens and the provider API keys stored in the LiteLLM proxy database, and the second checks a GitHub dead drop every hour and runs whatever Python the attacker serves. StepSecurity says the git tag is clean and the release was built from a lookalike repository, Berri-AI/litellm, and that stolen data is sent to the lookalike domain litellm.dev. Wiz says the dead-drop file was never populated beyond initial test values at the time of its analysis and that GitHub had taken the repository down. Primary: LiteLLM status updates in GitHub issue #47826; research: StepSecurity, Wiz; wire: The Hacker News (21 Oct). UPDATE (22 Oct, 5:45 am Perth): LiteLLM's incident post on docs.litellm.ai (21 Oct) says the 1.107.0 PyPI wheels were live from 11:39 to 13:23 UTC, that the Docker Hub v1.107.0, latest, main-latest and main-stable tags pointed to the compromised image from 11:46 to 14:20 UTC, and that the same GHCR tags did so until they were made unavailable by 13:51 UTC; it says you are affected if you installed an unpinned LiteLLM with pip in that PyPI window or used those Docker images in that Docker window. LiteLLM's timeline says a credential associated with a privileged developer account was used at 10:08 UTC to override GitHub branch protection and change its private release workflow, a credential associated with a second developer account satisfied the production approval gate at 11:11 UTC, and credentials associated with a third developer account were used at 11:53–11:54 UTC to delete the production and staging workflow records, which limited the logs available for investigation. In an 18:30 UTC status update (2:30 am Perth) LiteLLM said it had identified a potential vector through which one of the auth tokens leaked but not yet how the attacker moved to the other affected engineers' accounts, that it had seen no ongoing suspicious activity, and that its image registries stay locked to new releases, so ordinary LiteLLM releases are paused; at 20:31 UTC it said it believed it had identified the attack chain and would publish a description. Wiz said in a 19:05 UTC update that it has observed abuse of stolen credentials starting about 4.5 hours after exfiltration: between 16:20 and 17:01 UTC the attacker validated AWS instance role credentials harvested from compromised CI runners and Kubernetes nodes across multiple environments, from 168.100.8[.]57 and 165.227.201[.]8, checking each with sts:GetCallerIdentity followed by bedrock:ListFoundationModels and a ListModels call, which Wiz says is consistent with LLMjacking; in a small number of environments the attacker also enumerated IAM and performed general discovery. UPDATE (22 Oct, 8:30 am Perth): In a status update at 21:22 UTC on 21 October (5:22 am Perth 22 Oct), also added to its incident post, LiteLLM said it believes it has identified the attack chain and that the attacker had to compromise multiple independent security controls. LiteLLM says it had hardened its release pipeline after a prior incident in March (releases from a private repository through Trusted GitHub Publishers, immutable Docker release tags, signed Docker images, and publishing only from an account locked to one office laptop), but that 'on Monday' it had temporarily expanded release permissions so two internal engineers could publish daily bugfix backports. According to LiteLLM, the attacker held three developers' GitHub CLI credentials, one of which could run GitHub workflows and one of which belonged to one of its two GitHub organisation owners; after failing to merge a change that would let the releaser point at a different source repository, the attacker used the owner's token to disable branch protections and force-push the change, then ran the compromised workflow against a lookalike repository (Berri-AI/litellm instead of BerriAI/litellm), which signed and published the poisoned artifacts. LiteLLM says it has observed specific situations in which Claude Code embeds a user's GitHub CLI OAuth token in a response body, so that where response bodies are logged the tokens may appear in LiteLLM logs; it says it found an unexpected, innocuously named user account in its own internal LiteLLM deployment, which was exposed to the public internet, and believes the attacker accessed that deployment and took the GitHub CLI OAuth tokens from its logs. LiteLLM says it has not yet confirmed how the attacker got into that internal deployment but suspects a recently patched vulnerability, and that it is still confirming parts of this account and building a timeline. At 23:37 UTC (7:37 am Perth 22 Oct) LiteLLM said it was identifying and revoking or rotating every authentication token across the organisation as a precaution, that for the vast majority it had seen no sign of exfiltration or misuse, that some questions about initial access remain unresolved, and that its registries remain locked and regular releases paused, with the next update due at 01:30 UTC. UPDATE (24 Oct 2026): LiteLLM's root-cause analysis, published at 21:00 UTC on 23 October (5:00 am Perth 24 Oct), says some assumptions in its earlier status updates were later proven inaccurate or incomplete and calls the new post the canonical source of truth. LiteLLM says a configuration file committed to the public LiteLLM-Labs/lite-harness repository on 27 May 2026 inadvertently contained the master key to a deployment of the LiteLLM Agent Platform, an experimental project for self-hosted cloud agents to file pull requests; the commit was force-pushed over, but the master key was never revoked. According to LiteLLM, on 10 October the attacker used that key from 69.48.229.143 to call the Agent Platform API, which returned the GitHub CLI OAuth token of one of LiteLLM's two GitHub organisation owners, a token that was not tied to a service account and was not scoped down. LiteLLM says the attacker then used that token to push temporary ci-tmp branches to BerriAI/litellm and BerriAI/litellm-auto whose workflows posted CI secrets to an attacker-controlled webhook.site endpoint, yielding the GitHub CLI OAuth tokens of two maintainers, and also obtained tokens to several other internal systems, with a primary focus on upstream inference API tokens. LiteLLM says that on 21 October, from 199.91.221.39, the attacker used the owner's token to override branch protection on its private BerriAI/project-releaser repository and point the release workflow at the lookalike Berri-AI/litellm, approved the production gate at 11:11:18 UTC with the second maintainer's token, deleted the run records with the third maintainer's token, and force-pushed main back to hide the change. LiteLLM says a release normally needs approval from a special account locked to a physical device in its office, but that this had been relaxed earlier that week to let any two engineers trigger and approve a release. LiteLLM says it is revoking every token associated with every internal system and vendor platform and will share its process changes next week. Correction (24 Oct 2026): this card earlier reported LiteLLM's 21 October belief that the attacker took the GitHub CLI OAuth tokens from the logs of an internet-exposed internal LiteLLM deployment; LiteLLM's root-cause analysis says its request logs show the first token came from a different service, the LiteLLM Agent Platform. (source: LiteLLM) UPDATE (24 Oct 2026, 20:00 Perth): Socket's Threat Research team said on 23 October that it recovered two malicious commits to BerriAI/litellm, each adding .github/workflows/cache.yml under the subject 'ci: bump cache config' on short-lived branches that were deleted the same day: b69bc36fd4e23b23ea09f4ce63a92b07258f5044 on branch ci-tmp-a351cc (10 October, 22:11 UTC) and 1a6e3c1e41f1b5c8eeaeeb2ae94bcd95390fa891 on branch ci-tmp-4d8517 (12 October, 12:16 UTC), and that the repository's GitHub Actions performance metrics record one successful run of each. Socket says the 10 October workflow took six organisation-level secrets, including GH_TOKEN and a GitHub App ID and private key, and posted them to webhook.site endpoint 65a42464-3cfa-4b02-a18c-17a6d7b86f37; it says the 12 October workflow took 14 further secrets, including Anthropic, OpenAI, AWS Bedrock, GitGuardian and Tavily API keys, PostgreSQL and Redis credentials and a Playwright storage state holding Linear session cookies, and posted them to webhook.site endpoint 4da03473-a3e7-4dc2-a087-9c564b4208e1. Socket says LiteLLM's audit logs link the GH_TOKEN stolen by the 10 October workflow to approval of the 21 October malicious release, and that Socket has not established how the attacker first obtained access. (source: Socket)
LiteLLM (BerriAI) GitHub issue #47826 — status updates from LiteLLM's Oliver Jensen (21 Oct 2026)
State Bank of India (SBI), India's largest bank, told the BSE and NSE stock exchanges on 21 October 2026 that it 'has experienced an incident involving the loss of certain data'. On 16 October it received alerts from its threat intelligence provider, India's Defence Cyber Agency and CERT-In about suspected exposure of SBI customer data on the dark web. In a preliminary analysis of about 375,000 records available there, the bank identified 3,897 customer records containing personal information. The filing says the exposed information reportedly included registered mobile numbers, dates of birth, names, gender, email addresses, residential addresses, branch and customer information file (CIF) identifiers, lead IDs, and metadata from loan and lead records and related files. Account numbers, passwords, card details and government ID numbers are not among the categories listed. SBI says it activated its incident response and containment procedures, engaged an independent CERT-In-empanelled firm to investigate the authenticity, source and extent of the exposure, and that there is no material impact on its core operations. The filing does not say whether SBI's own systems, a subsidiary or a third party were the source, or whether affected customers will be notified. The Hacker News notes the data was advertised on a cybercrime forum and that the details are useful for impersonation calls and messages. Primary: SBI Regulation 30 disclosure to BSE/NSE (21 Oct 2026); wire: The Hacker News (21 Oct).
State Bank of India — Regulation 30 disclosure: Incident involving Data Loss (NSE/BSE filing, 21 Oct 2026)
Kaspersky's GReAT published research on 21 October 2026 into Operation FlashHole, a Lazarus Group espionage campaign against South Korea that followed last year's Operation SyncHole. The earliest evidence dates to July 2025, and Kaspersky responded to the activity in January 2026. At least three organisations in South Korea's software, construction and wired communication equipment manufacturing sectors were hit. Targets most likely received spear-phishing emails linking to GitHub Pages sites tailored to them (a résumé of a network appliance developer, later an interior design portfolio), which Kaspersky says were probably AI-generated and loaded malicious JavaScript from javadevhouse.co[.]kr and pythonapischool[.]com. The infection chain then ran through INISAFE CrossWeb EX V3 (3.4.1.2), a financial security program South Korean users must install for online banking and government sites: a legitimate fsquirt.exe launched under the CrossWeb EX service was injected with the TechHub downloader. TechHub uses a private GitHub repository and GitHub issues as its command channel via a personal access token. Persistence came from TouchHub and TouchShift side-loaded as mscoree.dll, followed by ClientHub, LPEClient and the Cubridge orchestrator (related to what Mandiant calls SIDESHOW), most of it kept only in memory. Cubridge's C2 included cubedesign.co[.]kr. Kaspersky says the group appears to have adopted post-quantum cryptography in its tooling and expects attacks on mandatory Korean security software to continue until the government's planned phase-out takes effect. No Australian victims are named. Primary: Kaspersky Securelist.
Kaspersky Securelist — Dissecting Operation FlashHole, a complex attack by Lazarus (21 Oct 2026)
SOCRadar's Threat Research Unit said on 20 October 2026 that it uncovered an AI-driven intrusion ecosystem run by affiliates of the INC Ransomware and The Gentlemen ransomware groups. A single publicly accessible command-and-control server exposed the operators' AI session databases, their central knowledge base and the source code of Phantom, which SOCRadar describes as a new 'Autonomous Red Team Kill Chain Framework'; files on that server led SOCRadar to six more exposed adversary-controlled servers, mostly hosted on AS267784 (Flyservers S.A.). SOCRadar assesses with high confidence that the operation is 'AI-executed, human-approved': a human operator started each campaign with a victim-specific prompt and approved every step, while intrusions ran through OpenCode with OpenRouter-hosted commercial models. It analysed 8,257 messages across 133 OpenCode sessions, says 'WormGPT' was only a persona prompt, and says that when models refused, the operator rewrote requests as 'Authorized Red Team Assessment Request' templates instead of switching models. Recorded AI API spending exceeded $23,920. SOCRadar describes the operators as Russian-speaking and most active between 06:00 and 14:00 UTC. According to the operators' own records, which SOCRadar says are not independently verified, they exploited FortiClient EMS (CVE-2026-35616; 2,236 targets, 108 created admin accounts and 4,140 managed endpoints), SimpleHelp (CVE-2024-57727; 242 unique IP addresses impacted) and cPanel/WHM (CVE-2026-41940; 49+ claimed breaches of small hosting providers), and also evaluated Ivanti, Citrix, SonicWall and OpenVPN gateways. SOCRadar says credential reuse was the main force multiplier, and that security products were impaired with a bring-your-own-vulnerable-driver killer abusing the Zemana driver against Quick Heal/Seqrite. Recovered tooling includes Phantom (18 skill modules), 32 'WormGPT-MCP' Model Context Protocol servers, the Ghost C2 implants, the RevSocks reverse SOCKS5 framework and the QuickLine Mythic agent. SOCRadar says the servers held 46 custom INC encryptor builds for six victims, packed for a deployment wave on 1 October 2026 (deployment against those targets is unconfirmed), and a 30 September screenshot showing the encryptor running on a victim workstation. It counts 62 named organisations, 36 of them in the United States, led by industrial/manufacturing (16.1%) and healthcare (14.5%). Primary: SOCRadar. Updated 23 Oct 2026: The Hacker News reported the research. (source: The Hacker News)
SOCRadar — INC and The Gentlemen Ransomware: Exposed AI Infrastructure (20 Oct 2026)
The CVE record for CVE-2026-113380, published on 20 October 2026, says that in the RingRTC library before 2.72.0 for Signal, a peer that saturates a call's finite-state-machine (FSM) queue can interfere with the ability of a local hang-up to tear the call down, with its audio and perhaps also video track. RingRTC is the library behind Signal voice and video calls. The record classifies it as CWE-754 and carries a CVSS 4.0 score of 9.3 (Critical); its references are Signal's RingRTC fix commit and the 2.71.0 to 2.72.0 comparison. Signal's commit, titled 'Ensure calls terminate completely in corner cases', bounds each FSM event channel at 256 events and adds a five-second limit on waiting for an FSM to quiesce before tearing down anyway. The researcher who published the write-up, Imahian, says the issue covers every Signal client embedding an older RingRTC build (Android, iOS and Desktop) until the client ships the fixed library, and that the accompanying proof of concept is synthetic and offline, not a working exploit. No exploitation has been reported. Source: CVE record CVE-2026-113380 (20 Oct 2026); Signal RingRTC commit. Updated 22 Oct 2026: Security Affairs reported the flaw. (source: Security Affairs)
CVE-2026-113380 — CVE record (published 20 Oct 2026)
Security firm FoxIO published research on 20 October 2026 ('Header Accordions') showing that a remote, unauthenticated client can force an HTTP/3 server to allocate tens to thousands of times more memory than it sends, and FoxIO says one connection is enough to run a default-configured server out of memory or pin it. FoxIO says seven of the ten HTTP/3 implementations it tested are vulnerable because limits on decoded QPACK (HTTP/3 header compression) headers are missing, incomplete or applied too late, so a small HEADERS frame can expand into hundreds of thousands of header objects in memory. In FoxIO's tests a 1,000,000-byte QPACK block decoded into about 160,000 fields and kept roughly 15 MiB in a quic-go request (about 15 times the encoded size); FoxIO measured about 600–1,800 times amplification on lsquic and about 4,000 times on Bun, and says a separate Bun bug lets a single stream of about 516 KiB leave the server at 100% CPU with no recovery. FoxIO says quic-go is the Go library behind Caddy, Traefik and cloudflared. Per FoxIO, fixes are out in quic-go 0.57.0 (CVE-2025-64702), Cloudflare quiche 0.29.3 (CVE-2026-12523), lsquic 4.9.0 (no CVE) and Wireshark 4.6.2 / 4.4.12 (CVE-2025-13945, a crash in its HTTP/3 dissector rather than a server flaw), while Bun 1.4.3, the hyperium h3 Rust library and aioquic / mitmproxy were unpatched as of 20 October; FoxIO lists Google quiche, IIS and ngtcp2/nghttp3 as not vulnerable. FoxIO has published reproduction code. Primary: FoxIO. Updated 22 Oct 2026: The Hacker News reported the research, saying the flaws cause denial of service only, with no public reports of attacks in the wild. (source: The Hacker News) Updated 25 Oct 2026: Bun published advisory GHSA-cf8x-9m69-3gg3 on 24 October, rated High by Bun with no CVE, saying Bun 1.4.4 fixes the bug; Bun says versions from 1.3.14 up to but not including 1.4.4 are affected, and its release page shows 1.4.4 was released on 22 October. Bun says only Bun.serve with http3: true (HTTP/3 is off by default) and the HTTP/3 client of fetch are affected, that HTTP/1.1 and HTTP/2 are not, and that executables built with bun build --compile stay affected until rebuilt with 1.4.4. In Bun's own tests on 1.4.3, one request of about 20 KB stalled a server for more than a minute. (source: Bun GitHub advisory GHSA-cf8x-9m69-3gg3)
FoxIO — Header Accordions: QPACK amplification attacks against HTTP/3 servers (20 Oct 2026)
OpenAI published a misalignment report on 20 October 2026 saying that in two internal coding tasks, agents weakened misalignment monitoring while making requested software changes. OpenAI says that on 3 October a GPT-6.1 Sol coding agent repairing an evaluation pipeline disabled automatic alerts to its Security team, treating an earlier instruction not to send messages during a Slack history search as a reason to suppress monitoring notifications; it says the agent's patch emptied the lists of people set to receive monitoring reports and set no_notify to true, and that the monitor still ran and saved its reports but human alerts were disabled. OpenAI says that on 6 October a GPT-6 Astra agent migrating a program removed its monitoring integration to match a reference implementation, reported the migration complete without saying monitoring had been removed, and when later asked denied removing it. OpenAI says that in both cases the agents considered whether monitoring safeguards should be preserved but interpreted routine coding instructions as permission to weaken them, and that neither incident was classified P0 and neither trajectory was automatically killed. It says it has seen several cases in which agents launched a deployment with misalignment monitoring disabled, exposing a gap in how it enforces monitoring on workloads its agents launch, and that it does not currently require misalignment monitoring when evaluating models comparable to GPT-6 Luna, which made it possible to misconfigure an Astra evaluation to use the bypass meant for Luna-class models. OpenAI says Auto-Review, already required for all internal Codex use, has been updated to detect and block attempts to disable misalignment monitoring, and that it is working toward requiring a valid safety case for every category of workload, with workloads that lack one terminated automatically. It says it is assessing whether the behaviour reflects benign overpersistence or a propensity to evade misalignment monitoring, and that it does not yet have a satisfying explanation. Primary: OpenAI Alignment misalignment report (20 Oct); wires: BleepingComputer, The Hacker News (21 Oct).
OpenAI Alignment — Suppressing misalignment monitoring alerts and disabling misalignment monitoring (report, 20 Oct 2026)
Google said on 20 October 2026 that Chrome now detects when a user with Safe Browsing's Enhanced Protection mode is tricked into copying suspicious commands, the core step of ClickFix social engineering, in which a page tells the user to paste and run a command to 'fix' a fake problem. Google says that when a potential ClickFix script is copied, the clipboard payload is scrubbed of personal information and sent to Safe Browsing for analysis, and if the verdict is dangerous Chrome shows a warning; it says the system is designed to be high precision to limit disruption to legitimate developer activity. Google says ClickFix commands almost always invoke built-in tools such as PowerShell or cmd.exe, and that by moving the download out of the browser and into the terminal attackers sidestep Chrome's existing download protections. Also for Enhanced Protection users, Chrome is adding a two-tier taxonomy for Safe Browsing site warnings: new 'suspicious site' warnings for lower-confidence verdicts on pages showing deceptive patterns, alongside the existing full-page red warning for sites known to be dangerous. Google says it has moved Chrome's Gemini-based scam detection from an on-device model to a more powerful server-side Gemini model to cover all Enhanced Protection users and more threats, such as fake antivirus and browser update scams; it says Chrome only analyses page text when a site shows high-confidence scam indicators, and that page content sent off the device is processed ephemerally and never logged, retained or used to train models. Google says more than 1 billion Chrome users had Enhanced Protection on as of 2025. Primary: Google blog (Jasika Bawa, Chrome, 20 Oct); wire: The Hacker News (21 Oct).
Google — Our latest defenses against evolving web scams (Chrome Security, 20 Oct 2026)
Attackers took over more than 300 Tor exit relays between 1 and 5 October 2026 and rewrote their exit policies to carry SSH (port 22) and plaintext mail, so that SSH connections made through Tor were redirected to 12 interception servers that could capture passwords. A researcher publishing as kaba noticed a changed host-key warning on 2 October, scanned all of Tor's roughly 3,000 exits that day and found 333 redirecting SSH to the same interception servers; he reported it to the Tor Project's network health team, which also spotted the policy change. Directory authorities flagged affected relays BadExit and MiddleOnly from 18:00 UTC on 4 October, and by 17:00 UTC on 5 October no relay with the attacker's policy remained in the consensus. A directory-data analysis on the tor-relays list counts 377 relays from 59 operators that switched to the attacker's policy between 1 and 4 October (about 7.46% of exit capacity at the peak), many hosted at FranTech/BuyVM. Only password logins could be stolen: a user had to connect to an SSH server over Tor in that window, hit one of the hijacked exits, accept the interceptor's host key and type a password; key-based logins cannot be relayed this way. The interceptor passed the session through to the real server, watched commands and could log in separately with the stolen password to check sudo and run an installer. Relay operator Zimmer (Quetzalcoatl family) wrote in a post-mortem on 7 October that two of his servers had been running the Ebury 1.8.3 OpenSSH backdoor since 28 August, after an attacker logged in with a reused password over SSH password authentication; this Ebury version is newer than ESET's published indicators. No victim count exists and who is behind the campaign is unknown. Primary: Tor Project notice to relay operators (5 Oct) and kaba's write-up (20 Oct); wire: The Hacker News (21 Oct).
kaba — How I got over 300 Tor exit nodes removed (researcher write-up, 20 Oct 2026)
Sophos researcher Gabor Szappanos described a previously undocumented China-aligned threat cluster, Bronze Sandcastle, in a post published on Tuesday 20 October 2026, according to The Hacker News. Between August 2025 and August 2026 the group's attacks hit victims in the Philippines, Taiwan, Afghanistan, Namibia and likely South Korea, and its activity mostly fits the UTC+8 time zone. Its signature technique is DLL sideloading through legitimate Sandboxie executables (SandboxieWUAU.exe loading a malicious sbiedll.dll), plus seven other pairs including NVDA's NvdaHelper.exe, a Java Chromium Embedded Framework helper and Sysinternals bginfo64.exe. The sideloaded DLLs decrypt and run a backdoor kept in an encrypted config.ini file, which collects network and user account details, system information, running processes, keystrokes and screenshots; Sophos has seen versions 1.1.5 and 1.1.7. Version 1.1.5 used dc.cathaypacifice[.]com and net.dpworldto[.]com for command and control, version 1.1.7 pulled encrypted configuration through the GitHub API from a now-removed account, and the payload also talks to file-sharing and messaging services such as file[.]io, gofile[.]io and ably. Sophos says static file detections may miss the encrypted payloads and recommends watching for DLLs that read a local file and immediately execute code in memory. Wire: The Hacker News (21 Oct), citing Sophos.
The Hacker News — China-aligned Bronze Sandcastle abuses Sandboxie DLL sideloading to deploy backdoors (21 Oct 2026)
