Russian cloud services provider Yandex announced that drone attacks damaged three of its data centers, forcing it to shut down two facilities and partially disable a third. Yandex customers are experiencing service outages, some of them reporting inability to access files stored on the company’s cloud infrastructure. The impacted data centers are in Sasovo (hit on October 8), Kaluga (hit on October 9), and Vladimir (attacked on October 11). The Sasovo and Vladimir facilities stopped operating completely, while the Kaluga facility's operations are degraded. The attacks are believed to have been carried out by Ukrainian forces trying to cause widespread operational disruptions. Yandex reported no injuries related to these incidents. As Russia’s largest technology companies, Yandex is often called “Russia’s Google,” offering search engine, maps, and navigation services. The company also offers ride-hailing, delivery, shopping, streaming, email, cloud storage, and business cloud infrastructure services.
Attackers are exploiting SonicWall SMA 1000 vulnerability, tracked as CVE-2026-102255 (CVSS score of 10.0), just days after its public disclosure. Attackers have begun exploiting a critical flaw in SonicWall SMA 1000 appliances, tracked as CVE-2026-102255 (CVSS score of 10.0), just days after public disclosure. The vulnerability is a server-side request forgery (SSRF) flaw that requires no login. Attackers could abuse it to make the appliance send requests and access internal functions, allowing unauthorized actions. “A Pre-authentication SSRF vulnerability exists in the SMA1000 Appliance Work Place interface due to an unintended alternate access path.” reads the advisory. “By abusing this path, a remote unauthenticated attacker could potentially exploit this vulnerability to direct the appliance to issue requests on their behalf and reach internal functionality and perform unauthorized operations.” The vendor said it has found no evidence of exploitation, but recommends applying the fixes. The vulnerability affects the following product and versions: Affected ProductAffected Version(s)SMA1000 Models – 6210, 7210, 8200v 12.4.3-03526 (platform-hotfix) and older versions. 12.5.0-02952 (platform-hotfix) and older versions. The company pointed out that the flaws do not impact SSL-VPN running on SonicWall firewalls or the SMA 100 Series product line. The hotfix is available through the MySonicWall portal, the vendor pointed out that there is no workaround. Multiple researchers warn the vulnerability is now being actively exploited. Cybersecurity firm Defused has detected unauthenticated SSRF traffic targeting its SonicWall SMA decoys since October 8, 2026. Defused alerted subscribers through its Radar service. Since yesterday we have been observing unauthenticated SSRF traffic against our SonicWall SMA decoys. CVE-2026-102255 (alternate access path SSRF, CVSS 10.0) was disclosed earlier this week by SonicWall. We notified Defused subscribers of the anomalous traffic via our Radar… pic.twitter.com/h0w30YT0Y3 — Defused (@DefusedCyber) October 9, 2026 Cybersecurity firm Previdian also announced that its sensors have detected exploitation attempts targeting SonicWall SMA 1000 appliances, consistent with CVE-2026-102255. The reported attacker IP is 146.70.143[.]142. SonicWall SMA1000 exploitation attempts are now being observed by Previdian sensors, consistent with CVE-2026-102255 (CVSS 10.0). The vulnerability allows unauthenticated server-side request forgery (SSRF). Attacker IP: 146.70.143[.]142 Apply SonicWall's hotfix and… pic.twitter.com/YBovnuEkvD — Previdian (@PrevidianCyber) October 9, 2026 According to Previdian, researchers have recorded 135 attack attempts from two IP addresses in the United States. Researchers have recorded 135 attempts from two different IP addresses in the United States. SonicWall has not yet updated its security advisory to confirm that attackers are exploiting the flaw. Follow me on Twitter: @securityaffairs and Facebook and Mastodon Pierluigi Paganini (SecurityAffairs – hacking, SonicWall)
Bitdefender finds Midnight Mimosa, preinstalled Android malware on cheap MediaTek phones that fakes ad clicks, drops apps and builds a proxy botnet. Bitdefender researchers discovered a campaign called Midnight Mimosa involving preinstalled Android malware on low-cost phones from different brands that use MediaTek platforms. The malware is built into the device firmware and may be hidden in different system packages depending on the model. It is already on the phone before the owner turns it on for the first time and cannot be removed. The malware has system-level privileges, allowing it to install and remove apps, grant permissions and download code from a remote server without the user’s knowledge. This gives its operators control over the infected devices and allows them to use them for different purposes, including building a large botnet. The campaign appears to be mainly financially motivated. “This scheme is likely designed mainly to generate revenue. The operators carry out ad and click fraud, collect device and installed-app information, and turn infected devices into residential-proxy relay nodes, making them zombies in botnets.” Bitdefender states. “This creates an additional revenue stream, as access to botnets for DDoS attacks is a hot commodity. The larger the botnet, the more money they can charge.” The money comes from several places. The operators run ad and click fraud, collect device and installed-app information, and turn infected phones into residential proxy relay nodes. Botnet access for DDoS attacks is a hot commodity, and the larger the botnet, the more they can charge. The system app doesn’t register the fraudulent clicks itself. The revenue comes from cover apps it drops onto the phone, such as real-looking weather, app-lock, note and OCR apps. Those load genuine ads through a legitimate ad SDK, while an invisible window on top registers ads being shown, and the ad network credits the cover app, not the hidden component. Bitdefender spotted it through behavior, not a signature. A package called com.android.system.lite looked like a core Android component but didn’t act like one: it repeatedly enabled sensitive access, including Accessibility and Notification Access, and silently installed and removed unrelated apps. It had no icon and an app label of just “System”, and its real machinery sat in a native library that only woke up at runtime. “The investigation began with App Anomaly Detection, a technology in Bitdefender Mobile Security, which flagged com.android.system.lite: a package carrying the name and appearance of a core system component while behaving like nothing of the sort.” continues the cybersecurity firm. “Most mobile security still runs on a single assumption: scan an app, and if it’s deemed clean, it’s safe. Bitdefender’s App Anomaly Detection (introduced in 2023) exists because, in practice, the theory often doesn’t hold up. Apps can sit dormant and turn hostile weeks later, sometimes only if certain conditions are met (targeted malware). Such apps can pass every static check, only to later pull their real payload from a server or cleverly unpack it from native code.” The first package discovered was only one version of the malware. The same core code was also found in packages named com.android.sys.prot, com.android.sys.gmsprot and com.android.sys.bcprot, with different digital signing certificates. Bitdefender explains that the main threat is not the package name itself, but the malicious code shared by all these versions. The malware can silently install at least 32 different apps disguised as useful tools, including app lockers, weather apps, file managers, icon tools, OCR tools and audio editors. It gives itself access to Android’s Accessibility, Notification Access and SMS read/write features. Bitdefender did not observe the malware using the notification or SMS permissions, but the operators could activate them when needed. The malware also repeatedly enables and disables these permissions after short periods. The install trick is neat and nasty. Before dropping a payload app, the malware disables the Google Play Store app, apparently to dodge Play Protect, then re-enables it afterward, and a safety net turns it back on when the user is present so nothing looks odd. It can also record Google Play as the install source for apps that never came from Play, though real Play apps carry a server-side signature block called frosting, and the forged ones don’t have it. Under the hood, a native library called libeasy.so decrypts a hidden framework, which fetches a remote configuration from a command server disguised as a weather API. The framework then loads further plugins that run the in-process ad fraud and the silent installs, and it can update itself with new code from the server. The plugins and payloads travel as files with misleading extensions, like JARs named .o and APKs served as .png, so a sample examined offline often holds no active payload at all. The ad fraud is tunable. The plugin shows ads in full-screen activities and overlays nobody asked for, triggered when the screen turns on or by commands from the operator. It marks those surfaces as secure, so they don’t show up in screenshots or screen recordings, and it fires synthetic clicks with daily caps and timing limits to look organic. The cover apps act as peers in an ad mesh, so one app can drive impressions that another app renders and gets paid for. One payload app, com.mobile.applock.en, is something else entirely: a single-purpose TCP proxy with no ads and no interface that enrolls the phone as a relay node. “Our insights reveal these payload applications being installed and removed repeatedly on the same devices. This churn helps the operation reduce the length of time a payload remains visible in the app list, rotate hashes, and change the active monetization module, while the underlying system component stays in place.” states the report. “Beyond generating revenue for operators, the devices can be turned into residential-proxy relay nodes, essentially becoming part of botnets and potentially helping launch DDoS attacks when called upon.” It connects to a control host over raw TCP on port 6000, rotates across four domains, and pipes traffic between the controller and whatever target the server names. Bitdefender notes an erratum here: the IP it first reported as the control server turned out to be a sinkhole, not a command server. The campaign relays on Google Play to target Android users. Thirteen apps published there talk to the same servers, under at least two developer accounts and thirteen different signing certificates. They passed Play review, they provide some real function, and they also show ads outside the app, sometimes while the phone sits idle. They don’t have the privileges of the preinstalled packages, but Bitdefender calls them dangerous anyway. Scale is large. Over roughly two years, the family showed up on thousands of unique devices in more than 150 countries, led by Mexico, France and Italy, followed by the United States, Germany, Brazil and Spain. Two separate regional centers with a long tail behind them is what hardware moving through international online marketplaces looks like, not a single carrier’s channel. “As we mentioned earlier, Zediel-signed firmware is not the only way malware is shipped. The operators use many other devices, most of them likely visual clones of real phones, to embed the same malware.” states the report. “Beyond the generic user agent strings, many of the affected models are counterfeit devices that borrow flagship names they have nothing to do with. Fake iPhones include: “i17 Pro Max”, “i16_Pro_Max”, or “17_Pro_Max”, and an “iPadAirPro” for the tablet line.“ The phones are often fake models. Some report names such as “i17 Pro Max,” “S25 Ultra” and “Note 18 Ultra,” even though these models do not exist. Others use fake codes that make them look like real Samsung devices. The two most common models are from budget brands: Doogee’s S200 X and Cubot’s KINGKONG X. A public discussion on the XDA forum also describes users finding a hidden com.android.sys.* package that returned under a different name after they removed it. Who installed the malware? Many affected phones use firmware signed with certificates linked to Shenzhen Zediel. Bitdefender confirmed that these certificates were used to sign firmware on affected devices, but it could not establish how the malware got there or whether the certificate owner knew about it. Other infected phones do not use Zediel-signed firmware, so the malware could have been added by a device manufacturer, a firmware integrator, a logistics partner or another party in the supply chain. The activity also has a longer history. Bitdefender linked the malware’s infrastructure, through shared domains, to Dr.Web’s Android.Joker family in 2021 and its Android.Phantom and Click families in 2025. The operation now also includes residential proxyware. For defenders, the key is to detect the malware’s core code and command server, and to monitor its behavior. Blocking specific package names is not enough because the attackers can easily change them. Clearing an infected phone isn’t something an owner can do by uninstalling, because the root component sits in the system partition. It takes firmware-level cleanup or disabling the component over ADB, and neither is realistic for most people who own these phones. The durable fix sits with the vendors and marketplaces that ship and sell the affected firmware. The two defenses users rely on, store review and the ability to uninstall, don’t apply here, which is why Bitdefender calls preinstalled malware a different threat class. Users cannot rely on app store checks or simply uninstalling the malware. Bitdefender considers preinstalled malware a separate category of threat for this reason.” concludes the report. “Preinstalled malware is a different threat class. Every user-facing defense assumes the owner is in the loop at installation: the install prompt, the store review, Play Protect, and the ability to uninstall afterwards.” Follow me on Twitter: @securityaffairs and Facebook and Mastodon Pierluigi Paganini (SecurityAffairs – hacking, preinstalled Android malware)
Four more U.S. states sued router maker TP-Link Systems on October 6, bringing the total to five, with Texas filing a suit in February. Florida, Iowa, Montana and Nebraska allege the California company misled buyers about how secure its routers are and how separate it is from China. TP-Link denies the claims and says it will fight them in court. TP-Link Systems is based in
Unit 42 details how threat actors leverage Web3 infrastructure and open-source supply chain attacks to breach enterprise cloud environments The post Evolution of Web3 in Cloud Supply Chain Attacks appeared first on Unit 42.
SonicWall has released hotfixes for four flaws in its SMA1000 appliances, the gateways that give remote workers access to a company's network and applications. The most serious could allow an attacker without a login to send requests through the appliance and reach internal functions. SonicWall rates it 10.0 on the CVSS scale and says it has no evidence that any of the four flaws is being
A critical vulnerability in LMCache, open-source software that speeds up large language model (LLM) servers such as vLLM, lets an attacker run code on the cache server without logging in, and no fixed version is available. The flaw is in LMCache's multiprocess mode, where the cache runs as a standalone server that LLM workers reach over the ZeroMQ messaging library. A single network
Analysis of Blinder Tunnel, an Iran-nexus campaign using fake Dubai Airports recruitment lures and GitHub C2 malware to target critical infrastructure. The post Blinder Tunnel Campaign Targets Iraqi Infrastructure appeared first on Unit 42.
Google has now suspended submissions to its Open Source Software Vulnerability Rewards Program (OSS VRP) after being flooded by AI-generated reports. The company's OSS VRP incentivizes security researchers to responsibly disclose security flaws across open-source projects maintained by Google, including Golang, Angular, Bazel, Protocol Buffers, Fuchsia, and critical third-party dependencies, as well as repository settings like GitHub actions, application configurations, and access control rules. Google launched the OSS VRP in August 2022 with rewards ranging from $100 to $31,337, and noted that the program would focus on security flaws with the most significant impact on the software supply chain. "We are temporarily no longer accepting OSS VRP product vulnerability submissions. This does not impact OSS VRP supply chain reports, or any outstanding reports," the company said. "Why is this happening? This pause is due to a significant rise in automated submissions, the vast majority of which are not valid."
GitLab fixes critical AI Gateway flaw that could let authenticated Duo users escape a prompt sandbox and execute commands on self-hosted gateways. GitLab has released patches for a critical vulnerability in its AI Gateway, tracked as CVE-2026-90970 (CVSS score of 9.9), that could allow an authenticated user with access to the Duo Agent Platform to execute arbitrary commands on the gateway. GitLab disclosed the flaw on October 2 and fixed it with the release of AI Gateway versions 19.2.4, 19.3.2 and 19.4.1. The issue affects the way the AI Gateway handles custom flow prompt templates. According to GitLab, a user with Duo Agent Platform access could use a specially crafted flow configuration to escape the prompt template sandbox and execute commands on the AI Gateway host. “GitLab has remediated an issue in the GitLab AI Gateway that, under certain conditions, could have allowed an authenticated user with Duo Agent Platform access to escape the prompt template sandbox via a specially crafted flow configuration, leading to arbitrary command execution on the AI Gateway.” reads the advisory. The important point is that the attack does not require an unauthenticated connection. GitLab’s advisory does not provide further details about the exact conditions required to exploit the flaw or the permissions needed beyond that access. GitLab credited the HackerOne researcher invisiblemeerkat with responsibly reporting the vulnerability. The GitLab AI Gateway is basically the middle layer between GitLab Duo and the AI models. GitLab Duo provides AI features such as code suggestions, chat, code explanation and agentic workflows. The AI Gateway receives the requests from GitLab, prepares the prompts and communicates with the underlying LLMs. GitLab operates its own cloud-based gateway, but organizations can also deploy an AI Gateway inside their own infrastructure. GitLab says the security fix has already been deployed to its own hosted AI Gateways. Customers using GitLab.com, GitLab Dedicated, or a GitLab Self-Managed instance connected to a GitLab-hosted gateway therefore do not need to take action. The customers that need to patch are those running a GitLab Self-Hosted AI Gateway. GitLab has already contacted those customers directly and strongly recommends updating affected installations immediately. Self-hosting the gateway is designed for organizations that want to keep AI requests and responses inside their own environment. In a fully self-hosted configuration, GitLab, the AI Gateway and the selected AI models can all operate within the organization’s infrastructure. Below are the affected AI Gateway releases: Affected versionFixed version18.1.6 through 19.2.319.2.419.3.0 through 19.3.119.3.219.4.019.4.1 The AI Gateway sits between GitLab’s AI features and the underlying models. In a self-hosted deployment, it processes requests between the GitLab instance and the organization’s AI infrastructure. The service also has access to sensitive authentication material. GitLab’s installation documentation says that self-hosted deployments require signing and validation keys for JSON Web Tokens. These keys are passed to the gateway as environment variables. For that reason, command execution on the gateway could provide an attacker with a foothold inside infrastructure that handles AI requests and authentication. The exact impacts would depend on how the gateway is deployed and what access it has to the rest of the organization’s environment. GitLab’s October 2 advisory does not say that CVE-2026-90970 has been exploited in the wild. It also does not publish a proof of concept or technical exploitation steps. That leaves several important questions unanswered, including the precise flow configuration needed to escape the template sandbox and the exact conditions under which the resulting command execution can be reached. Follow me on Twitter: @securityaffairs and Facebook and Mastodon Pierluigi Paganini (SecurityAffairs – hacking, newsletter)
Confirm this action.
Leaving now will discard your changes.