3 posts tagged with "cybersecurity"

Meta Description: Vercel confirmed a security breach via third-party OAuth compromise. Here's what every developer and founder needs to know about protecting their secrets and supply chain attacks.

The Wake-Up Call Every Founder Needed​

On April 19, 2026, Vercel—one of the most critical infrastructure platforms for modern web development—disclosed a security breach that should send shivers down every founder's spine. The attack wasn't some sophisticated zero-day exploit. It was a textbook supply-chain attack via a compromised OAuth application.

Think about it: one compromised Google Workspace account at a third-party AI tool (Context.ai) led to unauthorized access to Vercel's internal systems. The attacker didn't need to break Vercel's encryption or bypass their defenses—they walked in through a side door that no one thought to lock.

If you're deploying on Vercel, running a startup, or managing any cloud infrastructure, you need to understand what happened, why it matters, and what you should do right now.

How the Attack Unfolded: A Supply Chain Nightmare​

The breach began when a Vercel employee's Google Workspace account was compromised through Context.ai, a third-party AI platform. The attacker gained access via a malicious OAuth application:

OAuth App: 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com

From there, the attacker escalated their access within Vercel's internal systems. Here's where it gets interesting: they discovered environment variables that weren't marked as "sensitive" in Vercel's system.

Vercel has a feature to designate environment variables as sensitive, which ensures they're encrypted at rest. But variables marked as non-sensitive—the ones intended for configuration data—were stored unencrypted. The attacker enumerated these variables and used them to gain further access.

This is a classic privilege escalation attack disguised as a configuration issue. The problem wasn't that Vercel failed to encrypt sensitive data—they did. The problem was that what developers thought was "non-sensitive" configuration data turned out to be a pathway to deeper access.

Why This Attack Is So Dangerous​

This breach exposes a fundamental vulnerability in how we think about third-party integrations and OAuth security:

1. The Trust Chain Problem

We implicitly trust OAuth applications. When we click "Authorize" on a third-party tool, we're granting access to our Google Workspace, GitHub, or other accounts. If that tool is compromised, the attacker inherits all the access we've granted.

2. The Configuration Blind Spot

Developers often treat environment variables as either "sensitive" (API keys, database passwords) or "non-sensitive" (API endpoints, feature flags). But configuration data can be just as valuable—internal service URLs, project identifiers, and deployment targets can reveal a system's architecture.

3. The Supply Chain Ripple Effect

A breach at one third-party vendor (Context.ai) compromised a major platform (Vercel), which potentially exposed countless applications deployed by Vercel's customers. The attack surface expands exponentially through the supply chain.

What You Should Do Right Now​

If you're deploying on Vercel or using similar cloud platforms, here's your immediate action list:

1. Rotate All Secrets​

This is non-negotiable. Even if Vercel says you're not affected, assume you might be. Rotate:

• Database credentials
• API keys (Stripe, OpenAI, Twilio, etc.)
• OAuth tokens
• Private keys
• Any secret stored in environment variables

2. Review Your OAuth Permissions​

Go to your Google Workspace, GitHub, and other OAuth providers. Review every third-party application with access. Revoke anything you don't recognize or no longer use.

3. Audit Your Environment Variables​

Log into Vercel (or your platform of choice) and review every environment variable:

• Mark anything that could be used for access as "sensitive"
• Remove unused variables
• Audit the values—look for internal URLs, project IDs, or identifiers that could aid an attacker

4. Enable Vercel's Sensitive Variable Feature​

Vercel has a feature that encrypts sensitive environment variables at rest. Use it. For any variable that contains secrets, authentication data, or internal infrastructure details, mark it as sensitive.

5. Implement Secret Rotation Policies​

Don't wait for a breach. Rotate secrets regularly—every 90 days for high-risk credentials, every 6 months for others. Automate this where possible.

The Bigger Lesson: Defense in Depth Is Non-Negotiable​

Vercel did a lot of things right: they had encryption for sensitive data, defense-in-depth mechanisms, and a rapid incident response. But the attack still succeeded because one layer of defense—OAuth application security—was outsourced to a third party.

This is why security best practices matter:

• Zero Trust: Never assume any component is safe, even if it's from a trusted vendor
• Least Privilege: Grant the minimum access necessary
• Audit Regularly: You can't protect what you don't know about
• Assume Breach: Design your systems assuming an attacker already has some access

What Vercel Is Doing Right​

To Vercel's credit, they've handled this well:

• Immediate disclosure and transparent communication
• Clear guidance for affected customers
• Rolling out security updates (new environment variable overview, improved sensitive variable management)
• Confirmation that open-source projects (Next.js, Turbopack) remain safe

This is how security incidents should be handled. No hiding, no deflection—just facts, guidance, and action.

The Future of Cloud Security​

This breach isn't unique to Vercel. It could happen to any platform that relies on OAuth integrations. As we build more interconnected systems, the attack surface grows.

The future of cloud security lies in:

• OAuth hardening: More granular permissions, better auditing, automated revocation
• Secret management: Dedicated secret managers (AWS Secrets Manager, HashiCorp Vault) instead of environment variables
• Supply chain security: Security reviews for every third-party integration
• Automated rotation: Tools that automatically rotate secrets before they can be exploited

Conclusion​

The Vercel breach is a wake-up call, not a reason to abandon cloud development. The platform remains one of the best options for deploying modern applications—but this incident reminds us that security is a process, not a product.

Rotate your secrets. Review your OAuth apps. Audit your environment variables. And never assume that "non-sensitive" means "harmless."

The attacker didn't exploit a bug in Vercel's code—they exploited a blind spot in how we think about security. Close that blind spot before someone else walks through it.

FAQ Section​

Q: Was my Vercel project affected by the breach? A: Vercel states that only a "limited subset of customers" were affected. However, if you're not sure, the safest approach is to rotate all your secrets as a precaution.

Q: What's the difference between sensitive and non-sensitive environment variables in Vercel? A: Sensitive environment variables are encrypted at rest and have additional protections. Non-sensitive variables are stored unencrypted and intended for configuration data—but they can still contain valuable information for attackers.

Q: How often should I rotate my API keys and secrets? A: High-risk credentials (database passwords, production API keys) should be rotated every 90 days. Lower-risk credentials can be rotated every 6 months. Automate this process where possible.

Q: Is it safe to keep using Vercel after this breach? A: Yes. Vercel has responded transparently, patched the vulnerability, and implemented additional security measures. No platform is immune to attacks—what matters is how they respond, and Vercel's response has been exemplary.

Q: How can I check if a malicious OAuth app has access to my accounts? A: Go to your Google Workspace admin console, GitHub settings, or other OAuth providers. Look for applications you don't recognize or no longer use. Vercel has published the specific OAuth app ID to watch for: 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com

About the Author​

Arkin Julijanto is a founder and full-stack developer building Orbits Studio, a clip farming marketplace connecting creators with brands. He writes about development, security, and the founder journey. You can find him on Twitter @Arkinej.

Meta Description: NIST is no longer enriching most CVEs. Here's why the NVD backlog forced this change and what your dev team needs to do about it now.

The Single Source of Truth Just Stopped Being One​

On April 15, 2026, the US National Institute of Standards and Technology (NIST) made a quiet but seismic announcement: it will no longer enrich most CVE entries in the National Vulnerability Database (NVD).

This isn't a temporary measure or a funding delay. It's a structural capitulation. The agency admitted it cannot keep up with the volume of vulnerabilities being reported, and under current budgetary constraints, it never will.

If your team's security tooling, vulnerability scanning, or patch prioritization relies on NVD data — and most do — this affects you directly.

How We Got Here​

The NVD backlog started in early 2024. A handful of unprocessed CVE entries — around 2,100 — ballooned into nearly 30,000 by year-end. Despite efforts to catch up, the gap kept growing.

The numbers tell the story:

• 2025: CVE submissions increased by 263%
• 2025: NIST enriched 45% more CVEs than the previous year
• Result: They still fell further behind

Two structural forces made this inevitable. First, the sheer explosion of vulnerability disclosures — over 48,000 CVEs were assigned in 2025 alone. Second, budget cuts to DHS and CISA under the current administration reduced NIST's capacity to process them.

Then there's the incoming wave: AI-powered vulnerability scanners are expected to flood the system with even more disclosures, many of which will be low-quality "CVE chaff" — real but trivial bugs in obscure libraries with 100 GitHub stars.

NIST's solution is a triage approach. Going forward, they'll only enrich three categories of CVEs:

1. CVEs listed in CISA KEV — vulnerabilities known to be actively exploited
2. CVEs in software used by US federal agencies
3. CVEs in "critical software" — OS, browsers, security tools, firewalls, VPNs, backup software

Everything else gets added to NVD as a bare entry — no independent analysis, no enriched metadata, no verified severity scoring.

What Breaks When NVD Stops Being Complete​

The immediate impact falls on the vulnerability management industry. Companies that built scanners, dashboards, and reporting tools on top of NVD data are now working with an incomplete dataset.

False negatives in your tools. If a CVE isn't enriched by NIST, most tools won't surface it. Your team won't be alerted. The scanner says "all clear" — but it's only checking a shrinking pool of analyzed vulnerabilities.

Self-reported severity scores. NIST will stop providing independent CVSS scores and instead display whatever the CVE submitter assigned. Here's the problem: many CVE submitters are the vendors whose software has the vulnerability. There's a long history of vendors downgrading their own severity scores to minimize impact. Without NIST's independent assessment, this becomes the default.

The "not scheduled" black hole. The existing backlog is being moved to a status that essentially means "we might get to it someday." For security teams tracking specific CVEs in that backlog, this is a dead end.

As Sooraj Shah from Aikido Security put it: "The era of relying on one database as a source of truth is officially over."

The Deeper Problem: CVEs Were Never Enough​

The NVD change is significant, but it exposes a vulnerability management problem that existed long before this announcement.

CVEs only cover what gets formally disclosed. Maintainers — even at major vendors — regularly fix security issues without reporting them. Silent patches, vague changelog entries, and "miscellaneous bug fixes" that are actually security vulnerabilities are common.

Aikido Security's data backs this up: in 2024, 67% of packages where they found vulnerabilities through changelog and commit analysis were never publicly disclosed to any database — not NVD, not GitHub Advisory, not MITRE, nowhere.

The Axios prototype pollution vulnerability (affecting a library with 56 million weekly npm downloads) was silently patched without disclosure. This is not an edge case.

The NVD shrinking its coverage just makes an existing gap more visible.

What Your Team Should Do Now​

If you've been treating NVD as your primary vulnerability intelligence source, you need to diversify. Here's a practical approach:

1. Multi-Source Your Vulnerability Intelligence​

Stop relying on a single database. Layer multiple sources:

• CISA KEV — actively exploited vulnerabilities (high signal)
• GitHub Advisory Database — open-source specific, often faster than NVD
• EUVD — the EU's emerging vulnerability database (nascent but growing)
• Vendor security advisories — direct from the source
• Package manager alerts — npm audit, pip audit, Snyk, Dependabot

2. Invest in Changelog and Commit Monitoring​

Tools that analyze changelogs, release notes, and commit messages can catch silent patches before they're formally disclosed. If your dependency management doesn't include this layer, you're flying blind on the majority of real vulnerabilities.

3. Contextualize, Don't Just Count​

The NVD change actually reinforces a best practice: stop treating all CVEs equally. Focus on:

• Exploitability: Is there a known exploit in the wild? (KEV-listed)
• Reachability: Is the vulnerable code path actually reachable in your application?
• Business impact: What's the blast radius if this vulnerability is exploited?

A thousand low-severity CVEs in dependencies you barely use matter less than one actively exploited vulnerability in your authentication library.

4. If You Build Security Tooling​

If your product ingests NVD data, you need to:

• Accept that NVD coverage will shrink over time
• Build enrichment pipelines that combine NVD with other sources
• Consider using LLMs to analyze changelogs and patches directly (this is what the next generation of vulnerability intelligence tools are doing)
• Surface confidence levels — be honest with users about what's verified vs. unverified

The Startup Opportunity​

This is a rare moment where a government infrastructure gap creates a real market opportunity. The vulnerability intelligence space is about to get competitive:

• Multi-source aggregation — tools that unify CVE, advisory, changelog, and dark web intelligence
• AI-powered enrichment — using LLMs to independently assess vulnerability severity and impact when NIST won't
• Developer-first security — shifting from "here's a list of 500 CVEs" to "here are the 3 that actually matter in your codebase"

The companies that solve for NVD's gap won't just replace it — they'll build something better.

FAQ​

Q: Will NIST stop publishing CVEs entirely? A: No. All CVEs will still be added to the NVD. The change is about enrichment — the detailed metadata, independent severity scoring, and cross-referencing that makes the data useful. Most new CVEs will exist as bare entries without analysis.

Q: Which CVEs will NIST still enrich? A: Three categories: CVEs in CISA's Known Exploited Vulnerabilities catalog, CVEs in software used by US federal agencies, and CVEs in "critical software" including operating systems, browsers, security tools, firewalls, VPNs, and backup software.

Q: Why can't NIST just get more funding? A: The Trump administration's cuts to DHS and CISA budgets have constrained NIST's capacity. Combined with a 263% increase in CVE submissions, the gap between resources and demand became unbridgeable without a structural change in approach.

Q: What's the risk of self-reported CVSS scores? A: Vendors who issue CVEs for their own software often assign lower severity scores than independent analysts would. Without NIST's independent scoring, the default becomes whatever the vendor says — creating an incentive to downplay vulnerabilities.

Q: How should small dev teams adapt? A: Enable automated dependency scanning (Dependabot, Snyk, or npm audit), monitor CISA KEV for critical vulnerabilities, and subscribe to security advisories for your core dependencies. You don't need enterprise tooling — just multiple sources instead of one.

Meta Description: Anthropic's Mythos found thousands of zero-days — but small open models recovered the same analysis at a fraction of the cost. The moat in AI security is the system, not the model.

The Mythos Moment​

On April 7, 2026, Anthropic announced Claude Mythos Preview and Project Glasswing — a $100M+ initiative to use a frontier AI model to autonomously find and patch zero-day vulnerabilities in critical software. The results were staggering: thousands of vulnerabilities across every major OS and web browser, including a 27-year-old bug in OpenBSD and a fully autonomous remote code execution exploit against FreeBSD.

It was a watershed moment for AI cybersecurity. The narrative was clear: you need the biggest, most expensive model to do real security research.

Then AISLE ran the same vulnerabilities through small, cheap, open-weights models.

The results? 8 out of 8 small models detected Mythos's flagship FreeBSD exploit. One of them had only 3.6 billion active parameters and costs $0.11 per million tokens. A 5.1B-active parameter model recovered the core exploitation chain of the 27-year-old OpenBSD bug.

This changes the conversation entirely.

What AISLE Actually Tested​

AISLE took the specific vulnerabilities Anthropic showcased in their Mythos announcement, isolated the relevant code, and ran them through a range of small and open-weights models. Three tests stood out:

Test 1 — FreeBSD NFS Remote Code Execution (CVE-2026-4747): Mythos's crown jewel — a 17-year-old bug giving unauthenticated root access via NFS. Every single model they tested, from Kimi K2 to Qwen3 32B to a tiny GPT-OSS-20b (3.6B active params), correctly identified the stack buffer overflow and assessed it as critical. Detection was commoditized.

Test 2 — OpenBSD SACK Analysis (27-year-old bug): This one required mathematical reasoning about signed integer overflow. Much harder. Most models struggled — but GPT-OSS-120b (5.1B active) recovered the full public chain. Kimi K2 got close with an A- grade.

Test 3 — OWASP False Positive Discrimination: A Java servlet that looks like SQL injection but isn't. This is the test that flipped the script entirely — small, cheap models outperformed frontier models. Claude Sonnet 4.5 confidently mistraced the data flow. GPT-OSS-20b at $0.11/M tokens got it right. DeepSeek R1 nailed it across four trials. OpenAI o3 gave the most nuanced answer of all.

The pattern is clear: there is no stable "best model for cybersecurity." The capability frontier is jagged. Rankings reshuffle completely depending on the task.

Why This Matters for Developers and Security Teams​

The Mythos narrative suggests you need a frontier model — expensive, proprietary, limited access — to do meaningful AI security work. The evidence says otherwise.

Here's what the AISLE research actually demonstrates:

• Detection is cheap. A $0.11/M token model can spot a critical buffer overflow just as well as a model that costs 50-100x more. The FreeBSD exploit was detected by every model tested, regardless of size.
• The system is the moat, not the model. Anthropic's own scaffold — launch containers, scan files, use ASan as a crash oracle, rank by attack surface, run validation — is the same kind of system others in the field have built. The value is in the orchestration, targeting, and validation pipeline, not the specific model.
• Coverage beats precision. Because small models are sufficient for most detection work, you can deploy them broadly across entire codebases instead of carefully rationing an expensive model. A thousand adequate detectives searching everywhere will find more bugs than one brilliant detective guessing where to look.
• False positive management is the real differentiator. The OWASP test showed that bigger models often worse at distinguishing real vulnerabilities from false alarms. In production security systems, drowning reviewers in noise is worse than missing some bugs — it's what killed curl's bug bounty program.

The Bigger Picture: AI Security Economics​

This research has implications beyond vulnerability research:

For startups and indie security teams: You don't need to wait for Mythos-level access or budget. Open-weights models wrapped in good engineering can produce production-grade results. AISLE has been doing exactly this since mid-2025 — 180+ externally validated CVEs across 30+ projects, including 15 CVEs in OpenSSL.

For the open-source ecosystem: The security of critical infrastructure shouldn't depend on a single company's proprietary model. When small open models can detect the same bugs, it democratizes security research and makes the ecosystem more resilient.

For AI strategy: The "jagged frontier" phenomenon isn't limited to cybersecurity. It suggests that across many specialized domains, the relationship between model size and capability is non-linear. Smart system design can compensate for — or even outperform — raw model scale.

What Good AI Security Systems Actually Need​

Based on AISLE's production experience, here's what matters more than model size:

• Targeting intelligence: Knowing which files and functions to examine in a codebase with hundreds of thousands of files
• Iterative validation: Hypothesis → test → refine loops that separate real bugs from noise
• Maintainer trust: The metric that actually matters is whether project maintainers accept your findings and patches
• Full-loop remediation: Discovery is only the first step. Verification, severity assessment, patch generation, and coordination close the loop

The OpenSSL CTO praised AISLE's work for "high quality reports and constructive collaboration throughout remediation." That trust is earned through the system, not the model.

Conclusion​

Anthropic's Mythos proved that AI cybersecurity is real and here. AISLE's research proved it doesn't require a monopoly.

The frontier is jagged. Small models can do big things when wrapped in the right system. For developers, security teams, and anyone building AI-powered tools, the takeaway is empowering: you don't need the biggest model. You need the best system.

The economics of AI security just got a lot more interesting — and a lot more accessible.

FAQ​

Q: Can small AI models really replace frontier models for security research? A: Not replace — complement. AISLE's research shows small models can detect many of the same vulnerabilities as frontier models at a fraction of the cost. But the full pipeline (discovery, triage, validation, remediation) requires orchestration. The system matters more than any individual model.

Q: What is the "jagged frontier" in AI cybersecurity? A: It means AI capability doesn't scale smoothly with model size. A tiny 3.6B-parameter model might outperform a frontier model on one task and fail completely on another. There's no single "best" model across all cybersecurity tasks — rankings reshuffle depending on what you're testing.

Q: How are companies using small AI models for vulnerability detection? A: AISLE has been running a production system since mid-2025 using model-agnostic pipelines. They've found 180+ externally validated CVEs across 30+ projects including OpenSSL and curl. Their approach deploys cheap models broadly for coverage rather than rationing expensive models selectively.

Q: Should I use open-weights models instead of proprietary ones for security tooling? A: It depends on your use case. For detection and triage, open-weights models are often sufficient and far more cost-effective. For complex exploit construction requiring multi-step reasoning, larger models may still have an edge. The best approach is model-agnostic — use whatever works best for each specific task.

About the Author: Arkin is a software engineer and startup founder building Orbits Studio. He writes about AI, developer tools, and the intersection of technology and security. Find him at arkin-dev.com.