Grok Build Share Links Expose Data from 35,000 Coding Projects

Summary:Security researcher Claroc found that Grok Build, SpaceXSI's AI coding agent, exposes data belonging to thousands of users through enumerable project-sharing links. Although the platform randomizes URLs to restrict access, a separate design flaw allowed the researcher to discover roughly 35,000 live projects, most of which could be opened without authentication. The exposed material includes internal business plans, advertising proposals, medical examination results, employee identifiers, and o

---

The vulnerability: treating randomized links as authorization

Grok Build lets users generate applications and share them through links. The platform randomizes the URLs to make direct discovery difficult, but Claroc found that a separate implementation flaw allowed the enumeration of roughly 35,000 live Grok Build projects. With rare exceptions, opening the discovered link exposed the application and its associated data.

This was not a cryptographic break. It was a failure of authorization boundary design:

• URL randomness lowers the probability of guessing a path but does not replace authentication or object-level authorization.
• Once a share identifier enters an enumerable namespace, every protected resource behind it effectively becomes public.
• A server that assumes possession of a link is equivalent to authorization cannot distinguish public sharing, team collaboration, and private projects.
• The ability to enumerate thousands of projects suggests a systemic weakness across identifier generation, lookup, sharing, or data routing rather than a single exposed frontend element.

A secure implementation needs three independent controls: server-side authorization for every project request; high-entropy, non-enumerable share credentials; and field-level minimization so sensitive data is not returned with a complete application object.

What was exposed

Claroc reported access to internal business plans, advertising proposals, medical examination results, celebrity-cruise checklists, employee names, and identification numbers. The problem was not limited to generated source code: the exposed dataset spanned regulated personal information, proprietary business material, employee identities, and operational documentation.

| Data category | Principal risk | |---|---| | Source code and secrets | Credential compromise, supply-chain attacks, proprietary logic exposure | | Medical records | Sensitive personal-data violations and regulatory liability | | Business plans | Competitive-intelligence and decision confidentiality breaches | | Employee identifiers | Identity fraud, phishing, and targeted social engineering | | Operational documents | System topology exposure and internal-tool reconnaissance |

Twenty-four SpaceXSI-built applications were also exposed. A sample included a confidential onboarding plan for a new enterprise-sales employee, a sales-territory map covering 594 accounts, internal sales-tool addresses, and advertising proposals. The issue therefore was not limited to third-party users: outsiders could potentially reach high-value internal material through the same product mechanisms used for ordinary app sharing.

Engineering trade-offs: sharing must not erode tenant isolation

AI app-building platforms must balance rapid sharing, live collaboration, and confidentiality. Copying an entire application into a temporary address is convenient, but it expands the copied data surface and complicates revocation, auditing, and lifecycle management. A safer design separates the public representation from private source data:

1. Private by default: only authorized principals can access a newly created project; sharing must be explicitly enabled.
2. Capability tokens: issue high-entropy, short-lived, revocable tokens with narrowly scoped resource permissions rather than exposing enumerable sequential identifiers.
3. Server-side authorization: validate principal, token scope, tenant, object, and operation on every read and write.
4. Data minimization: exclude secrets, personal information, internal addresses, and source data from public snapshots.
5. Versioning and revocation: edits must not silently extend the lifetime of older links, and revocation must invalidate caches and derived links.
6. Audit and detection: apply rate limits, anomaly alerts, and bulk-enumeration detection to suspicious access patterns.

These controls add authorization queries, token-management overhead, and snapshot-generation costs, while making one-click sharing less immediate. Yet AI coding platforms routinely handle code, credentials, and business attachments. Isolation and governance are therefore part of the product’s core cost base, not optional overhead.

Immediate actions for developers and platform operators

Teams using Grok Build should treat every existing share URL as potentially disclosed:

• Inventory all share URLs, project IDs, embedded pages, and historical exports.
• Revoke and regenerate links, then inspect access logs for bulk or anomalous requests.
• Rotate API keys, tokens, and database passwords that may have entered prompts, source files, logs, or repositories.
• Search projects for employee names, customer accounts, medical information, internal domains, and sales material.
• Move sensitive work to repositories with identity controls, fine-grained permissions, and audit trails.
• Add secret scanning, dependency scanning, DLP checks, and human approval to release workflows.

The platform should determine whether the issue arose from server-side authorization failures or a frontend trusting enumerable project identifiers. It should also assess bulk-export, cross-tenant access, and search-interface amplification; notify affected users; and provide logs, credential rotation, and incident-response support. Fixing authorization is more important than merely changing the URL format.

Conclusion

The Grok Build incident is not fundamentally about an AI model producing dangerous code. It is about an AI development platform placing confidential assets inside an enumerable and shareable data path. URL randomization is only one defensive layer, not an identity or permission system. Exposure of around 35,000 projects—including SpaceXSI's own internal material—shows that coding-agent competition cannot be measured only by generation speed, interface quality, and deployment convenience. Object-level authorization, tenant isolation, data minimization, revocation, and auditing must be treated as core product capabilities.

---

Source: Ars Technica AI (2026-11-10)

— END —

Tags: #Grok Build Follow #Data Leak Follow #Access Control Follow #Coding Agents Follow #Multi-tenant Security Follow