GITHUB COPILOT SECURITY RISKS: WHAT THE RESEARCH ACTUALLY SHOWS

What the research actually says

The number that follows Copilot around is “40% of suggestions are vulnerable.” That is a misquote. The source is Pearce et al.’s 2021 study “Asleep at the Keyboard,” and what it found is narrower and more useful: the authors built a set of scenarios specifically designed to elicit security-relevant code — SQL handling, credential storage, buffer operations, mapped to high-risk CWEs — and roughly 40% of the programs Copilot completed in those scenarios were vulnerable. It says nothing about your average autocomplete of a for-loop. It says a lot about what happens when Copilot completes the exact lines where security is decided.

Later research sharpened the picture rather than reversing it. Sandoval et al.’s user study (“Lost at C”) found that developers assisted by a code model didn’t introduce dramatically more security bugs than an unassisted control group on low-level C tasks. Perry et al.’s Stanford study (“Do Users Write More Insecure Code with AI Assistants?”) found participants using an assistant wrote less secure code on several tasks — and were more confident it was secure. Put together: the model’s raw output is risky in security-critical spots, the human filter helps less than people assume, and overconfidence is part of the mechanism.

So the honest framing is not “Copilot is 40% wrong.” It is: when the code being completed is security-sensitive, Copilot fails in specific, recurring, recognizable patterns. This page is the catalog of those patterns. For the IDE-level trust questions (telemetry, data retention, IP), see Is GitHub Copilot Safe?; for hardening your Copilot configuration, see the Copilot security setup and the step-by-step guide. This page covers the code itself.

Pattern 1: Propagation from surrounding context

Copilot is a continuation engine. Its strongest signal is not “what is secure” but “what does this file already look like.” If the file above the cursor concatenates SQL, the suggestion concatenates SQL. If a nearby test fixture contains a hardcoded key, the next suggestion hardcodes a key in the same shape.

// Existing code in the file, written months ago:
const user = await db.query(`SELECT * FROM users WHERE id = ${userId}`);

// Copilot's completion for the next query, matching local style:
const order = await db.query(`SELECT * FROM orders WHERE ref = '${orderRef}'`);

The second line is a textbook SQL injection, and it was caused by the first — the model amplified the worst pattern already in the file. This is the most important Copilot-specific behavior to internalize: one insecure line in a file becomes the template for every future suggestion in that file.

Fix. Clean the anchor, not just the suggestion. When you find one instance of an insecure pattern, fix every instance in the file before generating more code there — otherwise you are farming the same bug. Parameterize the legacy query, delete example credentials from fixtures Copilot can see, and use content exclusion for files you can’t clean. The BOLA-in-generated-CRUD pattern shows the same propagation mechanic applied to missing ownership checks.

Pattern 2: Training-data-era practices

Copilot’s training corpus spans fifteen-plus years of public code, and the median tutorial from that corpus predates modern defaults. So the model reaches for practices that were common when the training data was written: MD5 or SHA-1 for passwords, Math.random() for tokens, pickle.loads on untrusted input, JWT examples with weak or absent verification.

// Copilot completing "hash the password":
const hash = crypto.createHash("md5").update(password).digest("hex");

This compiles, runs, and looks like security. It is crackable at billions of guesses per second on commodity hardware. The same era-lag shows up as SSLv3/TLSv1 options, DES/ECB cipher modes, and http:// URLs in fetch calls.

Fix. Treat any crypto, token, or session code Copilot writes as guilty until proven current. Password hashing means bcrypt, scrypt, or argon2 via a maintained library; random tokens mean crypto.randomBytes / crypto.getRandomValues; JWT means jwt.verify() with an explicit algorithm allowlist — see JWT alg-none and kid traversal for how badly the old patterns fail.

Pattern 3: Hallucinated packages

Copilot suggests imports for packages that don’t exist. The names are plausible — a real package’s name with a word reordered, or a compound of two real names — and research on this behavior (Lanyado’s “AI package hallucination” work, and the 2024 “We Have a Package for You!” study across multiple models) found hallucinated names recur consistently enough that attackers can pre-register them on npm or PyPI. That attack even has a name now: slopsquatting. You npm install the suggested name, the attacker’s package installs cleanly, and its postinstall script runs with your credentials.

// Suggested import — the package does not exist upstream:
import { validateSchema } from "express-schema-validator";

Fix. Never install a package on the model’s word alone. Check the registry page first: publish date, weekly downloads, repository link that actually resolves. A package published last month with three downloads that exactly matches a Copilot suggestion is a red flag, not a coincidence. Run the Package Hallucination Scanner against your dependency list, and let lockfiles plus npm audit in CI catch what slips through.

Pattern 4: Placeholder secrets that ship

When completing config or client-initialization code, Copilot produces realistic-looking credentials: sk_live_...-shaped strings, AIza... keys, plausible AWS access key IDs. Two failure modes follow. First, the placeholder is left in place and the file establishes hardcoded-credential style — every future suggestion in that file inlines keys too (see Pattern 1). Second, a developer swaps the placeholder for the real key “just to test,” and it lands in git history.

// Copilot completing a Stripe client setup:
const stripe = new Stripe("sk_live_51Hxxxxxxxxxxxxxxxxxxxxxx");

Fix. The moment a suggestion contains a quoted string shaped like a credential, rewrite it to process.env.X before accepting — not after. Add a secret scanner (gitleaks or equivalent) as a pre-commit hook so the mistake can’t reach history, and check your deployed bundle with the Token Leak Checker. Any real key that ever touched a commit gets rotated, not deleted.

Pattern 5: Context-window conflicts with your security layer

Copilot sees a window of code, not your architecture. If your auth, validation, or sanitization lives in middleware defined in another file, the model doesn’t know it exists — so it either re-implements a weaker local version or writes a handler that quietly bypasses the central one.

// Project convention: all routes mount behind requireAuth in routes/index.js.
// Copilot, completing a new route in an isolated file:
app.get("/api/export/:userId", async (req, res) => {
  res.json(await getExportData(req.params.userId)); // no auth, no ownership check
});

The handler works in testing (the dev is logged in), reads naturally in review, and ships an unauthenticated endpoint that takes an arbitrary userId. The same mechanic produces duplicate sanitizers that disagree with the central one and CSRF-exempt routes that were never meant to be exempt.

Fix. Make the security layer visible to the model: keep the middleware import at the top of files where routes are defined, and put one correctly-guarded route above the cursor as the anchor. Structurally, prefer designs where the secure path is the only path — a router that applies requireAuth to everything mounted under it beats per-route discipline. Then verify at runtime: an authenticated-endpoint scan catches the route the review missed.

How this differs from Cursor-style tools

The patterns above are amplified by Copilot’s interaction model: many small inline completions, each individually too trivial to review, accepted at tab-key speed. Agent-style tools like Cursor fail differently — larger multi-file diffs where the dangerous change hides in a file you didn’t open. The Cursor risk profile covers that side; the taxonomy both feed into is in Vibe Coding Vulnerabilities.

The defense is the same three gates regardless of tool: review discipline tuned for AI-specific failure modes (AI Code Review Guide), secure prompting and instruction files (Secure AI Coding Practices), and a scan of the deployed app on every release — the Vibe Code Scanner tests for every pattern on this page from the outside.

Related resources

• Is GitHub Copilot Safe? — the IDE and platform-level review
• Copilot security setup — configuration hardening
• How to secure GitHub Copilot — step-by-step guide
• Cursor Security Risks — the same analysis for Cursor
• OWASP Top 10 for AI Code
• AI Code Vulnerabilities — the full vulnerability-class breakdown
• Package Hallucination Scanner — check your dependency list