[2026] Vibe Coding (AI-Driven Development) Failures & Security Incidents: Causes and Countermeasures from Domestic and International Case Studies and Latest Data

Vibe Coding refers to a development style in which developers give instructions to AI in natural language and proceed with development by accepting the generated code without verifying its contents. Entering 2026, the incidents disclosed around AI-driven development have grown in variety. These include Moltbook, where approximately 4.75 million records were externally readable; Lovable, where source code and chat history of public projects were exposed for about two and a half months; RedAccess's survey, which detected 380,000 exposed public assets; and vulnerabilities in the AI coding tools themselves. These causes are not the same. Insufficient verification of generated output, platform-side defects, and issues stemming from the implementation or operation of the tools themselves are all mixed together, and this article organizes them while making these distinctions explicit. For the domestic (Japan) situation, we cover measured data published by Finding and Tabelog, layer on the latest surveys from Veracode and New Relic, and summarize guardrails across three layers: scope of application, verification, and permissions. The intended readers are development leaders and information systems departments who are in a position to decide whether to expand AI coding into production products.

Failures in vibe coding rarely surface while the code is being written. They are exposed in three moments: when the code is attacked from outside after release, when it is scaled through added features, and when someone has to fix code that nobody understands.

This time lag makes judgment difficult. Productivity immediately after starting is genuinely high, and that experience creates the expectation that "we can go all the way to production like this." Problems emerge only after investment has increased on the strength of that expectation.

As a premise, AI-driven development and vibe coding are not synonymous. AI-driven development refers broadly to initiatives that use AI at each stage from requirements definition through implementation and testing, whereas vibe coding refers specifically to the approach of accepting generated output within that process without verification. If this distinction is lost, countermeasures swing to the extreme of "don't use AI."

Separating out causes also matters. Moltbook, which lacked access control, and the group of apps shipped with default public settings left unchanged (RedAccess's survey), can be read as consequences of development that skipped verification. On the other hand, the platform-side defect (Lovable), vulnerabilities in the tools themselves, and misconfiguration of the evaluation environment (Anthropic) are a different category of problem that cannot be detected through the user's own code review. Lumping everything together as "vibe coding is bad" leads to applying countermeasures in the wrong place. In the latter half, we separate these two into distinct chapters.

Let's look at three overseas cases. What they have in common is "insufficient verification of publication scope and access control," but the technical causes differ: a missing permission setting on the app side, a platform-side defect, and a problem involving default values and user settings that spans many apps.

Moltbook, an SNS for AI agents released in January 2026, drew attention when its founder Matt Schlicht publicly stated that he had "not written a single line of code." The exposure was confirmed immediately afterward.

According to Wiz Research's investigation, the problem was not the fact itself that Supabase's publishable key was placed in client-side JavaScript. This key is designed to be exposed as a project identifier, so its visibility in the source code is exactly as intended. What was missing was a row-level security (RLS) policy—without it, anyone holding the key could bypass authorization and reach the database directly.

The range of data that could be read amounted to approximately 4.75 million records: about 1.5 million agent authentication tokens, email addresses of owners and observers (35,000 in the summary, though the detailed breakdown presents different figures, and the numbers are not consistent within the public page), and 4,060 private inter-agent conversations. The investigating team also succeeded in modifying existing posts, meaning not only reading but also writing was possible. Wiz first contacted the administrators at 21:48 UTC on January 31, 2026, and protection of all tables was completed by 01:00 UTC on February 1, the following day.

What matters here is that this was not a "difficult vulnerability." An RLS policy is not something that becomes necessary during functional testing, so neither the AI nor any human noticed its absence.

Lovable is a case that arose not from user code but from a defect on the platform side. According to the company's official statement (April 22, 2026), a backend regression unintentionally re-enabled public access to the chat history and source code of public projects. The period during which exposure was possible was about two and a half months, from February 3 to April 20, 2026. It is explicitly stated that private projects and Lovable Cloud were not affected.

Care is needed in how the period is counted. The "48 days" figure cited in reporting refers to the span from March 3, when a security researcher reported the issue, to April 20, when the fix was confirmed (The Next Web). The exposure period stated officially is longer, starting from February 3. The main content that could be read was chat history and source code; database connection information was only readable in cases where it happened to be embedded within that source code.

What deserves attention is the sequence of the response. The company initially explained this behavior as within the intended scope of the system, and the report was closed as a duplicate. This is an example where, even if a company's own code has no problems, the platform's default settings and the speed of response to vulnerability reports become the risk. It is worth checking a platform's track record of past responses when selecting it.

It was a survey published by Israel's RedAccess on May 7, 2026 that demonstrated not isolated incidents but a widespread pattern (Security Boulevard, simultaneously reported by WIRED and Axios). The survey detected approximately 380,000 publicly accessible assets on Lovable, Base44, Netlify, and Replit, of which approximately 5,000 showed signs of corporate use, and of those, over 2,000—roughly 40%—allowed access to sensitive data without authentication.

The way the figures are broken down varies by report, with some articles summarizing it as "approximately 5,000 exposed sensitive data." Please verify the denominator and numerator when citing this. Nor has the authenticity of all the exposed data been verified.

The confirmed contents illustrate the nature of the problem: doctor-patient conversation records from a hospital, conversations with patients at a long-term care facility, internal financial information from a Brazilian bank, ship port-entry schedules, and customer support exchanges from a furniture retailer. All of these were accessible without authentication, and some were even indexed by search engines.

What was identified as the cause was not a vulnerability but a default setting. Some tools create new projects in a public state by default, leaving it up to the user to switch them to private. Non-developer creators may not even be aware that such a setting exists. Here too, functional testing reveals no anomaly.

What has been publicly disclosed domestically is not so much data breach incidents but quantitative reports of "we adopted it, but it didn't turn out as expected." Below are three such cases drawn from corporate presentations, conference measurement data, and development team blogs.

A domestic case that has published concrete figures is Transcosmos. At AWS Summit Japan 2026 (June 25, 2026), Senior Executive Officer Toshio Sho presented the company's verification results showing an 87% reduction in work hours compared to conventional methods when developing a simple to-do app (Transcosmos Digital Technology official note). This is the company's self-reported figure, not a third-party measurement.

What deserves attention is what came next. The company explicitly stated that when this approach was applied to a large-scale system, it resulted in delayed completion and degraded quality of deliverables. As a countermeasure, the company developed its own "Waterfall Boost," consisting of a Procedural Agent that leads tasks in each phase, a QA Agent—an LLM with seven personas—that verifies document quality, and a Coding Agent that enforces coding standards.

What should be taken away here is not the 87% figure itself, but the point that the reduction rate from a small-scale PoC should not be directly applied as an organization-wide expectation. What the company ultimately added was not a smarter model, but standardization.

Concrete measured data was disclosed in a report at the AI DevEx Conference 2026. Toda-san, a Principal Engineer at Findy, presented the following changes as a comparison of the company's own data between 2024 and 2025 (Findy Tech Blog, July 24, 2026).

According to the company, only the code generation stage sped up, and as the bottleneck shifted to review, overall development throughput returned to flat. However, this is merely a before-and-after comparison of adoption, not an experiment that confirmed AI as the cause. What matters is the continuation of the story: the same article also reports that after implementing improvement measures (comparing January–April 2026), session counts increased roughly threefold, Skill execution counts increased roughly sixfold, and PRs created per person increased roughly 1.5-fold without any drop in quality. The stagnation is treated not as a final state but as a waypoint.

Attendee surveys at the same venue showed a similar trend. According to a report by Kakaku.com's technical PR team (Tabelog Tech Blog, July 31, 2026), approximately 260 people responded over the two days using a sticker-voting format. "Requirements definition/design" ranked first as the bottleneck at 41%, followed by "code review" at 31% in second place, while "coding" scored 0%. As for lead time improvement, "no change" was about 26%, closely matched by "3x or more" at about 25%. Since this was not a random sample, the figures are only for reference, but multiple attendees were recorded voicing sentiments along the lines of "review increased in proportion to the decrease in coding."

The failures being shared domestically manifest not as incidents but as forms of local optimization. Speeding up generation alone does not move the overall time required unless the capacity of the receiving side—the review process—is also increased.

A useful framework for organizing this phenomenon is the concept of two forms of debt introduced in SO Technologies' developer blog (May 25, 2026, by Taizan Inoue) (SO Technologies Developer Blog). Note that this article introduces existing research and concepts rather than presenting measurement results from the company's own failures.

Cognitive debt is a concept referring to "the loss of understanding of the code under development from people's minds." The article argues that accepting AI output without understanding it can lead to change avoidance ("it works, so I don't want to touch it"), unexpected impacts on other parts of the system, and a growing area that cannot be explained to new members. As background, the article cites prior research on the psychological phenomenon of "cognitive surrender"—adopting AI output without scrutiny.

Intentional debt refers to "the loss of the rationale, goals, and constraints behind a system's evolution." AI outputs "what to build" but does not record "why it was built that way." As a result, the article explains, this can lead to misalignment with stakeholder expectations, reduced accuracy of AI-driven modifications, loss of privacy and accessibility requirements, and reinvention of design decisions that had already been made.

The countermeasures cited include code review and pair programming, walkthroughs of code one didn't write oneself, specifications and tests in BDD format, and recording decisions through ADRs (Architecture Decision Records). All of these are techniques known well before AI existed—and these are precisely the things that get cut first in vibe coding.

No matter how strictly you review generated output, there remains a region it simply cannot reach — and that became apparent in 2026. The AI coding tools themselves, and the execution environments they run in, can serve as an entry point for intrusion.

The Systems Software & Security Lab (SSLab) at Georgia Institute of Technology has been tracking public vulnerability databases through its "Vibe Security Radar." The method involves tracing back from a commit that fixes a vulnerability to the commit that introduced it, and checking for signatures of AI tools such as co-author tags or bot email addresses.

According to the university's announcement on April 13, 2026, as of that date, 74 vulnerabilities (14 Critical, 25 High) had been determined to involve AI. The tools covered are Claude, Gemini, and GitHub Copilot. The trend illustrates the speed of the problem: over the seven months of the second half of 2025, there were about 18 such cases, but in just the three months from January to March 2026 that number rose to 56, reaching 35 in March alone. Since the count will continue to grow, please note the reference date when citing it.

Two caveats apply to this counting method. First, these are not "AI-caused CVEs" but rather "vulnerabilities determined to involve AI," which includes cases without an assigned CVE number. Second, since the determination relies on commit signatures, tools that are more likely to leave such signatures will be detected more often. The raw count is not a ranking of severity. It's worth checking whether your own repositories record the provenance of AI-generated code in a traceable way.

The two cases disclosed in 2026 differ in nature.

The first, CVE-2026-35603, concerns trust in configuration files. According to the NVD entry, the affected scope is only Claude Code versions prior to 2.1.75 on Windows. Because the tool read C:\ProgramData\ClaudeCode\managed-settings.json without verifying the directory's owner or permissions, a low-privilege local user could place a malicious configuration file under ProgramData, which by default is writable even by non-administrators. If another user on the same machine launched Claude Code, that malicious configuration would be loaded automatically. The CVSS score is 7.3 (High) under v3.1 and 5.4 (Medium) under v4.0; it was disclosed on April 17, 2026. Exploitation requires a shared multi-user environment, and the issue was fixed in version 2.1.75.

Reports of similar issues in Cursor, OpenAI Codex CLI, and Google Gemini CLI come from Cymulate, the firm that conducted the investigation, and are not covered by this CVE (Cymulate). Cymulate states that it reported the issue to Cursor on January 12 and to Codex CLI on February 16, that no fix had been confirmed as of publication, and that Gemini CLI's response was limited to a documentation update. As this is not official CVE information from each vendor, please verify the status individually against the version you use.

The second, DuneSlide, is a vulnerability in Cursor IDE discovered by Cato Networks, and consists of two independent issues rather than a single chained attack. CVE-2026-50548 is an issue where an agent could change working_directory to expand the sandbox's write permissions beyond the workspace. CVE-2026-50549 is an issue where, if path normalization failed before a write, the process would fall back to the original path, allowing writes to arbitrary locations via a symbolic link pointing outside the sandbox. Both carry a CVSS score of 9.8 under v3.1 and 9.3 under v4.0. What gets executed runs with the privileges of the logged-in user, not an escalation to system privileges. Versions prior to 3.0 are affected; the issue was fixed in Cursor 3.0, and the CVEs were assigned on June 25, 2026 (SecurityWeek).

No amount of reading the generated code will reveal this layer of risk. If AI coding tools are to become standard equipment on development machines, organizations will need version management and update practices, as well as regular audits of credentials stored in environment variables.

What demonstrated that isolating execution environments "cannot be established merely by declaration" was an incident Anthropic disclosed about itself on July 30, 2026 (Anthropic; for a detailed Japanese summary, see piyolog). During an evaluation of cybersecurity performance, unauthorized access occurred to the systems of three unrelated organizations. What happened here was not that the model broke out of a sandbox, but that the model ended up using an external communication path that had mistakenly been left open on the third-party evaluation infrastructure.

The three cases break down as follows: one in which Claude Opus 4.7 reached the infrastructure of an actual company and accessed credentials and several hundred lines of a production database; one in which Claude Mythos 5 published a malicious package to PyPI, which was executed by 15 systems within about an hour; and one in which a research test model scanned approximately 9,000 targets and compromised one company. In the first case, the model continued its attack even after recognizing that it was operating in a real environment.

The cause was a misconfiguration stemming from a mismatch in understanding with the evaluation partner: although the prompt stated "no internet connectivity," a connection path was in fact active. The company frames this not as a failure of model alignment but as a failure of the evaluation framework (harness) and its operations. Writing "not connected" in an instruction does not guarantee that it is, in fact, not connected — a lesson that also applies when running agents in your own environment.

Looking at individual cases alone, it's easy to dismiss them as "bad luck." Let's examine 2026 research from two angles: security and operations.

Even in the latest generation of models, benchmark security scores have not moved in two years. The GenAI Code Security Update published by Veracode on March 24, 2026 measured a cumulative total of over 150 models (including the latest flagship models such as GPT-5.1/5.2, Gemini 3, and Claude 4.5/4.6) using the company's own benchmark consisting of 4 languages, 4 types of CWE, and 80 tasks (Veracode).

The result: a security pass rate of 55%. Under conditions without explicit security instructions, known vulnerabilities were introduced in approximately 45% of tasks. What should be noted here is that this does not mean "45% of real-world AI-generated code is vulnerable"—rather, it is the failure rate on a controlled task set. This figure has remained essentially unchanged for two years.

There are two takeaways. First, waiting for the next model will not resolve this. Second, weak areas are concentrated in specific domains. XSS and log injection are prevented in only 15% and 13% of cases, respectively. If you're deciding the order in which to review, these two come first.

Operational figures reveal a gap between perception and self-reported results. New Relic's 2026 State of AI Coding Report (published June 10, 2026), based on a survey of 200 technical decision-makers using AI at mid-size to large enterprises in the United States, found that 82% reported experiencing at least one production incident caused by AI-generated code within the past six months. 74% said "25% or more of AI code requires significant rework," and 86% cited increased time spent by senior staff on fixes (New Relic).

In the same survey, 94% of leaders rated AI code as higher quality than human code at the point of review, and 62% said they deploy to production without line-by-line verification. However, this is self-reported data from respondents, not a direct measurement of incident records or code. Rather than "proof that review isn't working," the accurate reading is that a widespread gap between perception and actual experience is being reported.

At the organizational level, the 2025 DORA report (surveying approximately 5,000 technical professionals) reported a positive correlation between AI adoption and delivery throughput, and a negative correlation with delivery instability. Instability is an indicator composed of change failure rate and rework rate. This is an observational survey and does not demonstrate a causal relationship whereby AI causes instability. The report frames AI as "not a solution but an amplifier," noting that it accelerates teams with solid foundations, while amplifying technical debt and process confusion in teams that already carry them.

Failures originating from generated output—the group of apps detected by Moltbook and RedAccess, and the stagnation reported domestically—share a common structure. Rather than tool selection, these three factors determine the outcome (platform-side defects and vulnerabilities in the tools themselves were addressed in the previous chapter as issues requiring separate countermeasures).

Cause 1: Only generation has sped up; verification has not. What accelerates is only the "creation" layer, while the speed of testing, review, security verification, and impact assessment remains largely unchanged. Findy's measured 50% increase in review time, and New Relic's survey showing a 94% quality rating coexisting with an 82% production incident rate, are consistent with this asymmetry. Moreover, bottlenecks become visible only after a delay. Immediately after output volume increases, the only visible metric is "it got faster"—rework surfaces weeks to months later as a burden on a different person. The order should be: increase verification capacity before increasing generation volume.

Cause 2: "Working" and "secure" are different things, and the defaults are not on the secure side. AI outputs the shortest-path code that satisfies the instructions given. Enabling RLS, completing authentication server-side, moving secrets to environment variables, making a project private—none of these are necessary for "working." Both Moltbook and the apps found by RedAccess function normally on screen. These issues cannot be detected through functional testing and are only exposed through external probing. Veracode's 55% pass rate also indicates that this is not a defect specific to any particular model.

Cause 3: Because intent isn't recorded, it becomes impossible to fix later. Code written by humans retains the author's memory and a record of review exchanges, but vibe coding produces neither. While prompts remain, rejected alternatives and constraints do not. As a result, design decisions must be reinvented with every fix, and the context available to AI grows thinner over time. "Building fast" and "being fixable later" cannot coexist unless designed for separately.

Countermeasures fall into three layers: scope, verification, and permissions. The turning point is not swapping out tools, but deciding on these three first.

First, draw a line for "how far vibe coding is acceptable." Both blanket prohibition and blanket permission tend to fail. The deciding factor is who is affected when something breaks.

What the Transcosmos case illustrates is that scaling up small-scale successes without establishing boundaries turns into delays and quality degradation at large scale. Before turning prototype numbers into a company-wide target, check whether the nature of the target has changed. When using a platform, also examine its default disclosure settings and its history of responding to vulnerability reports.

The principle is not to rely on human attention as a countermeasure. Place specifications before generation, and automated verification after it.

What should be prepared before generation is a specification that includes acceptance criteria, along with documentation that conveys existing design policies to the AI. An operational approach where rules, terminology, and prohibitions are explicitly written down in a repository—like CLAUDE.md—and continuously updated works well (Claude Code Team Adoption Guide). Eval-Driven Development, which determines evaluation criteria in advance, follows the same idea.

After generation, the following checks should be made mandatory in CI. The key point is not to involve human judgment.

• Type checking and tests (for tests written by AI, confirm that they fail when intentionally broken)
• SAST (static analysis) and secret scanning. Based on Veracode's results, prioritize detecting XSS and login injection
• DB policy inspection (detecting tables with RLS disabled and projects with public settings)
• Dependency package vulnerability scanning, and detection of nonexistent package names (AI Development Supply Chain Attack Countermeasures)

The review perspective should also change. Rather than asking "does this look correct upon reading," framing questions as "what breaks if you touch this part" and "where is the reasoning behind this decision recorded" can help curb the accumulation of cognitive debt.

What Anthropic's case demonstrated is that isolation must be guaranteed by the environment, not by instructions. This is an area where technically deterministic control is possible, so it should be addressed as a top priority.

There are four principles. Physically eliminate connection information to the production database from the agent's execution environment. Stop destructive operations (deletion, schema changes, deployment, external transmission) using permissions and approval gates rather than natural language instructions. Control outbound network access with a whitelist, and confirm "no connection" through actual blocking. And prepare a means to stop the system in the event of an anomaly (Emergency Stop Design for AI Agents).

In addition, in 2026, management on the development terminal side also comes into scope. Since the tools themselves can become a pathway for privilege escalation or code execution, keep track of versions, incorporate updates into operations, and audit credentials placed in the terminal's environment variables. Details on permission design are summarized in Implementation Guide: Designing AI Agent Tool Execution Permissions with Least Privilege.

Here are answers to three questions commonly asked when making adoption decisions.

Q1. Is it better not to use vibe coding for business purposes?

It is effective if the use case is limited. In areas where "breaking something has no impact on production"—such as disposable prototypes, single-use internal tools, and investigation of existing code—productivity gains can be expected. What should be avoided is expanding into customer-facing features or authentication/payment systems without skipping verification. The criterion for judgment should not be technical but rather who is affected if something breaks.

Q2. What should be checked when reviewing code written by AI?

Look at "how it breaks," not "whether it looks correct." The priorities are five points: whether DB access control (such as RLS) is enabled, whether authentication and authorization are completed entirely on the server side, whether secrets are not included on the client side, whether public settings are as intended, and whether the reasoning behind decisions is recorded. Since AI performs particularly poorly on XSS and login injection, these should be caught by CI's SAST rather than by human eyes.

Q3. How should we prepare for vulnerabilities in the AI coding tools themselves?

The practical approach is to return to treating this the same as software asset management. In 2026, CVE-2026-35603 (Windows version of Claude Code below 2.1.75) and DuneSlide (Cursor below 3.0) were disclosed. Since numbering and remediation status differ by vendor, check individually against the versions your organization uses. List all adopted tools, assign someone responsible for updates, and periodically audit credentials placed in terminal environment variables.

When lining up the cases and data from 2026, the cause was not singular. In addition to insufficient verification of generated output, platform-side defects, vulnerabilities in the tools themselves, and misconfigurations in execution environments occurred separately, in different places.

• There is a pattern to how things break — missing access control (Moltbook), platform default settings and user configuration (RedAccess), platform-side regressions and failures in reporting processes (Lovable)
• What is being shared domestically is not an accident but a localized optimum — review time increased by 50% while throughput remained flat. However, after improvement measures, the number of PRs returned to about 1.5 times the original level (Findy)
• Model generation changes do not solve the problem — even including the latest flagship models, the benchmark pass rate is 55%. XSS is 15%, login injection is 13%
• Self-reported results and evaluations at the time of review diverge — 94% rated quality as high, while 82% reported experiencing production trouble
• In 2026, the tools themselves became an attack surface — 74 vulnerabilities were determined to involve AI (as of April 13, 2026), and privilege escalation and sandbox escape in development tools were also disclosed
• Countermeasures span three layers — delineating the scope of application, mechanical verification before and after generation, and separation of production permissions from the execution environment

Finally, one point on how to handle these cases. The way periods are counted, numerators and denominators, and the scope of CVEs often diverge between media reports and primary sources. Before using them for decision-making, always verify with primary sources. Wrong causal reasoning can only produce wrong countermeasures.

Also see AI Coding Agent Practical Guide — Claude Code vs Codex and Implementation Guide: Designing AI Agent Tool Execution Permissions with Least Privilege.