2026 – Page 172 – BackBox.org News

When AI Secrets Go Public: The Rising Risk of Exposed ChatGPT API Keys

February 12, 2026/in Company Blogs

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)

*Figure 1 – Public Websites exposing API keys*

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)

*Figure 2 – Cyble Vision indicates API key exposure leak*

Figure 3 – API key leak content ChatGPT — *Figure 3 – API key leak content*

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

Fortune 500 Tech Enterprise Speeds up Triage and Response with ANY.RUN’s Solutions

February 12, 2026/in Company Blogs

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.

Key challenges:

Too many alerts that were suspicious, but not provably malicious
Tier-1 escalations driven by incomplete signals
Tier-2 time lost on validation and confirmation work
Uneven triage speed across regions and shifts
Extra rework from low-confidence early decisions
Constant need to balance customer impact vs. security risk

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.

33 seconds to expose full attack chain inside ANY.RUN sandbox — *ANY.RUN’s sandbox exposed a multi-stage phishing attack with the final fake Microsoft login page in 33 seconds*

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.

Automated detonation of complex attacks, including QR codes — *ANY.RUN’s sandbox enables automated detonation of complex attacks, including QR codes*

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.

TI Lookup connected to analysis sessions — *TI Lookup connects isolated indicators with real live attacks in seconds*

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:

Tangible Gains Across SOC

Fewer unnecessary Tier-2 escalations decreased approximately 35%, driven by stronger early-stage evidence
Average triage time per suspicious file or link dropped by 40% across regions and analyst shifts
Higher-quality incident response handoffs, supported by behavioral proof and threat context
Over 82% of ambiguous alerts were resolved without secondary review, allowing senior responders to focus on confirmed incidents
Overall MTTR improvement by 24%, achieved through faster scoping and clearer decisions

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.

*Team management inside ANY.RUN sandbox for faster collaboration*

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

How does behavioral evidence improve SOC triage?

Behavioral analysis allows analysts to observe what a suspicious file or link actually does in a controlled environment. This removes guesswork, enables earlier confident decisions at Tier-1, and reduces unnecessary escalations.

Can ANY.RUN integrate into existing SOC workflows?

Yes. ANY.RUN is designed to fit into mature SOC environments without requiring workflow redesign, supporting investigation, enrichment, and reporting across Tier-1, Tier-2, and Tier-3 operations.

How quickly can analysts confirm a phishing attack?

In many real investigations, the full attack chain can be exposed within seconds through automated interactivity and behavioral observation, allowing faster evidence-based classification.

Who typically uses ANY.RUN in enterprise environments?

Security teams across enterprises, MSSPs, and SOC organizations worldwide rely on ANY.RUN to accelerate triage, improve investigation clarity, and support proportional response to modern threats.

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

This SSD enclosure has become one of my most-used laptop accessories – here’s why

February 12, 2026/in General News

The HyperDrive Next USB4 M.2 PCIe enclosure lets NVMe SSDs perform at their best, ensuring fast transfer speeds for large files.

The CTEM Divide: Why 84% of Security Programs Are Falling Behind

February 12, 2026/in General News

A new 2026 market intelligence study of 128 enterprise security decision-makers (available here) reveals a stark divide forming between organizations – one that has nothing to do with budget size or industry and everything to do with a single framework decision. Organizations implementing Continuous Threat Exposure Management (CTEM) demonstrate 50% better attack surface visibility, 23-point

The Hacker News – Read More

Nucleus Raises $20 Million for Exposure Management

February 12, 2026/in General News

The company will use the investment to scale operations and deepen intelligence and automation.

The post Nucleus Raises $20 Million for Exposure Management appeared first on SecurityWeek.

SecurityWeek – Read More

Apple Patches iOS Zero-Day Exploited in ‘Extremely Sophisticated Attack’

February 12, 2026/in General News

Impacting the ‘dyld’ system component, the memory corruption issue can be exploited for arbitrary code execution.

The post Apple Patches iOS Zero-Day Exploited in ‘Extremely Sophisticated Attack’ appeared first on SecurityWeek.

SecurityWeek – Read More

Senegalese Data Breaches Expose Lack of ‘Security Maturity’

February 12, 2026/in General News

Green Blood Group steals personal records and biometric data of the West African nation’s nearly 20 million residents.

darkreading – Read More

Apple Fixes Exploited Zero-Day Affecting iOS, macOS, and Apple Devices

February 12, 2026/in General News

Apple on Wednesday released iOS, iPadOS, macOS Tahoe, tvOS, watchOS, and visionOS updates to address a zero-day flaw that it said has been exploited in sophisticated cyber attacks.
The vulnerability, tracked as CVE-2026-20700 (CVSS score: N/A), has been described as a memory corruption issue in dyld, Apple’s Dynamic Link Editor. Successful exploitation of the vulnerability could allow an

The Hacker News – Read More

Microsoft just patched 6 zero-days, but you might want to hold off updating – here’s why

February 12, 2026/in General News

I’m normally in favor of updating ASAP, but recent events have given me pause.

I’ve tested dozens of earbuds over the last year – these blow them all out of the water

February 12, 2026/in General News

The Denon PerL Pro surpassed my expectations with audiophile-grade sound right out of the box.