An investigation into a threat actor bypassing AI safety controls to coordinate credential theft, VoIP fraud planning, and database exfiltration.
The post “Next Exploit Opportunities”: How a Threat Actor Used AI to Help Plan and Execute Multiple Types of Cybercrime Activities appeared first on Unit 42.
Antidetect browsers conceal their users’ digital identities, enabling a single operator or small team to simultaneously run thousands of isolated accounts across multiple platforms such as Facebook, Instagram, TikTok, YouTube, Twitter/X, Discord, LinkedIn, Reddit, and many more, without triggering the detection systems employed by those platforms.
In this report, we highlight three main tools: Kameleo, AdsPower, and MultiLogin. We selected these specifically on the basis of documented references across underground forums and criminal marketplaces, indicating active adoption beyond their stated commercial purposes. Confirmed use cases include:
As documented in Anthropic’s September 2026 Threat Intelligence Report, attackers used antidetect browsers in a fraud campaign that targeted cryptocurrency exchanges and financial marketplaces. They combined antidetect browser profiles, residential proxies, automated CAPTCHA-solving, and identity-verification bypass tools to create large numbers of verified accounts while avoiding onboarding security checks. These accounts were later used in fraud operations.
The risk posed by antidetect browsers is greater because these accounts pass KYC verification, build legitimate activity histories, and appear benign during transactions. As a result, fraud detection systems that rely on user behavior or device identity often cannot identify these accounts as suspicious until after fraudulent activity has already occurred.
The antidetect browsers documented in this research are commercially available, legally registered platforms with documented legitimate use cases in digital marketing, e-commerce, and privacy protection. When deployed by threat actors, the same infrastructure that enables financial fraud at scale is equally applicable to Coordinated Inauthentic Behavior (CIB), the term used to describe organized manipulation campaigns in which false identities are central to the operation and adversarial methods are used to evade detection.
Meta’s most recent transparency reporting explicitly flagged this as a growing concern, with Russia, Iran, and China identified as the three leading sources of such activity globally.
Figure 1 – The five layers through which antidetect browsers defeat platform detection methods.
While antidetect browsers are not a new phenomenon, their threat potential has increased with the integration of AI. Previously, their operational impact was constrained by the manual effort required to run and maintain large account networks at scale. AI-assisted content generation, automated persona management, and machine-speed distribution pipelines now enables a single actor with a subscription and a prompt to do the work of a coordinated team.
In the following sections, we provide a technical breakdown of each tool, examining capabilities documented on their own platforms, underground forum references, and the specific features that position them as an emerging threat.
Figure 2 – Comparison of popular antidetect tools.
Companies like Meta, TikTok, and Google have spent billions of dollars building behavioral and identity detection systems to identify abuse of their platforms for scams, financial fraud, and coordinated inauthentic activity. Antidetect browsers are engineered to defeat every signal on which those systems rely.
Every antidetect browser uses fingerprint spoofing. When a browser connects to a website, it exposes dozens of identifying parameters that the website can collect to build a browser fingerprint, including canvas rendering output, WebGL vendor and renderer strings, font enumeration behavior, screen resolution, time zone, user agent, and hardware identifiers. Platforms cross-reference these signals to determine whether two accounts originate from the same device. Antidetect browsers intercept and fabricate each of these parameters individually, assigning a unique combination to every profile.
The criminal ecosystem surrounding these tools extends well beyond their commercial vendors. As seen in Figure 3, a threat actor on a Russian-language underground forum advertised an AiTM engine as a commercial service, with built-in functionality to export harvested session credentials directly into antidetect browsers. The post confirms that the pipeline from credential harvesting to antidetect-assisted account takeover is a documented, commercially available and actively traded workflow with dedicated tooling, published instructions, and an active buyer community.
Figure 3 – An AiTM engine advertised as a commercial service on a Russian-language underground forum, with built-in functionality to export harvested session credentials directly into antidetect browsers.
Modifying browser engines at the source level rather than applying surface overrides, Kameleo produces fingerprints drawn from real device signatures, making them significantly harder to flag as anomalous. Its adoption within criminal ecosystems is evidenced by its repeated appearance across the most active Russian-language hacking forums. As seen in Figure 4, Kameleo is listed alongside other antidetect browsers in a post by a proxy seller on an underground forum, advertising residential proxy services explicitly marketed for account farming, CAPTCHA bypass, and shield evasion against security systems including DataDome, the same platform for which Kameleo’s own blog publishes dedicated bypass guides.
Figure 4 – A proxy seller on an underground forum listing Kameleo as part of a complete operational stack. The service is explicitly marketed for account farming and bulk account management.
Kameleo’s engineering team published a guide detailing how to automate Facebook likes across multiple accounts simultaneously using precisely this fingerprint manipulation. As seen in Figure 5, evading platform detection is not a side effect but the tool’s primary operational value.
Figure 5 – Kameleo’s guide on how to automate Facebook likes across multiple accounts simultaneously using browser fingerprint manipulation.
Beyond fingerprinting, Kameleo suppresses WebRTC, a protocol that can leak a device’s real IP address even when a proxy is active, and provides explicit configuration options to prevent non-proxied UDP connections. The documentation frames this not as a privacy feature but as a counter to a known de-anonymization vector used by platform security teams.
At the session layer, Kameleo’s dedicated cookie injection API accepts complete cookie objects including session IDs, refresh tokens, and authentication flags, allowing a pre-authenticated session state to be inserted into a profile before it is launched. The platform sees the profile as an already-authenticated user, with no login event occurring to trigger anomaly detection. As independently documented by threat intelligence research and confirmed by security researchers, this workflow is established and active in the criminal ecosystem. Figure 6 shows a recruitment post on a Russian-language underground forum advertising a multifunctional infostealer with RAT capabilities explicitly designed to operate within antidetect browser environments, listing Kameleo, AdsPower, and MultiLogin among 21 compatible platforms capable of harvesting session cookies, authentication tokens, cryptocurrency wallets, API keys, and 2FA credentials.
Figure 6 – A recruitment post on a Russian-language underground forum lists 21 browsers including Kameleo, AdsPower, and MultiLogin as compatible platforms.
As seen in Figure 7, a threat actor on a Russian-language underground hacking forum explicitly introduces Kameleo as a component of Browser-in-the-Middle phishing kits targeting credentials across Google, Microsoft, Facebook, and financial platforms. In a Browser-in-the-Middle attack, the phishing server instructs the antidetect browser to create a new profile for the victim, assigned a residential proxy in their country and a clean device fingerprint. The victim’s credentials, entered on the phishing page, are passed in real time into the real login page of the target service through an automation framework. The target platform sees a login attempt from a consistent, locally coherent device with a residential IP address in the expected country, none of the signals that would trigger a security challenge or step-up authentication.
Figure 7 – A post on a Russian-language underground hacking forum introducing Kameleo as a component of Browser-in-the-Middle phishing kits targeting credentials across Google, Microsoft, Facebook, and financial platforms.
Chinese in origin and subsequently registered across multiple jurisdictions and localized into more than 20 languages, AdsPower applies fingerprint spoofing logic across more than 20 configurable parameters per profile and advertises a 99.2% ban avoidance rate. As seen in Figure 8, its proxy editor provides a built-in catalog of compatible third-party residential and rotating proxy providers, assignable directly within the profile creation interface. Figure 9 illustrates the granularity of fingerprint control available, with each profile’s WebRTC handling, time zone, geolocation, and language individually configurable to ensure the synthetic identity is consistent across every detectable signal.
Figure 8 – AdsPower’s proxy integration interface lists compatible third-party residential and rotating proxy providers available within the platform.
Figure 9 – AdsPower’s fingerprint editor displaying granular per-profile identity parameters including WebRTC, timezone and location derived from the assigned proxy IP.
The scale of AdsPower’s intended use is reflected in its pricing structure, with published tiers supporting up to 5,000 distinct profiles as seen in Figure 10, and enterprise arrangements available on request. As seen in Figure 11, its account editor supports platforms spanning social media, e-commerce, financial services, and professional networks including Facebook, Amazon, LinkedIn, X, PayPal, and Google.
Figure 10 – AdsPower’s pricing table reflects the intended operational scale, with enterprise tiers supporting more than 5,000 profiles available upon request.
Figure 11 – AdsPower’s account editor shows supported platforms available for bulk profile management, including Facebook, Amazon, LinkedIn, X, PayPal, and Google.
Scalability is further addressed through a built-in RPA engine and a dedicated Marketplace, as seen in Figure 12, offering pre-built templates for automated liking, commenting, direct messaging, follower scraping, and AI-assisted engagement across hundreds of profiles simultaneously. The multi-window synchronizer replicates identical actions across hundreds of profiles from a single input, while account warming automation builds synthetic activity histories over weeks to reduce platform suspicion before deployment.
Figure 12 – AdsPower’s RPA Marketplace lists pre-built automation templates for bulk account activity across major platforms, including automated liking, commenting, direct messaging, follower scraping, and AI-assisted engagement.
On the AI front, AdsPower advertises a dedicated Model Context Protocol server enabling direct integration with large language model workflows, creating a pipeline in which AI-generated content can be produced, injected into pre-warmed account profiles, and distributed across platforms in a fully automated sequence requiring no human involvement. A companion feature, the Cookie Robot, automates cookie warming on TikTok and Twitter/X accounts prior to operational use. The RPA Marketplace is the delivery mechanism for this pipeline, with ready-to-deploy workflows designed to operate in direct combination with AI-generated content, resulting in an end-to-end operation at a scale and speed previously associated only with state-sponsored actors.
As seen in Figure 13, AdsPower’s own published scraping guide explicitly acknowledges that scraping Facebook constitutes a violation of the platform’s terms of service and may result in legal action, before advising users that an antidetect browser can help bypass these limitations.
Figure 13 – AdsPower’s official scraping guide advises users that an antidetect browser can help bypass scraping limitations.
MultiLogin operates as a fully featured antidetect browser platform, offering isolated browser profiles with unique device fingerprints covering canvas output, WebGL parameters, fonts, timezone, screen resolution, and user agent, with each profile maintaining separate cookies, local storage, and session data. The platform supports automation through Selenium, Playwright, and Puppeteer, enabling fully scripted, headless operation of multiple profiles simultaneously. MultiLogin has been referenced on Exploit, a Russian-language underground hacking forum, in a thread dedicated to antidetect browsers, indicating active discussion and adoption of the platform within criminal communities (see Figure 6).
MultiLogin extends its multi-account capability into the mobile layer through a phone farming infrastructure that replaces physical Android devices with cloud-hosted equivalents. Every cloud Android profile maintains its own persistent mobile device parameters, with proxies assigned per profile to control location and network identity. MultiLogin’s own documentation states that most account bans in phone farm environments occur due to multiple accounts sharing the same device signals, storage, or network patterns, and positions its product as the solution to this detection problem, an explicit acknowledgment that the platform is designed to defeat association detection at the mobile layer.
According to their website, virtual phone number provisioning through partner integrations enables SMS-based account verification without physical SIM cards or mobile devices. Each virtual number is paired with a mobile device fingerprint profile, enabling the rapid creation of large volumes of accounts that appear to originate from distinct mobile devices across different geographic locations.
MultiLogin maintains a dedicated web scraping solution page and publishes operational guides for scraping platforms including Facebook, LinkedIn, Amazon, and Twitter, with its built-in residential proxy infrastructure marketed as enabling scraping operations that bypass bot detection and IP-based rate limiting. Its stated use cases listed on its own website include ticket scalping automation, a practice explicitly illegal in multiple jurisdictions and prohibited by major ticketing platforms, with the platform’s infrastructure documented as tested daily against major ticketing services for compatibility. MultiLogin additionally lists AI Quick Actions Automation among its documented product capabilities, indicating a degree of AI integration into its operational workflow.
As seen in Figure 14, MultiLogin’s payment infrastructure accepts cryptocurrency alongside credit card payments and regional systems including SberPay and YooMoney. Notably, YooMoney has been designated on the OFAC Specially Designated Nationals list since April 2022 under Executive Order 14024 as a Sberbank subsidiary, and SberPay operates as a product of Sberbank, itself under comprehensive OFAC blocking sanctions since February 2022. The acceptance of these payment methods, alongside cryptocurrency, enables anonymous and potentially sanctions-non-compliant transactions. MultiLogin offers 24/7 support through dedicated Telegram channels staffed by human representatives and is tested daily against more than 50 major social media platforms to ensure continued compatibility. Taken together, MultiLogin’s mobile infrastructure, AI automation layer, scraping capabilities, criminal community presence, and payment infrastructure make it one of the most operationally complete platforms in this category.
Figure 14 – MultiLogin’s payment infrastructure accepts a variety of different payment services.
The most consequential recent development is AI integration directly into the operational stack. AdsPower advertises a dedicated Model Context Protocol server enabling direct integration with large language model workflows, creating a pipeline in which AI-generated content can be produced, injected into pre-warmed account profiles, and distributed across platforms in a fully automated sequence requiring no human involvement. A companion feature, the Cookie Robot, automates cookie warming on TikTok and Twitter/X accounts prior to operational use, simulating browsing behavior to establish account credibility before the content distribution phase begins.
The RPA Marketplace mentioned in the previous section is the delivery mechanism for this pipeline. Available templates contain ready-to-deploy workflows maintained and updated by the vendor, designed to operate in direct combination with AI-generated content. This creates an end-to-end influence operation pipeline that requires no active operator presence once the campaign is initiated. The result is a single automated workflow that places coordinated influence operation capacity within reach of any sufficiently motivated actor, regardless of resources or technical expertise.
The web scraping capabilities documented across these platforms serve a function that extends well beyond data collection. Scraped data is the intelligence layer that makes the operation more precise. Several of the tools we reviewed maintain dedicated scraping solution pages describing capabilities including fingerprint rotation, CAPTCHA bypass, and headless browsing designed to extract data from platforms including LinkedIn, Amazon, Facebook, and Twitter while evading their anti-scraping defenses. As seen in Figure 13, the AdsPower published scraping guide explicitly acknowledges that scraping Facebook constitutes a violation of the platform’s terms of service and may result in legal action, before advising users that an antidetect browser can help bypass these limitations.
The combination of well-farmed personas and targeted scraping capabilities enables a precision influence operation at scale.
Workflow:
The commercial availability of these tools reflects a fundamental shift in the influence-operation threat landscape: what was once the domain of well-resourced state actors and advanced persistent threat groups is now accessible to any motivated individual with a credit card. These are all professionally maintained, customer-supported, multilingual software platforms with pricing pages, knowledge bases, release notes, and dedicated sales teams. The only barrier to running a large-scale coordinated inauthentic operation is not a user’s technical sophistication but the need to pay a subscription fee.
The language coverage and market reach of these tools reflects the scale of their intended user base. AdsPower is available in 20 languages. MultiLogin supports English, Chinese, Russian, Vietnamese, and Portuguese, and is tested daily against more than 50 platforms. Kameleo maintains a public blog catalog of dedicated technical guides on bypassing Cloudflare bot detection, defeating DataDome, and solving Cloudflare Turnstile challenges, which are all security systems deployed specifically to identify and block automated or inauthentic browser sessions.
The customer support infrastructure surrounding these tools mirrors that of legitimate enterprise software, with MultiLogin offering 24/7 support through dedicated Telegram channels staffed by human representatives. As seen in Figure 14, MultiLogin’s payment infrastructure accepts cryptocurrency alongside credit card payments and regional systems including SberPay and YooMoney, both Russian payment services.
As seen in Figure 15, independent threat actors have developed and are actively selling purpose-built antidetect solutions on underground forums, complete with feature documentation, technical support, and monthly subscription pricing. This particular tool targets Android devices specifically, offering automated geolocation spoofing, device ID replacement, Wi-Fi environment manipulation, and Play Integrity bypass at 100 USD per month, reflecting the breadth of threat actor demand across different device categories and operational requirements.
As seen in Figure 16, the downstream commercial activity built on this infrastructure extends to farmed platform accounts advertised for sale on underground forums alongside explicit instructions to access them using antidetect browsers. Cryptocurrency is the default payment method. These posts confirm a mature commercial underground market in which these antidetect tools function as the operational backbone of a broader fraud and influence ecosystem.
Figure 15 – An antidetect tool designed for Android devices advertised on an underground forum, offers automated geolocation spoofing, device ID replacement, and Play Integrity bypass at 100 USD per month.
Figure 16 – Farmed Google Ads accounts advertised for sale on an underground forum.
The antidetect browser ecosystem represents a sophisticated, commercially mature, and increasingly AI-driven infrastructure that has fundamentally lowered the barrier to running scam and fraud operations, as well as coordinated inauthentic operations at scale. These commercially maintained tools are available in dozens of languages, backed by customer support teams, tested daily against the world’s largest social media platforms, and are now integrated with LLM pipelines that remove the human operator from the execution layer. The coupling of identity spoofing infrastructure, automated content distribution, and AI-assisted persona management represents a threat surface that platform detection systems may struggle to address, particularly in the context of elections taking place across multiple countries.
The infrastructure we documented is commercially available today. Its capabilities are not constrained by technical sophistication, national resources, or operational scale. The question is no longer whether these tools are being actively used for fraud, account takeover, and coordinated manipulation, but whether the detection, enforcement, and awareness frameworks across every layer of the ecosystem are prepared to counter them.
Social media platforms:
CISOs and companies:
The post The Risk of AI-Powered Antidetect Browsers in Online Fraud and Influence Operations appeared first on Check Point Research.
Our analysis an AI-powered espionage campaign targeting government Linux infrastructure with custom malware, web shells, and advanced credential theft.
The post AI-Powered Espionage Campaign Targets Government Linux Infrastructure appeared first on Unit 42.
We investigated an intrusion where attackers exploited CVE-2024-47575 to target 500+ firewalls and deploy PEERSTITCH, a memory-resident ARM64 malware.
The post Unit 42 Uncovers PEERSTITCH, a Stealthy FortiGate Implant appeared first on Unit 42.
Analysis of Blinder Tunnel, an Iran-nexus campaign using fake Dubai Airports recruitment lures and GitHub C2 malware to target critical infrastructure.
The post Blinder Tunnel Campaign Targets Iraqi Infrastructure appeared first on Unit 42.
SQL parsers are critical components of the modern data stack. They validate queries before they reach the database, transpile between dialects, and lint codebases for style violations. Increasingly, they also power AI-driven SQL generation in LLM-integrated data tools.
Our research focused on two popular Python-based parsers: SQLGlot and SQLFluff, both with around 10k GitHub stars each. These libraries sit at the foundation of the data ecosystem, trusted by thousands of projects, and we believe the underlying issues are relevant to other parsers and other programming languages as well.
But these parsers carry a hidden flaw. They are highly susceptible to resource exhaustion from seemingly “simple,” syntactically valid SQL queries. Not injection. Not malformed input. Just normal-looking SQL that happens to be shaped in the wrong way.
In this post, we describe our findings of new vulnerabilities stemming from two root causes: Recursive Stack Overflow and Parser AST Object-Inflation. We show how these flaws cascade into downstream applications, giving concrete examples from several major projects we found vulnerable, with many more still to be explored. We then explain the underlying mechanics and conclude with practical fix suggestions for both parser maintainers and application developers. We reported every issue to the respective maintainers and contributed to the fixes that now ship upstream; the SQLFluff findings were assigned CVE-2026-46373 and CVE-2026-46374.
Our research began with a simple question: what happens when you feed a deeply nested query to a SQL parser?
The answer: the Python interpreter crashes with a RecursionError. At higher concurrency, it segfaults.
This isn’t a contrived edge case. The query is syntactically valid SQL. Any database would reject it for being absurd, but a parser’s job is to parse it – and both SQLGlot and SQLFluff attempt to do so without any depth limit. At 50+ levels of nesting, the recursive descent parser exhausts the call stack.
The fix seems obvious in hindsight: enforce a maximum recursion depth (e.g., 30 levels) and abort gracefully. But neither parser does this.
The recursion crash was just the beginning. As we explored further, we discovered a more insidious problem: AST amplification.
SQL parsers work by converting raw SQL text into an Abstract Syntax Tree (AST) – a structured representation where each token (literal, identifier, operator, dot) becomes a Python object. These objects carry metadata: type information, position tracking, parent references. They’re heavyweight.
The question became: what if we crafted a query that was short but produced an enormous number of AST nodes?
The result was striking. In SQLGlot, a SQL string under 2MB in size demanded over 1.5GB of RAM to parse – roughly a 750x amplification ratio. SQLFluff showed the same pattern: at width=5000, it consumed over 1GB.
This is the core vulnerability: each SQL token gets wrapped in a heavy Python object. A compact input with thousands of columns and deep expression chains generates millions of AST nodes, far exceeding what any reasonable container or server can handle. The process is killed by the OOM killer – or simply hangs until it starves out everything else on the machine.
To see where the cost comes from, it helps to follow the input through each stage of parsing. The payload starts small, but every step multiplies it: tokenization splits the string into hundreds of thousands of pieces, AST construction wraps each one in a heavyweight Python object, and the resulting tree balloons into gigabytes of memory. The diagram below traces that roughly 750x expansion from a 2MB string to a 1.5GB+ footprint.
The key insight is that object inflation is the root cause. It isn’t about the input being “large”, it’s about the multiplicative cost of turning each token into a rich object. A 2MB string is a perfectly normal payload by any standard. But the parser amplifies it by orders of magnitude.
A vulnerability in a parser library is concerning on its own. But parsers don’t exist in isolation, they’re embedded deep in application stacks. When the parser crashes, the application may crash with it.
We traced this cascade through several major projects.
Apache Superset (~75k stars) uses SQLGlot under the hood. Its SQL Lab feature allows authenticated users to write and execute queries.
The weakness lives in the pre-execution phase. When a user submits a query through SQL Lab, Superset hands the raw SQL to SQLGlot for parsing and validation before it ever reaches the database and before any complexity checks are applied. There is no limit on query size, nesting depth, or AST node count at this boundary. An authenticated user with ordinary SQL Lab access is enough; the query never has to run.
Depending on the payload size, the attack produces two distinct denial-of-service states:
The attack is simple: authenticate as a normal user, then send a batch of concurrent requests to /api/v1/sqllab/execute/, each carrying a payload built from a large number of columns of a deeply nested x=x=x… expression. The number of columns determines which failure mode you hit:
[ERROR] Worker (pid:14) was sent SIGKILL! Perhaps out of memory?
The exact thresholds depend on available memory – a 16 GB host behaves differently from a 4 GB container – but either way, a single authenticated user takes down SQL Lab, and the shared worker pool, for everyone.
Dify (~150k stars) Uses SQLGlot within its plugin ecosystem. We found two vulnerable plugins – db-client-node and dify-bigquery-plugin – and that the plugin framework’s architecture amplified the parser vulnerability into a system-wide failure.
A large SQL payload (10,000 columns x 60 depth) executed through a workflow that triggers 5 concurrent database queries caused a 5GB RAM spike. This didn’t just kill the plugin – it destroyed the IPC bridge between Dify’s Go-based daemon and its Python workers.
PluginDaemonInternalServerError: write |1: file already closed failed to write request
The daemon lost track of healthy workers. The system entered a “Blackout” state for approximately 60 seconds, during which all tool calls across the entire framework returned errors – not just those involving the parser.
SQLFluff Online: Backend Exhaustion via Missing Input Limit
SQLFluff Online (source) exposes the parser through a web API. The frontend enforces a 3,000-character input limit. The backend does not.
By sending a crafted payload directly to the /fluffed endpoint – bypassing the frontend – a single request consumed 2GB+ of RAM and saturated the CPU. The service locked up entirely.
Pathway (~60k stars) uses SQLGlot internally and exposes a pw.sql interface that accepts user queries. We submitted a crafted query (10,000 columns x 70 depth) and watched memory grow unboundedly, consuming 8GB+ of RAM. The server was killed with OOMKilled: true and ExitCode: 137. Pathway produced no error or warning before the crash.
The security community has spent decades hardening systems against SQL Injection, the manipulation of query structure to execute unauthorized commands. This is a different class of attack entirely.
Parser Exhaustion doesn’t inject anything. It doesn’t exploit string concatenation or missing parameterization. The queries are syntactically valid. They would parse correctly on any SQL grammar. They just happen to be shaped in a way that overwhelms the parser’s resource consumption.
This distinction matters because Parser Exhaustion bypasses many traditional defenses:
As the industry moves toward automated SQL generation and LLM-integrated data tools, this attack surface grows. LLMs can generate arbitrarily complex SQL. If that SQL passes through a parser – for validation, linting, or transpilation – the parser becomes an attack vector. Not because the SQL is malicious in the traditional sense, but because it’s expensive.
The parser is no longer just a utility. It’s a trust boundary.
The good news: these vulnerabilities are straightforward to mitigate. Simple limits on recursion depth and AST size can harden parsers against this entire class of attack.
1. Recursion depth limit: abort parsing if nesting exceeds a threshold:
2. AST node limit: count nodes during construction and abort if a threshold is exceeded:
We reported both issues to the maintainers of SQLGlot and SQLFluff and contributed to the fixes. SQLGlot now enforces a configurable recursion/complexity limit during parsing (merged ahead of the v30.5.0 release), and SQLFluff adopted comparable guards. If you depend on either library, upgrade to a patched version and keep the default limits enabled.
The bad news: not all parsers support limits. If the parser you use enforces a recursion or node limit, enabling it is the best way to mitigate these vulnerabilities. If it doesn’t, defend at the application level:
SQL parsers are not special. The root causes – unbounded recursion and object inflation – are properties of recursive-descent parsers in general. We found the same patterns in query languages built on entirely different grammars.
Neo4j’s Cypher query language (~17k stars) exhibits both failure modes:
GraphQL (~20k stars) is the instructive counter-example: the spec supports a max_tokens limit, but whether it’s enforced by default varies by implementation.
The takeaway: this is a parser-design problem, not a SQL problem. Any parser that turns untrusted text into a rich object tree without bounding depth or node count is exposed.
We disclosed vulnerabilities in SQLGlot, SQLFluff (CVE-2026-46373, CVE-2026-46374), and several downstream applications – all stemming from the same root cause: parsers that trust their input to be reasonable. Beyond reporting, we worked with both maintainer teams and contributed to the fixes that now ship upstream, so every project depending on these libraries benefits by upgrading. The fixes themselves are straightforward: depth limits, node counting, input size validation. But the lesson is broader.
Parsers have quietly become critical infrastructure. They’re embedded in data platforms, CI/CD pipelines, AI agents, and production workflows. Yet they’ve historically been treated as safe, deterministic utilities that “just work.” Our findings show that even syntactically correct queries can be weaponized to dismantle the systems that depend on them.
As the industry moves toward automated SQL generation and LLM-integrated data tools, the parser is no longer a passive utility – it’s an active attack surface. Hardening it requires the same discipline we apply to any other trust boundary: validate input, limit resource consumption, and assume that anything coming from outside the system is potentially adversarial.
It’s time to move beyond SQL Injection. Welcome to Parser Exhaustion.
The post The Hidden DoS Vector in SQL Parsers appeared first on Blog.
As Amazon prepares for Prime Big Deal Days, its Fall Prime Day event on October 6-7, cybercriminals are already exploiting the anticipation surrounding one of the year’s largest online shopping events. New findings from Check Point Research reveal a significant increase in Amazon-related domains, alongside ongoing phishing campaigns and malicious websites designed to target online shoppers. Amazon-Related Domain Registrations Continue to Rise Check Point Research observed a steady increase in newly registered Amazon- and Prime Day-related domains in the months leading up to the event. New Amazon- and Prime Day-related domain registrations have risen for three straight months, climbing from […]
The post Amazon Prime Big Deal Days 2026: As Shopping Activity Surges, So Do Cyber Threats appeared first on Check Point Blog.
We introduce OperTraitor, a tool to audit privileges of Kubernetes operators, identify excessive RBAC risks, and secure non-human identities.
The post OperTraitors: How Kubernetes Operators Betray Your Security Posture appeared first on Unit 42.
Torrent trackers have long been abused for distributing malicious software, disguised as popular films, games, and other content. Our previous research has shown that cybercriminals repeatedly turn to torrents as an initial infection vector, using trojanized cracks and installers to reach a large number of users. Installation guides for pirated software routinely instruct users to disable their antivirus, conditioning them to ignore the potential threats they are inviting onto their computers.
During our analysis of malware that leverages blockchain networks for its C2 infrastructure, we discovered a previously unknown modular, multi-stage framework that we dubbed MovieReaper. This report details the new crimeware campaign that began with the mass infection of users via compromised torrent tracker file storage. We have identified several hundred victims, including both individual users and organizations in multiple countries, such as Russia, Türkiye, Japan, Kenya, Uganda, and Colombia, as well as in several European countries like Spain, the Netherlands, Belgium, and Germany. We analyze the techniques for evading detection by security and sandbox solutions, and examine the capabilities of the modular framework.
Kaspersky products detect this threat as HEUR:Trojan.Win64.Agent.gen.
In mid‑August 2026, during our threat‑hunting efforts, we identified a large‑scale infection campaign involving previously unknown malware disguised as popular movies. The campaign affected both individuals and organizations across multiple countries. Our initial analysis revealed a common denominator: all of the victims had used torrent trackers. This finding prompted us to investigate the campaign further and analyze its distribution mechanism, overall scope, and unknown malware implants.
Compromised torrent trackers are the primary vector used to distribute malware. During our investigation, we identified multiple user reports describing suspicious files being downloaded instead of the intended content.
For example, a user of a popular movie torrent tracker reported the following case on Reddit:
Further analysis of the attack revealed that instead of compromising torrent trackers, the threat actor modified a widely used public repository of torrent files, itorrents[.]org. As a result, the trackers that relied on the repository began inadvertently distributing malicious torrent files to their users. This approach is particularly dangerous because it lets the threat actor reach users of multiple trackers without having to compromise each platform individually.
As of the publication date of this report, the archive remains compromised. When a user attempts to download a torrent via a magnet link, the legitimate torrent archive returns a different torrent file. This malicious torrent leads to the download of the malware loader, used to deploy a framework that we dubbed MovieReaper.
The loader initiates the infection chain shown in the diagram below. Each stage of the chain is described in detail in the following sections.
The infection chain consists of several steps, where only the initial one is dropped on the disk before it is executed to avoid detection. The malware itself is not heavily obfuscated, apart from strings being encrypted with a custom stream cipher. Most of the countermeasures were aimed at avoiding detection by AV sandboxes.
The most popular initial executable was distributed through torrent trackers under many different names (for example, the odyssey (2026) [1080p] [webrip] [5.1].exe), but the file hash (MD5: A0B13781EDD7CFDAB13D79AFFF3C83C1) was identical across all downloads. We have seen multiple different loaders, where the executable file disguises itself with a long filename and an icon of some well-known application. Most of the filenames are rather long, presumably to hide the EXE extension at the end.
After the user manually starts the application, it establishes a global mutex to ensure that only one loader is executed at a time. We have seen several mutex variations in our samples, containing a randomly generated string (in the example Global\fnulSktzSqvVLXHU). This executable then performs a series of operations in order to avoid detection by AV sandbox solutions.
While performing those operations, the malware avoids making LoadLibrary and GetProcAddress calls to acquire the addresses of required functions. Instead, it searches for loaded libraries by traversing the double-linked list taken from the Ldr field of the PEB and then performs manual parsing of the loaded DLL to calculate the function address.
After all initial checks have passed, the binary prepares to establish a network connection to a C2 web server to download the shellcode, map it to the RWX memory and execute. While doing so, the loader decodes the domain name https://deadhub[.]org and if connection to it has failed, it uses the IP address http://193.23.118[.]155 as a fallback and connects to it using plain HTTP. The malware chooses a random group of strings and uses them as a path in the HTTP request to download the parts of the shellcode.
Example URLs:
/cloud/v192.4/ui/sync-status-icons.png
/cloud/v192.4/onboarding/welcome-bg.jpg
/cloud/v192.4/ui/file-preview-placeholder.png
/cloud/v192.4/shared/link-banner.jpg
While mapping the address space and executing the shellcode, the loader registers a vectored exception handler and rewrites the handler address in memory in order to perform a debug break. This, will not crash the program, but instead redirect controlflow to the function that actually makes a raw NtProtectVirtualMemory syscall (via a previously located “0x0F 0x05” syscall instruction inside ntdll). Then it calls the undocumented ntdll function EtwpCreateEtwThread, which is a popular alternative to CreateThread for code executionm, and executes the shellcode.
The second stage of this malware performs an HTTPS request to the Solana blockchain at the endpoint /getAccountInfo endpoint for the account 6pnDGAiHgyPdmckM5Qt1YbanGzrX43WLEU159nRaNLDm. The data in field of the response contains the base64‑encoded address of a second C2, which is encrypted with a static XOR key located within the shellcode itself. To store data in this account, attackers used a simple Solana program (address: CSiY8bQLBYPdfPWkwipBzH6sijTVQVVsA279JQdvwHtL).
Utilizing the Solana blockchain as a storage layer for next-stage C2 endpoints substantially complicates infrastructure takedown efforts by defenders.
The second stage payload communicates with its C2 server strictly through HTTPS via a TLS-pinned certificate using the nanopb protobuf library as a container for transferred data. The main logic of the stage 2 implant contains several initial commands, where the most important is the one that parses the COFF file, loads it into memory, and executes the module_init function from it. This provides a convenient interface for extension of the command list, which brings us to the next stage of the payload.
Notably, the recovered modules were compiled with symbols, which accelerated reverse engineering.
After receiving the next stage from the second C2 server, the newly loaded module performs several tasks right in the module_init function.
Stage 3 performs UAC Bypass and achieves persistence using public techniques, masquerades the original binary as C:\ProgramData\Microsoft\Windows\Telemetry\msedge.exe, and restarts itself.
The respawned process starts with the initial loader, but with a special command-line argument, which allows it to skip most of the anti-sandboxing checks and proceed straight to downloading the next payload. The executable proceeds with the same steps as before, but this time, instead of downloading the persistence and UAC bypass module, a new one is downloaded from the second C2 server. This is because the malware uses the beacon to send a flag to the remote server, indicating whether the implant is running from the Telemetry folder, which allows the C2 to distinguish between first-run and respawned instances.
The final module (“file manager”) exposes 21 commands that give the operator filesystem access on the victim host. This allows remote the operator to download, upload, and read files on the system; list and enumerate directories; manipulate files with create, copy, rename, move, delete, chmod, and symlink commands; and use preview and thumbnail commands to exfiltrate previews of images and files before actually extracting them.
We suspect that other modules may be loaded on demand if requested by the operator.
During this malware campaign, attackers are using various commercial hosting providers for their C2 infrastructure (see the IoC section for details). Furthermore, as noted above, the campaign leverages the legitimate Solana blockchain via the RPC endpoint api.mainnet.solana.com to deliver the address of the second‑stage C2 server to the malware. This approach provides the attackers with decentralized storage for C2 addresses, adding an additional layer of resilience and making it more difficult for defenders to disrupt the campaign by simply blocking the IP addresses of the C2 servers.
The observed campaign targeted both individuals and organizations across Europe, Asia, Africa, and Latin America, with infection attempts identified in Russia, Spain, Germany, Finland, Türkiye, Japan, Nepal, Kenya, Tanzania, Ghana, Uganda, Colombia, the Netherlands, Belgium, and other countries. The targeted organizations span a wide range of sectors, including enterprise, government, IT, consulting, retail, transportation, and agriculture.
Our research uncovered activity by the same actor dating back to October 2025. Although the campaign has evolved over time, with the malware authors expanding their arsenal and making the loader harder to detect, the pattern remains the same. This includes encoded strings, parts of shellcode downloaded through plain HTTP, and several techniques used to avoid sandboxes and virtual machines. We will continue monitoring this actor’s activity to catch new potential threats.
The first stage offers the clearest opportunity to disrupt this campaign: it relies on a single specific domain name and a single IP address to serve the shellcode, so taking down this server would prevent subsequent infection stages. This includes the second-stage payload, which uses the Solana blockchain network for a C2 and is therefore more resistant to conventional infrastructure takedowns.
However, this framework’s self-containment, modularity and in-memory execution has potential for reuse in later campaigns with minimal rework.
4334BBAEA8DE33BF9D45E9B4E4E3BC2
4843F9FAFCAE492F11E2D4D33DBB4CDD
5310CABAE3FBE6DB8742849B588093F9
A0B13781EDD7CFDAB13D79AFFF3C83C1
70060341CAF3338697A7DDFE0FB62875
AD4643EEA15AC286FA47D1131F9EF756
D0B967571AC8A3863C7F324BF5BDE99C
D88D550D0FB8E60CFFFF3EA61FF7A067
%ProgramData%\Microsoft\Windows\Telemetry\msedge.exe
Global\E4AyDKzvEhe2hgAr
Global\fnulSktzSqvVLXHU
First-stage C2:
deadhub[.]org
193.23.118[.]155
Second-stage C2:
208.64.33[.]90
208.94.246[.]53
Imperva Threat Research identified a series of remote denial‑of‑service vulnerabilities in GraphQL Java, one of the most widely used libraries for GraphQL in the Java ecosystem.
In this blog, we’ll deep dive into these vulnerabilities, analyze their impact, and provide recommendations to protect your environment. If your endpoints are protected by Imperva Web Application Firewall, your systems are already protected against these threats.
GraphQL Java is the engine beneath Spring for GraphQL, Netflix DGS, and Atlassian’s own products. With over one million downloads per month and ten years of production use, it is a natural choice for any team building a GraphQL API on the JVM.
Over the last few years, multiple types of DoS attacks have been identified across GraphQL implementations. These vulnerabilities can lead to either denial of service or, in cloud-billed environments, excessive cost consumption. In response, the industry converged on a set of protective controls, like depth limiting, query complexity budgets, and field count caps. Apollo added query cost analysis and depth limiting, GitHub meters its public GraphQL API by computed node cost, and GraphQL Java also introduced additional controls.
However, these enhancements can leave blind spots earlier in the pipeline, before the server has even understood the request.
The DoS attack we found live in the first half of the pipeline, where the query is parsed and validated, and therefore independent from the schema, the resolvers, and any backend logic.
They were reported under GHSA-7p4r-9rcc-8vhv (still as draft) and fixed in versions 24.4, 25.1, and 26.1. Several products embedding the library were affected, including Adobe Experience Manager (AEM), Atlassian Confluence, and HAPI FHIR server, a widely used open-source implementation of the HL7 FHIR healthcare interoperability standard.
Fig. 1: GraphQL Processing High Level Pipeline
GraphQL was built around a simple idea: “GraphQL queries mirror their response.” In other words, the client describes exactly the data it needs, while the server determines how to retrieve and resolve that data. The query is then sent to a GraphQL endpoint, where it goes through a series of processing steps before the response is returned:
The distinction between these stages matters. A request can be rejected before execution because its syntax is invalid or because it does not match the schema. Only after passing these checks does GraphQL reach the resolvers, where the application and its underlying data sources are accessed.
For security research, this pipeline provides a useful way to understand the attack surface. Each stage processes attacker-controlled input in a different way, making it important to understand not only what GraphQL does, but also when and where it does it.
Before a server decides what data to return, it must first decide whether the request makes sense. Parsing breaks the raw query text into an Abstract Syntax Tree. This involves:
Validation walks the AST and checks it against the schema. This involves:
Validation is where fragment cycle detection takes place. Named fragments are GraphQL’s reuse mechanism. Instead of repeating the same selection set in multiple places, a client defines it once and references it with a spread:
Fig. 2: Named Fragments in GraphQL
Fragments can themselves spread other fragments. The spec allows arbitrary nesting, but it forbids cycles: if A spreads B and B spreads A, resolving either one requires resolving the other first. The execution engine would recurse indefinitely. The same applies to indirect cycles across any number of fragments.
This check happens during validation, after parsing has produced the AST and before execution starts. At this point the server has a complete map of every named fragment in the document and every spread reference between them.
Cycle detection is pretty straightforward: for each fragment, follow its spread references transitively and check whether any path leads back to the starting node. If it does, the document is rejected with a validation error and execution never starts.
ValidateNoFragmentCycles is called once per FragmentDefinition in the document. Each call starts with a fresh HashMap.
For each fragment, it calls buildTransitiveSpreads, a depth-first traversal that follows every spread reference outward, building up the set of fragments reachable from the starting node.
The traversal tracks its current path in an ArrayList, and at each step calls ArrayList.contains to check whether the next node has already been visited.
We considered a document with the following chain of d fragments:
Fig. 3: Malicious Payload Structure
For each fragment, ValidateNoFragmentCycles starts a new traversal with a fresh HashMap. Since the traversal follows the entire chain, and ArrayList.contains iterates over the path of fragments visited so far, the cost of a single validation is O(d²).
Fig. 4: Processing of the First Fragment
Since this happens for all fragments, the overall complexity is O(d³), where d is the number of fragments in the document. Within the default 15,000-token limit, a single payload can contain up to around 1,800 fragments (~50 KB), which is sufficient to saturate a CPU core for several minutes at every request.
Traditional GraphQL protections such as depth limits and field-count limits operate during validation. However, this attack specifically targets the validation step itself. Therefore, it hits before the protections can prevent the attack.
Following the reception of our report, graphql-java released a patch that introduces memoization. Once a fragment has been explored, it is marked as done and never re-traversed again. The same malicious payload is processed in a few milliseconds instead.
This finding was the most impactful, but it wasn’t the only one.
We identified the same underlying idea as one of the attack vectors previously identified in React Server Components (BigInt values, CVE-2026-23864), and another vector involving block string normalization routine, more impactful. Both fixed in 24.4, 25.1 and 26.1.
HAPI FHIR is a Java server designed to store and serve medical data (patients, prescriptions, lab results) using the FHIR healthcare standard. Like many modern APIs, it exposes a GraphQL endpoint that clients can use to query this data.
Internally, HAPI handles GraphQL requests with its own parser, written specifically for FHIR, which knows how to resolve medical resources. But when a client asks for introspection (a standard GraphQL feature that returns the full list of available queries and types) HAPI delegates directly to graphql-java.
However, it’s possible to bypass HAPI’s custom FHIR resolver and route a non-introspection query straight to graphql-java.
This delegation is triggered by a simple string check: it relies on the presence of the string `__schema` in the body.
Therefore, simply starting the request with the following pattern (see Fig 5.) was enough.
Fig. 5: bypass HAPI’s custom FHIR GraphQL resolver
Tested on a fresh c7i.2xlarge instance, with the latest HAPI server with graphql enabled, a single request took 150 seconds of validation. A single wave of multiple small requests could lock the server entirely for several minutes and pin all 8 CPU cores at 100% for more than an hour.
In this application, this attack vector could represent an alternative avenue for a threat actor lacking authorization to exfiltrate patient data (as HAPI’s authorization model governs GraphQL endpoint access and data read permissions independently), and still willing to cause impact.
The attack surface is further widened by HAPI’s default CORS configuration (allows any origin, Access-Control-Allow-Origin: *). In environments where no additional network controls are in place, this means the attack could be triggered from a browser: a healthcare worker opening a malicious link while connected to the internal network is sufficient to take down the FHIR server for everyone.
An application is potentially exposed when:
The fixes are available in GraphQL Java versions 24.4, 25.1, and 26.1 via PRs #4440, #4441.
For environments where an immediate upgrade is not possible:
If your endpoints are protected by Imperva Web Application Firewall, your systems are already protected against these threats.
As AI accelerates vulnerability discovery and exploitation, threat actors can increasingly scan a target environment in real time, identify weaknesses across its technology stack, and rapidly turn those findings into attacks. This reduces the time organizations must detect and remediate newly exposed vulnerabilities, making proactive and continuously enforced security controls increasingly important.
Affected organizations should upgrade to a fixed release as soon as possible. Until patches can be applied, additional controls at the application and network layers can help reduce exposure and limit the impact of potential attacks.
Imperva customers are protected against exploitation of these vulnerabilities. Imperva Threat Research will continue to monitor this threat and work to ensure that customers remain protected against emerging attack techniques targeting GraphQL and other widely deployed technologies.
August 11 – We reported the security issue to GraphQL Java.
August 19 – Report Acknowledged.
August 23 – Fix released in versions 24.4, 25.1 and 26.1.
The post New Remote DoS Attacks Against GraphQL Java appeared first on Blog.
AI-assisted development has crossed a threshold. The question is no longer whether your IDE communicates with an AI, it’s how deeply that AI is now wired into your local environment. The Model Context Protocol (MCP) is one of the plumbing behind this shift: a JSON-RPC-based protocol that lets AI assistants invoke tools running on your machine. From setting a breakpoint, to running tests, or launching a debugger… all from a chat window.
DebugMCP is one of the extensions leading that charge. Published by Microsoft on GitHub, it exposes a local MCP server that gives any compatible AI agent (GitHub Copilot, Cline, Cursor, Codex, Windsurf, and others) direct control over the VS Code debugger. The value proposition is compelling: instead of pasting stack traces into a chat window and waiting for a suggestion, an AI agent can set breakpoints, step through code, inspect variables, and evaluate expressions autonomously.
We identified and reported a critical security issue in version 1.1.4. A remote attacker who tricked a developer into visiting a malicious webpage could achieve arbitrary code execution on that developer’s machine, in the background, without any further user interaction (drive by).
Following our report, the maintainers patched DebugMCP via commit 86776b2m. The fix was silently shipped (no version bump, no advisory) and is included in version 1.2.0 and later. We are publishing this report following the 90-day disclosure period.
We recommend updating to the latest available version.
The exploitability of this weakness was amplified by the context in which the software evolves.
Indeed, we’re talking about an opensource MCP server hosted on GitHub, that can be used as a standalone server. But this MCP server is also exposed as an extension in VSCode Marketplace, installable with a single click both in local endpoints, and in shared servers via systems like Github CodeSpaces, OpenVSCode Server, etc.
From this single installation click, the server is automatically started and listening on port 3001 without authentication, opening the door to RCE.
First, we’ll explore how this issue could be exploited from a surrounding compromised device, and we’ll then demonstrate how DNS rebinding could be exploited to trigger RCE via simply having a victim browse to a malicious site.
DNS Rebinding is a recurrent risk issue when it comes to MCP servers’ development (See our previous blogpost: Another Critical RCE Discovered in a Popular MCP Server).
At the end of 2025, probably following a series of vulnerabilities identified in multiple MCP servers, Anthropic added an additional layer of security to prevent this risk (CVE-2025-66414) that adds a default security layer in most MCP server cases.
Version 1.24.0 of modelcontextprotocol introduces createMcpExpressApp, a preconfigured express server instance that automatically registers validateHostHeader and validateOriginHeader. Together, these functions prevent the risk of DNS rebinding.
However, the library still relies on maintainers to use header validation middleware functions in case of custom express configuration. And in the case of DebugMCP, this is lacking.
That was the first node of our attack chain.
Combined with the lack of host and origin definition and validation, the custom express server defined (identical to CVE-2025-53967), exposed the MCP tools far beyond the intended reach.
But independently from the broad network exposure, an LLM could be tricked via indirect prompt injection to access a file outside VSCode workspace trust, and the fix produced by the maintainers doesn’t answer this question.
To further explore the attack chain, let’s review the tools exposed.
The README lists the available tools, including:
From reading the tool definitions, start_debugging jumped out immediately since it accepted a fileFullPath argument and instructs VS Code to launch a debugger session for that file. That’s a file execution primitive.
But to obtain an efficient RCE chain, a few more steps were required.
At first glance, because the vulnerability requires knowing the full path of an executable on the victim’s machine, it seems difficult to weaponize reliably in the wild.
However, on Windows, the Universal Naming Convention (UNC) path format allows programs to reference files on network shares using paths of the form:
\\SERVER\SHARE\path\to\file
This feature enabled us to make DebugMCP pass the path to VS Code’s debugging infrastructure, which passed it to the Python launcher, which reached out to the attacker’s SMB share and loaded the file. The file executed under the victim’s user context.
Fig. 1: SMB endpoint to fetch payload
The proof-of-concept payload was intentionally benign:
import os
os.system(“calc.exe”)
After a few seconds, Calculator opened. The attacker’s code was running on the victim’s machine via a single HTTP request.
At this point we had a working local exploit, if we could send one HTTP request to port 3001 with an attacker-controlled UNC path and get code execution.
The remaining question was how to deliver that request from a remote attacker’s position to a victim’s localhost, across the same-origin policy that is supposed to make this impossible.
One part of the answer lies in the MCP itself. You can find a detailed introduction to the protocol here.
What matters here is one implementation detail that significantly reduced the attack complexity.
MCP over HTTP is built on JSON-RPC 2.0. The protocol specification describes a lifecycle: a client must send an initialize request, receive the server’s capability response, then send an initialized notification (only after this handshake can tool calls be made). This sequence implies a minimum of two round-trips before any tool is invoked, and it gives a server the opportunity to establish authenticated session state.
The MCP TypeScript SDK’s StreamableHTTPServerTransport enforces this lifecycle through a validateSession function called on every non-initialize request. The enforcement is conditional:
Fig. 2: Stateless MCP mode
When sessionIdGenerator is undefined, validateSession returns immediately without checking anything. The entire initialization lifecycle is bypassed. In DebugMCP v1.1.4, the transport was explicitly configured in stateless mode.
The consequence for the attack chain is direct: a single no-cors HTTP request was sufficient to trigger the attack.
However, there was a last ingredient we needed to incorporate to obtain a frictionless exploit.
Indeed, Local Network Access’s aim is to protect users from cross-site request forgery (CSRF) attacks targeting routers and other devices on private networks, and to reduce the ability of sites to use these requests to fingerprint the user’s local network.
Combined with the same-origin policy (that prevents a piece of JavaScript from one domain and make cors requests to a different one and get the response), in modern browsers, there is a good chance a warning popup would be displayed and halt the execution of the malicious content if a threat actor tries to scan the local network.
But DNS rebinding is a technique that can potentially circumvent this boundary by exploiting the way browsers cache DNS records. And as we explained earlier, DebugMCP doesn’t include MCP default mitigation added by Anthropic against this risk.
Here is the attack flow:
Fig. 3: Attack Flow
The sequence unfolds in six steps:
Step 1: Victim visits the page. The attacker’s domain resolves to the attacker’s public IP (Phase 1 DNS). The browser loads the initial page content.
Step 2: DNS Rebinding. The domain was registered with a very short TTL: 1 to 2 seconds. Firefox enforces an internal minimum cache duration of ~60 seconds regardless of the declared TTL, so the page polls in a JavaScript loop until the entry expires and Firefox re-resolves the name: at which point the attacker’s DNS server returns 127.0.0.1.
Step 3: Local Network Access. The attacker’s JavaScript, issues a fetch to http://evil.attacker.com:3001/mcp?transport=streamable_http. The browser considers this request same-origin and sends it. The DNS entry now points to 127.0.0.1, so the request arrives at the victim’s local DebugMCP server.
Step 4: DebugMCP Execution. The request reaches the Microsoft DebugMCP server running locally on the victim’s machine. DebugMCP processes the request and triggers its Python launcher, which is responsible for starting the debugging workflow.
Step 5: Malicious Payload Download. The Python launcher connects to a publicly accessible SMB share controlled by the attacker and downloads the malicious Python script onto the victim’s machine.
Step 6: Code Execution. The launcher passes the downloaded script to the start_debugging() function. DebugMCP then executes the attacker-controlled payload, ultimately giving the attacker code execution on the victim’s machine.
Although the exploit triggers error messages in the VS Code console, the payload is still successfully executed. We used Firefox version 150.0.3, the latest at the time of our research.
Note: After the research, Firefox enforced a Local Network Access Protections (version 153). This prevents the a request originating from a domain associated with a public IP to reach more private address networks. This recent feature, currently existing in Chrome and Firefox, isn’t yet generalized to all browsers.
The target is a developer. That means the compromised machine holds live credentials, source code, and trusted access to internal infrastructure.
In practice: AWS keys, SSH keys, GitHub tokens in VS Code’s secret storage, active cloud CLI sessions, VPN tunnels open to the internal network, and push access to production branches would be likely available: a payload that runs as the developer inherits all of it silently.
The delivery requires no interaction beyond visiting a page, it’s a drive-by attack.
Developers using this tool should update to the latest available version. The fix ships after 1.1.4 (version 1.2.0 and later).
In addition, it’s recommended to regularly audit which servers are listening on loopback.
Use authentication in your MCP servers and enforce governance to control which MCP server is running in your network and be able to remove it if necessary.
Regarding MCP development more specifically:
Use middleware that enforce validation (like createMcpExpressApp Since SDK v1.23.0).
Validate file path inputs. Reject UNC paths and remote schemes before passing any path to an execution primitive.
AI-assisted development is quietly rewriting the developer machine’s threat model. To give an agent useful capabilities, extensions expose local servers, wire in execution primitives, and grant broad access to the filesystem and the debugger.
Each of these is a reasonable engineering decision on its own. Together, they turn the workstation into a dense collection of automation endpoints, and those same endpoints, built to be driven by a trusted agent, are equally drivable by an attacker who reaches them. The productivity story and the attack surface story are the same story.
Developer environments are where source code, signing keys, pipeline credentials, and cloud sessions converge; compromising one is often a shorter path to production than attacking production directly.
This vulnerability was not sophisticated. The techniques here are not new; what’s new is the rate at which capable, unvetted local servers are being deployed onto high-value machines, and the growing ability of AI agents to discover and chain weaknesses autonomously.
The post From Debugging to Code Execution: RCE in Microsoft DevLabs’ DebugMCP? appeared first on Blog.
A new kind of AI model returns decisions instead of text. We spent a day trying to change its mind. It cost about 50 cents. In this article Jev is a new kind of AI model that returns typed decisions instead of text, built for software to call rather than for people to read. We put it inside a realistic application and tried to change its verdict from the outside. →every configuration we tested was broken: risk downgraded to low and investment advised, on a document that flags every warning sign →about 50 cents per successful break, with our strongest […]
The post A Decision Model Breaks Like Any Other Language Model: A First Look at Jev appeared first on Check Point Blog.
In this article Nineteen Check Point AI Security R&D teams spent two days on one prompt: build the demo customers would ask to see twice. Three of the results tell a single story about securing AI agents, and none of it starts with an attacker. →an autonomous agent took dangerous actions with no attacker involved, it simply hit a wall and improvised →a single poisoned file in a code repository turned a popular coding agent into a data exfiltration channel →questioning an off-track agent prevented as many attacks as blocking it, and completed more legitimate work →the lesson for anyone […]
The post No Attacker Required: What a Two-Day Hackathon Taught Us About Agent Security appeared first on Check Point Blog.
Torrent trackers have long been abused for distributing malicious software, disguised as popular films, games, and other content. Our previous research has shown that cybercriminals repeatedly turn to torrents as an initial infection vector, using trojanized cracks and installers to reach a large number of users. Installation guides for pirated software routinely instruct users to disable their antivirus, conditioning them to ignore the potential threats they are inviting onto their computers.
During our analysis of malware that leverages blockchain networks for its C2 infrastructure, we discovered a previously unknown modular, multi-stage framework that we dubbed MovieReaper. This report details the new crimeware campaign that began with the mass infection of users via compromised torrent tracker file storage. We have identified several hundred victims, including both individual users and organizations in multiple countries, such as Russia, Türkiye, Japan, Kenya, Uganda, and Colombia, as well as in several European countries like Spain, the Netherlands, Belgium, and Germany. We analyze the techniques for evading detection by security and sandbox solutions, and examine the capabilities of the modular framework.
Kaspersky products detect this threat as HEUR:Trojan.Win64.Agent.gen.
In mid‑August 2026, during our threat‑hunting efforts, we identified a large‑scale infection campaign involving previously unknown malware disguised as popular movies. The campaign affected both individuals and organizations across multiple countries. Our initial analysis revealed a common denominator: all of the victims had used torrent trackers. This finding prompted us to investigate the campaign further and analyze its distribution mechanism, overall scope, and unknown malware implants.
Compromised torrent trackers are the primary vector used to distribute malware. During our investigation, we identified multiple user reports describing suspicious files being downloaded instead of the intended content.
For example, a user of a popular movie torrent tracker reported the following case on Reddit:
Further analysis of the attack revealed that instead of compromising torrent trackers, the threat actor modified a widely used public repository of torrent files, itorrents[.]org. As a result, the trackers that relied on the repository began inadvertently distributing malicious torrent files to their users. This approach is particularly dangerous because it lets the threat actor reach users of multiple trackers without having to compromise each platform individually.
As of the publication date of this report, the archive remains compromised. When a user attempts to download a torrent via a magnet link, the legitimate torrent archive returns a different torrent file. This malicious torrent leads to the download of the malware loader, used to deploy a framework that we dubbed MovieReaper.
The loader initiates the infection chain shown in the diagram below. Each stage of the chain is described in detail in the following sections.
The infection chain consists of several steps, where only the initial one is dropped on the disk before it is executed to avoid detection. The malware itself is not heavily obfuscated, apart from strings being encrypted with a custom stream cipher. Most of the countermeasures were aimed at avoiding detection by AV sandboxes.
The most popular initial executable was distributed through torrent trackers under many different names (for example, the odyssey (2026) [1080p] [webrip] [5.1].exe), but the file hash (MD5: A0B13781EDD7CFDAB13D79AFFF3C83C1) was identical across all downloads. We have seen multiple different loaders, where the executable file disguises itself with a long filename and an icon of some well-known application. Most of the filenames are rather long, presumably to hide the EXE extension at the end.
After the user manually starts the application, it establishes a global mutex to ensure that only one loader is executed at a time. We have seen several mutex variations in our samples, containing a randomly generated string (in the example Global\fnulSktzSqvVLXHU). This executable then performs a series of operations in order to avoid detection by AV sandbox solutions.
While performing those operations, the malware avoids making LoadLibrary and GetProcAddress calls to acquire the addresses of required functions. Instead, it searches for loaded libraries by traversing the double-linked list taken from the Ldr field of the PEB and then performs manual parsing of the loaded DLL to calculate the function address.
After all initial checks have passed, the binary prepares to establish a network connection to a C2 web server to download the shellcode, map it to the RWX memory and execute. While doing so, the loader decodes the domain name https://deadhub[.]org and if connection to it has failed, it uses the IP address http://193.23.118[.]155 as a fallback and connects to it using plain HTTP. The malware chooses a random group of strings and uses them as a path in the HTTP request to download the parts of the shellcode.
Example URLs:
/cloud/v192.4/ui/sync-status-icons.png
/cloud/v192.4/onboarding/welcome-bg.jpg
/cloud/v192.4/ui/file-preview-placeholder.png
/cloud/v192.4/shared/link-banner.jpg
While mapping the address space and executing the shellcode, the loader registers a vectored exception handler and rewrites the handler address in memory in order to perform a debug break. This, will not crash the program, but instead redirect controlflow to the function that actually makes a raw NtProtectVirtualMemory syscall (via a previously located “0x0F 0x05” syscall instruction inside ntdll). Then it calls the undocumented ntdll function EtwpCreateEtwThread, which is a popular alternative to CreateThread for code executionm, and executes the shellcode.
The second stage of this malware performs an HTTPS request to the Solana blockchain at the endpoint /getAccountInfo endpoint for the account 6pnDGAiHgyPdmckM5Qt1YbanGzrX43WLEU159nRaNLDm. The data in field of the response contains the base64‑encoded address of a second C2, which is encrypted with a static XOR key located within the shellcode itself. To store data in this account, attackers used a simple Solana program (address: CSiY8bQLBYPdfPWkwipBzH6sijTVQVVsA279JQdvwHtL).
Utilizing the Solana blockchain as a storage layer for next-stage C2 endpoints substantially complicates infrastructure takedown efforts by defenders.
The second stage payload communicates with its C2 server strictly through HTTPS via a TLS-pinned certificate using the nanopb protobuf library as a container for transferred data. The main logic of the stage 2 implant contains several initial commands, where the most important is the one that parses the COFF file, loads it into memory, and executes the module_init function from it. This provides a convenient interface for extension of the command list, which brings us to the next stage of the payload.
Notably, the recovered modules were compiled with symbols, which accelerated reverse engineering.
After receiving the next stage from the second C2 server, the newly loaded module performs several tasks right in the module_init function.
Stage 3 performs UAC Bypass and achieves persistence using public techniques, masquerades the original binary as C:\ProgramData\Microsoft\Windows\Telemetry\msedge.exe, and restarts itself.
The respawned process starts with the initial loader, but with a special command-line argument, which allows it to skip most of the anti-sandboxing checks and proceed straight to downloading the next payload. The executable proceeds with the same steps as before, but this time, instead of downloading the persistence and UAC bypass module, a new one is downloaded from the second C2 server. This is because the malware uses the beacon to send a flag to the remote server, indicating whether the implant is running from the Telemetry folder, which allows the C2 to distinguish between first-run and respawned instances.
The final module (“file manager”) exposes 21 commands that give the operator filesystem access on the victim host. This allows remote the operator to download, upload, and read files on the system; list and enumerate directories; manipulate files with create, copy, rename, move, delete, chmod, and symlink commands; and use preview and thumbnail commands to exfiltrate previews of images and files before actually extracting them.
We suspect that other modules may be loaded on demand if requested by the operator.
During this malware campaign, attackers are using various commercial hosting providers for their C2 infrastructure (see the IoC section for details). Furthermore, as noted above, the campaign leverages the legitimate Solana blockchain via the RPC endpoint api.mainnet.solana.com to deliver the address of the second‑stage C2 server to the malware. This approach provides the attackers with decentralized storage for C2 addresses, adding an additional layer of resilience and making it more difficult for defenders to disrupt the campaign by simply blocking the IP addresses of the C2 servers.
The observed campaign targeted both individuals and organizations across Europe, Asia, Africa, and Latin America, with infection attempts identified in Russia, Spain, Germany, Finland, Türkiye, Japan, Nepal, Kenya, Tanzania, Ghana, Uganda, Colombia, the Netherlands, Belgium, and other countries. The targeted organizations span a wide range of sectors, including enterprise, government, IT, consulting, retail, transportation, and agriculture.
Our research uncovered activity by the same actor dating back to October 2025. Although the campaign has evolved over time, with the malware authors expanding their arsenal and making the loader harder to detect, the pattern remains the same. This includes encoded strings, parts of shellcode downloaded through plain HTTP, and several techniques used to avoid sandboxes and virtual machines. We will continue monitoring this actor’s activity to catch new potential threats.
The first stage offers the clearest opportunity to disrupt this campaign: it relies on a single specific domain name and a single IP address to serve the shellcode, so taking down this server would prevent subsequent infection stages. This includes the second-stage payload, which uses the Solana blockchain network for a C2 and is therefore more resistant to conventional infrastructure takedowns.
However, this framework’s self-containment, modularity and in-memory execution has potential for reuse in later campaigns with minimal rework.
4334BBAEA8DE33BF9D45E9B4E4E3BC2
4843F9FAFCAE492F11E2D4D33DBB4CDD
5310CABAE3FBE6DB8742849B588093F9
A0B13781EDD7CFDAB13D79AFFF3C83C1
70060341CAF3338697A7DDFE0FB62875
AD4643EEA15AC286FA47D1131F9EF756
D0B967571AC8A3863C7F324BF5BDE99C
D88D550D0FB8E60CFFFF3EA61FF7A067
%ProgramData%\Microsoft\Windows\Telemetry\msedge.exe
Global\E4AyDKzvEhe2hgAr
Global\fnulSktzSqvVLXHU
First-stage C2:
deadhub[.]org
193.23.118[.]155
Second-stage C2:
208.64.33[.]90
208.94.246[.]53
We explore how AWS neutralizes exposed IAM credentials using managed policies, detailing GitHub secret scanning and CloudTrail monitoring strategies.
The post From Exposure to Lockdown: How AWS Neutralizes Compromised IAM Credentials through Managed Policies appeared first on Unit 42.
Analysis of how default configurations in AWS AgentCore Harness allow prompt injection to exfiltrate credentials, and key steps to secure your agents.
The post A Vault with a Heap-View: The Uncomfortable Space Between AgentCore Harness and Identity appeared first on Unit 42.
We designed a behavioral clustering model to map cloud identity roles from audit logs, enabling continuous threat detection using standard SQL queries.
The post Unmasking Cloud Identities: From Behavioral Clustering to Automated Detection appeared first on Unit 42.
Learn how root access on a compromised K8s node allows attackers to utilize SPIFFE/SPIRE metadata to spoof and harvest co-located workload identities.
The post The Machine With Many Faces: Post-Exploitation Identity Misuse in SPIFFE/SPIRE appeared first on Unit 42.
An investigation into how cybercriminals used YouTube gaming lures and SEO poisoning to deliver multi-payload malware to enterprise networks.
The post Untracked Nightmares: The Threats Hiding Behind Commodity Infrastructure appeared first on Unit 42.
The defining development of the period came not from attackers but from the AI labs themselves, whose models broke out of controlled evaluations and reached real systems. In the wild, the criminal and state use of AI continued to mature along the lines tracked in earlier editions: models now act as attack operators, an underground market supplies the access, and AI systems have themselves become a target. The substantial distance between what the strongest models demonstrated under evaluation and what criminals are currently doing is the central fact of the period.
Want the full report? Read the complete July-August 2026 AI Threat Landscape Digest here.
The post AI Threat Landscape Digest: July–August 2026 appeared first on Check Point Research.
Login
