Executive Summary

Cyble Research and Intelligence Labs (CRIL) observed large-scale, systematic exposure of ChatGPT API keys across the public internet. Over 5,000 publicly accessible GitHub repositories and approximately 3,000 live production websites were found leaking API keys through hardcoded source code and client-side JavaScript.

GitHub has emerged as a key discovery surface, with API keys frequently committed directly into source files or stored in configuration and .env files. The risk is further amplified by public-facing websites that embed active keys in front-end assets, leading to persistent, long-term exposure in production environments.

CRIL’s investigation further revealed that several exposed API keys were referenced in discussions mentioning the Cyble Vision platform. The exposure of these credentials significantly lowers the barrier for threat actors, enabling faster downstream abuse and facilitating broader criminal exploitation.

These findings underscore a critical security gap in the AI adoption lifecycle. AI credentials must be treated as production secrets and protected with the same rigor as cloud and identity credentials to prevent ongoing financial, operational, and reputational risk.

Key Takeaways

• GitHub is a primary vector for the discovery of exposed ChatGPT API keys.
• Public websites and repositories form a continuous exposure loop for AI secrets.
• Attackers can use automated scanners and GitHub search operators to harvest keys at scale.
• Exposed AI keys are monetized through inference abuse, resale, and downstream criminal activity.
• Most organizations lack monitoring for AI credential misuse.

AI API keys are production secrets, not developer conveniences. Treating them casually is creating a new class of silent, high-impact breaches.

Richard Sands, CISO, Cyble

Overview, Analysis, and Insights

“The AI Era Has Arrived — Security Discipline Has Not”

We are firmly in the AI era. From chatbots and copilots to recommendation engines and automated workflows, artificial intelligence is no longer experimental. It is production-grade infrastructure with end-to-end workflows and pipelines. Modern websites and applications increasingly rely on large language models (LLMs), token-based APIs, and real-time inference to deliver capabilities that were unthinkable just a few years ago.

This rapid adoption has also given rise to a development culture often referred to as “vibe coding.” Developers, startups, and even enterprises are prioritizing speed, experimentation, and feature delivery over foundational security practices. While this approach accelerates innovation, it also introduces systemic weaknesses that attackers are quick to exploit.

One of the most prevalent and most dangerous of these weaknesses is the widespread exposure of hardcoded AI API keys across both source code repositories and production websites.

A rapidly expanding digital risk surface is likely to increase the likelihood of compromise; a preventive strategy is the best approach to avoid it. Cyble Vision provides users with insight into exposures across the surface, deep, and dark web, generating real-time alerts for them to view and take action.

SOC teams will be able to leverage this data to remediate compromised credentials and their associated endpoints. With Threat Actors potentially weaponizing these credentials to carry out malicious activities (which will then be attributed to the affected user(s)), proactive intelligence is paramount to keeping one’s digital risk surface secure.

“Tokens are the new passwords — they are being mishandled.”

AI platforms use token-based authentication. API keys act as high-value secrets that grant access to inference capabilities, billing accounts, usage quotas, and, in some cases, sensitive prompts or application behavior. From a security standpoint, these keys are equivalent to privileged credentials.

Despite this, ChatGPT API keys are frequently embedded directly in JavaScript files, front-end frameworks, static assets, and configuration files accessible to end users. In many cases, keys are visible through browser developer tools, minified bundles, or publicly indexed source code. An example of the keys hardcoded in popular reputable websites is shown below (see Figure 1)

This reflects a fundamental misunderstanding: API keys are being treated as configuration values rather than as secrets. In the AI era, that assumption is dangerously outdated. In some cases, this happens unintentionally, while in others, it’s a deliberate trade-off that prioritizes speed and convenience over security.

When API keys are exposed publicly, attackers do not need to compromise infrastructure or exploit vulnerabilities. They simply collect and reuse what is already available.

CRIL has identified multiple publicly accessible websites and GitHub Repositories containing hardcoded ChatGPT API keys embedded directly within client-side code. These keys are exposed to any user who inspects network requests or application source files.

A commonly observed pattern resembles the following:

```javascript
const OPENAI_API_KEY = "sk-proj-XXXXXXXXXXXXXXXXXXXXXXXX";
```

```javascript
const OPENAI_API_KEY = "sk-svcacct-XXXXXXXXXXXXXXXXXXXXXXXX";
```

The prefix “sk-proj-“ typically represents a project-scoped secret key associated with a specific project environment, inheriting its usage limits and billing configuration. The “sk-svcacct-“ prefix generally denotes a service account–based key intended for automated backend services or system integrations.

Regardless of type, both keys function as privileged authentication tokens that enable direct access to AI inference services and billing resources. When embedded in client-side code, they are fully exposed and can be immediately harvested and misused by threat actors.

GitHub as a High-Fidelity Source of AI Secrets

Public GitHub repositories have emerged as one of the most reliable discovery surfaces for exposed ChatGPT API keys. During development, testing, and rapid prototyping, developers frequently hardcode OpenAI credentials into source code, configuration files, or .env files—often with the intent to remove or rotate them later. In practice, these secrets persist in commit history, forks, and archived repositories.

CRIL analysis identified over 5,000 GitHub repositories containing hardcoded OpenAI API keys. These exposures span JavaScript applications, Python scripts, CI/CD pipelines, and infrastructure configuration files. In many cases, the repositories were actively maintained or recently updated, increasing the likelihood that the exposed keys were still valid at the time of discovery.

Notably, the majority of exposed keys were configured to access widely used ChatGPT models, making them particularly attractive for abuse. These models are commonly integrated into production workflows, increasing both their exposure rate and their value to threat actors.

Once committed to GitHub, API keys can be rapidly indexed by automated scanners that monitor new commits and repository updates in near real time. This significantly reduces the window between exposure and exploitation, often to hours or even minutes.

Public Websites: Persistent Exposure in Production Environments

Beyond source code repositories, CRIL observed widespread exposure of ChatGPT API keys directly within production websites. In these cases, API keys were embedded in client-side JavaScript bundles, static assets, or front-end framework files, making them accessible to any user inspecting the application.

CRIL identified approximately 3,000 public-facing websites exposing ChatGPT API keys in this manner. Unlike repository leaks, which may be removed or made private, website-based exposures often persist for extended periods, continuously leaking secrets to both human users and automated scrapers.

These implementations frequently invoke ChatGPT APIs directly from the browser, bypassing backend mediation entirely. As a result, exposed keys are not only visible but actively used in real time, making them trivial to harvest and immediately abuse.

As with GitHub exposures, the most referenced models were highly prevalent ChatGPT variants used for general-purpose inference, indicating that these keys were tied to live, customer-facing functionality rather than isolated testing environments. These models strike a balance between capability and cost, making them ideal for high-volume abuse such as phishing content generation, scam scripts, and automation at scale.

Hard-coding LLM API keys risks turning innovation into liability, as attackers can drain AI budgets, poison workflows, and access sensitive prompts and outputs. Enterprises must manage secrets and monitor exposure across code and pipelines to prevent misconfigurations from becoming financial, privacy, or compliance issues.  

Kautubh Medhe, CPO, Cyble

From Exposure to Exploitation: How Attackers Monetize AI Keys

Threat actors continuously monitor public websites, GitHub repositories, forks, gists, and exposed JavaScript bundles to identify high-value secrets, including OpenAI API keys. Once discovered, these keys are rapidly validated through automated scripts and immediately operationalized for malicious use.

Compromised keys are typically abused to:

• Execute high-volume inference workloads
• Generate phishing emails, scam scripts, and social engineering content
• Support malware development and lure creation
• Circumvent usage quotas and service restrictions
• Drain victim billing accounts and exhaust API credits

In certain cases, CRIL, using Cyble Vision, also identified several of these keys that originated from exposures and were subsequently leaked, as noted in our spotlight mentions. (see Figure 2 and Figure 3)

Unlike traditional conventions, AI API activity is often not integrated into centralized logging, SIEM monitoring, or anomaly detection frameworks. As a result, malicious usage can persist undetected until organizations encounter billing spikes, quota exhaustion, degraded service performance, or operational disruptions.

Conclusion

The exposure of ChatGPT API keys across thousands of websites and tens of thousands of GitHub repositories highlights a systemic security blind spot in the AI adoption lifecycle. These credentials are actively harvested, rapidly abused, and difficult to trace once compromised.

As AI becomes embedded in business-critical workflows, organizations must abandon the perception that AI integrations are experimental or low risk. AI credentials are production secrets and must be protected accordingly.

Failure to secure them will continue to expose organizations to financial loss, operational disruption, and reputational damage.

SOC teams should take the initiative to proactively monitor for exposed endpoints using monitoring tools such as Cyble Vision, which provides users with real-time alerts and visibility into compromised endpoints.

This, in turn, allows them to take corrective action to identify which endpoints and credentials were compromised and secure any compromised endpoints as soon as possible.

Our Recommendations

Eliminate Secrets from Client-Side Code

AI API keys must never be embedded in JavaScript or front-end assets. All AI interactions should be routed through secure backend services.

Enforce GitHub Hygiene and Secret Scanning

• Prevent commits containing secrets through pre-commit hooks and CI/CD enforcement
• Continuously scan repositories, forks, and gists for leaked keys
• Assume exposure once a key appears in a public repository and rotate immediately
• Maintain a complete inventory of all repositories associated with the organization, including shadow IT projects, archived repositories, personal developer forks, test environments, and proof-of-concept code
• Enable automated secret scanning and push protection at the organization level

Apply Least Privilege and Usage Controls

• Restrict API keys by project scope and environment (separate dev, test, prod)
• Apply IP allowlisting where possible
• Enforce usage quotas and hard spending limits
• Rotate keys frequently and revoke any exposed credentials immediately
• Avoid sharing keys across teams or applications

Implement Secure Key Management Practices

• Store API keys in secure secret management systems
• Avoid storing keys in plaintext configuration files
• Use environment variables securely and restrict access permissions
• Do not log API keys in application logs, error messages, or debugging outputs
• Ensure keys are excluded from backups, crash dumps, and telemetry exports

Monitor AI Usage Like Cloud Infrastructure

Establish baselines for normal AI API usage and alert on anomalies such as spikes, unusual geographies, or unexpected model usage.

The post When AI Secrets Go Public: The Rising Risk of Exposed ChatGPT API Keys appeared first on Cyble.

Cyble – ​Read More

In enterprise SaaS, unclear security decisions carry real cost. False positives disrupt customers, while missed threats expose the business. 

A Fortune 500 cloud provider addressed this risk by embedding ANY.RUN into SOC investigations, giving analysts the behavioral evidence needed to reduce escalations, improve triage confidence, and make proportionate response decisions at scale. 

Company Context and Security Scope 

The organization is a Fortune 500 enterprise SaaS provider headquartered in North America, supporting enterprise customers across multiple regions and regulatory environments, with a workforce in the tens of thousands. 

• Industry: Enterprise cloud software and SaaS, where customers expect strong security, high availability, and strict data protection. 

• Environment: Not endpoint-centric; security coverage spans a large multi-tenant SaaS platform, internal corporate environments, and a broad ecosystem of integrations, partners, and third-party access, each introducing distinct threat characteristics 

• Security organization: A mature, multi-tier structure with dedicated SOC, incident response, threat hunting, and security engineering functions operating across regions. 

Core Challenges: Volume, Ambiguity, and Escalation Friction 

When we spoke with the security engineer, we expected the usual story, missing visibility, gaps in tooling, not enough telemetry. But the discussion quickly showed the real problem was somewhere else. 

The issue wasn’t seeing what was happening. The team already had plenty of signals coming in every day: authentication events, API activity, admin actions, and a constant flow of partner and integration traffic. The issue was that most of it was legitimate, which made the dangerous moments harder to prove early. 

On the surface, nothing looked wrong. But unclear alerts were consuming more and more of our time. We were drowning in uncertainty. For a company serving global customers, that level of ambiguity wasn’t acceptable.

During our discussion, it became clear that the pressure point was volume + ambiguity. 

Defining the Right Direction for Triage and Response 

Once we clarified the challenges, the priority became clear: make early triage decisions more certain, without increasing operational risk in a multi-tenant SaaS environment. 

The team focused on: 

• Reducing uncertainty during triage 

• Improving confidence in early-stage decisions 

• Separating isolated external issues from broader attack patterns and benign platform behavior 

• Supporting proportional response, not aggressive automation 

Solution: Behavior-Based Evidence in Early Investigations 

To reach the clarity they were aiming for, the team needed a way to introduce reliable behavioral evidence into early-stage investigations, without disrupting existing SOC workflows or forcing premature automation. 

ANY.RUN closed this gap by giving analysts a safe way to observe the real behavior behind a suspicious file or link, replacing guesswork based on reputation, static indicators, or incomplete external signals with direct, controlled evidence. 

The biggest change was moving from ‘this looks suspicious’ to ‘this is what it actually does.’ That kind of controlled, repeatable proof is what makes confident decisions possible, especially when threats originate outside your perimeter.

Rather than accelerating response blindly, this approach helped the SOC make earlier, calmer, and more proportional decisions within the same operational model. 

Process Impact: Phishing and External Threat Triage 

Phishing was one of the clearest use cases for the new approach. Many alerts weren’t obviously malicious, but they couldn’t be ignored either, especially when they involved links, attachments, or multi-step redirected flows coming from outside the company’s perimeter. 

With behavior-based validation provided by ANY.RUN sandbox, Tier-1 no longer had to rely on “looks suspicious” signals to make the first call. Analysts could safely interact with artifacts, observe what actually happened, and capture the full chain; redirects, credential capture, payload delivery, or follow-on behavior. 

In practice, this made a visible difference: in roughly 90% of cases, analysts were able to surface the full attack chain within about 60 seconds, turning unclear alerts into evidence-backed decisions early in the workflow. 

A big part of the improvement came also from automated interactivity. Instead of spending time manually clicking through steps that attackers use to slow investigations, CAPTCHAs, multi-hop redirects, or links hidden behind QR codes, analysts could let the sandbox mimic user behavior and capture the full sequence safely. That meant faster verdicts, less friction, and more confidence at Tier-1 without relying on guesswork. 

These shifts improved day-to-day operations: 

• More cases closed confidently at Tier-1 when behavior was clearly benign or clearly malicious 

• Escalations became more intentional, with evidence attached instead of uncertainty 

• Tier-2 spent less time on basic confirmation and more time on true incident work 

• Triage became more consistent across regions and shifts 

Expanding Context with Threat Intelligence 

While behavioral evidence clarified what a threat does, the team also needed faster answers to what it means in the broader landscape. 

To close that gap, they decided to extend their workflow with ANY.RUN’s Threat Intelligence capabilities, adding immediate context to artifacts discovered during triage. 

Threat Intelligence Lookup helped analysts quickly determine: 

• Whether infrastructure was linked to known campaigns 

• If observed behavior matched publicly reported threats 

• How relevant an external signal was to their specific environment 

We notice how our threat hunting is getting more grounded and faster to validate. When a hunt intersects with external artifacts, phishing payloads, suspicious links, or malware samples, we can confirm the behavior and enrich the hypothesis quickly, instead of spending time on patterns that stay theoretical.

At the same time, Threat Intelligence Feeds delivered behavior-verified indicators that could be correlated inside existing detection and monitoring pipelines, strengthening visibility without adding noise. 

Together, these solutions allowed the SOC to move from isolated alert handling toward context-aware investigation, where decisions were supported not only by observed behavior, but also by real-world threat activity. 

We started using TI Feeds as an enrichment layer on top of our existing threat intelligence stack. What stood out for us is that the indicators are tied to sandbox-verified behavior, so we’re not reacting to blind IOCs, we’re adding context we can actually trust. 

As a result, analysts spent less time searching for background information and more time responding with clarity and confidence. 

Measurable Improvements Across SOC Operations 

As the new workflow stabilized, the team began to see consistent improvements across investigation quality, escalation patterns, and overall SOC efficiency: 

What SOC Managers Reported After the Workflow Shift 

Beyond individual investigations, SOC managers began to notice improvements in how decisions were communicated, reviewed, and justified across the organization.  

With clearer behavioral evidence and immediate threat context, plus auto-generated investigation reports and built-in collaboration capabilities, updates to stakeholders became more straightforward, and post-incident analysis required far less backtracking. 

Cases were easier to standardize across regions and shifts because the same evidence, context, and artifacts were captured and shared in a consistent way. Escalations increasingly arrived with supporting proof rather than open questions, which reduced “back-and-forth” and helped keep response actions proportional to real risk. 

From a manager’s perspective, the biggest change was consistency. Decisions were easier to stand behind because the evidence and reporting were already there, and teams could collaborate on the same case without losing context.

Importantly, this progress didn’t require changing the overall security strategy. Instead, it reduced friction inside an already mature SOC model, helping ensure that when action was taken, it was taken for the right reasons. 

Conclusion: From Uncertainty to Confident, Proportional Response 

By embedding ANY.RUN into daily SOC operations, this Fortune 500 SaaS provider reduced ambiguity in early triage and strengthened decision-making across the entire workflow. 

We just stopped losing time to uncertainty. Now we can confirm what’s happening faster and escalate only when it actually makes sense.

With behavioral evidence, immediate threat context, and consistent reporting built into investigations, the SOC became more predictable, more efficient, and better aligned with the need for proportional response at enterprise scale. 

About ANY.RUN 

ANY.RUN is part of modern SOC workflows, integrating into existing processes and strengthening the full operational cycle across Tier 1, Tier 2, and Tier 3. 

It supports every stage of investigation; from exposing real behavior through safe detonation, to enriching findings with broader threat context, to delivering continuous intelligence that helps teams move faster and make confident decisions. 

Today, more than 600,000 security professionals and 15,000 organizations rely on ANY.RUN to accelerate triage, reduce unnecessary escalations, and stay ahead of evolving phishing and malware campaigns. 

Check how ANY.RUN can improve investigation clarity and speed in your SOC 

Frequently Asked Questions

The post Fortune 500 Tech Enterprise Speeds up Triage and Response with ANY.RUN’s Solutions appeared first on ANY.RUN’s Cybersecurity Blog.

ANY.RUN’s Cybersecurity Blog – ​Read More

RESEARCH DISCLAIMER:  
This analysis examines the most recent and actively maintained repositories of OTP & SMS bombing tools to understand current attack capabilities and targeting patterns. All statistics represent observed patterns within our research sample and should be interpreted as indicative trends rather than definitive totals of the entire OTP bombing ecosystem. The threat landscape is continuously evolving with new tools and repositories emerging regularly. 

Executive Summary

Cyble Research and Intelligence Labs (CRIL) identified sustained development activity surrounding SMS, OTP, and voice-bombing campaigns, with evidence of technical evolution observed through late 2025 and continuing into 2026. Analysis of multiple development artifacts reveals progressive expansion in regional targeting, automation sophistication, and attack vector diversity.

Recent activity observed through September and October 2025, combined with new application releases in January 2026, indicates ongoing campaign persistence. The campaigns demonstrate technical maturation from basic terminal implementations to cross-platform desktop applications with automated distribution mechanisms and advanced evasion capabilities.

CRIL’s investigation identified coordinated abuse of authentication endpoints across the telecommunications, financial services, e-commerce, ride-hailing, and government sectors, collectively targeting infrastructure in West Asia, South Asia, and Eastern Europe.

Key Takeaways

• Persistent Evolution: Repository modifications observed through late 2025, with new regional variants released in January 2026
• Cross-Platform Advancement: Transition from terminal tools to Electron-based desktop applications with GUI and auto-update mechanisms
• Multi-Vector Capabilities: Combined SMS, OTP, voice call, and email bombing, enabling sustained harassment campaigns
• Performance Optimization: Implementation in Go, claiming significant speed advantages with FastHTTP library integration
• Advanced Evasion: Proxy rotation, User-Agent randomization, request timing variation, and concurrent execution capabilities (75% SSL bypass prevalence)
• Broad Infrastructure Exposure: ~843 authentication endpoints across ~20 repositories spanning multiple industry verticals
• Low Detection Rates: Multi-stage droppers and obfuscation techniques evade antivirus detection at the time of analysis

Discovery and Attribution

What began in the early 2020s as isolated pranks among tech-savvy individuals has evolved into a sophisticated ecosystem of automated harassment tools. SMS bombing – the practice of overwhelming a phone number with a barrage of automated text messages – initially emerged as rudimentary Python scripts shared on coding forums.

These early implementations were crude, targeting only a handful of regional service providers and using manually collected API endpoints. Given the dramatic transformation of the digital threat landscape in recent years, driven by the proliferation of public code repositories, the commoditization of attack tools, and the increasing sophistication of threat actors.

Our investigation into this evolving threat began with routine monitoring of malicious code repositories and underground discussion forums. What we discovered was far more extensive: a well-organised, rapidly expanding ecosystem characterized by cross-platform tool development, international collaboration among threat actors, and an alarming trend toward commercialization.

Repository Analysis and Dataset Composition

Malicious actors have weaponised GitHub as a distribution platform for SMS and OTP-bombing tools, creating hundreds of malicious repositories since 2022. Our investigation analyzed around 20 of the most active and recently maintained repositories to characterize current attack capabilities.

Across these repositories, there are ~843 vulnerable, catalogued  API endpoints from legitimate organizations: e-commerce platforms, financial institutions, government services, and telecommunications providers.

Each endpoint lacks adequate rate limiting or CAPTCHA protection, enabling automated exploitation. Target lists span seven geographic regions, with concentrated focus on India, Iran, Turkey, Ukraine, and Eastern Europe.

Repository maintainers provide tools in seven programming languages and frameworks, from simple Python scripts to cross-platform GUI applications. This diversity enables attackers with minimal technical knowledge to execute harassment campaigns without understanding the underlying exploitation mechanics.

Attack Ecosystem: By The Numbers

Our analysis of active SMS bombing repositories gives us an insight into the true scale and sophistication of this threat landscape:

Regional Targeting Distribution

Iran-focused endpoints dominate the observed sample at 61.68% (~520 endpoints), followed by India at 16.96% (~143 endpoints). This concentration suggests coordinated development efforts targeting specific telecommunications infrastructure.

Web-Based SMS Bombing Services

Accessibility and Threat Escalation

In parallel with the open-source repository ecosystem, a thriving commercial sector of web-based SMS-bombing services exists.

These platforms represent a significant escalation in threat accessibility, removing all technical barriers to conducting attacks. Unlike repository-based tools that require users to download code, configure environments, and execute commands, these web services offer point-and-click interfaces accessible from any browser or mobile device.

Deceptive Marketing Practices

Our analysis identified numerous active web services operating openly via search-engine-indexed domains. These services employ sophisticated marketing strategies, positioning themselves as ‘prank tools’ or ‘SMS testing services’ while providing the exact functionality required for harassment campaigns.

Data Harvesting and Resale Operations

Although these websites present themselves as benign prank tools, they operate a predatory data-collection model in which users’ phone numbers are systematically harvested for secondary exploitation. These collected contact numbers are subsequently used for spam campaigns and scam operations, or monetized through resale as lead lists to third-party spammers and scammers. This creates a dual-threat model: users inadvertently expose both their targets and themselves to ongoing spam victimization, while platform operators profit from both service fees and the commodification of harvested contact data.

Technical Analysis

Attack Methodology

SMS bombing attacks follow a predictable workflow that exploits weaknesses in API design and implementation.

Phase 1: API Discovery

Attackers identify vulnerable OTP endpoints through multiple techniques:

• Manual Testing: Identifying login pages and registration forms that trigger SMS verification
• Automated Scanning: Using tools to probe common API paths like /api/send-otp, /verify/sms, /auth/send-code
• Source Code Analysis: Examining mobile applications and web applications for hardcoded API endpoints
• Shared Intelligence: Leveraging community-maintained lists of vulnerable endpoints on forums and GitHub

Industry Sector Targeting Patterns

Our analysis reveals systematic targeting across multiple industry verticals, with telecommunications and authentication services comprising nearly half of all observed endpoints.

Phase 2: Tool Configuration

Modern SMS bombing tools require minimal setup:

• Multi-threading: Simultaneous requests to multiple APIs
• Proxy Support: Rotation of IP addresses to evade rate limiting
• Randomization: Variable delays between requests to appear more legitimate
• Persistence: Automatic retry mechanisms and error handling
• Reporting: Real-time statistics on successful message deliveries

Attacker Technology Stack Evolution

A detailed analysis of the ~20 repositories reveals significant technical sophistication and platform diversification:

Phase 3: Attack Execution

Once configured, the tool initiates a flood of legitimate-looking API requests.

Attack Vector Prevalence Analysis

Our analysis reveals the distribution of attack methods across the ~843 observed endpoints:

Technical Sophistication: Evasion Techniques

Analysis of the ~20 repositories reveals widespread adoption of anti-detection measures designed to bypass common security controls.

Impact Assessment

Individual Users

For end users targeted by SMS bombing attacks, the consequences include:

Impact Type	Description
Device Overload	Hundreds or thousands of incoming messages degrade device performance.
Communication Disruption	Legitimate messages are buried under spam, potentially leading to missed important notifications.
Inbox Capacity	SMS storage limits reached, preventing the receipt of new messages.
Battery Drain	Constant notifications deplete the affected device’s battery.
MFA Fatigue	Overwhelming authentication requests create security blind spots.
Data Harvesting	Prank sites for SMS bombing likely sell or reuse data for fraud or scams.

Organizations

Businesses whose APIs are exploited face multiple challenges:

Impact Category	Impact Type	Details
Financial Impact	Cost per OTP SMS	$0.05 to $0.20 per message
	Attack cost (10,000 messages)	$500 to $2,000 per attack
	Unprotected endpoints	Monthly bills can escalate to significant high amounts.
Operational Impact	User access issues	Legitimate users are unable to receive verification codes
	Customer service	Overwhelmed with complaints
	SMS delivery	Delays affecting all customers
	Regulatory compliance	Potential violations if users cannot access accounts
Reputational Impact	Media coverage	Negative social media coverage
	Customer trust	Erosion of customer confidence
	Brand damage	Association with spam and poor security
	Competitive position	Potential loss of business to competitors

Mitigation Strategies: Evidence-Based Recommendations

Based on analysis of successful bypass techniques across ~20 repositories, the following mitigation strategies are prioritized by effectiveness against observed attack patterns. Implementation of these controls addresses the primary exploitation vectors identified in our research.

For Service Providers (API Owners)

CRITICAL Priority

1. Implement Comprehensive Rate Limiting
Rationale	67% of targeted endpoints lack basic rate controls
Implementation	Per-IP Limiting: Maximum 5 OTP requests per hour. Per-Phone Limiting: Maximum 3 OTP requests per 15 minutes. Per-Session Limiting: Maximum 10 total verification attempts
Evidence	Would have blocked 81% of observed attack patterns

2. Deploy Dynamic CAPTCHA
Rationale	33% of tools exploit hardcoded reCAPTCHA tokens
Implementation	Use reCAPTCHA v3 with dynamic scoring. Rotate site keys regularly. Implement challenge escalation for suspicious behaviour
Evidence	Static CAPTCHA is defeated in most of the repositories

3. SSL/TLS Verification Enforcement
Rationale	75% of tools disable certificate validation to bypass security controls
Implementation	Enable HSTS (HTTP Strict Transport Security) headers, implement certificate pinning for mobile applications. Monitor and alert on certificate validation errors
Evidence	The most common evasion technique observed across repositories

HIGH Priority

Control	Rationale	Implementation Guidance
4. User-Agent Validation	58.3% of tools randomize User-Agent headers to evade detection	Maintain a whitelist of legitimate clients. Cross-validate User-Agent with other headers Flag mismatched browser/OS combinations
5. Request Pattern Analysis	Automated tools exhibit consistent timing patterns, unlike human behavior	Maintain a whitelist of legitimate clients. Cross-validate User-Agent with other headers. Flag mismatched browser/OS combinations
6. Phone Number Validation	Prevents abuse of number generation algorithms and invalid targets	Monitor for sub-100-ms request interval. Detect sequential API endpoint testing. Flag multiple failed CAPTCHA attempts

For Enterprises (API Consumers)

Mitigation Area	Recommended Actions
SMS Cost Monitoring	Set spending alerts at $100, $500, and $1,000 thresholds. Review daily SMS volumes for anomalies. Identify and investigate anomalous spikes immediately
Multi-Factor Authentication Hardening	Mandate rate-limiting requirements in service-level agreements Require CAPTCHA implementation on all OTP endpoints Request monthly security and abuse reports. Include SMS abuse liability clauses in contracts
Vendor Security Requirements	Mandate rate-limiting requirements in service-level agreements. Require CAPTCHA implementation on all OTP endpoints. Request monthly security and abuse reports. Include SMS abuse liability clauses in contracts

For Individuals

Protection Area	Recommended Actions
Number Protection	Document attack timing, volume, and sender information File police reports for harassment or threats. Request carrier assistance in blocking source numbers. Monitor all accounts for unauthorized access attempts
MFA Best Practices	Document attack timing, volume, and sender information. File police reports for harassment or threats. Request carrier assistance in blocking source numbers. Monitor all accounts for unauthorized access attempts
Incident Response	Prefer authenticator apps (Google Authenticator, Authy) over SMS Never approve unexpected or unsolicited MFA prompts. Contact the service provider immediately if SMS bombing occurs

Conclusion

The SMS/OTP bombing threat landscape has matured significantly between 2023 and 2026, evolving from simple harassment tools into sophisticated attack platforms with commercial distribution. Our analysis of ~20 repositories containing ~843 endpoints reveals systematic targeting across multiple industries and regions, with concentration in Iran (61.68%) and India (16.96%).

The emergence of Go-based high-performance tools, cross-platform GUI applications, and Telegram bot interfaces indicates the professionalization of this attack vector. With 75% of analyzed tools implementing SSL bypass and 58% using User-Agent randomization, defenders face sophisticated adversaries simultaneously employing multiple evasion techniques.

Organizations must prioritize comprehensive rate limiting, dynamic CAPTCHA implementation, and robust monitoring to achieve the projected 85%+ attack prevention effectiveness. The financial impact—potentially exceeding $50,000 monthly for unprotected endpoints—justifies immediate investment in defensive measures.

As the ecosystem continues to evolve, continuous monitoring of underground forums, repository activity, and emerging attack patterns remains essential for maintaining effective defenses against this persistent threat.

MITRE ATT&CK® Techniques

Tactic	Technique ID	Technique Name
Initial Access	T1190	Exploit Public-Facing Application
Execution	T1059.006	Command and Scripting Interpreter
Defense Evasion	T1036.005	Masquerading: Match Legitimate Name or Location
Defense Evasion	T1027	Obfuscated Files or Information
Defense Evasion	T1553.004	Subvert Trust Controls: Install Root Certificate
Defense Evasion	T1090.002	Proxy: External Proxy
Credential Access	T1110.003	Brute Force: Password Spraying
Credential Access	T1621	Multi-Factor Authentication Request Generation
Impact	T1499.002	Endpoint Denial of Service: Service Exhaustion Flood
Impact	T1498.001	Network Denial of Service: Direct Network Flood
Impact	T1496	Resource Hijacking

The post SMS & OTP Bombing Campaigns: Evolving API Abuse Targeting Multiple Regions appeared first on Cyble.

Cyble – ​Read More

Microsoft has released its monthly security update for February 2026, which includes 59 vulnerabilities affecting a range of products, including two that Microsoft marked as “Critical”. 

CVE-2026-21522 is a critical elevation of privilege vulnerability affecting Microsoft ACI Confidential Containers. Successful exploitation of this vulnerability could enable an authorized attacker to escalate privileges on affected systems. This vulnerability is not listed as publicly disclosed and received a CVSS 3.1 score of 6.7.  

CVE-2026-23655 is a critical information disclosure vulnerability affecting Microsoft ACI Confidential Containers. This vulnerability could enable an authorized attacker to disclose sensitive information including secret tokens and keys if successfully exploited. This vulnerability is not listed as publicly disclosed and received a CVSS 3.1 score of 6.5. 

In this month’s release, Microsoft reported active exploitation of five vulnerabilities rated as “Important”. Additionally, one “Moderate” vulnerability, CVE-2026-21525, was also listed as being actively exploited. CVE-2026-21510, CVE-2026-21513, and CVE-2026-21514 have also been publicly disclosed. 

CVE-2026-21510 is a security feature bypass vulnerability affecting Windows Shell. Successful exploitation of this vulnerability could allow an unauthenticated attacker to bypass a security feature on affected systems. This vulnerability could be exploited by convincing a user to open a malicious shortcut or link file, enabling them to bypass Windows SmartScreen and Windows Shell security prompts. 

CVE-2026-21513 is a security feature bypass vulnerability affecting MSHTML Framework. This vulnerability could be exploited by convincing a user to open a specially crafted HTML or LNK file, allowing an attacker to bypass security features and achieve code execution. This vulnerability received a CVSS 3.1 score of 8.8. 

CVE-2026-21514 affects Microsoft Office Word and results from reliance on untrusted input, enabling an unauthorized attacker to bypass security protections locally. Exploitation requires user interaction, typically by persuading a user to open a malicious Office document, and may bypass OLE mitigation mechanisms designed to protect against vulnerable COM/OLE controls. 

CVE-2026-21519 is a type confusion vulnerability in the Desktop Window Manager that allows an authenticated attacker to elevate privileges locally, potentially gaining full SYSTEM-level access. 

CVE-2026-21533 is an elevation of privilege vulnerability affecting Windows Remote Desktop Services. This vulnerability is due to improper privilege management and could enable an attacker to escalate privileges on affected systems. Successful exploitation of this vulnerability could grant an attacker SYSTEM level privileges on the system. 

CVE-2026-21525 is a moderate denial-of-service vulnerability affecting Windows Remote Access Connection Manager. This vulnerability is due to a null pointer dereference that could allow an unauthorized attacker to create a denial-of-service condition on affected systems. This vulnerability has not been publicly disclosed and received a CVSS 3.1 rating of 6.2.

Talos would also like to highlight the following “important” vulnerabilities affecting Microsoft Azure, Notepad, various GitHub Copilot components, and Hyper-V. 

CVE-2026-21228 is an improper certificate validation issue in Azure Local that allows an unauthorized attacker to execute code over the network; successful exploitation may result in a scope change, enabling interaction with other tenants’ applications and data. An attacker could exploit this flaw by intercepting unsecured communication between the configurator application and target systems, tampering with responses to trigger command injection with administrative privileges, and subsequently extracting Azure tokens from application logs to facilitate lateral movement within the cloud environment. 

CVE-2026-20841 addresses an RCE vulnerability in Microsoft Notepad. This issue could allow an attacker to entice a user into clicking a malicious link within a Markdown file opened in Notepad, resulting in the launch of untrusted protocols that download and execute remote content. 

CVE-2026-21244 and CVE-2026-21248 affect Windows Hyper-V and enable unauthorized attackers to achieve arbitrary code execution locally. Exploitation requires local code execution, commonly by convincing a user to open a malicious Office file. 

Several RCE vulnerabilities were also identified in GitHub Copilot, including CVE-2026-21516, CVE-2026-21523, and CVE-2026-21256. CVE-2026-21516 is a locally exploitable arbitrary code execution vulnerability in GitHub Copilot for JetBrains, requiring code execution on the affected system. For CVE-2026-21523, Microsoft has provided limited details beyond indicating a network attack vector. CVE-2026-21256 is a command injection vulnerability caused by improper handling of special characters, enabling unauthorized remote code execution in GitHub Copilot and Visual Studio Code. 

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 Security 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. 

Snort 2 rules included in this release that protect against the exploitation of many of these vulnerabilities are: 65895-65900, 65902, 65903, 65906-65911, 65913, 65914, 65923, 65924. 

The following Snort 3 rules are also available: 301395-301403. 

Cisco Talos Blog – ​Read More