Search This Blog
Powered by Blogger.

Blog Archive

Labels

Footer About

Footer About

Labels

Load More
Trendy Right Now

Popular Posts

Showing posts with label Cyber Security. Show all posts
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.

Read more »
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.
Read more »
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.
Read more »
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.

Read more »
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. 

Read more »
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.
Read more »
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.



Read more »
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.
Read more »
Subscribe to: Posts (Atom)