CySecurity News - Latest Information Security and Hacking Incidents: Cyber Security

API API Security Vulnerability Critical Infrastructure Cyber Security cybersecurity vulnerability

Critical Orkes Conductor Flaw Exploited for Unauthenticated Remote Code Execution

A critical vulnerability in Orkes Conductor is being actively exploited by attackers, potentially allowing them to execute arbitrary commands on vulnerable systems without authentication. Tracked as CVE-2026-58138 and rated 9.8 on the CVSS scale, the flaw affects Conductor, an open-source enterprise framework used to orchestrate microservices, workflows and AI agents. The vulnerability can be exploited through inline workflow definitions submitted to the platform’s workflow API. The security issue stems from the way Conductor executes scripts within workflows.

Attackers can insert malicious JavaScript or Python expressions into workflow definitions and use them to execute arbitrary system commands. According to Empirical Security, INLINE tasks, along with LAMBDA, DO_WHILE and SWITCH tasks, can evaluate user-controlled JavaScript or Python expressions. Conductor creates the evaluator using a GraalVM context configured with HostAccess.ALL, effectively removing the intended sandbox protections. The attacker-controlled code can then reach the underlying Java runtime and execute operating system commands with the privileges of the Conductor process.

In many deployments, that process runs with root privileges, potentially giving attackers extensive control over the affected system. Authentication does not prevent exploitation by default because the open-source Conductor server does not enforce authentication and leaves its workflow API accessible. An attacker can reportedly send a single unauthenticated POST request to register a malicious workflow containing an INLINE task and trigger its execution. Orkes patched CVE-2026-58138 in June with Conductor version 3.30.2.

However, attackers began targeting the vulnerability after proof-of-concept exploit code was publicly released in early August. Empirical Security identified exploitation attempts in the wild on August 21. Fortinet subsequently blocked approximately 1,300 exploitation attempts between September 8 and September 9 and has issued an outbreak alert warning about continued exploitation. Organizations running Conductor should upgrade to version 3.30.2 or later and limit external access to the platform’s workflow API endpoints.

Security teams should also place Conductor deployments behind firewalls and ensure vulnerable services are not directly exposed to the public internet. Administrators should monitor Conductor instances for suspicious workflow submissions and unexpected command execution. Systems that previously ran vulnerable versions should also be reviewed for signs of unauthorized access or compromise.

An AI Helped Researchers Break Into OpenAI



 

open AI

AI Models Anthropic Claude Opus 4.7 ASLR Claude AI cyber espionage Cyber Security open AI

An AI Helped Researchers Break Into OpenAI

A three-person security research team quietly walked into OpenAI's internal infrastructure last July, submitted a pull request inside the company's private monorepo as proof, and then stopped. The whole operation, from first vulnerability discovery to confirmed repository access, took under 72 hours. The tool that made it possible was not a custom-built hacking suite. It was Claude Opus 5.

The researchers, Harsh Jaiswal, Mohan Pedhapati, and Rahul Maini, work at Hacktron, an AI-assisted security research firm. They published their full technical account on September 13. OpenAI confirmed a fix roughly 14 hours after receiving the initial report on July 25, and paid out a $6,500 bounty on September 1.

The case is one of the clearest demonstrations yet of what skilled human researchers can accomplish when they hand the grinding, iterative work of exploit development to a capable AI model. It is also a story about a mundane but persistent failure: software that depends on unpatched libraries, and login systems that trust services they probably should not.

The Chain That Got Them In

The attack surface was not OpenAI's flagship products. It was the company's public help forum, community.openai.com, which runs on Discourse, an open-source forum platform used by tens of thousands of organizations.

Discourse allows users to upload images. For most formats, it relies on a tool called FastImage to inspect files before processing them. But FastImage does not support HEIC or HEIF images, the high-efficiency formats popularized by Apple. So Discourse passes those files to ImageMagick instead, which in turn calls an underlying library called libheif to do the actual decoding.

That handoff is where the vulnerability lived. libheif version 1.19.7, the version running inside Discourse's Docker image at the time, contained a heap buffer overflow. A specially crafted HEIC file could corrupt server memory, giving an attacker the ability to manipulate program execution. The flaw is tracked as CVE-2026-32882 and carries a severity score of 8.8 out of 10 in Discourse's own advisory, which classifies the result as remote code execution.

The patch for this bug had been available since libheif 1.22.0, released in May 2026. The CVE existed. The fix existed. But Discourse's Docker image, built on Debian 12, still shipped the old, vulnerable library when the Hacktron team looked in July. Debian had not yet backported the fix into its packaged version. That two-month window between upstream patch and downstream delivery is what the researchers walked through.

Once they had code execution on the Discourse server, the path to OpenAI employee accounts ran straight through the forum's login button. OpenAI's forum offers a "Sign in with OpenAI" option, the same single sign-on system its staff uses for ChatGPT, Codex, and other internal services. With control of the forum server, the researchers could hijack that authentication flow and take over the accounts of any OpenAI employee who had ever used it. The victims did not have to click anything or be online at the time.

Hacktron was explicit in their writeup about what this means: the forum was one path, not the problem. "If any first-party or third-party OpenAI service using the OpenAI SSO was compromised, it would lead to the same access," the team wrote. The identity flaw was OpenAI's, not Discourse's.

After confirming the account takeovers, the researchers used one employee's Codex account, which was connected to OpenAI's GitHub organization, to open a single pull request inside OpenAI's internal monorepo. They read nothing, merged nothing, and touched no customer data. The pull request was the proof. Then they stopped and filed their report.

Where the AI Came In

The libheif heap overflow gave the researchers memory corruption primitives, which is a starting point, not a working exploit. Memory corruption bugs require additional work to become reliable code execution, particularly on modern systems protected by Address Space Layout Randomization (ASLR), a defense that scrambles where code sits in memory to make it harder to redirect program flow.

This is where most vulnerability research slows down. Turning a crash into a reliable, weaponized exploit requires significant expertise, patience, and time. The Hacktron team decided to find out how much of that work an AI could absorb.

They started with Claude Opus 4.8, the previous flagship model from Anthropic. Across multiple sessions, it managed to help develop a working exploit when ASLR was disabled. When they enabled ASLR, matching the configuration of real servers, Opus 4.8 struggled and failed to produce anything reliable.

On the evening of July 24, Anthropic released Claude Opus 5. The researchers started a fresh session.

Within three hours, Opus 5 had produced a working exploit for an ARM64 Mac environment. They asked it to adapt the exploit to x86-64 and to the jemalloc memory allocator configuration that Discourse uses. By 6:00 a.m. on July 25, they had confirmed local code execution through an image upload.

The researchers then placed Claude in what they describe as an autonomous "/goal" loop, pointed at their own Discourse Cloud instance, framed as a capture-the-flag practice target. Opus 5 has guardrails meant to prevent it from writing exploits for real systems, so the team disguised the target. When they checked again at 10:00 a.m., the agent had achieved code execution on their cloud instance on its own, demonstrating access by reading /etc/hosts. They then used the generated exploit on OpenAI's forum and confirmed it worked there too.

The researchers are careful to note that this was not fully autonomous hacking. Skilled human judgment and direction were required throughout. But the gap between what they could accomplish in hours with Opus 5 versus the days or weeks such work might have taken without it was significant.

The cost of the entire Discourse and OpenAI portion of the project: a few days of AI compute and a few hours of human time.

One Bug, Many Targets

The OpenAI breach was not a standalone operation. It was one piece of a broader research campaign Hacktron calls HEIF Heist, a multi-month investigation into how widely the libheif library is embedded in major internet services, and how many of those services were running vulnerable versions.

Over roughly two months, the three researchers say they traced the same class of image-decoding flaws across software used by Slack, Meta, GitHub Enterprise, and web frameworks including Next.js, Astro, and Gatsby. The total cost of the entire campaign was under $3,000 in AI model usage, spread across roughly sixty days of work.

The team found that adapting each exploit to a new target environment generally took only one or two days with AI assistance. They report that the only company that appeared to detect their testing activity was Shopify, even after thousands of test images were sent to various targets and image processors at several of those companies crashed repeatedly under the load.

Not all of the claims have been independently verified. The Next.js vulnerability is confirmed in Vercel's own advisory. libheif's maintainers confirmed a working code-execution exploit against Meta's deployment of the library. The wider claim of successful code execution across the full list of targets has not been corroborated by external sources as of publication.

The HEIF Heist project also surfaced a difference between AI models. For cases where the team had information about the target environment, Claude Opus 5 was the primary tool. For targets where they had almost no prior knowledge of the deployment configuration, they switched to OpenAI's GPT-5.6 Sol, which they found performed better in those conditions. Each major model jump brought a clear capability improvement: Opus 5 succeeded where Opus 4.8 failed, and GPT-5.6 Sol handled blind exploitation scenarios that Opus 5 struggled with.

The report documented Russia-linked espionage operations using Claude to run nearly fully automated phishing campaigns against Ukrainian, European, and diplomatic targets. It described a Chinese group, including operators identified as university students in Hunan province, who used Claude as the core engineering layer of an offensive program that found multiple zero-day vulnerabilities in a major security product. It also described a French-speaking hacktivist who used Claude to attack European political parties, media organizations, and think tanks at a scale that previously would have required a well-resourced team.

Anthropic's core observation across all of those cases was the same observation the Hacktron team made in their own writeup: AI is closing the gap between what a small, budget-constrained team can do and what used to require state-level resources.

The Hacktron team put it plainly: "Work that once required a well-resourced team and months of effort can now be compressed into days."

That assessment lines up with what Anthropic itself told the company's own threat report readers, and with what security researchers have been warning about for the past year. The Hacktron operation is the first time those warnings have been backed by a public, step-by-step technical demonstration against one of the most scrutinized technology companies on the planet.

What Needs to Change

The specifics of the OpenAI fix have not been made public. The company acknowledged the finding through payment and remediation rather than through a detailed disclosure of the login flaw.

On the Discourse side, the forum platform responded fast: they received the report on a Saturday, replied on Sunday, had a fix ready on Monday, and published their advisory on Tuesday. They also added image-processing sandboxing as a hardening measure, running ImageMagick in a restricted environment so that even a successful exploit against the image library cannot directly execute arbitrary code on the host server.

Microsoft Fixes Critical Azure AI Flaw Rated CVSS 10.0



 

Privilege Escalation

Azure AI Cloud Security Cyber Security Microsoft Azure Privilege Escalation

Microsoft Fixes Critical Azure AI Flaw Rated CVSS 10.0

Microsoft has patched a maximum-severity vulnerability in Azure AI Foundry that could allow unauthorized attackers to escalate their privileges over a network. Tracked as CVE-2026-85889, the flaw carries a CVSS score of 10.0, making it one of the most serious security issues affecting Microsoft’s cloud-based artificial intelligence services. The company said the vulnerability resulted from missing authentication for a critical function within Azure AI Foundry. There is currently no evidence that the flaw has been exploited in real-world attacks.

Azure AI Foundry, also known as Microsoft Foundry, is an enterprise platform used to build, deploy and manage generative AI applications and autonomous agents. A successful exploit could have enabled an unauthorized attacker to gain elevated privileges, potentially increasing access to sensitive resources or administrative functions. Security researcher Rémy Marot, who uses the handle @R_Marot, discovered and reported the vulnerability to Microsoft. The company has already addressed the issue across its cloud infrastructure.

Microsoft said customers do not need to take any action because the affected cloud services have been fully mitigated. Alongside CVE-2026-85889, the company also fixed several other critical cloud vulnerabilities. These include CVE-2026-85885, a command injection flaw in Microsoft 365 Copilot rated 9.9; CVE-2026-85878, an improper authorization issue in Azure Database for PostgreSQL rated 9.9; and CVE-2026-87701, an improper neutralization vulnerability in Azure Cosmos DB rated 9.6.

The tech giant separately released updates for two Windows vulnerabilities. CVE-2026-62721 affects the Windows User-Mode Power Service and could allow an authorized local attacker to gain SYSTEM privileges. CVE-2026-85921 is a double-free vulnerability in Windows Secure Kernel Mode that could enable privilege escalation to Virtual Trust Level 1. Both vulnerabilities were fixed through an out-of-band update for Windows 11 version 26H1, distributed as cumulative update KB5129194 for arm64 and x64 systems.

The latest fixes arrive shortly after Microsoft patched 974 vulnerabilities across its software portfolio. Two of those flaws, affecting Windows Advanced Local Procedure Call and the Windows Update Stack, were reportedly exploited in active attacks. Proofpoint and Volexity said the ALPC flaw was chained with two Google Chrome vulnerabilities to create the BlueMoon exploit kit, which multiple espionage-linked threat actors allegedly used to deliver malicious payloads. The developments highlight the growing security risks surrounding cloud platforms, enterprise AI tools and widely deployed operating systems.

FBI Seizes NightmareStresser DDoS-for-Hire Domains in Global Crackdown



 

NightmareStresser

Cyber Security DDOS Attacks FBI NightmareStresser

FBI Seizes NightmareStresser DDoS-for-Hire Domains in Global Crackdown

The U.S. Department of Justice has announced the court-authorized seizure of internet domains linked to “NightmareStresser,” one of the world’s longest-running Distributed Denial of Service (DDoS) for-hire services. The operation, led by the FBI Anchorage Field Office with support from the Royal Canadian Mounted Police, targets so-called “booter” and “stresser” platforms that enable paying customers to launch powerful cyberattacks against individuals, organizations, and critical online infrastructure across Alaska and globally.

According to the seizure warrant affidavit, NightmareStresser was used to carry out hundreds of thousands of actual or attempted DDoS attacks worldwide since 2022. These services lower the barrier to entry for cybercrime by allowing users with minimal technical expertise to disrupt internet connections, knock targeted devices offline (“booting”), and degrade or completely interrupt access to websites and online services. Victims have included schools, government agencies, gaming platforms, and millions of everyday users whose connectivity was affected by these coordinated attacks.

The takedown forms part of Operation PowerOFF, an ongoing international law enforcement initiative aimed at dismantling criminal DDoS-for-hire infrastructures and holding both administrators and users accountable. Over the past eight years, federal prosecutors and investigators in Anchorage and Los Angeles have charged twelve defendants involved in facilitating DDoS-for-hire services and seized more than 100 associated domains. This latest action expands on those efforts by targeting all known booter sites, shutting down as many as possible, and coupling enforcement with a public education campaign on the harms caused by illegal DDoS activity.

Assistant U.S. Attorneys Adam Alexander and Ainsley McNerney are prosecuting the case in the District of Alaska. The Justice Department emphasizes that booter and stresser services not only harm direct targets but also undermine broader internet reliability and safety. As digital dependence grows, such crackdowns signal a sustained push to disrupt the ecosystem enabling low-cost, high-impact cyberattacks—and to deter would-be offenders by removing the domains and infrastructure these services rely on to operate.

Parallels Desktop Vulnerability Gives Any Local Mac User Full Root Access, Intel Mac Users Left Without a Clear Fix



 

Parallels Desktop

Apple Device Vulnerability CVE exploits Cyber Security Developers JFrog Security Mac macOS Parallels Desktop

Parallels Desktop Vulnerability Gives Any Local Mac User Full Root Access, Intel Mac Users Left Without a Clear Fix

Security researchers at JFrog disclosed the vulnerability on Tuesday, assigning it the identifier CVE-2026-90894 and the nickname "ParaShells." JFrog rates the flaw 7.8 out of 10 on the CVSS severity scale. The bug does not allow remote attacks over a network. An attacker needs code already running on the machine as an ordinary local user, but once that condition is met, exploitation does not require administrator rights, a signed Parallels client, or an active virtual machine.

What Parallels Desktop Is and Why This Matters

Parallels Desktop runs Windows and Linux inside virtual machines on a Mac. It installs a background service called prl_disp_service that runs as root, because its work includes setting up host networking and unpacking virtual machine packages. The flaw is on the Mac side of the product, so the machine at risk is the Mac itself rather than the virtual machines on it.

That distinction is important. Many Mac users who run Parallels think of security risks as something that might affect the virtual Windows or Linux environment inside. ParaShells skips the guest entirely and compromises the Mac host directly.

How the Attack Works

The exploit chains together three separate weaknesses, none of which would be enough on its own.

The vulnerability combines three security weaknesses: a world-writable Unix socket, weak local client authentication, and argument injection during appliance extraction. On a default installation, prl_disp_service listens through /var/run/prl_disp_service.socket. JFrog researchers found that the socket could have 0777 permissions, allowing any local process to connect.

The login call that follows, PrlSrv_LoginLocal, checks only the credentials the kernel reports for the connecting process. It needs no Parallels code signature and works for an account that is not an administrator.

The third piece is where things get technically interesting. To install a virtual machine appliance, the service builds its unpack command as one line of text, tar -xf "%1" -C "%2". It then splits that text back into separate arguments using Qt's QProcess::splitCommand. The caller chooses part of that text, because it picks the folder the new virtual machine goes into. A double quote inside the folder name closes the quoting early, so whatever the attacker put after it becomes extra options for tar instead of part of a path.

The option JFrog used was --use-compress-program, which tells macOS tar to hand the archive to another program first. Because tar is running as root here, that program runs as root too. JFrog's test script wrote a passwordless sudo rule and opened a root shell.

In the lab demonstration, the sequence plays out in seconds: connect to the socket, send a crafted appliance install request with a poisoned directory path, and watch the compression program execute as uid 0. JFrog assembled this into a one-liner but has chosen not to publish that script, releasing the technical breakdown without the ready-to-fire weapon.

Yuval Moravchick, JFrog's vulnerability research team lead, explained: "The chain is short: A world-writable Unix socket, a login that trusts peer credentials rather than a Team ID, and an appliance unpack path that builds tar arguments using Qt string splitting. A quote in the parent path injects --use-compress-program=, and macOS tar runs the attacker's script as uid 0."

Who Is Most at Risk

The danger is highest on developer laptops, where a single poisoned Homebrew formula or malicious npm preinstall script can go from local user to full control, and on shared university and corporate machines that have many local accounts.

The threat model here is real and not hypothetical. Software developers routinely run third-party tools through package managers like Homebrew or execute npm scripts from projects they pull from the internet. Every one of those code paths represents a potential entry point for an attacker who knows the machine has Parallels installed. On a shared training lab or university computer lab Mac with a dozen local accounts, a single weak password or compromised student account is all it takes.

"From root, the attacker can replace system software, read other users' data, and persist via launchd," Moravchick noted. That last point about launchd persistence is particularly concerning because an attacker who establishes root access through this chain can survive a reboot by registering their own background processes with macOS's system daemon manager.

JFrog also confirmed no virtual machine needs to be actively running. The vulnerable service, prl_disp_service, starts automatically via a launch daemon at load, runs as root, and exposes the socket regardless of whether any VM is open. Simply having Parallels Desktop installed is enough to create the exposure.

The Patch Is Out, With a Catch

JFrog reported CVE-2026-90894 to Parallels maker Alludo, which fixed it in Parallels Desktop v27.0.0, released at the beginning of September 2026. The fix is real, but getting to it is not straightforward for a meaningful portion of Parallels' user base.

Parallels Desktop 27 needs a Mac with an Apple silicon chip. Its system requirements list Apple silicon only for the processor and macOS Sonoma 14.7 or newer for the operating system. On earlier releases of macOS, including Ventura 13, the installer sets up an older version of the product instead. Parallels removed Intel Mac support in version 27 and says the change follows Apple's plans rather than its own.

For Intel Mac users, the situation is murky. Intel users are told to stay on Parallels Desktop 26. "Parallels Desktop 26 fully supports Intel-based Mac computers today, and that will not change," the company wrote on 25 August, three weeks before this flaw became public, adding that Intel users can keep using version 26 and "expect future security and maintenance updates."

The problem is that according to JFrog, "Hosts that stay on the 26.x line, including 26.4.2, do not have that extract change." JFrog does not say it tested 26.4.1 or 26.4.2, and its writeup says it did not check older builds.

Parallels has not published a statement about CVE-2026-90894, and its list of security fixes, which maps each flaw to the version that repairs it, has not been reviewed since May 2025 and does not include this one. That leaves Intel Mac users running Parallels in a difficult position: a confirmed flaw, a fix that requires hardware they do not have, and no public acknowledgment from the vendor about plans for their platform.

The release notes for Parallels Desktop 26.4.2, which shipped on September 8, describe a single change related to Enterprise edition deployment and say nothing about a security fix for the extract path.

What Organizations Should Do Now

JFrog's immediate guidance comes in three parts: find every Mac in your environment running Parallels Desktop, restrict who can log in to those machines locally, and upgrade to version 27.0.0 or later where possible.

Two commands can confirm exposure without making any changes to the system. Running defaults read "/Applications/Parallels Desktop.app/Contents/Info" CFBundleShortVersionString reports the installed version, and ls -l /var/run/prl_disp_service.socket shows the socket permissions. JFrog says a socket showing srwxrwxrwx on a build at or near 26.4.0 should be treated as exposed until a patched build is confirmed.

Administrators using device management to push updates should check version rules before pushing anything. Parallels warns that a policy which sends out new major versions automatically will try to install version 27 on Intel Macs and fail.

One more complication: none of the published material says whether installing a fixed build removes access an attacker has already taken. JFrog notes that an attacker who reaches root can keep a foothold through launchd, which a product update would not clear. For any machine where compromise is suspected, an update alone is not enough.

Acronis Discloses Actively Exploited Privilege Escalation Bug in Its cPanel Backup Plugin



 

vulnerabilities and exploits

acronis cPanel CVSS Cyber Security Linux sensitive data system files vulnerabilities and exploits

Acronis Discloses Actively Exploited Privilege Escalation Bug in Its cPanel Backup Plugin

Acronis has confirmed that attackers are actively exploiting a high-severity security flaw in its backup plugin for cPanel and WebHost Manager (WHM), urging system administrators to install available patches without delay.

The vulnerability, tracked as CVE-2026-87886 and rated high severity, allows local privilege escalation through insecure file permissions. Classified under CWE-276 (incorrect default permissions), the flaw affects Linux-based installations of the Acronis backup plugin and, if exploited successfully, could allow a threat actor to compromise system confidentiality, integrity, and availability.

The flaw received its CVE designation on Tuesday, September 16, after Acronis quietly published a brief initial advisory over the weekend. The company assigned it a CVSS severity score of 7.8.

What the Plugin Does

To understand the risk here, it helps to know what this software actually sits on top of. The Acronis Backup plugin for WHM and cPanel gives hosting providers and web professionals cloud backup capabilities and granular, self-service recovery for end clients, including the ability to back up an entire cPanel server to cloud storage.

Acronis is a cybersecurity and data protection technology company that is popular among web hosting providers and managed service providers, since its platform lets them offer backup and security to their clients under their own branding. Its backup add-ons connect cPanel and Plesk to Acronis' cloud infrastructure, letting administrators back up and recover sites, databases, and mailboxes.

That puts the plugin in a particularly sensitive position on any server it runs on. An attacker who can escalate privileges inside this kind of environment has a direct path to the backup data of every customer account on that server.

The market footprint here is worth noting. According to the 2026 Web Hosting Trends Report by WebPros, cPanel/WHM leads the hosting control panel market with 64% adoption, while Plesk accounts for 31%. Both platforms are affected by this vulnerability, though active exploitation so far appears confined to cPanel and WHM deployments.

How the Attack Works

CVE-2026-87886 stems from insecure file permissions and allows authenticated attackers to achieve local privilege escalation without any user interaction. The vulnerability's CVSS string indicates that it can be exploited in low-complexity attacks, meaning the attack does not require special conditions or circumstances beyond the attacker's control to succeed.

In plain terms: an attacker who already has a low-level foothold on a vulnerable Linux server running this plugin can use this flaw to climb to higher privilege levels, without needing to trick a user or wait for any specific system event. Depending on the access gained, this could allow sensitive data to be accessed or modified and could potentially disrupt the server.

The type of data at risk includes backup data, system files, and customer account data.

Targeted Attacks, Limited Disclosure

Acronis' advisory language around the exploitation is measured but direct. The company stated that "exploitation of this vulnerability has been detected in the wild in limited, targeted attacks against Acronis Backup plugin for cPanel and WHM deployments."

However, the disclosure comes with some important caveats. BleepingComputer reported that Acronis based that assessment on a single report from a potentially affected customer. That is enough to justify urgent patching, but it is not the same as evidence of broad, automated exploitation across hosting providers.

There are currently no signs of active exploitation on Plesk deployments. Still, the extension for Plesk remains vulnerable and should be patched regardless.

Acronis has not published detailed technical information about the flaw, saying it wants to give system administrators time to apply available patches before sharing further details. The company has also identified no specific indicators of compromise and has not disclosed when the activity occurred or what attackers achieved beyond the privilege escalation impact described in the advisory.

What Needs to Be Patched

Acronis pushed out security updates for the affected plugins before the CVE was formally assigned. The versions administrators need to be on are:

Acronis Backup plugin for cPanel and WHM builds earlier than 1.9.3.1021, now fixed in version 1.9.3 HF3, and Acronis Backup extension for Plesk builds earlier than 1.8.11.638, fixed in version 1.8.11.

For shared hosting providers, the guidance is to check every server image and automation path, rather than assuming the version on one control-plane node represents the entire fleet. Once patched, administrators should also focus review on systems where initial access was plausible: servers hosting compromised sites, accounts with recent credential resets, and hosts that allow customers to upload or execute code.

One additional note worth flagging: a cPanel or Plesk server without the Acronis plugin or extension is outside the scope of CVE-2026-87886. This is an Acronis integration issue, not a blanket advisory for every cPanel, WHM, or Plesk installation.

Acronis is a Swiss cybersecurity company headquartered in Schaffhausen and operates a global network of cloud data centers, supporting over 20,000 service providers that protect approximately 750,000 businesses worldwide. That scale makes vulnerabilities in its hosting integrations a high-priority concern for the managed service provider community, where a single compromised server can cascade into customer data across dozens or hundreds of accounts.

The company has not indicated whether it plans to release a more detailed post-mortem on the exploitation activity once patching rates improve, which is a common practice after actively exploited flaws. For now, the immediate priority is getting affected installations onto the fixed builds before whatever foothold attackers have found gets wider use.

Homebrew 7.0.0 Ships With Fixes for Eight Security Advisories



 

macOS Security

Cyber Security cybersecurity vulnerability Intel Intel Security Linux Mac security updates macOS macOS Security

Homebrew 7.0.0 Ships With Fixes for Eight Security Advisories

Homebrew, a popular package manager for installing command-line tools and desktop apps on macOS and Linux, released version 7.0.0 on Sunday, with eight security advisories closed in the process. The most severe of the 18 reported issues is an unsigned removal metadata vulnerability for a cask, a formula in Homebrew's format for prebuilt app installs, allowing arbitrary sudo commands.

Homebrew removed the vulnerable recovery code and associated API accessors. Seven of the advisories were addressed in earlier 6.0.x releases, which means auto-updating machines already carry those fixes. The eighth is new and would let a malicious cask execute code outside the sandbox of a macOS via LaunchServices. Homebrew classified the issues as one High, two Moderate, and five Low. The High severity sudo path issue was fixed in 6.0.12, where a Moderate was also addressed for preventing the installer from reading Git config owned by the Homebrew prefix, which could run programs as root.

The second Moderate is the LaunchServices escape mentioned earlier, which is fixed in 7.0.0 by restricting launching of applications, Mach services, and Unix socket connection. The five Low-level issues were fixed earlier and involved redirects and file paths pointing to unintended locations, including headers leaks, tap-restriction bypasses, and files being written outside of staged source trees. The new 7.0.0 brings a built-in scanner (`brew vulns`) that checks for known vulnerabilities in installed formulae, with flags such as `--severity=high` and `--fix-available` to narrow the results, against a database of known vulnerabilities in formulae versions that have been shipped.

It includes backported fixes for some issues and minimizes false positives, with Homebrew's data on vulnerabilities being in the OSV format with a CC0 license and published through the Homebrew API. Provenance checks are now performed for third-party tap bottles, in addition to the Homebrew core tap, with new taps publishing these by default. Homebrew notes that tap trust remains the primary defense against malicious casks, with sandboxing not making "untrusted software safe to run" due to apps running with the user's privilege and a vendor's installer not running inside the sandbox.

Nonetheless, 7.0.0 provides sandboxing of formula and cask operations, provides setup instructions as signed data instead of arbitrary Ruby code, and deprecates old post-install blocks in favor of declaring steps. On Linux, Bubblewrap sandboxing is replaced with Landlock, a new kernel feature that requires no additional dependencies. Intel Macs are moved to Tier 3 status following the end of reliable build infrastructure and cessation of routine Intel bottles, with support continuing until September 1, 2027, and MacPorts suggested as an alternative. macOS 10.15 is dropped with the release, while Sonoma 14 is moved to Tier 3.

Study Warns Enterprise AI Rollouts Are Outpacing Data Security Checks



 

Enterprise AI Security

Ai Data AI technology AI tools Cyber Security cybersecurity research data security enterprise AI Enterprise AI Security

Study Warns Enterprise AI Rollouts Are Outpacing Data Security Checks

Companies are adopting AI tools faster than they are testing whether their underlying data is appropriately secure, a new report from governance firm Syskit suggests. Based on a survey of 327 IT and security decision-makers at U.S. and U.K. organizations with at least 500 workers, Syskit's State of Microsoft 365 Governance Report, published Sept. 10, found that 76% of the companies surveyed had deployed or tested enterprise AI tools such as Copilot in their Microsoft 365 environments, but less than half (43%) had conducted a thorough review of file permissions and potential oversharing risks prior to deployment, and the rest skipped the review process or reviewed only partially.

There was a similar gap for oversight over AI agents. While 91% of respondents said they were confident about their knowledge of what AI agents were and had access to, in practice, barely one in five companies (22%) had a formal policy outlining permitted agents' access, and roughly one in 10 (9%) had an agent that had inherited all the permissions of the person who had deployed it. "If you look at tools such as Copilot, you can see the value it can bring," said Syskit CEO Toni Frankola, noting that some content could be exposed purely based on permissions that had been set years ago and then simply forgotten about, and that AI had removed the friction that had previously prevented accidental exposure.

"Permission audits may be the most critical and least desirable step in preparing a safe and secure AI deployment." The report also highlighted areas of weakness in Microsoft 365 environments overall. Roughly 41% of organizations had SharePoint sites that were publicly available with no access restrictions, 35% had visible files for past employees, and a third had files shared publicly with "Everyone." Ownerless content was the biggest concern, with 47% of organizations citing orphaned teams, groups and sites, which had no one accountable for reviewing or securing them, despite being accessible to an AI just as readily as any other content.

"There seems to be a disconnect between confidence and reality with regard to the management and control of data and information," said Frankola. "While eight in 10 (83%) organizations feel confident that they know exactly who can access specific sensitive information, only 4% could provide a complete access report for an auditor within an hour if asked ... and more than half would need at least a day to prepare one." Perhaps most concerningly, 90% of organizations said they had suffered or suspected a security incident related to incorrectly configured permissions or excessive access in the last two years, and 39% confirmed that a security incident had definitely occurred.

Nintendo Switch Security Flaw Lets Nearby Attackers Exploit QR Codes Used to Share Screenshots



 

switch

Cyber Security Data Theft Nintendo qr code switch

Nintendo Switch Security Flaw Lets Nearby Attackers Exploit QR Codes Used to Share Screenshots

Nintendo has issued an urgent security advisory for owners of the original Switch console, warning of a flaw that could allow an attacker in close physical proximity to run unauthorized code on the device or pull data stored on it, simply by scanning a QR code displayed on the screen.

The vulnerability, catalogued as CVE-2026-82079, sits inside the console's local wireless networking stack and is classified as a stack-based buffer overflow, a type of memory corruption flaw in which a program writes more data into a fixed-length block of memory than it can hold. According to the technical record logged on OpenCVE, an attacker within wireless range can send specially crafted network packets that overflow this buffer and hijack the execution path of the device using a technique called return-oriented programming, which chains together fragments of existing code to carry out malicious instructions.

The bug affects all Nintendo Switch consoles running firmware earlier than version 23.0.0. The Switch 2 is not affected.

Where the QR code comes in

The attack is not theoretical in isolation, but it does require a specific scenario to work. The vulnerability surfaces when the console generates a QR code as part of its "Send to Smartphone" feature inside the Album application, which players use to transfer screenshots and video clips to a mobile device. It also appears when the local wireless function is active during a session of Mario Kart Live: Home Circuit, a game that pairs a real-world physical kart with the console.

In both cases, a QR code is briefly displayed on the Switch screen or the connected TV. Nintendo's advisory states that an attacker would need to physically scan that code while it is visible. If they manage to do so, the console becomes vulnerable to arbitrary code execution or information disclosure.

Nintendo said it has no evidence the flaw has been exploited in the wild as of September 10. The company also did not say that the vulnerability could be used to steal Nintendo account credentials, though it acknowledged that more serious exploits could theoretically be built on top of it.

Update now, or take these precautions

The fix is straightforward: install system update 23.0.0. Consoles connected to the internet will pull the update automatically, but players should verify the installation has completed in the console's System Settings under System and then System Update.

For players who cannot update immediately, Nintendo recommends keeping QR codes out of sight during photo and video sharing sessions. The company also advises against using another person's smartphone when transferring media, and against letting anyone else use their kart during a Mario Kart Live: Home Circuit session, since either scenario could create an opportunity for an attacker to scan the code.

How exposed is the player base

The scope of this issue is substantial purely because of how many original Switch units are in circulation. The original Switch has shipped over 155.92 million lifetime units as of March 31, 2026, making it one of the best-selling consoles ever made. Even with the Switch 2 now in the market, tens of millions of households around the world are still running the original hardware day to day.

Nintendo said the flaw was discovered and reported by external security researchers, though it did not name them in its advisory, which was published on September 10.

The practical risk of this exploit being triggered in a real-world attack is relatively narrow. An attacker would need to be physically close to the device, see the QR code on screen, and scan it within the brief window it is displayed. That is a more demanding set of conditions than most software vulnerabilities require. But the potential consequence, unauthorized code execution on the console, is serious enough that Nintendo moved quickly to patch it, and players should move just as quickly to install that patch.

Check Point Discloses Two Critical VPN Vulnerabilities Allowing RCE



 

VPN

Check Point Critical Vulnerability Cyber Security RCE VPN

Check Point Discloses Two Critical VPN Vulnerabilities Allowing RCE

Check Point has addressed two critical flaws in the way its management and firewall products manage VPN certificates. Both vulnerabilities have been assigned a CVSS score of 9.8 out of 10. This makes them one of the most serious flaws impacting the products. The vulnerabilities could permit an unauthorized remote threat actor to run malicious code on compromised devices.

The flaws, tracked as CVE-2026-85103 and CVE-2026-85102, are associated with the validation and processing of digital certificates utilized during VPN connections.

Technical information

The first flaw, CVE-2026-85103, is associated with a heap-based buffer overflow in the VPN certificate data processing. A threat actor may send particularly tailored certificate details to a compromised device and trigger memory corruption.

The second flaw, CVE-2026-85102, is associated with improper verification of certifications during VPN processes. A threat actor could exploit the flaw without getting genuine verification credentials under certain conditions.

The flaws impact Check Point Security Gateways, while the impacted product range also consists of Security Management Server for the related flaw.

The vulnerabilities affect Check Point Security Gateways, while the affected product range also includes Security Management Server for the relevant flaw.

Potential risks

The flaws can have major risks to enterprises that use Check Point Security Gateways to give site-to-site VPN services or remote-access.

An unauthorized attack may be problematic as the threat actor may not need genuine VPN credentials before trying to abuse the vulnerable component. In case of successful exploitation, remote code execution (RCE) could let a threat actor infect the impacted security infrastructure and may use it as a starting point for more compromise inside an enterprise.

But, Check Point has signalled that it has no proof that these flaws have been abused in the wild. Thus, the incident should be looked at as a critical patching issue and not an active exploitation campaign of the flaws.

Addressing the flaws

The security updates offered by Check Point should be applied to organizations immediately. Admins should check Check Point’s security advisory for the particular product variants and related fixes.

Organizations should also keep an eye for Security Gateway systems and VPN for suspicious activity, unusual certificate-related requests, or suspicious connections.

As both flaws have a CVSS score of 9.8, security teams should prioritize restoration, especially for internet-facing VPN infrastructure.

Microsoft Tracks Cloud Intrusion Campaign Using Passkey Phishing and Graph API Abuse



 

Google Microsoft

API Cloud Based Solutions Cyber Phishing Cyber Security cybersecurity research Cybersecurity Researchers Google Microsoft

Microsoft Tracks Cloud Intrusion Campaign Using Passkey Phishing and Graph API Abuse

Microsoft Security Research published a report on September 9, 2026, detailing active cloud-based intrusions spanning multiple accounts, in which unusual sign-ins were followed by threat actor-added authentication methods, high-volume Microsoft Graph activity, SharePoint and OneDrive downloads, and email collection through REST APIs.

According to Microsoft, the activity begins with identity-focused social engineering and impersonation infrastructure, then progresses through authentication persistence and cloud reconnaissance before culminating in targeted data access consistent with data collection and potential exfiltration. Microsoft Threat Intelligence assesses that the initial access techniques observed in this campaign are used by a range of threat actors, including Storm-3121, Storm-3032, and others.

The attack typically begins with what appears to be a routine call or message to a user's personal phone number from someone posing as the organization's IT helpdesk. Microsoft found that a "passkey" narrative is frequently used as a pretext, guiding victims through adversary-in-the-middle phishing or device-code authentication flows designed to hijack their session.

Once initial access is achieved, the actor's first priority is converting a temporary compromise into a persistent foothold. This is typically done by enrolling a new multi-factor authentication (MFA) method under the attacker's control, such as registering a new phone number, an authenticator app, or a software-based one-time password token. With MFA persistence established, the actor moves into an extensive internal reconnaissance phase, using Microsoft Graph to inventory users, groups, permissions, resources, and accessible content across the compromised tenant.

Following reconnaissance, the actor transitions into large-scale data collection across Microsoft 365 workloads. Microsoft observed significant volumes of FileAccessed and FileDownloaded events across SharePoint and OneDrive, indicating systematic retrieval of cloud-hosted documents and organizational data. Microsoft recommends that defenders investigate this attack sequence across identity, Microsoft Graph, SharePoint, OneDrive, and Exchange signals. For confirmed compromises, organizations should revoke active sessions and remove any unauthorized authentication methods added by the attacker.

Microsoft further advises enforcing phishing-resistant MFA through Conditional Access policies, along with Conditional Access rules requiring a managed, compliant device for access to Exchange, SharePoint, and Graph-privileged applications. Microsoft has published a list of indicators of compromise associated with the campaign. These include domains tied to fraudulent passkey support and setup lures, such as passkeyhelpdesk[.]com, secure-passkey[.]com, setupmypasskey[.]com, and add-passkey[.]com. Additional domains are linked to identity-provider sessions and key synchronization infrastructure, including oktasession[.]com, keysyncos[.]com, oskeysync[.]com, oskeysetup[.]com, oskeyregister[.]com, syncmykey[.]com, myconnectkey[.]com, and oskeyconnect[.]com. Other identified domains, validationsetupac[.]com and portalsetuphub[.]com, are associated with account validation and portal setup lures respectively.

Microsoft's report underscores the growing sophistication of identity-based attacks that blend social engineering with legitimate cloud APIs, making early detection across authentication and Graph activity critical for organizations defending Microsoft 365 environments.

The Four-Character Password Guarding Your Company's AI Keys



 

LiteLLM

AI keys API cloud environment Credential Theft CVE Cyber Security IAM Security LiteLLM

The Four-Character Password Guarding Your Company's AI Keys

Security researchers at Wiz scanned 3,074 internet-facing deployments of LiteLLM in February and found something that should embarrass more than a few engineering teams: 294 of them, just under 10 percent, accepted `sk-1234` as the administrator password. That is the exact value printed in LiteLLM's own quickstart guide, sitting above a comment telling operators to replace it with a long random value before any real use. As of September 9, the guide still reads that way.

The number sounds like a configuration slip, the kind that shows up in enterprise audits and gets quietly fixed. The consequences here are anything but quiet. LiteLLM sits between a company's applications and every AI provider it pays for. Whoever holds the master key can read every provider API key stored on the server, inspect every prompt and reply that moves through it, reach internal tools connected via the Model Context Protocol, and, as Wiz demonstrated, pull the cloud IAM credentials off the machine the gateway runs on. Researchers also found a code execution path that returned root access inside the container during testing. Attackers have since been seen using related flaws to install cryptocurrency miners and copy entire databases of provider credentials.

What LiteLLM Actually Is, and Why It Matters

LiteLLM is an open-source AI gateway. Companies use it as a single routing layer for more than 100 model providers, including OpenAI, Anthropic, AWS Bedrock, Azure, and Google Vertex AI. Rather than scattering API keys and budgets across every team and application, organizations push all their inference traffic through one place. That makes LiteLLM a centralized store for some of the most valuable secrets in a modern cloud environment.

According to Wiz's own cloud data, roughly one in three cloud environments already has a LiteLLM deployment. The project has more than 22,000 stars on GitHub. Many of those instances sit behind corporate networks and VPNs, unreachable from the internet. But the 3,074 Wiz found on Shodan in February were not.

The master key does two things at once, which is what makes a default value particularly dangerous here. It is the administrator credential for the proxy. It is also the secret LiteLLM uses to sign session JWTs with HS256. When it stays at `sk-1234`, anyone who knows that can forge arbitrary user sessions for the entire proxy without ever brute-forcing a password. They just already know it because they read the docs.

Of the 294 instances that accepted the default key, 191 had no master key set at all, meaning the server accepted any request. Before version 1.82.0-stable, gateways with no master key granted every incoming request full proxy administrator rights automatically, no credential needed.

How Far an Attacker Gets

Wiz researchers, working through LiteLLM's codebase with Claude Code, traced what an administrator credential actually unlocks beyond the obvious credential theft.

LiteLLM has a pass-through endpoint feature that lets administrators create proxy routes forwarding requests to any URL they choose. The target URL is never checked against private address ranges, localhost, or cloud metadata addresses. A researcher can point a route at the AWS instance metadata service and read back IAM credentials in a straightforward request chain. The feature works the same way against IMDSv2, which is supposed to require a specific token header to prevent exactly this kind of request. LiteLLM's header forwarding mechanism passes any header prefixed with `x-pass-` to the target with the prefix removed, so an attacker can send the IMDSv2 token request headers along for the ride.

Wiz describes this as arguably working as intended. LiteLLM's threat model treats administrators as trusted, and the project has not assigned it a CVE or issued a fix. The problem, as the researchers put it, is that the threat model has often been broken by deployments that never changed the default key.

The code execution path is a separate issue. LiteLLM lets administrators register custom Python guardrails, code that runs around every inference request to enforce policies like blocking sensitive prompts or filtering outputs. Before version 1.82.0-stable, the endpoint that registers a guardrail applied none of the safety checks present in the test interface. The test interface blocks `import`, `os`, `subprocess`, and strips Python's built-in functions before execution. The registration endpoint did neither. Submitted code ran with the full standard library, inside the container, at root, immediately on registration. Wiz showed this with a proof of concept returning `uid=0(root) gid=0(root)` in the guardrail's block reason field after a single chat completion call.

A second flaw, CVE-2026-40217, published in May, showed that even after the guardrail sandbox was added in 1.82.0, it could be escaped using Python bytecode techniques. That one affects versions 1.81.8 through 1.83.10. The same admin credential is the entry point for both.

The Disagreement Over Severity

Wiz and LiteLLM's maintainers describe the guardrail code execution flaw, CVE-2026-59821, in almost incompatible terms.

Wiz calls it post-authentication code execution at root level and shows test output to support that. LiteLLM's own advisory rates it as Low severity, with a CVSS score of 2.1, noting that the flaw requires a high-privilege account. Both are describing the same behavior. What they disagree on is how to weigh the significance of that requirement, given that high-privilege access was readily available on nearly 10 percent of public instances.

LiteLLM's published security policy categorizes attacks that depend on setup mistakes, such as leaving the master key at its default value, as explicitly out of scope and not treated as vulnerabilities. The project's position is that operators who do not follow the setup instructions have created their own exposure. That is a reasonable position for a software maintainer to take. It is a harder position to defend when the setup guide's own example value is still `sk-1234` months after researchers flagged the issue.

The Flaw Attackers Have Actually Used

The code execution and cloud credential paths described above are Wiz demonstrations. Real attackers have been doing something related but distinct, using a different set of flaws against the same product.

CVE-2026-59822, a separate flaw also found by Wiz, lets an unauthenticated attacker establish a valid MCP session using any Bearer token, including a single character. The authentication handler for LiteLLM's MCP endpoint catches a 401 error from a failed token validation and silently returns an empty authentication object, granting access as if the request were valid. CISA added this to its Known Exploited Vulnerabilities catalog on September 2, with a CVSS score of 8.8. Federal civilian agencies had until September 16 to address it. Wiz's honeypots first recorded it being used in the wild on July 7, in requests probing model listing endpoints with single-character tokens. The agency designation makes it an urgent patch for government networks; the active exploitation makes it pressing for everyone else.

CVE-2026-42271, a different flaw with a CVSS score of 8.7, let any authenticated user run commands on the host through two MCP test endpoints. Horizon3.ai reported in June that it could be chained with a Starlette host-header validation bypass, CVE-2026-48710, to achieve unauthenticated remote code execution on vulnerable instances. Wiz's honeypots recorded attackers using that chain to drop an XMRig cryptocurrency miner via an ELF binary, after first fingerprinting the host and killing competing mining processes.

Microsoft published a case in August where attackers went further. After getting command execution inside a LiteLLM gateway process, they read the container's environment variables for the master key, provider keys, and database connection string. They then used the database string to connect to the PostgreSQL backend and copy records from LiteLLM's model and virtual-key tables. Microsoft assessed with high confidence that the entry point matched the CVE-2026-42271 and CVE-2026-48710 chain. "Treat AI gateways as Tier-0 secrets stores," the company said.

These active attacks sit on top of a separate incident from earlier this year. In March 2026, attackers used stolen maintainer credentials to publish two backdoored versions of LiteLLM to PyPI, versions 1.82.7 and 1.82.8. The malicious packages collected SSH keys, AWS, GCP, and Azure credentials, Kubernetes secrets, and database configurations from any environment that pulled them as a dependency. DSPy, MLflow, CrewAI, and OpenHands all pulled the compromised versions. A subsequent analysis by Hudson Rock found a 153-gigabyte stolen archive linked to the incident, containing files attributed to roughly 2,500 corporate domains including AWS, Samsung, Cisco, and Salesforce. The supply chain attack and the authentication flaws are separate incidents, but they affect the same product, and some organizations are managing fallout from both simultaneously.

What Needs to Happen

Every flaw in the Wiz report is patched in version 1.84.0 or later. The upgrade covers the MCP authentication bypass, the guardrail code execution flaw, the sandbox escape, and the endpoint that let non-admin accounts reach the pass-through configuration. There is no patch for the pass-through route to instance metadata, because LiteLLM does not treat it as a vulnerability. Restricting outbound network access from the container and scoping the workload's cloud IAM role as narrowly as possible are the only controls available for that path.

Changing the master key from `sk-1234` to a long random value requires no upgrade at all and closes every attack path in Wiz's report that depends on holding it. One check is worth doing before rotating: if a separate salt key is set in the configuration, the rotation procedure differs, and using the wrong one can leave stored credentials unreadable.

Organizations that cannot upgrade immediately should block the `/mcp/` path and the two MCP test endpoints at their reverse proxy or API gateway. Blocking `POST /guardrails/test_custom_code` and restricting the guardrail creation and update endpoints to administrators are the workarounds in LiteLLM's own advisories.

If there is any chance an attacker had access, the guardrails list should be reviewed for entries that were not created by the team, and the process should be restarted to clear code held in memory. Guardrails an attacker registered and SSH keys they may have added persist through an upgrade. The provider keys, master key, and database credentials should all be rotated.

The underlying issue is structural and not unique to LiteLLM. AI gateways now hold credentials for every model provider, execute server-side code, connect to internal tools through MCP, and run with the cloud permissions of the workloads they are deployed in. They have become critical infrastructure that is often still being treated as a developer convenience. The security controls surrounding them have not caught up.

DoppelCart Fake-Shop Network Found Operating Across 119,000 Domains



 

fake websites

Cyber Security cybersecurity research Domain E-commerce Websites Compromised Fake Domains fake network fake URLs fake websites

DoppelCart Fake-Shop Network Found Operating Across 119,000 Domains

A newly published investigation has uncovered what may be the largest documented fake-shop network to date, spanning roughly 119,000 domains and dubbed "DoppelCart" by researchers at nebty. The cluster's .shop domains alone account for 2.72 percent of the entire .shop domain population captured in a September 2026 snapshot — roughly one in every 37 domains registered under that extension.

The investigation, led by Benedikt Scheungraber and published September 7, began not as a large-scale probe but as routine work handling individual customer complaints. Researchers found fake shops targeting several clients and arranged for their removal, but noticed the same infrastructure patterns recurring across unrelated takedowns and monitoring cases. Using publicly accessible website scans from urlscan, the team began connecting domains and quickly realized the scale far exceeded a handful of isolated scam sites — eventually tracing around 119,000 associated domains back to a single technical foundation dressed up as countless different brand identities.

To put the discovery in context, researchers compared it to other publicly documented fake-shop networks. BogusBazaar, reported by SRLabs in 2024, spanned more than 75,000 domains over several years, with about 22,500 active at any one time. FraudWear, documented by CTM360 in 2026, involved over 30,000 domains with roughly 8,000 simultaneously active. Malwarebytes identified a cluster of more than 20,000 domains in March 2026, while Netcraft's Fibergrid investigation found 16,700 active fake shops on connected hosting infrastructure in April 2026.

DoppelCart's scale surpasses all of these prior cases. What makes the fake shops convincing, according to the investigation, is their use of genuine material lifted from real businesses. Examined storefronts featured product descriptions copied word for word from legitimate online stores, including detailed explanations of product features and construction. In some cases, the fake sites even embedded images directly from the legitimate brand's own image servers, pairing authentic-looking product photos with advertised discounts of 65 percent to create a convincing illusion of a genuine sale.

The fallout lands squarely on the copied businesses. Because many fake shops list the legitimate store's real support address, customers who never receive their orders end up contacting the authentic company, forcing its support staff to untangle orders they never placed or received payment for — all while trust in the real brand suffers.

To help affected companies respond, the researchers are publishing the full investigation database, allowing businesses to search for their own brand name or domain and review classifications and evidence for each entry. Journalists and security researchers can request the underlying raw data, including archived HTML pages, by contacting the team directly. While takedowns pursued so far have kept removed stores offline, the majority of the DoppelCart cluster reportedly remains active.

LG Targets Residential Proxies in New Smart TV Security Move



 

WebOS Apps

Connected Device Security Cyber Security LG Smart TV Proxy SDKs Residential Proxies Residential Proxy Networks Smart TV Security WebOS Apps

LG Targets Residential Proxies in New Smart TV Security Move

Several webOS apps using residential proxy technology are being suspended by LG Electronics for routing third-party traffic through smart TVs. The company is working with developers to remove proxy functionality, and apps that fail to do so will be suspended. According to research conducted by security firm Spur, residential proxy software is embedded in a significant number of LG and Samsung smart TV apps.

A proxy SDK was identified in 2,058 of 6,038 examined applications, raising concerns about how television owners' internet connections may be exploited without clear awareness of the activity. As a result of the study, more than 42% of LG webOS apps examined contained residential proxy functionality, while 26.5% of Samsung Tizen apps did not. As a result of such software, a device's connection to the internet and public IP address can be used as part of residential proxy networks.

Web data collection, advertisement verification, optimization monitoring and market research are some of the legitimate business uses of residential proxies. However, the same infrastructure can also be misused for the purpose of concealing malicious activity. Recent takedowns of large residential proxy networks have demonstrated the dangers associated with the use of compromised consumer devices as proxy nodes.

A particular concern is associated with smart TVs because proxy software can continue to operate while connected to the internet. According to Spur researchers, unclear consent mechanisms can lead users to be unaware that their connection has been shared with other parties or that their IP address may be exposed to third parties.

In a statement provided by LG Senior Vice President John Taylor, the company is working with developers to eliminate the residential proxy option from webOS applications. While the company has not provided a specific deadline for developers, apps that retain the functionality will be suspended. In Spur's research, some SDKs remain active after the associated TV app has been closed, making the concern even more serious when the proxy is running in the background.

Some applications are presented as alternatives to advertisements using the TV's internet connection. This model allows apps to remain ad-free and utilize the internet connection to perform activities such as web indexing while using the television's internet connection as an alternative to advertisements. This model poses a security risk that goes beyond exposing the household IP address.

A smart TV is connected to a local network that includes routers, printers, cameras, and storage units. It is possible for the TV to provide a path to other systems on a network if proxy traffic is permitted to reach private network addresses or if filtering mechanisms are not effective. Spur's analysis also observed different implementations of proxy SDKs that enforce these boundaries.

In the sample of Bright Data, restrictions were established for private and reserved IP ranges; however, comparable protections were not observed for the local versions of Massive and Honeygain/Oxylabs SDKs examined. It is therefore necessary to rely heavily on filtering on the provider's end, customer screening, and abuse controls to prevent this type of misuse. The wider platform policies add another level to this problem.

While Amazon explicitly prohibits the use of proxy services for third parties, Roku has also been reported to restrict similar software. LG and Samsung previously did not institute a public restriction that would prevent proxy-enabled applications from using their TV platforms. Instead of relying solely on store descriptions or permission prompts, the research involved an analysis of actual LG webOS and Samsung Tizen application packages.

A team of researchers analyzed the applications to confirm fingerprints associated with residential proxy SDKs, such as Bright Data, Massive, and Honeygain/Oxylabs components, and has denied the suggestion that proxy networks are intrinsically unsafe. The data provider mentioned consent, customer vetting, and governance measures, whereas Massive stated that their network employs KYC checks, server-side controls, and consent checks.

In addition, Oxylabs said it implements filtering and local-network restrictions using both infrastructure and SDK-level controls. However, LG's issue is now more complex than the removal of individual applications alone. Through its scheduled review of webOS apps, the company may determine whether residential proxy functionality is subjected to greater scrutiny during the approval process for the platform's apps.

As a result of this change, smart TV applications are also required to disclose background network activity and obtain consent for services that continue to operate after an app is closed. It is LG's intention to take action on its planned plans that illustrates the need for clearer disclosures, stronger app review policies, and effective controls surrounding residential proxy services.

Ransomware Affiliate Pretends to be Recovery Service for Extortion



 

Ransomware

Cyber Security Extortion Ransom Busters Ransom Payments Ransomware

Ransomware Affiliate Pretends to be Recovery Service for Extortion

An alleged ransomware affiliate is pretending to be a ransomware recovery service named “Ransom Busters,” reaching out to victims before the attacks become public and claims it can delete stolen data and provide decryption keys for some fees.

Fake ransomware recovery service

The activity was discovered by GuidePoint Security’s Research and Intelligence Team (GRIT) after it responded to various cases where targets got emails apparently from Ransom Busters, contacting to provide help in recovering from the ransomware attack.

This seems suspicious because cybersecurity firms usually contact ransomware victims to offer recovery services or consulting after the attack has happened and becomes public knowledge. But in this case, Ransom Busters’ knowledge about the attack that was not yet public raises questions.

GRIT believes Ransom Busters to be working across various ransomware operations, and have taken a new extortion approach.

The group contacted victims via emails, requesting to get in touch with their CEO or IT leadership.

According to GRIT, the email said “I am a representative of a project that assists victims of cyberattacks. We have been identifying vulnerabilities and infiltrating the servers of criminal groups for over three years. On the server we recently accessed, we discovered data stolen from your company [...] We can return your files to you and destroy all backups held by the group. Additionally, we have gained access to the encryption key storage and can help you regain access to your encrypted files.”

Extortion tactic

In the communications after this mail, Ransom Busters said they found the flaws in the admin panels of various ransomware-as-a-service (RaaS) operations. It offered to remove the stolen data from ransomware servers such as Settra, DragonForce, and Anubis, for a fee of $20,000 to $60,000.

But evidence from the two incidents has led GRIT to suspect that Ransom Busters is the group responsible for the attacks.

In both incidents, the threat actors used the same software such as s5cmd, Remotely remote monitoring tool, and SoftPerfect Network Scanner. The group also used the same approach to create a local backdoor account via the same threat actor-controlled hostname 'DESKTOP-BBETH6K' and password Numlock!123'.

The attacker claimed this access gave them command over “almost all of their infrastructure,” according to GRIT. The aim of Ransom Busters seems to be financial, like other RaaS groups.

Impact on ransomware victims

Ransomware groups such as Ransom Busters cannot be trusted as they use deceptive tactics for extortion payments. In these incidents, it is observed that even payments to these gangs does not guarantee recovery of stolen data and if it will be deleted. If your organization receives such mails, it should be immediately reported to the response team.

Elementor Pro WordPress Flaw Exploited to Upload Webshells and Execute Commands



 

Glutton PHP Backdoors

Critical Vulnerability CVE CVE exploits CVE vulnerability Cyber Security Cyber Servers data compromised Glutton PHP Backdoors

Elementor Pro WordPress Flaw Exploited to Upload Webshells and Execute Commands

A critical vulnerability in the Elementor Pro WordPress plugin is being actively exploited to upload malicious PHP files and execute commands remotely on the affected websites.

The vulnerability, tracked as CVE-2026-32475, affects the Elementor Pro versions 4.2.1 and lower. This issue was patched on August 19. Elementor Pro has more than 6 million active installations and is widely used to design WordPress websites with drag-and-drop tools.

The vulnerability is related to the insufficient validation of file-upload arrays in Elementor Pro forms. Attackers can exploit this issue by uploading an empty file as the first element of the upload array and a malicious PHP file as the second. Then the plugin will not validate the following files in the array, thus allowing the attacker-controlled PHP payload to be successfully uploaded on the server without any additional checks.

Once the malicious file is uploaded, it will be stored on the /wp-content/uploads/elementor/forms/ directory with a randomly generated name but preserving the attacker’s .php extension. Then the attacker will be able to directly access this file on the server to execute arbitrary commands and potentially deploy a webshell for further attacks. To successfully exploit the vulnerability, an attacker needs to have access to a WordPress website with a published Elementor Pro Form widget that contains at least one File Upload field.

This is a relatively common case for WordPress websites that utilize Elementor Pro forms. WordPress security company Defiant, which operates the Wordfence firewall, noted that exploitation began on August 19, the same day Elementor released the 4.2.2 version to address the vulnerability. Wordfence observed that the traffic was especially heavy between August 19 and 23, having blocked more than 190,000 attempts to target its customers.

Wordfence has identified IP addresses that were responsible for thousands of exploitation attempts. Website administrators can add these addresses to their blocklists to protect their WordPress sites. Administrators that utilize Elementor Pro need to make sure to update their software to the latest versions, preferably 4.2.2 or newer. Moreover, they should check their /wp-content/uploads/elementor/forms/ directories for any unexpected .php files.

As the name suggests, the directory is supposed to contain the files that users upload with Elementor forms, meaning that the discovery of any .php files should be investigated and potentially result in an intrusion assessment.

redactproxy, a tool that lets pentesters use AI without leaking client data



 

redteaming

AI Pentesting Cyber Security Pentesting redteam redteaming

redactproxy, a tool that lets pentesters use AI without leaking client data

AI coding agents are now part of a lot of security work. They are good at the parts a tester has no time for: going through every request, every parameter and every file rather than a sample of each. But none of that work happens on your machine. Everything the agent reads is sent to a model running on someone else's servers. So are you sending your client's data to an AI provider?
Where the client's data goes

The moment you point one of these agents at a live engagement, everything it touches reaches a third party. Client domains. Internal hostnames. Credentials pulled out of a config file. Employee email addresses. The client's own name, in the folder path, in the ticket reference, in the commit message. A testing agreement authorises you to access the client's systems. It rarely says anything about transmitting their contents to a model provider, and the same gap shows up against PCI-DSS, HIPAA and SOC 2 data-handling clauses.

The usual advice lands in one of two places: run a local model, or don't paste client data. Both work. Both cost you the thing you wanted. A 7B model on a laptop is not the model that spots the subtle chain across three hosts, and an agent you feed carefully redacted scraps by hand is an agent you are babysitting instead of using.

There is a third option. Almost none of that data needs to be there in the first place: the model does not need the real hostname to reason about a finding on it. It needs a hostname that stays the same every time it sees it.

That is where redactproxy(https://github.com/CSPF-Founder/redactproxy) comes in.

Where the model runs

Before we get to what redactproxy does, we need to understand where the work actually happens. Claude Code is the part on your machine: a terminal tool that reads your files, runs your commands and collects the output. The model is not on your machine at all: it runs on an AI provider's servers, Anthropic for example. Claude Code does no reasoning of its own, so anything it needs an answer about, including the scan output and the config file it just read, is sent to those servers over the API.

RedactProxy

redactproxy is an open-source tool from the Cyber Security & Privacy Foundation. It sits between Claude Code and the provider, on your own machine, and rewrites that API traffic in both directions. On the way out it replaces real client values with stable fake ones. On the way back it puts the real ones in again, before Claude Code ever sees the response.

The provider only ever sees placeholders. Your tool calls still run against real infrastructure, because the substitution back happens before the response reaches the agent. When the model writes a Bash command against a placeholder hostname, Claude Code receives the real hostname and runs it against the real host. Not just the first time: on every response, ten turns later, for the life of the conversation.

The swap happens inside the traffic itself, so nothing about the way your team works changes. No telemetry, no sync, no backup: everything it stores stays on the machine you run it on.

What the model receives

Here is some scan and config-dump output, exactly as Claude Code would send it, next to what the model actually receives.

What changed, and what didn't:

The mail. subdomain survives, and the same organisation placeholder appears in both the hostname and the email address. The relationship between them is intact.
The host octet .19 survives. Only the /24 network changed, so hosts that were adjacent stay adjacent.
The AWS key still looks like an AWS key, so the model knows what kind of secret it found without seeing the secret.
The connection string collapses into one opaque placeholder, because the whole credential span is sensitive.
The nginx banner, the latency, the port, the Dell OUI comment: untouched. None of them identify the client.

Stable placeholders

An engagement is redactproxy's word for one client project. Inside one, the same real value always gets the same fake. The hostname that became tok5198ede8bdbb1ada.internal this morning is still that same fake tomorrow, and in every request in between. This is not a convenience. It is the reason the tool is usable at all.

The model can still work out that two hosts belong to the same organisation. It just never learns which organisation.

Because tok1a2b3c4d5e6f7890.com and mail.tok1a2b3c4d5e6f7890.com are consistently the same fake, the model can reason that a finding on one host relates to a finding on another, that an email address belongs to the same company as a web server, that the same credential turned up in two places. All the analytical work survives. The identity does not.

The mappings live in the engagement's own folder and survive restarts, so the placeholder the model saw yesterday is still the same one today. Each engagement is self-contained and shares nothing with the others.

Placeholder shapes

Redaction that destroys structure destroys usefulness. Where a value's shape carries something useful but not identifying, the shape is kept:

The ranges are not arbitrary. Every fake comes from a space that cannot collide with something real: an IPv4 block reserved for equipment testing rather than one of the private ranges internal engagements actually target, the 555 phone exchange reserved for fiction, MAC addresses that can never belong to a real manufacturer. Fake credentials carry the string FAKE in a position where a real key can only hold a digit or a letter A to F, so no vendor could ever issue one.

What it detects

Detection is regex plus a validation step. No model in the loop, no network call, no learning. The detector set covers, roughly:

Network identity: domains and hostnames (bare or inside URLs), IPv4, IPv6, MAC addresses.
People: email addresses, NANP and international phone numbers.
Credentials for 25+ vendors: AWS, GitHub, GitLab, Slack, Stripe, Razorpay, Google, npm, DigitalOcean, Cloudflare, Azure, Docker Hub, CircleCI, Terraform, Snyk, Vault, Twilio, SendGrid, OpenAI, Anthropic and more, plus JWTs, bearer tokens, connection strings, PEM private keys and password hashes.
Regional PII: Indian Aadhaar and PAN numbers.
AD artifacts: machine account names, GPP cpassword values.
Client identity: whatever you add by hand, which is the part that matters most. See below.

There is also an allowlist, split into categories you can toggle. Your own out-of-band testing services (burpcollaborator.net, interact.sh, webhook.site) are never the client's, and common CDN and public dev platform hostnames say nothing about who the client is. Every category can be switched off per engagement.

Only the parts of a request that carry content get scanned, and only the values that match get replaced. Everything else is left exactly as it was. MCP tool calls and results are scanned too, because an MCP server is local infrastructure producing exactly the client data this exists to keep in.

Fail closed

If the proxy cannot finish redacting a request, it returns an error instead of sending it on. A malformed request, a detector that errors, a store that cannot save a new mapping: all of them fail the request rather than let it through.

An unredacted forward is the one outcome this project treats as worse than a broken request.

Setting up an engagement

go install github.com/CSPF-Founder/redactproxy/cmd/redactproxy@latest

Then, in a folder for the engagement. Name it after an engagement code, not the client; the Known gaps section explains why that matters more than it looks.

cd ~/engagements/eng-2026-014
redactproxy wizard --engagement eng-2026-014

The wizard asks four things. First, customer name variations: the legal name, the trading name, abbreviations, product names, internal codenames. No detector can match a name, so this is the only way they get redacted. They become case-insensitive substring matches, so XYZCorp also catches XYZCorporation.

Second, domains. Give the base domain only. Subdomains, email addresses at that domain and URLs all resolve from it automatically. Internal-only names work too: an AD forest, or any private scheme that will never appear on a public suffix list.

Third, which API this engagement talks to. Real Claude by default. redactproxy never asks for an Anthropic credential; it forwards Claude Code's own authentication untouched. Anything else speaking the Anthropic Messages API works too, z.ai for example, and each engagement remembers its own choice, so two client projects can run against different providers side by side.

Fourth, it offers two conveniences for the folder: a CLAUDE.md note explaining the placeholder shapes, and a .claude/settings.local.json that points Claude Code at the proxy and closes several channels that bypass the proxy entirely.

Then:

redactproxy      # terminal 1
claude           # terminal 2, already pointed at the proxy

That terminal running the proxy is also a live console. Type show to see every mapping minted so far, remove <value> to drop a bad one, or rules block "XyzExample" to add a value mid-session without interrupting anything.

Two files the wizard writes

The CLAUDE.md note is not decoration. Without it, a session sees strange placeholder values with no explanation: it corrects them as typos, hesitates to use them in tool calls, or retypes them from memory slightly wrong. The note tells the model these are stable identifiers to copy verbatim. It also covers a trap worth knowing yourself: if the model decodes base64 inline, the decoded content lands in its own output completely unprotected, because the encoded form passed through unredacted. Decoding to a file with Bash and reading the file back gives that content a normal pass through redaction.

The settings hardening closes paths that never touch ANTHROPIC_BASE_URL at all. The Artifact tool is a confirmed leak path: a report published through it goes straight to a hosted claude.ai URL, entirely unredacted, through a separate service call the proxy never sees. The wizard removes it from the session entirely rather than prompting for it each time, because a permission prompt can be approved out of habit and a tool that was never offered cannot leak anything. It also turns off WebFetch's safety check, which sends the target hostname to Anthropic before the fetch, whichever provider the engagement uses. A domain being reconned is exactly the value this tool exists to keep off side channels.

Known gaps

redactproxy ships a Known gaps page, and it is worth reading before you point this at real client data. The ones that matter most:

Your folder name is the big one, and redaction cannot fix it. Claude Code puts its working directory into the system field of every request, and that field is deliberately never scanned. A folder called xyz-example-bank-pentest sends "xyz example bank" to the model on every single request no matter what your rules say. The tool warns about it, at wizard time and at startup, but the only fix is to name engagement folders after an engagement code.
Encoded data passes straight through. A .env piped through base64, an xxd dump, Terraform state: none of it looks like anything to a regex. Decode locally first.
Names and prose are not detected. This is what rules block is for, and why it is the wizard's first question. A company name shows up in URL paths, ticket references, code comments and commit messages, and no detector can recognise it.

Who this is for

Pentest and consulting teams who want the productivity of an AI coding agent on a live engagement, and who would rather not explain to a client why their internal hostnames are in a third party's logs.

It was built for pentest work, and that shapes the vocabulary: engagements, clients, findings. Nothing in the redaction is specific to offensive work, though. Blue teams and infrastructure teams hit the same problem: a SOC analyst pasting alerts full of internal hostnames, a sysadmin debugging a manifest with credentials in it, anyone under an NDA who wants an AI agent working on real data. The detectors only care about the shapes they recognise, not why you are looking at them.

Source: github.com/CSPF-Founder/redactproxy
Manual: cspf-founder.github.io/redactproxy

Search This Blog

Sections

Popular Posts

Blog Archive

Labels

Report Abuse

About Me

Footer About

Labels

Showing result(s) for

Popular Posts

Pages

Critical Orkes Conductor Flaw Exploited for Unauthenticated Remote Code Execution

An AI Helped Researchers Break Into OpenAI

Microsoft Fixes Critical Azure AI Flaw Rated CVSS 10.0

FBI Seizes NightmareStresser DDoS-for-Hire Domains in Global Crackdown

Parallels Desktop Vulnerability Gives Any Local Mac User Full Root Access, Intel Mac Users Left Without a Clear Fix

Acronis Discloses Actively Exploited Privilege Escalation Bug in Its cPanel Backup Plugin

Homebrew 7.0.0 Ships With Fixes for Eight Security Advisories

Study Warns Enterprise AI Rollouts Are Outpacing Data Security Checks

Nintendo Switch Security Flaw Lets Nearby Attackers Exploit QR Codes Used to Share Screenshots

Check Point Discloses Two Critical VPN Vulnerabilities Allowing RCE

Technical information

Potential risks

Addressing the flaws

Microsoft Tracks Cloud Intrusion Campaign Using Passkey Phishing and Graph API Abuse

The Four-Character Password Guarding Your Company's AI Keys

DoppelCart Fake-Shop Network Found Operating Across 119,000 Domains

LG Targets Residential Proxies in New Smart TV Security Move

Ransomware Affiliate Pretends to be Recovery Service for Extortion

Fake ransomware recovery service

Extortion tactic

Impact on ransomware victims

Elementor Pro WordPress Flaw Exploited to Upload Webshells and Execute Commands

redactproxy, a tool that lets pentesters use AI without leaking client data

Footer About

Search This Blog

Sections

Popular Posts

Blog Archive

Labels

About Me

Footer About

Labels

Showing result(s) for

Popular Posts

Pages

Menu Item

Technical information

Potential risks

Addressing the flaws

Fake ransomware recovery service

Extortion tactic

Impact on ransomware victims