Latest cyber news, threats, security, and guidelines. Stack up.

Incidents

Fri 16 Oct

Hack of Russia's education watchdog Rosobrnadzor and its assessment institute FIOKO showed anti-Putin messages to students mid-test and halted nationwide school assessments on 16 October; pro-Ukrainian group Black Spark claims it

Russia's federal education supervisor Rosobrnadzor said on 19 October 2026 that it had restored its online systems after a cyberattack on its resources and those of the Federal Institute for Education Quality Assessment (FIOKO), its subordinate body that runs national education-quality testing. During the attack on Friday 16 October, students answering questionnaires on the Edutest assessment platform were shown messages urging them to join an underground movement against President Vladimir Putin instead of the next question, and assessments at schools and vocational colleges across the country were suspended. The disruption hit a major stage of the programme, which runs from 12 to 29 October, when 9th-grade students in 29 regions were due to sit questionnaires; the results rate institutions, not individual students. A pro-Ukrainian group calling itself Black Spark claimed responsibility on Telegram and denied trying to recruit minors. Rosobrnadzor has not said how the attackers got in or whether any data was taken. Primary: Rosobrnadzor statement (MAX channel); wire: The Record (20 Oct).

Rosobrnadzor — statement on restoration of online resources after the attack (MAX channel, 19 Oct 2026; Russian)

breaches

Incidents

Fri 16 Oct

Nikkei (Japanese media group, owner of the Financial Times) says stolen credentials were used on 7 Oct to get into a cloud service it uses for system development, leaking about 1.83 million personal-information items, about 150,000 of them with names, emails, addresses, phone numbers or birth dates; its third disclosed incident in about a month

Nikkei Inc. said on 16 October 2026 that a cloud service it uses for system development was accessed without authorisation and that, as of 16 October, about 1.83 million items of personal information had leaked. About 150,000 items contained at least one of name, email address, postal address, phone number or date of birth, and about 120,000 of those included an email address. The other roughly 1.68 million items held only identifiers that cannot identify a person on their own. No credit card information was involved. Nikkei says the credentials used were stolen by unknown means, the access took place from the early hours to the morning of 7 October, and personal information stored in the cloud was taken. It has disabled the credentials, reported the incident to Japan's Personal Information Protection Commission on 11 October, and will contact each person whose information is confirmed to have leaked. As of 16 October it had found no misuse of the data, no system outages and no data tampering. Nikkei has not named the cloud service or an attacker. This is a separate incident from the hijacked Microsoft 365 account that sent about 9,000 phishing emails on 30 September and the earlier Google Workspace account compromise, both covered on this desk (/n/nikkei-m365-email-phish-breach-20261004); Nikkei has not said whether they are connected. Primary: Nikkei Inc. notice (English and Japanese, 16 Oct); wire: BleepingComputer (19 Oct).

Nikkei Inc. — Personal Information Leak Due to Unauthorized Access (16 Oct 2026)

breaches cloud identity

AI

Fri 16 Oct

Anthropic says a Claude research model explained where the NIST P-curve seeds came from in under half an hour: 1997–98 Unix timestamps fed to the C library's 48-bit rand48 generator, not a hashed phrase; Filippo Valsorda confirms and pays the bounty

Anthropic published research on 16 October 2026 saying an internal Claude research model worked out, in under half an hour, how the unexplained 'seed' values behind the NIST elliptic curves P-192, P-224, P-256, P-384 and P-521 were produced. The seeds, supplied by the NSA and published in FIPS 186-2 in 2000 without explanation, have long fuelled suspicion that the curves could have been chosen with a hidden weakness. According to Anthropic, they were not hashes of a forgotten phrase, as the long-told story went, but successive 20-byte outputs of the POSIX 48-bit rand48 pseudorandom generator seeded with the then-current Unix time. Each prime-curve run dates to between May 1997 and April 1998; for example P-256 is the 1,842nd candidate from a run seeded at 01:52:34 UTC on 16 August 1997. Claude spotted a statistical fingerprint in the top bits of some seeds, recovered the generator state with LLL lattice reduction, and stepped it back to a timestamp; the same method explained five ANSI X9.62 example-curve seeds and, if the clock was halved, four binary-curve seeds. It also traced the base points of P-192 and five X9.62 curves to the FreeLIP library's generator. Filippo Valsorda, who ran the NIST Elliptic Curves Seeds Bounty, re-implemented the method in Go, confirmed it (he describes the drand48 variant of the same generator family) and says the Anthropic team claimed the bounty on 15 October; the US$36,864 is being donated to ISRG, which runs Let's Encrypt. He argues the finding rules out the 2017 Bernstein–Lange idea of using seed freedom to aim at a hidden class of weak curves, since the generation leaves roughly 30 bits of choice at most. Still unexplained: why some valid candidates were skipped (P-256's own run produced a usable curve at candidate 876), the B-163 seed, and the base points of P-224, P-256, P-384 and P-521. Anthropic and Valsorda both say this is not a break or weakness in the curves and nothing needs to change. Primary: Anthropic (16 Oct); confirmation: Filippo Valsorda (16 Oct).

Anthropic — Claude reveals ECDSA curve origins (16 Oct 2026)

ai

Vulnerabilities

Fri 16 Oct

Updated Tue 20 Oct

Rank Math SEO PRO 3.0.123 supply-chain compromise (CVE-2026-111862, CVSS 9.8): some copies downloaded 15–16 Oct carried a self-rebuilding WordPress backdoor — install clean 3.0.124 and treat activated sites as compromised

Rank Math, maker of the widely used Rank Math SEO plugin for WordPress, published a security incident notice on 16 October 2026 (UTC) saying that some copies of its paid Rank Math PRO plugin, version 3.0.123, contained malware. Only packages downloaded, or installed through an update, between 20:02 UTC on 15 October and 07:12 UTC on 16 October 2026 are affected (about 4:02 am to 3:12 pm on 16 October in Perth). Having version 3.0.123 does not by itself mean a site was compromised. Rank Math removed the affected files and released a clean version, 3.0.124. Wordfence assigned CVE-2026-111862 and rated it CVSS 9.8; Patchstack lists it as a backdoor, published 17 October. If the plugin was activated, the malicious code could set up persistent access and rebuild a hidden backdoor whenever someone visited the site, so deactivating the plugin is not enough. Rank Math warns that WordPress passwords, database credentials, API keys and other secrets the web server can read should be treated as exposed. Indicators from the notice: outbound connections to rank1cdn[.]com; wp_options entries named _uf6qdn2hmm, t8krdk990phb or _np5pvf754c; administrator accounts whose usernames start with wpsupport_ or that use @wp-mail[.]net email addresses; PHP files in the inc/, includes/ or lib/ folders of non-default themes containing base64_decode with XOR loops, the key xmmqhn, proc_open or PHP-FPM socket code; a fake WordPress core file; .htaccess rules that make .cache files run as PHP; and a web-server-user crontab entry tagged #ms6v46. Rank Math has not said how its distribution was tampered with or how many sites received the affected package. The free Rank Math SEO plugin on WordPress.org is not named in the notice. UPDATE (19 Oct, BleepingComputer): BleepingComputer found a PHP malware sample on VirusTotal, named 'cache-preloader-fff033 (1).php', that carries the same indicators as Rank Math's notice, including code that creates administrator accounts with the wpsupport_ prefix and @wp-mail[.]net addresses. It appears to be a first-stage script that drops the wp-includes/class-wp-cache-util.php backdoor named in the advisory, and it can also run commands, change the WordPress database and steal AWS, Cloudflare, Google Cloud and Azure credentials and SSH keys. BleepingComputer could not confirm that this file was delivered through the compromised plugin. Rank Math has not answered questions about how many sites were affected or how the attackers got in.

Rank Math — PRO 3.0.123 security incident: how to secure your website (16 Oct 2026, updated 17 Oct)

vulnerabilities

Incidents

Fri 16 Oct

Updated Sun 25 Oct

ConnectWise Cloud Backup (formerly SkyKick) app credential stolen and used to pull Microsoft Graph tokens in customer M365 tenants — Huntress now sees sign-ins at almost 1,000 tenants (300+ successful); ConnectWise disables seven of its app identities, suspends Cloud Backup and takes SaaS Security and Cloud Management offline; ConnectWise says a China state-aligned group appears responsible, and Microsoft assesses China-state aligned Storm-0940, using the ARTEX agentic AI framework, was behind it

ConnectWise says it found unauthorised access to application identities in its Cloud Backup environment (the Microsoft 365 and Google Workspace backup service for MSPs, formerly SkyKick). Its Trust Center advisory, first posted 16 October 2026 and updated 17 October 05:01 UTC, says it has shut off Cloud Backup application access as a protective step, which interrupts backups until further notice; it has no indication so far that partner backup data was compromised and the existing backup archive is not affected. Huntress, which found the activity, says the app's Microsoft 365 credential (API secret) is in an attacker's hands: on 15 October between 06:13 and 08:34 UTC it was used from 144.172.64[.]128, a hosting-provider address, to obtain Microsoft Graph tokens in customer tenants, moving through tenants in sorted order a few seconds apart, which points to a script. As of 19:00 UTC on 16 October Huntress had confirmed unauthorised sign-ins in 162 tenants, and says the credential works in every tenant where the app is consented, so any organisation with it installed is exposed. The app's consent covers mail and attachments, OneDrive and SharePoint files, Teams chats and directory data, and some directory reads leave no audit trail. Huntress also saw the same IP password-spraying four law-firm tenants on 13 and 14 October, and in one tenant a ConnectWise Cloud Management app for Teams added itself to Global Administrator and added new secrets to an MSP management app and Huntress's own app; it has not tied that earlier activity to the same operator. Todyl separately reported the same Graph sign-ins and notes that revoking user sessions does not end app access. No country breakdown has been published. Primary: ConnectWise Trust Center advisory; research: Huntress (16 Oct); wire: The Hacker News (18 Oct). UPDATE 17 October (ConnectWise, 17:00 UTC): ConnectWise says it suspended the Cloud Backup service by revoking the certificates used for the affected application connections for all users, so the shared credentials previously used for Cloud Backup are no longer valid. It has brought in an outside incident response firm, has not seen successful threat activity in the environments it monitors since the mitigations, and has no evidence that the encrypted backup archives were accessed; archives are preserved but backup and restore remain unavailable until service is restored. ConnectWise says Cloud Backup gives it no visibility into partner and customer tenants, so it cannot tell whether a given Microsoft 365 tenant saw unauthorised activity; partners must check their own. UPDATE 17 October (Huntress, 21:15 UTC): Huntress now counts almost 1,000 Entra tenants with sign-in activity from 144.172.64[.]128, more than 300 of them successful, although tenants without the app's service principal could not be accessed. It also found a second, targeted wave on 15 October against 16 tenants in the policy, national security, trade and critical-minerals sectors, most of which do not use ConnectWise products; an automated sweep for Graph tokens (09:25 to 12:35 UTC) was followed by what looked like a manual sweep (13:54 to 14:20 UTC) aimed at Exchange Online, SharePoint Online, Teams, Azure Resource Manager, Entra and the Office 365 Management APIs, and failed where the app was not present. The credential added to a Huntress application in one tenant came from private Azure IPv6 space rather than the earlier IP. Huntress has received unverified outside reports of similar, apparently hands-on activity in other tenants. UPDATE 18 October (ConnectWise, 01:00 UTC): ConnectWise says it first identified the issue on 14 October and at 07:00 UTC on 17 October disabled seven of its application identities: ConnectWise Cloud Backup (506e08f9-6e9a-4da4-942b-a099a03644ae) and six ConnectWise Cloud Management apps, the base app (2399d300-6fca-4e6a-a686-399fefe75b83) plus MS Teams (24205314-2b89-4e07-a2a4-579e898a5640), Exchange Online (b78f6a77-d4e5-46fb-87e5-d1648bd02519), MS Graph (0de14c77-b9b0-4137-9360-34878a929827), Partner Center (412dcf96-176d-4b3a-a1b0-4981ad66971e) and SharePoint Online (b2b55f5b-7758-4719-8d8f-88ae172e6bdb). It stresses that disabling them stops new sign-ins through those connections but does not undo changes already made inside a tenant, that previously issued access tokens may stay usable until they expire, and that any credentials, roles or consents an attacker added through other identities need separate clean-up. As a further precaution it has taken SaaS Security (monitoring and alerting) and Cloud Management (user and licence management) offline; Cloud Backup stays suspended with no restoration time, scheduled backups are not running and archives cannot be restored, though ConnectWise says they remain encrypted and it has no evidence they were accessed. It has engaged an outside forensics firm and says it has not yet established whether a product vulnerability was involved; how the credential was exposed is still under investigation. Huntress told The Hacker News it last saw malicious sign-ins from the original IP at 08:45 UTC on 15 October, with targeted manual activity until about 14:20 UTC, and has confirmed abuse of the Cloud Management Teams app in one tenant. UPDATE 18 October (ConnectWise, 18:45 UTC; 19 Oct 02:45 Perth): ConnectWise lists two further attacker IP addresses, 144.172.64[.]99 and 144.172.64[.]60, shared through downstream monitoring of partner and customer environments, alongside the original 144.172.64[.]128, and asks partners to include all three when reviewing Microsoft 365 sign-in and audit logs. Its 16:00 UTC update reported no new confirmed findings; Cloud Backup, SaaS Security and Cloud Management stay suspended, archives remain encrypted and isolated with no sign of compromise, and ConnectWise says that finding does not establish whether individual live tenants were affected. iTnews (19 Oct) reports that the rogue secrets added to the MSP management app and Huntress's app in the one tenant were both set to remain valid until 2028, which would have allowed a return after ConnectWise's own credential was cancelled; Huntress says it found and removed the credential on its app on 16 October. UPDATE 19 October (ConnectWise, 13:45 UTC; 21:45 Perth): ConnectWise says it has not seen successful threat activity in the environments it monitors since 17 October 05:00 UTC (1:00 pm Perth), with containment measures still in place. Cloud Backup, SaaS Security and Cloud Management remain suspended, scheduled backups, archive access and restores are still unavailable, and there is no confirmed restoration time; it will publish a timeline and any reconnection instructions once confirmed. It asks partners who serve customers through a reseller, distributor or marketplace to make sure the administrator of each customer tenant receives and acts on its remediation guidance. UPDATE 19 October (Huntress, 1:30 pm ET / 17:30 UTC; 1:30 am Perth 20 Oct): reviewing application sign-ins across more than 10,000 tenants with ConnectWise apps where it can see logs, Huntress says only 144.172.64[.]128 and Microsoft-internal ranges produced application sign-ins. The other circulating addresses in the same provider range (AS14956, RouterHosting) showed only failed user logins or password spraying, which Huntress does not currently link to the app sign-ins: 144.172.64[.]99 (concentrated spray, 10–14 Oct), 144.172.64[.]60 (a few failed logins, 18 Oct) and 144.172.94[.]243 (broad, ongoing spray against many organisations). Huntress has found a second tenant with post-compromise activity. In both tenants the actions ran within two minutes of each other at about 03:45 UTC on 15 October (11:45 am Perth): the ConnectWise application granted itself Global Administrator, then planted new secrets on a few other applications registered in the tenant, apparently chosen at random and often low-privilege ones, to keep a foothold. Huntress found no mailbox or file tampering or user or policy changes in those two tenants, but notes Microsoft Graph directory reads leave no audit record. The last confirmed successful sign-in with the stolen credential was at 08:44 UTC on 15 October (4:44 pm Perth); since then it has seen only failed attempts. UPDATE 19 October (ConnectWise, 18:50 UTC; 2:50 am Perth 20 Oct): containment remains in place with no successful threat activity seen since 17 October 05:00 UTC; ConnectWise says it is monitoring its entire environment and sees no indication of impact beyond Cloud Backup and the precautionary suspensions of SaaS Security and Cloud Management, all three of which remain suspended with no restoration time yet. It has published a video walkthrough of its Cloud Backup technical investigation and remediation guide, and repeats that affected applications must stay disabled until it issues formal restoration instructions. UPDATE 20 October (ConnectWise, 00:45 UTC; 8:45 am Perth): ConnectWise says it has strengthened administrative-access protections and is resetting accounts and replacing application credentials in the affected environment, with third-party forensics still validating remediation; existing Cloud Backup archives remain encrypted, isolated and preserved with no indication they were compromised, though it stresses this does not show whether live Microsoft 365 tenants were affected, so each tenant still needs review. Services will come back in controlled phases, with partner instructions issued before anything is re-enabled; no restoration time yet, and the next update is due by 13:00 UTC on 20 October (9:00 pm Perth). UPDATE 20 October (ConnectWise, 13:01 UTC and 19:05 UTC; 9:01 pm 20 Oct and 3:05 am 21 Oct Perth): ConnectWise says it completed a full reset of all accounts and credentials in the affected Cloud Backup environment on 19 October and is finishing security validation before restoring services in controlled phases, core infrastructure first, with extra review of the most sensitive connections. Once restoration starts it expects it to take several days; it will give a firmer timeline after the first full day of restoration work and will issue instructions before partners need to re-enable connections. Cloud Backup, SaaS Security and Cloud Management stay suspended, so scheduled backups, archive access, restores, SaaS Security alerting and Cloud Management user and licence management are still unavailable. It is still working with outside specialists to find how the access first happened and its full scope, sees no impact on other ConnectWise products, and has started partner technical webinars every two hours from 18:00 UTC on 20 October (2:00 am Perth 21 Oct) walking through Entra ID sign-in and audit logs, app registrations, credentials and permissions, including legacy backup integrations. UPDATE 21 October (ConnectWise status page, 14:35 UTC; 10:35 pm Perth): ConnectWise says it has begun restoring services in controlled phases after remediation and security validation, with each restoration step subject to security review, and expects restoration to take several days; it says service will return in stages and the start of restoration does not mean all capabilities are available. It will publish step-by-step instructions on when and how partners should reconnect affected services, including any reauthorisation and verification steps, and says partners should keep affected application connections disabled until then. Its investigation continues alongside restoration; existing backup archives remain encrypted, isolated and preserved with no indication of compromise, which it says does not establish whether individual partner or customer Microsoft 365 environments were affected, and it sees no indication that other ConnectWise products are impacted. Next update due by 19:00 UTC on 21 October (3:00 am Perth 22 Oct). UPDATE 22 October (ConnectWise status page, 00:52 UTC; 8:52 am Perth): ConnectWise says phased restoration is underway, with each step subject to security validation, and still expects restoration to take several days; partners should keep affected connections disabled until formal instructions apply to their service. It says existing backup archives remain encrypted, isolated and preserved with no indication of compromise, that it has no indication other ConnectWise products, services or offerings are impacted by this incident, and that individual Microsoft 365 tenants still require review for unauthorised changes or persistent access. ConnectWise says that beginning 22 October it will publish updates twice daily. UPDATE 22 October (attribution): In a Trust Center update at 22:00 UTC on 21 October (6:00 am Perth 22 Oct), ConnectWise says that, based on the evidence available to it, including threat intelligence shared by Microsoft, it appears that a China state-aligned group was responsible for the attack on Cloud Backup, and that the group used an openly available agentic AI framework to automate and speed up its operation; ConnectWise says its containment and phased restoration do not remove unauthorised access that may already have been established within individual customer tenants, which require separate review. In a Microsoft Security Blog post (21 Oct, 18:23 UTC; 2:23 am Perth 22 Oct), Microsoft assesses that Storm-0940, a China-state aligned actor active since 2021, was responsible for the ConnectWise supply chain compromise, and says the actor used ARTEX, an agentic AI penetration testing framework, to accelerate scanning and reconnaissance, password spraying and OAuth application abuse at downstream victims. Microsoft says that following the unauthorised access Storm-0940 used ARTEX to attempt to sign in to more than 2,250 tenants at 2,900 sign-in attempts per minute, and that in some environments the agents progressed to Microsoft Graph and directory operations, including reconnaissance, application credential modifications to establish persistence, and changes involving identities, groups and privileged roles, which Microsoft warns can remain active as a backdoor. Microsoft also says Storm-0940 infrastructure at 144.172.64.99 ran a cross-tenant password-spray campaign against 327 accounts across eight organisations between 10 and 14 October in which no successful authentication was observed, that the presence of an affected application or a successful sign-in does not necessarily mean customer data was accessed or exfiltrated, and that the activity did not result from a compromise of or vulnerability in Microsoft corporate systems, products or services. UPDATE 23 October (ConnectWise status page, 01:11 UTC; 9:11 am Perth): ConnectWise says service restoration work is progressing and it anticipates completing testing and security validation of the restored environment by the end of this weekend, which, subject to successful completion, will let it begin returning capabilities to partners in phases: first a process for partners who need to restore data from existing backups, which it currently anticipates enabling early next week, then phased full-service re-enrolment with step-by-step instructions. Partners should keep affected application connections disabled until ConnectWise provides instructions that apply to their service. ConnectWise says that starting 23 October it will move to once-daily updates. Updated 23 Oct 2026 (ConnectWise Trust Center, 14:00 UTC; 10:00 pm Perth): ConnectWise says its teams and independent specialists are continuing restoration testing and security validation, which it expects to complete by the end of the weekend; it then anticipates enabling a process for partners to restore data from existing backups early next week, followed by phased re-enrolment supported by step-by-step instructions, video tutorials and webinars. Partners should keep affected application connections disabled until ConnectWise gives instructions for their service; existing backup archives remain encrypted, isolated and preserved with no indication of compromise; and ConnectWise will publish updates once daily at 14:00 UTC. (source: ConnectWise) Updated 24 Oct 2026 (ConnectWise Trust Center, 14:00 UTC; 10:00 pm Perth): ConnectWise says services are being brought back online in a controlled sequence, including rotating certificates across its infrastructure, with restoration, testing and security validation continuing through the weekend and a target of beginning phased partner onboarding on Monday 26 October, subject to the required checks. It anticipates enabling backup restoration for partners on Monday, followed by phased re-enrolment, and says bringing infrastructure online does not mean all partner capabilities are available. Existing backup archives "remain encrypted, isolated and preserved, with no indication of compromise", and it has no indication that other ConnectWise products, services or offerings are impacted. (source: ConnectWise) Correction (24 Oct 2026): an earlier version said The Hacker News reported 173 affected tenants on 17 October; The Hacker News's article is dated 18 October and does not give that figure, so it has been removed. (source: The Hacker News)

ConnectWise Trust Center — Cloud Backup (formerly SkyKick) service interruption advisory (16–18 Oct 2026)

breaches cloud identity ai

Vulnerabilities

Fri 16 Oct

Apple iOS 27.0.1: Calif demos an untethered jailbreak with root on iPhone 18 Pro at Hexacon, alongside Signal and iMessage attack demos — bugs not disclosed and no Apple fix yet

Security firm Calif showed a series of iPhone attacks on stage at the Hexacon offensive-security conference in Paris on 16 October 2026. Its newsletter post lists four demos ('Signal 1-click', an iMessage demo, 'Can your iPhone do this?' and 'APT stands for Apple Persistent Threat') and says everything 'will be released in due time'. Stage video posted by jailbreak researcher Billy Ellis, as described by Decrypt, shows an iPhone 18 Pro running iOS 27.0.1 being rebooted, unlocked with its normal passcode, and an SSH session opened as root with about two minutes of uptime, so root access came back on its own after the restart with no computer attached (an untethered jailbreak). heise online reports the chain works on versions up to iOS 27.0.1, Apple's latest public release, and that AI helped find it. Calif has not named the vulnerabilities, released a tool or published a write-up; there are no CVE IDs, Apple has not commented and no fix has shipped. No exploitation outside the demo has been reported. Primary: Calif newsletter (16 Oct); context: heise online and Decrypt.

Calif — iPhone: demos revealed at Hexacon Paris (16 Oct 2026)

vulnerabilities

Vulnerabilities

Fri 16 Oct

Pion DTLS (Go): six advisories including two critical (CVSS 9.1) client-authentication bypass and peer-impersonation flaws found by Anthropic's OSS Scanner — upgrade to v3.1.14; v2 has no fixed release

The maintainers of Pion DTLS, the Go DTLS library used by the pion/webrtc stack and many Go real-time and IoT services, published six GitHub security advisories on 16 October 2026, all credited to Anthropic's OSS Scanner. GHSA-7c2r-jhm9-43vf (critical, CVSS 3.1 9.1) lets an attacker who can redirect a DTLS handshake and has the peer's public certificate impersonate that peer without its private key, because the library chose the verification primitive from the certificate's key type but took the digest from the attacker-controlled signature scheme; the maintainers note that checking the WebRTC SDP certificate fingerprint does not stop it, since the genuine certificate is presented. GHSA-hhpj-h56m-9f2p (critical, 9.1) lets an unauthenticated client skip required client-certificate checks by resuming a DTLS 1.2 session the server cached before the original handshake finished. GHSA-cqhp-ggp7-58qj (high, 7.4) is a similar bypass when an application shares one session store between its outbound connections and its listener. The other three are denial-of-service bugs: an unbounded handshake cache (memory exhaustion), oversized peer RSA keys (CPU exhaustion), and repeated client-certificate verification while the server waits for the client's Finished message. The maintainers say the two session-resumption bypasses do not affect pion/webrtc users, but the impersonation flaw and the DoS bugs can reach WebRTC applications acting as the DTLS server. No CVE IDs were listed at publication and no exploitation is reported. Fixes shipped in v3.1.13 (16 Oct) and v3.1.14 (16 Oct, the session-store fixes); the advisories list no patched v2 release. Primary: Pion DTLS GitHub security advisories; context: maintainer post on Hacker News (16 Oct).

Pion DTLS — GHSA-7c2r-jhm9-43vf: handshake signature scheme confusion allows peer impersonation (16 Oct 2026)

vulnerabilities network

Vulnerabilities

Fri 16 Oct

Broadcom Wi-Fi WPS EAP reassembly overflow: over-the-air unauthenticated code execution on Broadcom-based ISP gateways, present in the SDK since 2010 and still no CVE

Researcher Quentin Kaiser disclosed on 16 October 2026, at Hexacon in Paris and in a long write-up, a memory-corruption flaw in Broadcom's proprietary 802.11 Wi-Fi stack: an overflow in the reassembly of WPS EAP messages that can be triggered remotely over Wi-Fi without the network key or a completed WPS enrollment, giving controlled information disclosure and arbitrary code execution. He says the bug has been in Broadcom's SDK since at least 2010; Broadcom silently shipped an incomplete patch in 2018 and then advised OEMs to move to hostapd, leaving it a lasting 'forever day' on eCos-based chips (BCM3380, BCM3383, BCM33834) and a potential one on Linux-based chips (BCM3390, BCM65xx, BCM68xx) on any device that was never migrated. Broadcom declined to assign a CVE or publish an advisory, which Kaiser says is why so many OEMs never patched; he reported it under a 90-day timeline that expired on 16 October. He demonstrated working over-the-air exploitation against gateways from three of four Belgian ISPs (Proximus BBOX 3/3V+ Sagemcom F@st, VOO Netgear CG3100/CG3700 and Technicolor/Commscope models, Orange Belgium ASKEY TCG3000), showing a root shell and extraction of the Wi-Fi PSK from NVRAM, and says that as of 15 October none of the demonstrated devices were patched. The same Broadcom silicon ships worldwide in cable and DSL gateways from many vendors, so the blast radius extends well beyond Belgium; Kaiser released a fingerprinting script and a YARA rule to help map affected models. There is no indication of in-the-wild exploitation, and no Australian ISP or device has been named. Primary: Quentin Kaiser research (16 Oct); context: Hexacon 2026 talk.

Quentin Kaiser — One Parser, Two Bugs, Many Routers: exploiting Broadcom Wi-Fi across eCos and Linux (16 Oct 2026)

vulnerabilities network

AI

Fri 16 Oct

Microsoft and NVIDIA publish 'Risk Management for Open-Weight Models in Enterprise': a shared five-category risk taxonomy mapped to evaluations, arguing that weight openness alone does not decide an AI system's risk

Microsoft and NVIDIA published a joint paper, Risk Management for Open-Weight Models in Enterprise, on 16 October 2026, the first in a planned series of joint resources. Its core argument is that whether a model's weights are open does not by itself set an AI system's risk: risk depends on the model, the use case, the deployment and the safeguards around it. A model drafting internal documents carries different risk from the same model in a customer-facing workflow or connected to external data and tools, and the best control may sit in the inference environment or application rather than the model. The paper offers a shared taxonomy with five risk categories (cybersecurity, data protection, content, human-AI interaction, and bias), grounded in ISO standards and the NIST AI Risk Management Framework, and maps evaluations to selected risks so teams can produce evidence for the risks that matter in their deployment. Microsoft stresses the taxonomy is not a policy or deployment checklist. The paper also notes that organisations running their own open-weight deployments may take on safeguards that a managed service would otherwise provide. This first paper covers mainly the model layer; Microsoft says evaluating a model alone does not establish that an agent or application is safe, and later papers are meant to cover the runtime, harness and application layers. A companion GitHub repository in NVIDIA's organisation, co-maintained by both companies, will collect further evaluations, including community contributions. Primary: Microsoft Security blog; paper and repository: NVIDIA GitHub.

Microsoft Security blog — Managing open-weight model risk in enterprise deployments (16 Oct 2026)

ai

Incidents

Fri 16 Oct

Updated Fri 23 Oct

Canva: some enterprise customers' contact and contract details exposed through feedback vendor Canny's link to Canva's Salesforce (Canva confirmed 21 Sep); Canva repeated this on 19 Oct after a leak-site listing

Canny, a customer-feedback platform used by Sydney-based Canva, told Canva on 29 August 2026 that it was investigating unauthorised access to its systems. Canny was connected to Canva's Salesforce account, so the intruder reached limited information about some Canva enterprise customers, mainly larger customers handled by Canva's sales team. A Canva spokesperson told Capital Brief (21 September) that the exposed data included business contact details and contract information, that Canva immediately removed Canny's access and notified affected customers, and that Canva's own platform was not compromised and Canva accounts, passwords, designs and content were not accessed. Other Canny customers have published their own notices. VRChat (18 September) said Canny told it on 28 August that an unauthorised party had accessed one of Canny's internal systems, and that Canny's investigation with an outside forensics firm found no further unauthorised activity after 28 August. Anaconda (12 October) said it rotated all credentials and integrations connected to Canny and has stopped using it. A group calling itself The Seven Deadly Sins has claimed the attack; Canva has not confirmed the group's claims. The case shows how a SaaS-to-SaaS integration token can carry a vendor breach into a customer's CRM. Primary: Canva statement via Capital Brief; vendor-side notices: VRChat, Anaconda. UPDATE 19 October 2026 (Cyber Daily): Canva gave a fresh statement after the leak-site listing, saying unauthorised access to Canny reached 'some enterprise customer records' through its Salesforce connection, including business contact details and routine business documentation; that it removed Canny's access, informed affected customers where required, complied with its obligations and worked with relevant agencies; and that Canva's own platform, accounts, passwords, designs and content were not affected. Correction (23 Oct 2026): removed The Seven Deadly Sins' own claims about record counts, data types, time inside Canva's systems and a sale; Canva has confirmed only that some enterprise customer records were exposed through Canny. (source: https://www.cyberdaily.au/security/14317-exclusive-aussie-software-giant-canva-confirms-third-party-data-incident)

Capital Brief — Canva enterprise customer data exposed in third-party breach (Canva statement, 21 Sep 2026)

australia cloud

Vulnerabilities

Fri 16 Oct

OpenBSD 7.9: Calif publishes a working local-root exploit chaining a 37-year-old shared-memory counter overflow with a kernel use-after-free — fixed in errata 018 and 026 (syspatch)

Security firm Calif published research and full exploit code on 16 October 2026 showing local privilege escalation to root on OpenBSD 7.9 with KARL kernel relinking, SMAP and SMEP enabled, and without any information-leak bug. The chain starts with shm_nattch, the System V shared-memory attach counter, which has been a signed 16-bit short since the original 1988 BSD sources: mapping 127 segments and forking 259 processes wraps it to -32,643, and a race then frees kernel memory other processes still use. A separate out-of-bounds write corrupts multicast-membership counters so that later decrements alter page-table entries, making a user mapping supervisor-accessible; the exploit then overwrites a function pointer that sits at a predictable kernel address because OpenBSD's boot-time and best-fit allocators are not randomised. OpenBSD fixed the integer overflow in errata 018 on 14 September 2026, labelled a reliability fix, and the reference-counting use-after-free in errata 026 on 30 September, labelled a security fix; both apply to all architectures through syspatch, and OpenBSD 7.8 also received the overflow fix. No CVE has been assigned and there is no report of use in attacks. Calif also proposes kernel hardening such as safe unlinking for linked lists and allocator randomisation. Primary: OpenBSD 7.9 errata; research: Calif (16 Oct); wire: The Hacker News.

OpenBSD — 7.9 errata (018 shmat integer overflow, 14 Sep 2026; 026 kernel use-after-free, 30 Sep 2026)

vulnerabilities network

Vulnerabilities

Fri 16 Oct

Apache Kylin 5.0.5 fixes five flaws including an unauthenticated SQL injection in a backend cache API (CVE-2026-64959, rated critical by Apache) — upgrade from 4.x–5.0.4

The Apache Kylin project published five CVE records on 16 October 2026 for the open-source OLAP analytics engine, all fixed in Kylin 5.0.5. CVE-2026-64959, which Apache rates critical, is a backend cache API that is missing authentication and can execute injected SQL (Kylin 5.0 to 5.0.4). The others, affecting Kylin 4 through 5.0.4, are CVE-2026-68571, code injection through a special parameter in a JDBC URL (moderate); CVE-2026-64610, unsafe Java deserialisation from a broken external cache service (moderate); CVE-2026-63619, a metadata dump API without enough authorisation or path confinement (moderate); and CVE-2026-63618, exposure of system configuration information (important; CISA's enrichment scores it CVSS 3.1 7.5). Apache says the impact falls mostly on Kylin services exposed directly to the internet, which it describes as uncommon, and that in-house deployments are mostly unaffected. No exploitation is reported. Primary: Apache Kylin advisories on the Apache security mailing list (16 Oct 2026).

Apache Kylin — CVE-2026-64959 advisory (Apache mailing list, 16 Oct 2026)

tech cloud