Incident Overview: "Wayback Copilot" Exposes Private GitHub Repositories via Microsoft Copilot
In February 2025, Lasso Security demonstrated that Microsoft Copilot could retrieve and expose content from thousands of GitHub repositories that had been made private after initially being public. The issue stemmed from Bing’s caching mechanism, which retained snapshots of these repositories even after they were restricted.
The problem originated from Bing’s indexing of GitHub repositories during their public phase. Once a repository was made private, direct access via GitHub returned a 404 error, but Bing’s cached versions persisted. Microsoft Copilot, which relies on Bing for data retrieval, could still access these cached snapshots, effectively bypassing GitHub’s privacy controls. Lasso Security identified over 20,580 repositories affected by this issue, with 16,290 organizations impacted.
The incident highlighted a broader risk: the persistence of 'zombie data'—information that was once public, even briefly, but remains accessible through cached sources. This phenomenon is exacerbated by the reliance of AI systems like Copilot on search engines and cached datasets, which may not align with real-time access controls. The exposure of such data poses significant risks, including intellectual property leakage, credential theft, and potential dependency confusion attacks.
Lasso Security’s investigation began in August 2024 after a LinkedIn post suggested OpenAI was training on and exposing data from private GitHub repositories. Initial tests confirmed that ChatGPT could reference repositories that were no longer publicly accessible, attributing this to Bing’s indexing. Further testing revealed that Microsoft Copilot could retrieve actual content from cached versions of private repositories, including Lasso Security’s own internal repositories that had been briefly public.
The researchers automated the process of identifying 'zombie repositories' by querying Google BigQuery’s githubarchive dataset for repositories that were public at any point in 2024. They then cross-referenced these with Bing’s cache to extract and analyze the data. The findings underscored the ease with which sensitive information could be accessed through AI-driven tools, even after the original source was secured.
Microsoft acknowledged the issue and initially disabled Bing’s cached-page feature and restricted access to the cc.bingj.com domain. However, this fix was incomplete: while human users could no longer directly access cached pages, Microsoft Copilot continued to retrieve data from these caches. Subsequent testing in January 2025 confirmed that Copilot still had access to the cached content, demonstrating that the underlying data remained exposed despite the superficial patch.
The incident also revealed a legal dimension. In January 2025, Microsoft took legal action against a group accused of bypassing safety guardrails in its cloud AI products. Lasso Security tested Copilot’s ability to retrieve content from repositories that had been removed from GitHub due to such violations. Despite the repositories returning 404 errors, Copilot successfully extracted code from these deleted repositories, further illustrating the persistence of cached data in AI-assisted systems.
The broader implications of this vulnerability extend beyond Microsoft Copilot. It reflects a systemic risk in AI systems that rely on third-party data sources, such as search engines or cached datasets. The pressure to acquire unique datasets for training large language models (LLMs) has led organizations to adopt riskier data acquisition strategies, increasing the likelihood of accidental or malicious exposure. This incident serves as a case study in how traditional cybersecurity measures may fail to address the new risks introduced by AI-driven data retrieval.
Root Cause: Bing’s Caching Mechanism and Copilot’s Data Retrieval
The primary root cause of the "Wayback Copilot" vulnerability was Bing’s persistent caching of GitHub repository pages, even after those repositories were made private. Bing’s indexing system captures and stores snapshots of publicly accessible content, including GitHub repositories. When a repository is later restricted to private, the cached version remains available through Bing’s search results and cached-page feature (cc.bingj.com).
Microsoft Copilot, which integrates Bing as its primary search engine, inherits this cached data. Unlike human users, who were eventually blocked from accessing cached pages after Microsoft’s fix, Copilot continued to retrieve content from these caches. This discrepancy arose because Copilot’s data retrieval process does not enforce the same access controls as direct user requests. As a result, Copilot could surface information from repositories that were no longer publicly accessible, effectively bypassing GitHub’s privacy settings.
The vulnerability was exacerbated by the transient nature of repository visibility. Many repositories are briefly made public due to human error, such as accidental commits or misconfigured permissions. This creates a window of exposure where sensitive information, including secrets, tokens, and proprietary code, remains accessible to AI systems long after it should have been secured.
Bing’s caching mechanism is not inherently malicious but rather a byproduct of its design as a search engine. When Copilot queries Bing for information, it retrieves results from this cache, including outdated or restricted content. This behavior is particularly problematic for organizations that rely on GitHub for collaborative development, as it introduces a latent risk of data leakage.
The incident also highlighted a design flaw in Copilot’s data retrieval pipeline. While Microsoft implemented a fix to block human users from accessing cached pages, the underlying issue—the persistence of cached data in Copilot’s responses—remained unresolved. This suggests that Copilot’s reliance on Bing’s cache does not account for the temporal or permission-based changes in the source data. Without additional safeguards, such as real-time validation of data sources or explicit permission checks, Copilot will continue to surface stale or unauthorized information.
Takeaways: Implications for AI Security and Organizational Data Protection
The "Wayback Copilot" incident underscores the need for organizations to adopt a zero-trust approach to data exposure, particularly in the context of AI-driven tools. Any data that leaves an organization’s network, even briefly, should be assumed to be at risk of ingestion by third-party systems, including search engines and AI assistants.
Organizations must implement rigorous data sanitization and access control policies before publishing repositories or other sensitive information. This includes automated checks to detect and revoke exposure of secrets, tokens, or proprietary code before it becomes public. Additionally, organizations should monitor their repositories for accidental public exposure and take immediate action to secure them.
The incident also reveals a critical gap in the security posture of AI systems like Copilot. While these tools offer significant productivity benefits, their reliance on third-party data sources introduces new attack surfaces. Organizations deploying AI assistants must ensure that these systems adhere to the same access controls and data protection standards as their internal tools. This may require customizing or extending the AI’s data retrieval mechanisms to include real-time validation of source permissions and content freshness.
For developers and security teams, the findings serve as a reminder that traditional threat intelligence models are insufficient in the age of AI. While scanning the web, forums, or dark web for leaked data remains important, the risk now extends to AI-driven exposure. A single prompt to an AI assistant could inadvertently surface sensitive information to unauthorized users.
The exposure of internal packages and secrets in this incident also highlights the risks associated with dependency confusion attacks. When private packages are mistakenly published to public repositories, they can be exploited by malicious actors to inject compromised dependencies into an organization’s supply chain. Organizations should use official package repositories (e.g., PyPI, npm) for private packages and implement strict versioning controls to prevent such attacks. Additionally, regular audits of dependencies and access logs can help identify and mitigate potential vulnerabilities.
Microsoft’s response to this issue, while swift, was incomplete. The disabling of Bing’s cached-page feature addressed the immediate risk to human users but did not resolve the underlying problem of Copilot’s access to cached data. This suggests that AI systems require more comprehensive security measures, including the ability to dynamically validate data sources and enforce access controls at the point of retrieval. Organizations developing or deploying AI tools should prioritize these capabilities to align with their security policies.
Finally, the incident serves as a cautionary tale about the long-term persistence of digital data. Even when information is deleted or restricted, it may continue to circulate in caches, backups, or third-party systems. Organizations must assume that any data they produce or handle could be exposed at some point and take proactive steps to minimize this risk. This includes not only securing repositories but also monitoring external sources for cached or indexed versions of sensitive content.
The "Wayback Copilot" vulnerability demonstrates that AI-driven tools, while powerful, introduce new and evolving security challenges. Addressing these challenges requires a combination of technical safeguards, organizational policies, and continuous vigilance. By learning from incidents like this, organizations can better protect their data and mitigate the risks associated with AI-assisted systems.