Microsoft today issued updates to fix more than 1,400 security vulnerabilities in its Windows operating systems and other software. Today’s epic patch batch dwarfs September’s record of nearly 1,000 fixes, which was already about ten times the normal monthly patch load from Redmond.
Just one of the weaknesses patched this week is considered a “zero day,” or already exploited in the wild. CVE-2026-96951 is a security feature bypass in the Windows Shell that affects Windows 10 and 11 systems, as well as some Server versions.
Windows 10 users might be wondering if they can still expect security updates after this month. Microsoft had been slated to stop shipping updates for Windows 10 systems in October 2025, but ended up adding another year of free updates after considerable pushback. A few months ago, Microsoft quietly extended that support for another year (until October 2027).
At least 78 of the flaws fixed this month are rated “critical,” meaning they could be exploited with little or no action by the user, and most of those critical bugs allow an attacker to execute code of their choice on the vulnerable system.
While Microsoft said there are no signs anyone is exploiting it yet, a security feature bypass in the .NET Framework (CVE-2026-108398) was publicly disclosed prior to today, potentially giving attackers advance time to work out how to exploit the bug.
Satnam Narang at Tenable said the number of flaws fixed this month far surpasses the previous record-setting year 2020, when Microsoft patched 1,261 CVEs.
“We’ve now crossed the 4,000 CVE mark with two months left to go,” he said.
Microsoft credits large language models for the high volume of bug discovery, and presumably AI gets credit for many of the patches used to fix these flaw. Meanwhile, security experts have been warning that these unusually large patch volleys from Microsoft are placing extra strain on corporate security teams, which often have to test individual updates before deploying them across a network to ensure the fixes don’t cause problems for other software.
Tyler Reguly, associate director of security research and development at Fortra, notes that just 26 Microsoft vulnerabilities appeared in the “Known Exploited Vulnerabilities” (KEV) catalog maintained by the U.S. Cybersecurity & Infrastructure Security Agency (CISA) so far this year, and security teams would do well to prioritize patching those 26 vulnerabilities first.
“Security leaders should focus on exploitable risk, and ask whether their teams have the clarity, capacity and support to act,” Reguly said.
Which vulnerabilities deserve the most scrutiny in your organization? The folks at Cisco Talos have a useful roundup of the more noteworthy flaws that Microsoft fixed today, and of course the SANS Internet Storm Center has a reliable roundup that indexes vulnerabilities by severity, CVE number and affected software.
Unit 42 dissects a cyberattack targeting a European bank’s IT infrastructure, delivering concrete defense strategies to help organizations detect and counter comparable threats.
Microsoft has released its monthly security update for October 2026, which includes 1415 vulnerabilities affecting a range of products, including 85 that Microsoft marked as “critical.”
Microsoft notes that 1 of the vulnerabilities disclosed this month have been exploited in the wild
CVE-2026-96951 is a security feature bypass vulnerability that affects Windows Shell. The shared weakness is Improper Neutralization of Special Elements used in a Command (‘Command Injection’). The vulnerability has a CVSS base score of 8.8.
Out of 85 “critical” vulnerabilities, 67 are remote code execution (RCE) vulnerabilities.
Microsoft considers exploitation of the following vulnerabilities more likely.
CVE-2026-70229 is a remote code execution vulnerability that affects Windows Active Directory Domain Services. The shared weakness is Incorrect Authorization. The vulnerability has a CVSS base score of 8.1.
CVE-2026-70571 is a remote code execution vulnerability that affects Microsoft Exchange Server. The shared weakness is Stack-based Buffer Overflow. The vulnerability has a CVSS base score of 8.1.
Microsoft considers exploitation of the following vulnerabilities less likely.
CVE-2026-105733, CVE-2026-102214, and CVE-2026-108399 affect Windows Hyper-V. CVE-2026-105733 has an impact of remote code execution; involves Incorrect Initialization of Resource; has a CVSS base score of 8.8. CVE-2026-102214 has an impact of remote code execution; involves Use After Free; has a CVSS base score of 8.8. CVE-2026-108399 has an impact of elevation of privilege; involves Heap-based Buffer Overflow; has a CVSS base score of 7.2.
CVE-2026-100202 is a remote code execution vulnerability that affects Windows Message Queuing Queue Manager. The shared weakness is Use After Free. The vulnerability has a CVSS base score of 9.8.
CVE-2026-100215 is a remote code execution vulnerability that affects Microsoft Graphics Component. The shared weakness is Heap-based Buffer Overflow. The vulnerability has a CVSS base score of 7.8.
CVE-2026-100220 is a remote code execution vulnerability that affects Windows Media Video Decoder. The shared weakness is Heap-based Buffer Overflow. The vulnerability has a CVSS base score of 8.8.
CVE-2026-102211, CVE-2026-88074, CVE-2026-108130, CVE-2026-108471, and CVE-2026-96914 are elevation of privilege vulnerabilities that affect Windows Virtualization-Based Security (VBS) Enclave. CVE-2026-102211 involves Concurrent Execution using Shared Resource with Improper Synchronization (‘Race Condition’) and Use After Free; has a CVSS base score of 7.0. CVE-2026-88074 involves Integer Overflow or Wraparound; has a CVSS base score of 7.8. CVE-2026-108130 involves Heap-based Buffer Overflow; has a CVSS base score of 7.8. CVE-2026-108471 involves Untrusted Pointer Dereference; has a CVSS base score of 8.8. CVE-2026-96914 involves Heap-based Buffer Overflow and Integer Overflow or Wraparound; has a CVSS base score of 8.8.
CVE-2026-102225 and CVE-2026-97814 are remote code execution vulnerabilities that affect Windows Text Shaping. CVE-2026-102225 involves Numeric Truncation Error and Out-of-bounds Read; has a CVSS base score of 8.8. CVE-2026-97814 involves Heap-based Buffer Overflow; has a CVSS base score of 9.8.
CVE-2026-102855, CVE-2026-102856, and CVE-2026-102857 are remote code execution vulnerabilities that affect Microsoft Office Visio. The shared weakness is Heap-based Buffer Overflow. Each has a CVSS base score of 8.8. CVE-2026-102856 involves Integer Overflow or Wraparound. CVE-2026-102857 involves Off-by-one Error.
CVE-2026-102866 is an elevation of privilege vulnerability that affects Microsoft Office SharePoint. The shared weakness is Improper Verification of Cryptographic Signature. The vulnerability has a CVSS base score of 8.1.
CVE-2026-62840 is an elevation of privilege vulnerability that affects Linux Kernel. The shared weakness is Time-of-check Time-of-use (TOCTOU) Race Condition. The vulnerability has a CVSS base score of 7.0.
CVE-2026-69802 is a remote code execution vulnerability that affects Network Device Enrollment Service (NDES). The shared weakness is Weak Authentication. The vulnerability has a CVSS base score of 8.1.
CVE-2026-70187 is a remote code execution vulnerability that affects Windows Remote Desktop Services. The shared weakness is Use After Free. The vulnerability has a CVSS base score of 8.1.
CVE-2026-70250 is a remote code execution vulnerability that affects Windows DHCP Client. The shared weakness is Concurrent Execution using Shared Resource with Improper Synchronization (‘Race Condition’) and Use After Free. The vulnerability has a CVSS base score of 8.8.
CVE-2026-83934 is a remote code execution vulnerability that affects Windows GDI+. The shared weakness is Stack-based Buffer Overflow. The vulnerability has a CVSS base score of 8.8.
CVE-2026-88073 is an elevation of privilege vulnerability that affects Windows Graphics Kernel. The shared weakness is Use After Free. The vulnerability has a CVSS base score of 8.8.
CVE-2026-96222 and CVE-2026-108131 are spoofing vulnerabilities that affect Active Directory Federation Services (AD FS). CVE-2026-96222 involves Improper Certificate Validation; has a CVSS base score of 7.4. CVE-2026-108131 has a CVSS base score of 7.5.
CVE-2026-96913 is an elevation of privilege vulnerability that affects Windows Kernel. The shared weakness is Heap-based Buffer Overflow. The vulnerability has a CVSS base score of 8.8.
CVE-2026-96952 is a remote code execution vulnerability that affects Microsoft Windows Media Foundation. The shared weakness is Heap-based Buffer Overflow. The vulnerability has a CVSS base score of 8.8.
CVE-2026-105718 is a remote code execution vulnerability that affects Microsoft Excel. The shared weakness is Improper Input Validation and Out-of-bounds Read. The vulnerability has a CVSS base score of 8.8.
CVE-2026-108400 is a remote code execution vulnerability that affects HEVC Video Extensions. The shared weakness is Integer Overflow or Wraparound. The vulnerability has a CVSS base score of 8.8.
CVE-2026-108457 is a remote code execution vulnerability that affects Microsoft Windows PDF. The shared weakness is Out-of-bounds Write. The vulnerability has a CVSS base score of 8.1.
CVE-2026-108460 is a remote code execution vulnerability that affects Windows Message Queuing. The shared weakness is Use After Free. The vulnerability has a CVSS base score of 8.1.
CVE-2026-70269 and CVE-2026-70300 are remote code execution vulnerabilities that affect Microsoft Office Word. CVE-2026-70269 involves Heap-based Buffer Overflow and Integer Overflow or Wraparound; has a CVSS base score of 8.1. CVE-2026-70300 involves Untrusted Pointer Dereference; has a CVSS base score of 9.8.
CVE-2026-83917 is an elevation of privilege vulnerability that affects Windows ALPC. The shared weakness is Use After Free. The vulnerability has a CVSS base score of 7.0.
CVE-2026-94510 is an elevation of privilege vulnerability that affects Microsoft Bookings. The shared weakness is Authorization Bypass Through User-Controlled Key. The vulnerability has a CVSS base score of 9.9.
CVE-2026-96202 and CVE-2026-96943 are remote code execution vulnerabilities that affect Windows Raw Image Extension. The shared weakness is Heap-based Buffer Overflow. Each has a CVSS base score of 8.8. CVE-2026-96943 involves Integer Overflow or Wraparound.
CVE-2026-96207 is an elevation of privilege vulnerability that affects Microsoft Partner Center. The shared weakness is Improper Certificate Validation. The vulnerability has a CVSS base score of 10.0.
Microsoft considers exploitation of the following vulnerabilities unlikely.
CVE-2026-69789 is a remote code execution vulnerability that affects Windows Reliable Multicast Transport Driver (RMCAST). The shared weakness is Heap-based Buffer Overflow. The vulnerability has a CVSS base score of 7.5.
CVE-2026-88174 is a remote code execution vulnerability that affects Windows Deployment Services. The shared weakness is Concurrent Execution using Shared Resource with Improper Synchronization (‘Race Condition’). The vulnerability has a CVSS base score of 8.1.
CVE-2026-88185 is a remote code execution vulnerability that affects Microsoft Office Word. The shared weakness is Heap-based Buffer Overflow. The vulnerability has a CVSS base score of 8.1.
Other critical vulnerabilities
CVE-2026-69435 is an elevation of privilege vulnerability that affects Azure SRE Agent. The shared weakness is Server-Side Request Forgery (SSRF). The vulnerability has a CVSS base score of 9.6.
CVE-2026-77900 is a remote code execution vulnerability that affects Azure App Service. The shared weakness is Missing Authentication for Critical Function. The vulnerability has a CVSS base score of 9.8.
CVE-2026-83943 is an information disclosure vulnerability that affects Azure API Center. The vulnerability has a CVSS base score of 8.7.
CVE-2026-83947 is a spoofing vulnerability that affects Azure Event Grid. The shared weakness is Missing Authorization. The vulnerability has a CVSS base score of 7.7.
CVE-2026-88131 is a remote code execution vulnerability that affects Microsoft Dataverse. The shared weakness is Deserialization of Untrusted Data. The vulnerability has a CVSS base score of 9.8.
Talos would also like to highlight the following “important” vulnerabilities as Microsoft has determined that their exploitation is “more likely:”
CVE-2026-100214: Microsoft Dynamics 365 Business Central Remote Code Execution Vulnerability
CVE-2026-102217: WebDAV Elevation of Privilege Vulnerability
CVE-2026-69673: Windows Update Elevation of Privilege Vulnerability
CVE-2026-69718: Windows Update Elevation of Privilege Vulnerability
CVE-2026-69733: Windows Update Elevation of Privilege Vulnerability
CVE-2026-69783: Windows Update Elevation of Privilege Vulnerability
CVE-2026-69882: Windows Update Elevation of Privilege Vulnerability
CVE-2026-69923: Windows AI Elevation of Privilege Vulnerability
CVE-2026-69926: Desktop Window Manager Elevation of Privilege Vulnerability
CVE-2026-70054: Windows NetBIOS Elevation of Privilege Vulnerability
CVE-2026-70060: Windows Win32k Elevation of Privilege Vulnerability
CVE-2026-70076: Windows Win32k Elevation of Privilege Vulnerability
CVE-2026-70104: Windows Win32k Elevation of Privilege Vulnerability
CVE-2026-70108: Windows Win32k Elevation of Privilege Vulnerability
CVE-2026-70117: Windows Win32k Elevation of Privilege Vulnerability
CVE-2026-70132: Windows Portable Device File System Driver Elevation of Privilege Vulnerability
CVE-2026-70144: Windows Win32k Elevation of Privilege Vulnerability
CVE-2026-70156: Microsoft Windows Search Component Elevation of Privilege Vulnerability
CVE-2026-70218: Windows StateRepository API Elevation of Privilege Vulnerability
CVE-2026-70223: Windows Console Driver Elevation of Privilege Vulnerability
CVE-2026-70233: Windows Common Log File System Driver Elevation of Privilege Vulnerability
CVE-2026-70236: Windows Win32k Elevation of Privilege Vulnerability
CVE-2026-70237: Windows Ancillary Function Driver for WinSock Elevation of Privilege Vulnerability
CVE-2026-70241: Windows Kerberos Elevation of Privilege Vulnerability
CVE-2026-70245: Windows Ancillary Function Driver for WinSock Elevation of Privilege Vulnerability
CVE-2026-70249: Windows Win32k Elevation of Privilege Vulnerability
CVE-2026-70253: Windows Win32k Elevation of Privilege Vulnerability
CVE-2026-70255: Desktop Window Manager Elevation of Privilege Vulnerability
CVE-2026-70271: Windows Win32k Elevation of Privilege Vulnerability
CVE-2026-70273: Windows Win32k Elevation of Privilege Vulnerability
CVE-2026-70286: Windows Graphics Component Elevation of Privilege Vulnerability
CVE-2026-70303: Windows Kernel Elevation of Privilege Vulnerability
CVE-2026-72955: Windows Application Compatibility Cache Elevation of Privilege Vulnerability
CVE-2026-81971: Windows NTFS Elevation of Privilege Vulnerability
CVE-2026-83505: Windows Setup Files Cleanup Elevation of Privilege Vulnerability
CVE-2026-83509: Windows Setup Files Cleanup Elevation of Privilege Vulnerability
CVE-2026-83510: Windows Setup Files Cleanup Elevation of Privilege Vulnerability
CVE-2026-83580: Windows Client-Side Caching (CSC) Service Elevation of Privilege Vulnerability
CVE-2026-83669: Windows Error Reporting Elevation of Privilege Vulnerability
CVE-2026-83699: Windows Client-Side Caching (CSC) Service Elevation of Privilege Vulnerability
CVE-2026-83704: Microsoft Windows Search Component Elevation of Privilege Vulnerability
CVE-2026-83717: Windows Installer Elevation of Privilege Vulnerability
CVE-2026-83724: Windows Management Instrumentation Elevation of Privilege Vulnerability
CVE-2026-83732: Win32k Elevation of Privilege Vulnerability
CVE-2026-83735: Windows Kernel Elevation of Privilege Vulnerability
CVE-2026-83738: Windows Ancillary Function Driver for WinSock Elevation of Privilege Vulnerability
CVE-2026-83750: Windows Error Reporting Elevation of Privilege Vulnerability
CVE-2026-83761: Windows Win32 Kernel Subsystem Elevation of Privilege Vulnerability
CVE-2026-83763: Windows Input System Elevation of Privilege Vulnerability
CVE-2026-83768: Windows Kernel Elevation of Privilege Vulnerability
CVE-2026-83769: Microsoft OpenSSH for Windows Elevation of Privilege Vulnerability
CVE-2026-83793: Windows Update Orchestrator Service Elevation of Privilege Vulnerability
CVE-2026-83830: Windows COM+ Event System Service Elevation of Privilege Vulnerability
CVE-2026-83834: Windows Kernel-Mode Drivers Elevation of Privilege Vulnerability
CVE-2026-83840: Windows Error Reporting Elevation of Privilege Vulnerability
CVE-2026-83842: Windows TCP/IP Elevation of Privilege Vulnerability
CVE-2026-83848: Windows COM+ Event System Service Elevation of Privilege Vulnerability
CVE-2026-83867: Windows Push Notifications Elevation of Privilege Vulnerability
CVE-2026-83886: Windows Update Orchestrator Service Elevation of Privilege Vulnerability
CVE-2026-83896: Windows Direct Composition Elevation of Privilege Vulnerability
CVE-2026-83899: Windows Installer Elevation of Privilege Vulnerability
CVE-2026-83902: Windows Direct Composition Elevation of Privilege Vulnerability
CVE-2026-83921: Windows Search Service Elevation of Privilege Vulnerability
CVE-2026-84014: Windows Device Association Service Elevation of Privilege Vulnerability
CVE-2026-85355: Windows Common Log File System Driver Elevation of Privilege Vulnerability
CVE-2026-85791: Windows Encrypting File System (EFS) Elevation of Privilege Vulnerability
CVE-2026-85802: Windows Win32 Kernel Subsystem Elevation of Privilege Vulnerability
CVE-2026-85804: Windows Win32 Kernel Subsystem Elevation of Privilege Vulnerability
CVE-2026-85832: Windows Background Intelligent Transfer Service (BITS) Elevation of Privilege Vulnerability
CVE-2026-85843: Windows Background Intelligent Transfer Service (BITS) Elevation of Privilege Vulnerability
CVE-2026-85848: Windows Background Intelligent Transfer Service (BITS) Elevation of Privilege Vulnerability
CVE-2026-85849: Windows AppX Deployment Service Elevation of Privilege Vulnerability
CVE-2026-85850: Windows Kernel Elevation of Privilege Vulnerability
CVE-2026-85855: Windows DWM Core Library Elevation of Privilege Vulnerability
CVE-2026-85870: Windows Common Log File System Driver Elevation of Privilege Vulnerability
CVE-2026-85901: Windows Graphics Component Elevation of Privilege Vulnerability
CVE-2026-85908: Windows Graphics Component Elevation of Privilege Vulnerability
CVE-2026-85941: Windows Installer Elevation of Privilege Vulnerability
CVE-2026-85945: Windows Kernel Elevation of Privilege Vulnerability
CVE-2026-88118: Windows Background Intelligent Transfer Service (BITS) Elevation of Privilege Vulnerability
CVE-2026-88133: Windows Portable Device Enumerator Service Elevation of Privilege Vulnerability
CVE-2026-88147: Windows Secure Socket Tunneling Protocol (SSTP) Elevation of Privilege Vulnerability
CVE-2026-88152: Windows Background Intelligent Transfer Service (BITS) Elevation of Privilege Vulnerability
CVE-2026-88159: Windows Background Intelligent Transfer Service (BITS) Remote Code Execution Vulnerability
CVE-2026-88191: Microsoft Windows Search Component Elevation of Privilege Vulnerability
CVE-2026-96858: Windows Security Account Manager Tampering Vulnerability
CVE-2026-96911: Microsoft Windows Search Component Elevation of Privilege Vulnerability
CVE-2026-96929: Windows Kernel Elevation of Privilege Vulnerability
CVE-2026-96940: Microsoft Exchange Server Elevation of Privilege Vulnerability
CVE-2026-69452: Windows Enterprise App Management Elevation of Privilege Vulnerability
CVE-2026-69880: Desktop Window Manager Elevation of Privilege Vulnerability
CVE-2026-69918: Windows Core Messaging Elevation of Privilege Vulnerability
CVE-2026-70103: Windows Error Reporting Elevation of Privilege Vulnerability
CVE-2026-70106: Windows Kernel Elevation of Privilege Vulnerability
CVE-2026-70151: Windows Direct Composition Elevation of Privilege Vulnerability
CVE-2026-70176: Windows Win32k Elevation of Privilege Vulnerability
CVE-2026-70279: Microsoft Exchange Server Spoofing Vulnerability
CVE-2026-83785: Windows COM+ Event System Service Elevation of Privilege Vulnerability
CVE-2026-83927: Windows Registry Elevation of Privilege Vulnerability
CVE-2026-85884: Windows Health and Optimized Experiences Service Elevation of Privilege Vulnerability
CVE-2026-85902: Windows Direct Composition Elevation of Privilege Vulnerability
CVE-2026-85906: Windows Direct Composition Elevation of Privilege Vulnerability
CVE-2026-88093: Desktop Window Manager Elevation of Privilege Vulnerability
CVE-2026-96939: Servicing Stack Updates Elevation of Privilege Vulnerability
CVE-2026-97798: Windows Error Reporting Service Elevation of Privilege Vulnerability
CVE-2026-97799: Windows Audio Service Elevation of Privilege Vulnerability
CVE-2026-97800: Windows Mobile Broadband Elevation of Privilege Vulnerability
A complete list of all the other vulnerabilities Microsoft disclosed this month is available on its update page.
In response to these vulnerability disclosures, Talos is releasing a new Snort ruleset that detects attempts to exploit some of them. Please note that additional rules may be released at a future date, and current rules are subject to change pending additional information. Cisco Secure Firewall customers should use the latest update to their ruleset by updating their SRU. Open-source Snort Subscriber Ruleset customers can stay up to date by downloading the latest rule pack available for purchase on Snort.org.
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):
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):
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:
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”””
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
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
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.
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}”)
Parses the S3 URL to extract bucket (attacker-bucket) and object key (adapters/evil_adapter.py)
Downloads the Python file to a temporary location
Calls exec_module() which executes the top-level os.makedirs() call
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:
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:
LiteLLM creates a new router using the attacker’s model_list
The chat completion request is sent to http://10.10.13.37:9999 instead of the legitimate OpenAI API
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.
Threat intelligence teams are heading into 2027 with more than ever to monitor, driven by an acceleration in the AI threat landscape. However, their expanded mandate typically doesn’t come with a proportional budget windfall. Instead, teams are under pressure to get greater value from the intelligence, systems, and analyst expertise already available to them.
New independent research commissioned by Flashpoint shows where that pressure is being felt most. Alert noise and false positives are the most frequently cited challenges affecting threat intelligence program effectiveness, followed by analyst bandwidth, changes in the threat landscape, and integration across security tools. At the same time, AI-related threats have emerged as the leading area where practitioners want to expand intelligence coverage.
These findings point to some of the decisions that will shape threat intelligence programs in the year ahead: where to focus finite analyst capacity, how intelligence requirements need to evolve, and where AI can meaningfully support the work. Organizations are already evaluating agentic AI across threat intelligence workflows, but the research also shows that greater autonomy comes with higher expectations around accuracy, control, and measurable value.
For security leaders planning their 2027 threat intelligence strategy and budgets, this report examines:
Which operational challenges are putting the greatest pressure on analyst capacity and threat intelligence programs today.
How intelligence requirements are changing as AI-enabled threats create new coverage priorities.
How threat intelligence budgets are trending in the next 12 months, and where incremental budgets will go.
Where practitioners see the strongest applications for agentic AI, and which AI-powered workflows face a higher threshold for trust and autonomy.
What teams need to prove before expanding AI investment, including the metrics practitioners are using to evaluate time savings, accuracy, risk reduction, and ROI.
Together, the findings provide a practical benchmark for teams evaluating their own intelligence operations: where to focus limited analyst time, where automation may have the greatest impact, and what to measure as AI becomes part of the workflow.
Executive Summary
As threat intelligence teams plan for 2027, the research shows them managing two simultaneous pressures: intelligence requirements are expanding, while the capacity available to address them remains constrained. AI is intensifying that pressure as adversaries adopt new capabilities, but also becoming part of how organizations are thinking about scaling their ability to defend their organizations.
“2027 will test whether threat intelligence programs can scale their reach as fast as AI is reshaping the threat landscape. The opportunity for agentic AI on the defensive side is significant, and our research shows security leaders are ready to invest. But they aren’t swayed by the hype. They’re holding agentic AI to a high bar, and they want to know where it improves their work, whether they can trust the output, and where human judgment must remain part of the process.”
Josh Lefkowitz Co-Founder and CEO, Flashpoint
Four findings stand out:
The AI threat landscape is accelerating faster than threat intelligence teams can keep up. Alert noise and false positives were the most frequently cited challenge, identified by 65% of respondents, while 55% cited insufficient analyst bandwidth and half pointed to integration gaps across their security tools.
Threat intelligence budgets are rising to close the gap. Half of respondents expect their budgets to increase over the next 12 months, including 35% anticipating meaningful increases of 10% or more. Another 40% expect spending to remain essentially flat. No respondents anticipate a decrease. Where budgets are growing, organizations are directing investment toward areas including AI-related threat coverage, additional intelligence feeds and modules, and broader program development.
AI-related threats are the leading priority for expanded coverage and new investment. Practitioners pointed to deepfake detection, AI-accelerated vulnerability exploitation, and emerging AI-enabled threat vectors as areas where their intelligence requirements are expanding.
Agentic AI adoption is underway, but teams are setting a high bar. Just 25% of organizations interviewed are using agentic AI in production today. Another 20% are piloting it, while 35% are planning adoption within the next 12 to 24 months. Rather than rushing toward autonomy, teams are evaluating where agents can improve workflows while maintaining intelligence quality, appropriate controls, and human oversight.
Taken together, the findings show where threat intelligence teams are feeling the greatest pressure, where they see opportunities to extend their capabilities with AI, and what will determine whether those tools earn a lasting place in the intelligence workflow. The sections that follow examine each of these findings in greater detail and what they mean for threat intelligence programs.
Operational Challenges Are Putting Pressure on Analyst Capacity
The rising AI threat landscape is increasing pressure on organizations to get more capacity from the people and systems they already have. Threat intelligence leaders therefore say the biggest barriers to program effectiveness are operational: too much noise, limited analyst bandwidth, and disconnected tools.
Alert noise and false positives emerged as the leading challenge affecting threat intelligence programs, cited by 65% of respondents. Analyst bandwidth followed at 55%, while half of respondents pointed to both the evolving threat landscape and integration gaps across their security tools.
The impact of these challenges becomes clearer at the workflow level. One healthcare practitioner described receiving alerts about email breaches that were seven or eight years old, with the same data resurfacing each time it was resold and requiring another investigation. Practitioners also described manual steps between intelligence feeds, SIEMs, SOAR platforms, ticketing systems, and response workflows.
Each unnecessary investigation or manual handoff consumes time that could otherwise go toward analysis. That becomes difficult to solve through hiring alone because threat intelligence expertise takes time to develop. As one healthcare threat intelligence leader explained:
“Good analysts take time to develop and train, and we can’t hire our way out of that problem.”
The research suggests an opportunity to look for capacity within the intelligence workflow itself. Reducing repetitive investigations, improving integration between systems, and helping analysts identify relevant intelligence faster can return more of their time to work that depends on context and judgment.
Threat Intelligence Investment Remains Resilient Heading Into 2027
The rise of AI-driven threats is driving increases in the intelligence budgets of many organizations. Among respondents who provided a budget outlook, 50% expect their threat intelligence budgets to increase over the next 12 months, while the remaining 40% expect budgets to stay essentially flat. None anticipate a decrease.
More than a third (35%) expect meaningful growth of at least 10%, suggesting that for many organizations, threat intelligence remains an area of active investment heading into 2027.
Where organizations are increasing investment is equally important. Respondents expecting meaningful growth described spending on AI defense capabilities, expanded threat intelligence feeds and modules, and broader program development. AI-related threat coverage also emerged across both flat and growing budgets as the most frequently cited area where teams want to expand coverage.
For teams heading into 2027, the findings suggest that the question is increasingly where to direct threat intelligence investment for the greatest impact. Organizations are evaluating how existing resources can address new intelligence requirements, where additional capabilities are needed, and which investments can demonstrate clear operational value.
AI-Related Threats Are Driving New Coverage Priorities
As organizations decide where to focus threat intelligence investment in the year ahead, AI is the clear priority. AI-related threats were the most frequently cited area where organizations want to expand intelligence coverage, including among teams with relatively flat budgets. Practitioners specifically pointed to deepfake detection, AI-accelerated vulnerability exploitation, and emerging AI-enabled threat vectors.
These priorities reflect activity already visible across the threat landscape. During the first half of 2026, Flashpoint tracked more than 22 million threat actor posts discussing, sharing, or advertising AI toolkits for criminal deployment. Flashpoint analysts observed AI being used across phishing, malware development, evasion, and vulnerability exploitation.
For threat intelligence teams, expanding AI coverage requires more specificity than treating “AI threats” as a single monitoring category. Deepfakes may matter because of executive impersonation or fraud. AI-accelerated exploitation may change vulnerability monitoring and prioritization. New attack tooling may affect the adversaries or TTPs a team already tracks.
The challenge extends beyond visibility into these threats. Organizations also need the expertise to understand how AI is changing adversary behavior and attack chains. That expertise is still developing. As one practitioner put it, “everybody’s learning it at the same time.”
Connecting those developments to existing PIRs and business risks gives analysts clearer collection priorities and helps teams determine what new sources, expertise, and monitoring they actually need.
Those requirements are also expanding at a time when analyst bandwidth is already constrained, creating a second question for threat intelligence leaders: where can AI support the intelligence workflow itself?
Agentic AI Adoption Is Underway
Nearly half of the organizations interviewed are already using or piloting agentic AI in threat intelligence workflows, while another 35% are planning adoption within the next 12 to 24 months. That makes agentic AI an important part of 2027 planning, but despite the attention surrounding it, threat intelligence teams are taking a measured approach. They are looking for clear business value, evidence that AI can maintain the quality of their intelligence workflows, and appropriate human oversight as agents take on more consequential tasks.
The work being handed to agents already varies considerably, from information retrieval and alert prioritization to more active tasks such as blocking IP addresses, updating blacklists, and monitoring suspicious traffic. Organizations in the pilot stage also described use cases spanning detection, validation, context generation, SIEM alert analysis, TIP querying, MITRE ATT&CK mapping, and reversible response actions.
As agents move from retrieving and analyzing information to taking actions that can directly affect security operations, accuracy and trust become increasingly important. One respondent captured the concern succinctly:
“An agent that’s confidently wrong is worse than one that’s slow.”
That concern is reflected across the research. Practitioners raised questions around data leakage, auditability, regulatory requirements, cost, and the level of control agents should have over security workflows. One retail respondent, for example, would only consider read-only AI assistants because of the risks associated with granting agents write permissions.
For teams evaluating agentic AI, that makes the workflow itself an important part of the decision. Tasks with reviewable outputs, reversible actions, and clear success criteria provide a practical starting point. As autonomy increases, teams need equally clear controls around what an agent can access, what it can change, where human approval is required, and how its actions are audited.
What the Findings Mean for Threat Intelligence Programs
As threat intelligence leaders plan for 2027, the research points to a clear set of priorities. Teams have more to monitor, limited analyst capacity, and growing interest in AI as a way to scale the work their programs already perform.
The findings also show that practitioners are selective about where they see that value. PIR coverage monitoring and intelligence briefings can extend coverage and reduce recurring work while keeping analysts involved in the intelligence process. As agents take on more consequential actions, questions around accuracy, permissions, auditability, and human oversight become more important.
For teams setting priorities for the year ahead, that creates a practical path forward: understand where analyst capacity is being consumed, connect new intelligence requirements to the risks that matter to the organization, identify workflows where automation can meaningfully extend the team, and establish clear measures of success before deployment.
The challenge for 2027 will be turning expanding intelligence requirements into an operating model that can scale for threat intelligence programs. That means making better use of existing data, systems, and analyst expertise while being deliberate about where agentic AI can extend those capabilities and where human judgment remains essential.
Methodology
Flashpoint commissioned independent qualitative research among a select group of more than 20 threat intelligence budget owners and influencers at large North American enterprises across financial services and insurance, healthcare and biotech, retail, and information technology and telecommunications during the early fall of 2026.
Disclaimer: This blog is based on publicly available information, including a police report and posts shared on X, as of October 13, 2026. Cyble has not independently verified these claims. The allegations remain unproven, and naming any organization does not imply its involvement. This content is for informational purposes only and is not legal or financial advice.
A crypto security event that promised to teach attendees how to avoid scams is now the subject of scam allegations. The gathering, branded “Don’t Get Played,” was held as a side event during TOKEN2049 week in Singapore and co-hosted by groups operating under the names “Apex Accelerator” and “Stone Venture.”
According to a police report filed by one attendee with the Singapore Police Force, the organizers allegedly pressured guests to install software that would have handed the organizers remote control of their computers.
The allegation first gained traction on X, where several other users claimed they had also been approached by the same group.
What the “Don’t Get Played” Police Report States
The document circulating online is page two of a six-page Singapore Police Force report (form NP299), bearing reference number E/20261011/7004. In it, the complainant lists the group’s website as token.apexaccs.org and notes that the event’s Telegram group had no public URL; prospective attendees could only join through the website.
Report filed to the Singapore Police (Source: SolanaFloor on X)
The report is titled “Suspected cyber scam targeting TOKEN2049 attendees (‘Don’t Get Played’ event).” Its summary reads:
“A group using the names ‘Apex Accelerator’, ‘Stone Venture’ and ‘Don’t Get Played’ promoted a crypto security event for TOKEN2049 week (Sun 11 Oct 2026, 6pm to 10pm, The Singapore EDITION). They pressured attendees to install software that would give them remote control of their computers. I did not install their software and have no financial loss.”
Two details in that statement matter. First, the person who filed the report says they did not install anything. Second, they report no financial loss. The filing therefore documents an alleged attempt rather than a confirmed compromise.
How the TOKEN2049 Side Event Was Pitched
On paper, “Don’t Get Played” looked like exactly the kind of session a careful attendee would seek out. It was marketed as a security-focused gathering designed to help people protect themselves from token scams.
“Don’t Get Played” registration page (Source: Defraud on X)
The event was scheduled for The Singapore EDITION hotel in early October 2026. Entry was free, though guests had to register beforehand, and attendance was capped at 200 people, as detailed by Crypto Briefing.
The agenda featured a live “wallet clinic” where attendees could have their holdings checked with “Apex Audit” tools. These were promoted as scanners for token risk and honeypots, a term for tokens engineered so that holders can buy them but are never able to sell.
The promotional material also advertised a panel on how crypto scams have evolved, listing representatives from Spartan Group, Bybit’s security team, and the Singapore Police Force Cyber Command among the speakers.
The final hook was a giveaway. Every confirmed guest was promised a free year of Sophos MDR endpoint protection, bundled with up to $1 million in breach coverage. Research into the event suggests this offer was a major driver of interest.
There is nothing in the available material indicating that Spartan Group, Bybit, Sophos, or the Singapore Police Force Cyber Command played any part in the alleged conduct. Their names appeared in the event promotion, and that is the full extent of what the sources establish.
The Allegation and the Gaps in the Record
The central claim is simple: organizers of “Don’t Get Played” allegedly pushed attendees to install software that would give a third-party remote access to their machines. At a crypto event, where many guests carry laptops connected to wallets and exchange accounts, that level of access could be enough to empty funds.
Several important facts remain unclear. The source material does not name the software attendees were allegedly asked to install. It does not state whether anyone lost money, and it does not say how many people may have been targeted.
As of October 12, 2026, no mainstream coverage of a police report involving the organizers, or of complaints from victims, could be located. The Singapore Police Force has not publicly confirmed the filing. Apex Accelerator and Stone Venture have not been charged with any offense based on the information available, and their account of events has not yet entered the public record.
How the Crypto Community Reacted to “Don’t Get Played”?
After SolanaFloor shared the police report on X, the replies split between people claiming firsthand contact, skeptics, and users offering security advice. The account 0xKYM Registry (@KYMRegistrySG) said it filed the report and shared what it described as a scan of the installation’s contents.
Several others, including FamCrypt (@Famous0x3), NomadFury (@NomadFury_), and Sabya | YeNo (@SabyaYeNo), said the group had approached or pressured them to install software or buy a subscription. Alex (@alwye) claimed Apex Accelerator had used similar tactics in Twitter DMs.
Reactions on Don’t Get Played (Source: X)
Not everyone was convinced. Sprunky (@sprunky_eth) argued that “page 2 of a report is not a finding,” noting the complainant lost nothing, SPF had not confirmed the filing, and no charges exist. Others questioned how anyone could be pressured in Singapore or who vetted the project for the TOKEN2049 lineup.
Security-minded users focused on the risk. StakeCraft (@stakecraft) called remote laptop access at a crypto event “a wallet drain waiting to happen,” and Jey (@TheWarKettle) advised anyone who installed the software to treat the device as compromised, move funds from a clean device, and rotate every password and key.
Others pointed to fake Luma after-party links and similar incidents at other conferences, and one user floated an unsupported DPRK link. Many replies also mocked the irony of a security event called “Don’t Get Played” allegedly becoming the play.
Conclusion
The “Don’t Get Played” allegations rest on a single attendee’s police report and a growing set of claims on X, none of which have been confirmed by authorities. Several questions remain open.
Will Singapore authorities confirm that a report was filed? Will Apex Accelerator or Stone Venture respond publicly? And will Spartan Group or the Singapore Police Force Cyber Command clarify whether they had any connection to the event? Until those answers arrive, the safest assumption for attendees is the one the event’s own name suggested: any request to install software deserves suspicion.
Disclaimer: This blog is based on publicly available information, including a police report and posts shared on X, as of October 13, 2026. Cyble has not independently verified these claims. The allegations remain unproven, and naming any organization does not imply its involvement. This content is for informational purposes only and is not legal or financial advice.
A crypto security event that promised to teach attendees how to avoid scams is now the subject of scam allegations. The gathering, branded “Don’t Get Played,” was held as a side event during TOKEN2049 week in Singapore and co-hosted by groups operating under the names “Apex Accelerator” and “Stone Venture.”
According to a police report filed by one attendee with the Singapore Police Force, the organizers allegedly pressured guests to install software that would have handed the organizers remote control of their computers.
The allegation first gained traction on X, where several other users claimed they had also been approached by the same group.
What the “Don’t Get Played” Police Report States
The document circulating online is page two of a six-page Singapore Police Force report (form NP299), bearing reference number E/20261011/7004. In it, the complainant lists the group’s website as token.apexaccs.org and notes that the event’s Telegram group had no public URL; prospective attendees could only join through the website.
Report filed to the Singapore Police (Source: SolanaFloor on X)
The report is titled “Suspected cyber scam targeting TOKEN2049 attendees (‘Don’t Get Played’ event).” Its summary reads:
“A group using the names ‘Apex Accelerator’, ‘Stone Venture’ and ‘Don’t Get Played’ promoted a crypto security event for TOKEN2049 week (Sun 11 Oct 2026, 6pm to 10pm, The Singapore EDITION). They pressured attendees to install software that would give them remote control of their computers. I did not install their software and have no financial loss.”
Two details in that statement matter. First, the person who filed the report says they did not install anything. Second, they report no financial loss. The filing therefore documents an alleged attempt rather than a confirmed compromise.
How the TOKEN2049 Side Event Was Pitched
On paper, “Don’t Get Played” looked like exactly the kind of session a careful attendee would seek out. It was marketed as a security-focused gathering designed to help people protect themselves from token scams.
“Don’t Get Played” registration page (Source: Defraud on X)
The event was scheduled for The Singapore EDITION hotel in early October 2026. Entry was free, though guests had to register beforehand, and attendance was capped at 200 people, as detailed by Crypto Briefing.
The agenda featured a live “wallet clinic” where attendees could have their holdings checked with “Apex Audit” tools. These were promoted as scanners for token risk and honeypots, a term for tokens engineered so that holders can buy them but are never able to sell.
The promotional material also advertised a panel on how crypto scams have evolved, listing representatives from Spartan Group, Bybit’s security team, and the Singapore Police Force Cyber Command among the speakers.
The final hook was a giveaway. Every confirmed guest was promised a free year of Sophos MDR endpoint protection, bundled with up to $1 million in breach coverage. Research into the event suggests this offer was a major driver of interest.
There is nothing in the available material indicating that Spartan Group, Bybit, Sophos, or the Singapore Police Force Cyber Command played any part in the alleged conduct. Their names appeared in the event promotion, and that is the full extent of what the sources establish.
The Allegation and the Gaps in the Record
The central claim is simple: organizers of “Don’t Get Played” allegedly pushed attendees to install software that would give a third-party remote access to their machines. At a crypto event, where many guests carry laptops connected to wallets and exchange accounts, that level of access could be enough to empty funds.
Several important facts remain unclear. The source material does not name the software attendees were allegedly asked to install. It does not state whether anyone lost money, and it does not say how many people may have been targeted.
As of October 12, 2026, no mainstream coverage of a police report involving the organizers, or of complaints from victims, could be located. The Singapore Police Force has not publicly confirmed the filing. Apex Accelerator and Stone Venture have not been charged with any offense based on the information available, and their account of events has not yet entered the public record.
How the Crypto Community Reacted to “Don’t Get Played”?
After SolanaFloor shared the police report on X, the replies split between people claiming firsthand contact, skeptics, and users offering security advice. The account 0xKYM Registry (@KYMRegistrySG) said it filed the report and shared what it described as a scan of the installation’s contents.
Several others, including FamCrypt (@Famous0x3), NomadFury (@NomadFury_), and Sabya | YeNo (@SabyaYeNo), said the group had approached or pressured them to install software or buy a subscription. Alex (@alwye) claimed Apex Accelerator had used similar tactics in Twitter DMs.
Reactions on Don’t Get Played (Source: X)
Not everyone was convinced. Sprunky (@sprunky_eth) argued that “page 2 of a report is not a finding,” noting the complainant lost nothing, SPF had not confirmed the filing, and no charges exist. Others questioned how anyone could be pressured in Singapore or who vetted the project for the TOKEN2049 lineup.
Security-minded users focused on the risk. StakeCraft (@stakecraft) called remote laptop access at a crypto event “a wallet drain waiting to happen,” and Jey (@TheWarKettle) advised anyone who installed the software to treat the device as compromised, move funds from a clean device, and rotate every password and key.
Others pointed to fake Luma after-party links and similar incidents at other conferences, and one user floated an unsupported DPRK link. Many replies also mocked the irony of a security event called “Don’t Get Played” allegedly becoming the play.
Conclusion
The “Don’t Get Played” allegations rest on a single attendee’s police report and a growing set of claims on X, none of which have been confirmed by authorities. Several questions remain open.
Will Singapore authorities confirm that a report was filed? Will Apex Accelerator or Stone Venture respond publicly? And will Spartan Group or the Singapore Police Force Cyber Command clarify whether they had any connection to the event? Until those answers arrive, the safest assumption for attendees is the one the event’s own name suggested: any request to install software deserves suspicion.
Disclaimer: This blog is based on publicly available information, including a police report and posts shared on X, as of October 13, 2026. Cyble has not independently verified these claims. The allegations remain unproven, and naming any organization does not imply its involvement. This content is for informational purposes only and is not legal or financial advice.
I remember the name of that AI doco now – The AI Doc: Or How I Became an Apocaloptimist. I was watching it on the long-haul flight home the other day, and what I found particularly engrossing was the polar-opposite opinions from a bunch of people: “it’s gonna kill us all” versus “it’s gonna make us all rich”, and so on. But to some extent, I can understand the gap between opinions when we’re all just speculating about the future. I have much less understanding for why people infatuate with hyping AI as a data breach monster when the evidence to date is quite the opposite. In fact, I’ve enjoyed sharing example after example of recent breaches perpetrated by kids with a telephone (vishing), while pointing out I haven’t seen a single one orchestrated by AI.
Speaking of AI, a big thanks to this week’s sponsor who’s doing gtreat things in the agent observability space, Origin. The machines may not be dumping data that lands in HIBP (yet), but they do go off-script and Origin will help trace back precisely what happened when it all goes wrong.
Toho Holdings a annoncé qu’une cyberattaque par ransomware a compromis la base de données de sa filiale Entouch. L’incident a été découvert le 13 octobre 2026. Les données compromises incluent les noms et affiliations des professionnels de la santé, les coordonnées, les noms de sociétés pharmaceutiques et les informations relatives aux rendez-vous. Bien que l’étendue exacte des données volées soit toujours en cours d’enquête, l’entreprise affirme que les autres systèmes du groupe n’ont pas été affectés.
La Clinique vétérinaire Voltaire de Dijon est confrontée à une cyberattaque depuis le 13 octobre 2026, entraînant l’indisponibilité de son site web et de la prise de rendez-vous en ligne. L’établissement opère avec des services numériques dégradés et redirige ses clients vers le secrétariat téléphonique. À ce stade, aucune fuite de données, rançongiciel ou revendication d’un groupe cybercriminel n’a été confirmée, et l’origine exacte de l’attaque reste inconnue.
Le Colegio Oficial de Médicos de Tenerife (COMTF) a été victime d’une cyberattaque le 13 octobre 2026. L’entité a déconnecté son réseau pour stopper l’accès non autorisé et analyser l’incident. Bien qu’une note reçue par les équipes suggère que des données ont été chiffrées et volées, le COMTF n’a pas encore détecté de fuite de données. L’entité a signalé l’incident aux autorités espagnoles compétentes.
Victim: Colegio Oficial de Médicos de Tenerife (COMTF)
Table Of Contents
