Through Microsoft Teams, cybercriminals are impersonating IT support personnel in order to gain access to corporate systems and exploit vulnerabilities in Active Directory Certificate Services (AD CS).
The attacks targeted a maximum-severity vulnerability tracked as CVE-2026-97229, which carries a CVSS score of 10.0. Although Alpine Linux found no evidence that the attackers successfully executed malicious code or modified its software packages, the project said it could not completely rule out a breach.
Alpine Linux is a lightweight, open-source operating system widely used as the foundation for Docker container images. Its GitLab server hosts development repositories, code reviews and continuous integration (CI) jobs, including the build recipes used to produce Alpine software packages. This makes the server an important target for attackers seeking to compromise the software supply chain.
The vulnerability is caused by an integer overflow in Onigmo, the regular expression engine included in Ruby and used by GitLab's CI/CD system. If successful, this could allow the attacker to execute arbitrary code on the vulnerable server.
GitLab disclosed the vulnerability and released security fixes on October 12. However, Alpine Linux initially installed GitLab version 19.3.4 instead of the patched 19.3.5. The project later upgraded to version 19.3.6 on October 22, but the vulnerability remained because the required Ruby security patch was missing from Alpine's custom container image.
According to Alpine Linux, an attacker created a new account and began submitting specially crafted CI configurations to its GitLab server on October 20-21.
The security team recorded eight worker crashes during the attacks. Four attempts reportedly progressed partway through the exploitation process before failing to complete.
The attackers also downloaded Alpine Linux's GitLab container image, suggesting they may have been studying the server's configuration and preparing an exploit specifically designed for that environment.
The project later discovered that upgrading GitLab alone was insufficient to address the problem. The security fix required an updated version of Ruby, which was included in GitLab's official packages but was not present in Alpine's custom image.
There were doubts about a possible software supply-chain attack. If attackers had successfully compromised the GitLab server, they could potentially have accessed user information, password hashes, two-factor authentication secrets, CI/CD credentials, integration tokens and private project repositories.
The project also advised users to change passwords reused on other websites and to pull the updated alpinelinux/gitlab:19.3.6 container image published on October 27. This image includes Ruby 3.3.13, which contains the necessary security fix.
Drupal has confirmed active exploitation of a highly critical access bypass vulnerability in its Commerce Core module, warning online retailers that attackers could manipulate orders and circumvent payment processes. The company has urged administrators to install the latest security updates and investigate existing transactions for unauthorized modifications.
Tracked as CVE-2026-118539, the vulnerability affects Drupal Commerce Core, a contributed module that enables websites to sell products and services through shopping carts, checkout systems and payment integrations. It also supports headless commerce architectures, where external applications interact with Drupal through APIs.
According to the original security advisory, certain application routes and entity fields do not have sufficient access restrictions, allowing unauthorized users to bypass established permission checks. This could enable attackers to manipulate commerce-related information, potentially causing direct financial losses for merchants.
Published on October 28 under advisory SA-CONTRIB-2026-254, the vulnerability received a Drupal security risk score of 21 out of 25, placing it in the highly critical category. Its assessment identifies the flaw as exploitable without authentication or special access requirements, regardless of the module's configuration.
Drupal has confirmed that the vulnerability is being actively exploited in the wild. However, its initial advisory did not disclose the attack methodology, affected organizations or the number of compromised websites.
Fraudulent Order Attempts Reported on Live Websites
Additional information published on October 29 by Centarro, the maintainer of Drupal Commerce, provides further insight into the exploitation activity.
According to Centarro, it received two reports from merchants who observed suspicious attempts to place fraudulent orders on their live websites. Following an investigation conducted alongside the Drupal Security Team, the maintainers stated that they had not found evidence of scripted or widespread exploitation beyond the initially reported sites.
The vulnerability affects both traditional, full-stack Drupal Commerce installations and headless deployments, although the potential attack paths differ depending on the website's architecture.
Centarro identified several suspicious transaction patterns that administrators should investigate. These include orders placed without corresponding payments, transactions marked as paid despite having no associated payment records, product prices modified without legitimate promotions, and unauthorized discounts, fees or other adjustments applied to orders.
Some reported attempts involved products listed at unusually low prices, including $0.01, while others used apparently normal prices to make fraudulent transactions less conspicuous.
The maintainers also warned that the vulnerability may have existed in earlier Commerce Core releases for several years. Exploitation was theoretically possible from version 8.x-2.18, released in May 2020, on installations using Drupal's JSON:API module. Other configurations became potentially vulnerable from version 8.x-2.25, released in June 2021.
Consequently, organizations should not restrict their investigation to transactions created shortly before the October security disclosure.
Security Updates and Additional Commerce Vulnerabilities
Drupal has released Commerce Core 3.3.13 and 8.x-2.41 to address CVE-2026-118539. Administrators running the 3.x branch should upgrade to version 3.3.13, while installations using the earlier 8.x-2.x branch should move to 8.x-2.41.
Centarro has also recommended updating the associated Commerce API, Commerce License, Commerce Shipping and Commerce Stripe modules, which received separate security releases. Websites that do not require write operations through JSON:API should consider restricting the interface to read-only access.
The October 28 security releases addressed several additional vulnerabilities across Drupal's contributed projects.
Among them, CVE-2026-118558 affects Commerce Stripe through a cross-site request forgery (CSRF) vulnerability. The module does not include a CSRF token in the return URI used during Stripe Connect authorization. An attacker could exploit this weakness by tricking an administrator into following a malicious link, potentially causing an order to be marked as paid without an actual payment.
Another issue, CVE-2026-118582, affects the CAPTCHA module. The vulnerability results from inadequate invalidation of previously solved CAPTCHA sessions, allowing an already-submitted protected form to be submitted again without completing another challenge. This could weaken protections against automated registrations, comment spam and login brute-force attempts. Drupal's advisory indicates that exploit code exists, although it does not confirm active exploitation.
Drupal also disclosed information disclosure vulnerabilities in Commerce Core and Media Alias Display. The former can expose information about unpublished product variations under certain JSON:API configurations, while the latter involves improperly configured caching that could expose files containing information intended to remain inaccessible.
Earlier Critical Drupal Vulnerabilities
The October disclosures follow another security release on October 14, when Drupal addressed two critical remote code execution vulnerabilities.
CVE-2026-108097 affects the Field UI module in Drupal Core, while CVE-2026-108099 impacts the contributed Entity List module. Although neither component independently exposes the vulnerabilities through its default functionality, certain contributed modules and custom implementations can introduce exploitable pathways. Drupal identified at least one potential attack path that does not require authentication.
Another vulnerability, CVE-2026-9082, involved SQL injection in Drupal Core's database abstraction API, affecting websites using PostgreSQL databases. The flaw could allow unauthenticated attackers to execute specially crafted database queries, potentially resulting in information disclosure, privilege escalation or remote code execution. The vulnerability was added to the US Cybersecurity and Infrastructure Security Agency's Known Exploited Vulnerabilities catalog in May 2026 following confirmed exploitation.
With CVE-2026-118539 now confirmed under active exploitation, administrators should prioritize security updates, examine historical order records and verify that payment confirmations correspond to actual transactions before fulfilling orders. Centarro has also recommended comparing suspicious transactions against website access logs to establish whether they originated through legitimate checkout processes.
Northflank provides a cloud-based platform that allows developers to deploy and manage applications, containers, databases and AI applications without having to manage the underlying infrastructure.
After the warning, Northflank advised customers to immediately change their environment variables and API keys stored on the platform. The company later issued a stronger warning, asking users to assume that all environment variables had been decrypted and that the sensitive information stored inside them had been stolen.
Environment variables are commonly used by applications to store sensitive information, including database passwords, cloud service credentials, authentication tokens and API keys. If attackers gain access to these details, they can use them to compromise other services, steal data or misuse accounts to generate unauthorized charges.
Northflank later confirmed that several customers had reported unauthorized use of AI API keys stored on its platform.
"Users have reported unauthorised use of AI API keys supplied to the Northflank platform," the company said in an update. It urged customers who had not yet changed their stored secrets to do so immediately.
The company also advised users to examine their AI service providers' usage and billing records for unusual activity. Any suspicious usage should be reported to Northflank and the relevant AI service provider.
According to the company's incident timeline, Wiz notified Northflank about the security breach at 11:43 UTC on October 30. Its engineering team began investigating the alert one minute later. Northflank initially introduced a network policy patch and deployed additional security updates at 12:50 UTC and 13:05 UTC. The company also requested assistance from Wiz's incident response team.
As part of its response, Northflank enabled credential rotation for PostgreSQL, MongoDB, MySQL and Redis databases. It also introduced audit logs for all customers, including users on free accounts, to help them identify suspicious activities.
According to Wiz, attackers are increasingly targeting environment variables that contain AI service credentials. Stolen API keys can be used in a practice known as LLMJacking, in which attackers exploit another organization's AI accounts to access expensive AI models without permission. They may also resell access to these services to other users.
In two cases investigated by Wiz, attackers used compromised enterprise credentials to make approximately 2.5 million requests to Amazon Bedrock, resulting in nearly $100,000 in AI usage charges.
The device quietly navigating your living room floor might be doing more than picking up crumbs. Robot vacuums, now a fixture in millions of homes, collect data that goes far beyond what most buyers realize when they pull one off the shelf. Depending on the model, a connected vacuum can generate detailed floor maps, record cleaning histories, capture ambient audio through built-in microphones, and stream live video to an app on your phone. Some models let you monitor progress remotely, routing that footage and data through the manufacturer's servers. And while the machine charts a path between your couch and your coffee table, it may be quietly building a picture of how you live.
iRobot, maker of the popular Roomba line, spells out its data practices in its privacy policy. Connected models can send room names, floor types, detected objects, robot movements, and Wi-Fi network details back to the company. That is not a hidden clause buried in fine print, but it is something most consumers never read before buying. For businesses, this kind of information carries real commercial value: consumer behavior data, household layouts, and everyday habits are precisely the intelligence that advertisers and smart home companies have long sought.
The Flaw That Opened 7,000 Homes
In February 2026, a software engineer named Sammy Azdoufal set out to do something benign: control his DJI Romo vacuum with a PlayStation 5 controller. What he found was a flaw that handed him access to roughly 7,000 other people's vacuums across more than 20 countries.
Azdoufal, an AI strategy specialist, reverse-engineered how the Romo communicated with DJI's servers. The backend authentication system accepted his device token as valid for thousands of other users' devices. From that position, he could view live camera feeds, hear microphone audio, see floor plans and room layouts, and check battery levels and cleaning status. He reportedly watched a journalist's vacuum operating in that person's living room in real time.
"Devices promising convenience can invite unseen observers into private spaces." [Dallas Express, February 2026]
Azdoufal notified DJI immediately. The company closed the vulnerability by late February and attributed the problem to a permission issue in its MQTT communication system, deploying automatic updates that required no action from users. The Romo model was removed from DJI's online store two days later. DJI said no widespread misuse had been detected. Critically, Azdoufal did not bypass encryption or use any sophisticated hacking technique. The problem sat on DJI's server, where device data was stored in plain text and access controls were loose enough that a legitimate customer's token opened thousands of doors.
This was not an isolated episode. In 2024, hackers took over Ecovacs Deebot X2 robot vacuums in several American cities, steering the machines remotely and playing racial slurs through their speakers. Minnesota lawyer Daniel Swenson, one of the affected users, described the intruder: "I got the impression it was a kid, maybe a teenager."
What the Vacuum Actually Knows About You
The data a robot vacuum collects is more revealing than it first appears. Floor maps trace the layout of your home, including where you sleep, where you store valuables, and the shape of your living spaces. Object detection features identify furniture, shoes, and personal items. Layer microphone access on top of that and the device starts resembling something other than a cleaning appliance. A privacy policy describes what a company intends to do with your data. It does not guarantee the product is free of security vulnerabilities. An attacker who reaches a manufacturer's servers could access whatever has already been collected, regardless of what any policy says.
Buying a Vacuum That Collects Less
Not every connected vacuum poses the same degree of risk. Buyers wanting to limit their exposure should look for models that process navigation data locally rather than routing it through manufacturer servers. Matic, a smaller company, builds its vacuum around that principle: maps stay on the home Wi-Fi network and all processing happens on the robot itself. Remote app access is available, but only through encrypted cloud infrastructure with explicit user consent.
One distinction worth keeping straight: a camera-free model still generates maps and sends account data to the manufacturer. "No camera" and "no data collection" are not the same thing. Mandatory cloud features, with no option to use the device offline, are a signal worth weighing as a dealbreaker before purchase.
Steps for People Who Already Own One
For the millions of households already running a connected vacuum, a few changes lower the risk without requiring a new purchase. Set a strong, unique password and enable two-factor authentication on any linked account. Keep the vacuum's firmware updated. Disable remote viewing and other cloud-connected features unless you actually use them. The fewer connections left open, the smaller the surface available to anyone looking for a way in.
The vulnerability, tracked as CVE-2026-98432, has received a critical severity rating of 9.8 out of 10 from the Linux kernel CVE team. It affects Linux kernel versions dating back to 4.4 and could put several widely used Linux distributions at risk.
The security issue is caused by a use-after-free vulnerability in the Linux kernel’s IPv4 TCP networking code. It occurs because of a race condition during the handling of TCP connection requests.
The vulnerability affects both regular TCP connections and Multipath TCP (MPTCP). MPTCP allows a single network connection to use multiple network paths simultaneously, improving connection reliability and performance.
Researchers at Anthropic demonstrated that the flaw could be exploited remotely without authentication on servers running MPTCP listeners. Their exploit was developed using an unreleased Claude AI model and reportedly took around 53 minutes to achieve remote code execution with root privileges.
The exploit also managed to bypass Kernel Address Space Layout Randomization (KASLR), a security mechanism designed to make memory-based attacks more difficult.
Another concern involves Go 1.24, which enables MPTCP by default for TCP listeners on Linux when the underlying kernel supports the feature. This means some Go-based applications could expose vulnerable services without administrators being aware of it.
The vulnerability affects multiple Linux distributions, including Ubuntu, Red Hat Enterprise Linux (RHEL) and Rocky Linux. While the Linux kernel issue can also be triggered through ordinary TCP connections, publicly demonstrated remote root exploitation has so far focused on systems running MPTCP listeners.
Red Hat has assessed the vulnerability as a complex exploitation risk that could result in a denial-of-service condition, assigning it a lower severity score of 5.9.
The vulnerability has been fixed in the upstream Linux kernel, with patches also backported to maintained kernel branches. However, security updates were still pending for several distributions as of October 30, 2026.
Rocky Linux support provider CIQ has also recommended temporary firewall protections using nftables to block IPv4 TCP packets containing IP options. But simply disabling MPTCP is not sufficient because the underlying vulnerability can also be triggered through ordinary TCP traffic.
There are currently no confirmed reports of CVE-2026-98432 being exploited in real-world attacks.
Hackers tied to North Korea stole roughly $6.36 billion from Binance on Wednesday, stripping the world's largest cryptocurrency exchange of funds across ten blockchains in a heist that blockchain intelligence firms are calling the largest crypto theft in history.
The attack, which began at 8:05 p.m. UTC on October 29, moved faster than most exchange security teams could respond. The bulk of the money was gone within 20 minutes.
Binance suspended deposits and withdrawals shortly after detecting the breach and said user funds would be covered in full. "Investigating a potential security issue," the exchange wrote in an early-evening post, adding that user assets were safe. By late that night, a coalition of blockchain infrastructure firms had frozen roughly $3 billion of the stolen assets, though more than $2.4 billion remained in the attacker's control as of press time.
How They Got In
Blockchain intelligence firm TRM Labs, which traced the attack in near real-time, said the intrusion bore the hallmarks of TraderTraitor, the North Korean state-sponsored hacking unit that the FBI also attributed to February's $1.5 billion Bybit breach.
The preparation started at least 36 hours before the theft. TRM Labs found that the attackers funded an operator wallet with small withdrawals from Tornado Cash, a crypto mixing service, then ran test transactions across wallets they controlled. In the day before the main theft, the attackers rehearsed the final version of their code on a third wallet before installing it on a live Binance hot wallet.
The technical method on Ethereum was particularly precise. The attackers used EIP-7702, an account delegation feature introduced in a recent Ethereum upgrade, to effectively convert a Binance hot wallet into a sweeper they controlled. A single transaction carried 50 pre-signed authorizations; one matched the wallet's transaction count exactly, granting the attackers the ability to sweep new incoming deposits for hours after the initial theft, all the way until 11:56 p.m. UTC.
On nine other blockchains, including Bitcoin, Tron, XRP Ledger, Solana, Arbitrum, and several Ethereum layer-2 networks, wallets sent funds through standard signed transfers during the same window. TRM's analysis concluded the most likely explanation was that the attacker had somehow obtained the ability to instruct Binance's hot wallet signing infrastructure to authorize transactions of their choosing. Binance has not yet published a root cause analysis.
What Was Taken
The breakdown by chain is staggering. Ethereum accounts for the largest slice: about $3.79 billion, including 200,630 ETH and roughly 1.875 billion USDT. Bitcoin follows with 18,270 BTC worth approximately $1.47 billion. Tron contributed about $628 million, primarily USDT, and XRP Ledger added 233 million XRP worth around $296 million. The remaining losses were spread across Solana, Arbitrum, Optimism, Base, Avalanche, and Polygon.
At those figures, the theft dwarfs every previous crypto hack on record by a considerable margin. The Bybit breach in February 2025, which itself broke every prior record, involved $1.5 billion. This attack is roughly four times larger.
The Freeze Race
Within hours of the theft, stablecoin issuers and blockchain governance bodies began freezing assets. Tether moved first, blacklisting 971 million USDT across wallets traced to the attacker at 9:01 p.m. UTC. Circle followed three minutes later with a freeze on $823 million in USDC, acting in coordination with law enforcement. Ripple froze 40.5 million RLUSD at 10:01 p.m. The Arbitrum Security Council executed forced transfers of 8,426 ETH and 74.6 million ARB tokens after midnight.
By 11:35 p.m. UTC, Binance said the verified total of frozen assets had reached $2.54 billion. TRM Labs placed the figure closer to $2.7 billion by 12:30 a.m. the following morning.
The attacker, however, moved quickly to convert portions of the stolen funds. Some USDT was swapped for ETH at a discount of more than 10%, and the attacker used Aave, a decentralized lending protocol, to borrow ETH against frozen stablecoin positions. As of the morning of October 30, the attacker still held more than 420,000 ETH and all 18,270 BTC, assets beyond the reach of any issuer's freeze function.
North Korea's Crypto Playbook
The FBI said it was aware of the incident and working with partners to assess the activity. The U.S. Secret Service had not responded to a request for comment at time of publication.
The timing fits a pattern that intelligence analysts have tracked closely. Chainalysis reported that North Korean operatives stole about $2 billion in cryptocurrency throughout 2025. TRM Labs found that two North Korea-linked groups accounted for three-quarters of all crypto hack losses in the first quarter of 2026 alone. The funds are widely believed to support Pyongyang's weapons programs, which have been cut off from conventional financial markets through international sanctions.
TRM Labs said it expects the attacker to route remaining funds through cross-chain bridges, swap services, and over-the-counter brokers in the coming weeks, and said it was monitoring those flows in real time.