TL;DR: A July 22-23, 2026 report from Xint.io, covered by SecurityWeek and Help Net Security, reviewed 28 AI-generated ("vibe-coded") applications and found 434 verified exploitable vulnerabilities after source-code review and runtime testing. The largest classes were resource exhaustion and denial of service (93), broken authorization and insecure direct object reference (88), and access boundary flaws including path traversal and SSRF (54). North Carolina small businesses that let sales, marketing, and operations teams ship AI-generated code without a review process are now shipping the same vulnerability patterns into customer-facing production systems.
Key takeaway: Vibe coding is not the problem, ungoverned vibe coding is. The 434-vulnerability finding shows that current AI coding assistants optimize for "the code works" and not "the code is safe to ship." Any NC business using Cursor, Copilot, v0, Lovable, or Bolt to build internal tools needs a written AI-code governance process, and the entry-level version costs less than one incident response engagement.
Worried about what your team has been shipping with Cursor or Copilot? Contact Preferred Data Corporation at (336) 886-3282 for an AI-assisted development risk review. We have been building custom software in High Point, NC since 1987, so we know what a defensible code review process looks like when the developer is a large language model.
What Are the "434 Vulnerabilities" and Where Did They Come From?
The 434 number comes from a July 2026 Xint.io analysis, summarized by Cybersecurity News, that took 28 AI-generated applications built across multiple AI coding assistants, workflows, and programming environments and put them through source-code review plus runtime testing. Every one of the 434 findings was verified as exploitable rather than theoretical, which is the number that matters for a High Point or Greensboro business owner deciding whether the risk applies to their internal apps.
The class breakdown reported by SecurityWeek and Help Net Security is what makes this study operationally useful. Resource exhaustion and denial of service accounted for 93 findings, broken authorization and insecure direct object reference accounted for 88, and access boundary issues including path traversal and server-side request forgery (SSRF) accounted for 54. Secrets exposure, injection, memory-safety, and weak cryptography rounded out the rest, and every category maps to something a small NC business has probably built with AI help in the last quarter.
Two facts frame why NC business owners in Charlotte, Raleigh, Winston-Salem, and the Piedmont Triad should care. First, GitGuardian's 2024 State of Secrets Sprawl reported more than 12.8 million new leaked secrets committed to public GitHub in 2024 alone, a 28% year-over-year jump that pre-dates the AI coding boom. Second, Sysdig Threat Research documented an autonomous AI ransomware agent exploiting Langflow CVE-2025-3248 in July 2026, meaning the attackers themselves are already using AI to hunt for exactly the classes of vulnerability that vibe-coded apps ship with by default.
Why Is Vibe-Coded Software So Predictably Vulnerable?
AI coding assistants are trained to produce code that runs, not code that survives a hostile internet, so their default output ships features first and controls later. When a marketing intern in Greensboro asks a chat interface to "build me a dashboard that shows leads from HubSpot," the assistant will happily emit a working Flask app without an authentication layer, without input validation, and with the API key pasted directly into the source file.
Three root causes explain why the 434 findings are not a fluke:
- Training incentive mismatch. The models were rewarded for code that compiles and passes basic tests, not for code that survives adversarial input, so the security posture regresses to the least secure examples in the training set. OWASP's Top 10 for LLM Applications documents this "insecure output handling" pattern as a foundational risk class.
- No threat model in the prompt. Business users describe features, not attackers. The assistant has no idea that the "internal" dashboard will end up exposed to a public URL because it was quicker to deploy to Vercel than to set up a VPN.
- Human review is missing or shallow. In a traditional engineering shop the code goes through a pull-request review by a second developer. In vibe-coded workflows the "reviewer" is often the same non-engineer who wrote the prompt, and the review consists of "does the page load."
The result is what NIST's AI Risk Management Framework calls a governance gap: the artifact ships fast but no one owns its security posture. In a 45-person High Point manufacturer this looks like an AI-generated PowerShell script that reads a domain admin credential in cleartext because that was the fastest way to make it work.
What Are the Four Most Dangerous Vulnerability Classes and What Do They Look Like in Real NC SMB Apps?
The four vulnerability classes that dominate the 434 total are not academic categories, they are the exact patterns a Piedmont Triad business will find in the "quick internal tools" its team has been shipping. The table below maps each class to the kind of app an NC SMB is most likely to have built with an AI assistant and what a real-world exploit looks like on the ground.
| Vulnerability class | Count in Xint.io study | Typical NC SMB vibe-coded app | What an attacker actually does |
|---|---|---|---|
| Resource exhaustion / DoS | 93 | Public quote-request form, PDF generator, image resizer | Sends 200 requests with 50MB payloads and takes the app offline for the day |
| Broken authorization / IDOR | 88 | Internal customer dashboard, invoice viewer, order status page | Changes the URL from /invoice/1042 to /invoice/1043 and reads a competitor's invoice |
| Access boundary / traversal / SSRF | 54 | Report exporter, avatar uploader, "fetch this URL" helper | Reads /etc/passwd, or forces the server to hit internal AWS metadata for credentials |
| Secrets exposure | Included in remaining findings | Any script or Next.js app that hard-codes API keys | Downloads the public repo, pulls the OpenAI or Stripe key, runs up a bill |
For a construction firm running an AI-generated punch-list app on jobsites in Charlotte and Raleigh, the IDOR class alone is a data-breach event: any authenticated user can iterate through project IDs and read every other client's job. For a manufacturer in the Triad exposing an AI-generated warranty portal, the SSRF class is a direct path from a "safe" public form to internal AWS metadata credentials, which is exactly the pivot OWASP documents in its 2021 Top 10 for SSRF (A10) with cited real-world breaches.
What Are NC Small Businesses Actually Building With AI Right Now?
Every NC business we talk to that says "we do not build software" is building software. The moment a marketing manager in Greensboro asks Lovable to spin up a lead-magnet landing page, or an ops director in High Point asks Cursor to generate a Python script that reconciles two exports, that business has become a software publisher without a security program.
The five patterns we see most often in the 100+ NC small businesses in PDC's service region:
- Sales dashboards from Cursor or Copilot that pull from HubSpot or Salesforce and render on an internal URL, usually without an auth layer beyond "you have to know the URL."
- Marketing landing pages and lead-capture forms from Bolt, Lovable, or v0 deployed to Vercel or Netlify, with form-submit handlers that email JSON to Slack and store secrets in client-side environment variables.
- Internal PDF and Excel generators built with ChatGPT or Claude and hosted in Google Apps Script or a small Flask container, ingesting customer PII with zero input validation.
- PowerShell scripts for shop-floor OT tasks generated by an AI assistant, run as domain admin, deployed via an RMM tool to hundreds of endpoints, reviewed by no one.
- Chatbot integrations against internal knowledge bases, often built by wiring an AI-generated Python script to an OpenAI or Anthropic API key, with the knowledge base exposed to the LLM in ways that violate the client's own data-handling policy.
The Backslash Security and Snyk research communities have both reported that AI-generated code is measurably more likely to contain hard-coded secrets and outdated dependencies than human-written code from the same organization. Combined with GitGuardian's 12.8 million leaked secrets figure, the base rate of "this code is going to leak something" is high enough that every one of the five patterns above needs a governance answer before the sixth pattern gets built.
What Is a Lightweight AI-Code Governance Model a 25-100 Seat NC Business Can Implement in 30 Days?
A 30-day AI-code governance rollout is realistic for any NC business with 25-100 employees, and it anchors to two publicly available frameworks so it also serves as compliance evidence. Use NIST SSDF SP 800-218 for the software development lifecycle controls and OWASP Top 10 for LLM Applications for the AI-specific attack surface. The plan below fits a manufacturer, a construction firm, or a professional-services shop in the Piedmont Triad without needing an in-house security team.
- Days 1-3: Inventory what has already been shipped. Every AI-generated app, script, and page. Include the sales dashboards, the Bolt landing pages, the shop-floor PowerShell, the Google Apps Script. Assign an owner to each.
- Days 4-7: Classify by blast radius. Three tiers: (T1) touches customer data or auth, (T2) runs on the shared network or production systems, (T3) local sandbox. T1 and T2 require review, T3 does not.
- Days 8-14: Stand up a minimum viable pipeline. GitHub or GitLab, protected main branch, required pull-request review, at least one SAST scan (Semgrep, CodeQL, or Snyk Code) and one secrets scan (GitGuardian, Gitleaks, or TruffleHog) blocking merge.
- Days 15-21: Write the two-page AI-code policy. Approved assistants, prohibited data classes in prompts (PHI, PII, credentials, source code covered by NDA), required review path for T1 and T2 apps, deployment approval process.
- Days 22-27: Roll out human-in-the-loop review for T1 and T2. Even a 30-minute review by a fractional security engineer or managed IT partner catches the IDOR, SSRF, and hard-coded secret findings that dominate the Xint.io report.
- Days 28-30: Run a tabletop. Simulate an incident where an AI-generated app leaked a customer record. Walk the response, the notification obligations, and the insurance call. Fix the gaps.
The NIST AI Risk Management Framework treats governance, mapping, measurement, and management as its four functions, and this 30-day plan operationalizes all four at SMB scale.
Key takeaway: A defensible AI-code governance program for a 40-person Triad business is a two-page policy, a required pull-request review with SAST plus secrets scanning, three risk tiers, and one tabletop exercise. That is the minimum, and it is enough to stop the top three vulnerability classes in the Xint.io study.
What Tools and Guardrails Belong in the AI-Assisted Developer's Pipeline?
The correct AI-development pipeline is not different from a mature human-development pipeline, it is the same pipeline applied without exception to code the humans did not write. The Xint.io study effectively confirms this: the classes of vulnerability it found are the exact classes that a standard secure SDLC catches when it runs.
The recommended stack for an NC SMB shipping AI-generated code:
- Source control with protected branches. GitHub or GitLab, no direct commits to main, required pull-request review by a named human.
- Static analysis (SAST) on every pull request. Semgrep or Snyk Code for general code, plus rules tuned for the languages the AI most frequently emits (Python, JavaScript, TypeScript, PowerShell).
- Software composition analysis (SCA). Dependabot, Snyk Open Source, or GitHub's advisory database, to catch the outdated and vulnerable dependencies that AI assistants pull in from their training data.
- Secrets scanning at commit time. GitGuardian, Gitleaks, or TruffleHog with pre-commit hooks and a server-side check, because AI-generated code hard-codes secrets more often than human-written code.
- Sandbox execution during development. GitHub Codespaces, GitPod, or a devcontainer, so the AI-generated script cannot reach production data or shop-floor systems until it has been reviewed.
- Separate production secrets. Doppler, AWS Secrets Manager, or HashiCorp Vault, so the moment a repo leaks it does not leak a live Stripe or QuickBooks key.
- Deployment approvals. No AI-generated code deploys to production without a named human clicking approve, no exceptions.
- Runtime monitoring. Managed cybersecurity with an EDR and SIEM that will actually see the exploitation attempt if the review process misses something.
None of this is exotic tooling, and none of it costs more than a mid-sized SaaS subscription. The Xint.io findings suggest the alternative, which is running unreviewed AI-generated code in production, is priced at "one incident."
Ready to stand up a defensible AI-code review pipeline? Contact Preferred Data Corporation at (336) 886-3282 or visit 1208 Eastchester Drive, Suite 131, High Point, NC 27265. We serve manufacturers, construction firms, and professional services across North Carolina within 200 miles of High Point.
How Does AI Code Governance Intersect With Cyber Insurance, NC ITPA, HIPAA, PCI DSS, and CMMC?
AI-generated code is not a separate compliance regime, it inherits every regime that applies to the data it touches. A vibe-coded internal dashboard that reads patient scheduling data is subject to HIPAA. A vibe-coded checkout page that touches card numbers is subject to PCI DSS. A vibe-coded workflow tool at a defense subcontractor in the Triad is subject to CMMC. In every case, the question a regulator or an insurer will ask is the same: who reviewed this code, when, and against what standard?
Four specific intersections NC business owners should plan around:
- Cyber insurance. Coalition and Corvus 2024 broker reports both flagged "insecure code in customer-facing applications" as a rising root-cause category and insurers are increasingly asking about secure SDLC controls at renewal. An AI-generated app that leaked data because no one ran SAST is exactly the kind of finding that leads to a coverage dispute.
- North Carolina Identity Theft Protection Act (NC ITPA). A breach involving NC resident PII triggers notification obligations regardless of whether the breached app was AI-generated, human-generated, or a purchased SaaS. Documentation of a governance program is what makes the incident defensible.
- HIPAA and 42 CFR Part 2. Any AI-generated app in a healthcare context needs a documented SDLC and access control review before it goes near PHI. AI-authored code without review is a Security Rule finding.
- CMMC 2.0. Defense-industrial-base subcontractors in North Carolina must document a secure development lifecycle. The Cybersecurity and Infrastructure Security Agency's Secure by Design pledge has already begun to normalize the expectation that this SDLC apply to AI-generated code the same as human-generated code.
For manufacturers, construction firms, and defense subcontractors in the Piedmont Triad, the safe posture is to treat AI-generated code as human-authored code for compliance purposes and to insist on the same review, testing, and documentation. That posture is also the cheapest way to keep insurance in force and audits clean.
Frequently Asked Questions
Our sales team is using Cursor to build "small" tools. Is that really software?
Yes. If the artifact runs on a computer, reads or writes data, or is used by more than one person, it is software and it inherits every risk that the term implies. The 434 findings in the Xint.io study came from apps that were almost all built as "small tools" by non-engineers, which is precisely why the vulnerability rate was so high.
We use OpenAI or Anthropic's API from a Python script. Is that considered "vibe coding"?
If a person wrote the Python script and understands what each line does, it is human-authored code that uses an AI service. If the script was mostly generated by ChatGPT or Claude with minimal review, it is vibe-coded and needs the same governance as any AI-generated app. The relevant question is not the runtime, it is who reviewed the code.
Should we ban AI coding assistants outright?
No, and any policy that tries to will fail. AI coding assistants are already delivering real productivity gains, and shadow-IT adoption will happen whether the policy allows it or not. The correct posture is approved assistants, tiered review by blast radius, and required tooling in the pipeline. Ban the practice of shipping AI-generated code without review, not the practice of using AI assistants.
What is the difference between AI-generated code and low-code / no-code platforms from a risk perspective?
Low-code and no-code platforms (Airtable, Retool, Zapier, Make) run inside a vendor's controls, so authentication, authorization, and secrets storage are handled by the platform. AI-generated code runs inside your controls, so every one of those responsibilities transfers to you. The risk is not comparable: low-code is closer to a SaaS purchase, vibe-coded software is closer to in-house development without the in-house developers.
Do we need to disclose "AI-authored" software in vendor questionnaires?
Increasingly, yes. Enterprise buyers in 2026 are adding "was any part of the codebase generated by AI, and if so what review process was applied" to vendor security questionnaires. Answering "we do not know" is now a red flag. Answering "yes, and here is our review pipeline" is a clean answer.
What is the cheapest defensible governance stack for a 25-person NC SMB?
GitHub Team or GitLab Premium, protected main branch, one SAST scanner (Semgrep Cloud or Snyk Code, both have free tiers), one secrets scanner (GitGuardian free or Gitleaks self-hosted), a two-page written AI-code policy, and a named human reviewer. Total software cost is typically well under $500 per month for a 25-person business, and it stops the majority of the vulnerability classes in the Xint.io report.
Does GitHub Copilot include indemnification? Does Cursor?
GitHub Copilot Business and Enterprise include Microsoft's copyright indemnification for suggestions accepted with the duplication filter enabled, per their published terms. Cursor's terms are different and evolve, and no vendor indemnifies you against security vulnerabilities in the code the assistant generates. Indemnification is a copyright shield, not a security shield.
Should we insist on SAST and SCA scanning in AI-generated pull requests?
Yes, without exception. AI-generated pull requests should be treated as a higher-risk category than human-authored pull requests, not a lower-risk one, because the author cannot answer questions in a review. Required SAST plus SCA plus secrets scanning on every AI-authored pull request is the minimum defensible standard for any NC business shipping AI-generated code to production in 2026.