LIVE THREATS
HIGH 2,000 AI-Built Apps Expose Corporate Data via Misconfigured Vibe-Coding Platforms // MEDIUM Anthropic Documents Sandbox Escape Risks and Credential Exfiltration Vectors in Claude … // HIGH ChatGPhish Exploit Turns ChatGPT Summarisation Into a Live Phishing Surface // HIGH LLMShare Campaign Weaponises ChatGPT Sharing Feature to Distribute Malware // MEDIUM Process-Level CAPTCHA Analysis Exposes Behavioural Fingerprints of AI Agents // HIGH Robinhood MCP Integration Grants AI Agents Autonomous Financial Trading Powers // HIGH Malicious npm Package Targets Claude AI Users via Supply Chain Attack // HIGH Multi-Agent LLM System Discovers 29 Zero-Day Vulnerabilities in Open-Source Projects // HIGH Russia-Linked GreyVibe Weaponises ChatGPT and Gemini Across Full Attack Lifecycle // HIGH Russian GreyVibe Group Weaponises ChatGPT and Gemini for Cyberespionage //
ATLAS OWASP HIGH Significant risk · Prioritise patching RELEVANCE ▲ 7.2

2,000 AI-Built Apps Expose Corporate Data via Misconfigured Vibe-Coding Platforms

TL;DR HIGH
  • What happened: Over 2,000 AI-built corporate apps sit exposed on the open web with no access controls.
  • Who's at risk: Enterprises across all industries whose employees have used vibe-coding platforms to build and publish apps connected to production systems without IT oversight.
  • Act now: Inventory AI-assisted development platform usage across the organisation and identify publicly accessible artifacts · Enforce access control policies at the vibe-coding platform level, requiring authentication by default for all published apps · Extend CASB and web asset discovery tooling to monitor AI-native development platforms as a new shadow-IT vector
2,000 AI-Built Apps Expose Corporate Data via Misconfigured Vibe-Coding Platforms

Overview

A new research report from Red Access, The Shadow Builders, has documented more than 380,000 publicly accessible web assets across leading AI-assisted development platforms — commonly referred to as ‘vibe-coding’ tools. Of these, over 5,000 appeared corporate in origin, and more than 2,000 were confirmed to contain sensitive corporate, operational, or personal data. These applications were deployed without basic authentication controls, many granting admin-level access to anyone with the URL.

The findings represent a structural evolution in the shadow IT threat model. Where legacy shadow IT involved unsanctioned SaaS subscriptions, this new category involves custom-built applications that are directly integrated with production systems of record — CRMs, ERPs, ticketing platforms, and business intelligence tools — and published on the open internet by non-developer employees acting in good faith.

Technical Analysis

Vibe-coding platforms allow users to describe desired functionality in natural language and receive a deployable web application. The compression of development time — from months to hours — has outpaced the security awareness and configuration habits of the non-technical builders using these tools.

The exposure pattern is consistent: an employee builds a functional app, connects it via API or native integration to a sanctioned internal system, and publishes it using the platform’s default settings. Default settings on many platforms do not enforce authentication. The result is a URL-accessible application with live reads — and sometimes writes — into production data sources.

No exploitation in the traditional sense is required. The data is accessible to any unauthenticated user who reaches the endpoint. The applications were active while their parent organisations were passing security audits, because the audit surface — identity providers, SIEM, CASB, DLP — does not extend to custom applications built on third-party AI platforms.

Framework Mapping

OWASP LLM06 (Sensitive Information Disclosure) applies directly: LLM-assisted applications are surfacing sensitive business data to unauthenticated external parties. LLM07 (Insecure Plugin Design) covers the integration pattern, where AI-built apps are granted broad API access to production systems without scoped permissions. LLM08 (Excessive Agency) is relevant where these apps can write back to source systems. LLM09 (Overreliance) captures the organisational dynamic — builders and their managers trust that the platform handles security concerns.

On the MITRE ATLAS side, AML.T0047 (ML-Enabled Product or Service) covers the deployment of AI-built artifacts into production contexts. AML.T0057 (LLM Data Leakage) maps to the unintended external exposure of sensitive data via AI-generated applications.

Impact Assessment

The impact spans six continents and every major industry vertical surveyed. The severity is elevated by three factors: the data exposed is live production data, not copies; integrations grant direct access to systems of record; and the exposures are invisible to conventional enterprise security tooling. Organisations may be compliant on paper while harbouring active, unauthenticated data exposures.

Mitigation & Recommendations

  • Discover before you govern: Deploy web asset discovery tooling capable of identifying AI-platform subdomains and published applications associated with corporate identities.
  • Enforce secure defaults at the platform layer: Work with vibe-coding platform vendors to require authentication by default for any published application.
  • Extend shadow IT policy: Classify AI-assisted development platforms as a governed category requiring IT registration before production deployment.
  • Scope integrations: Any AI-built app connecting to a production system should use scoped, read-only credentials with short expiry where possible.
  • Educate builders: Non-technical employees building apps need lightweight security onboarding — specifically around access control configuration before publishing.

References

◉ AI THREAT BRIEFING

Stay ahead of the threat.

Twice-weekly digest of critical AI security developments — every story mapped to MITRE ATLAS and OWASP LLM Top 10. Free.

No spam. Unsubscribe anytime.