17 posts tagged with "open-source"

Meta Description: Cal.com just abandoned open source after 5 years, blaming AI-driven security threats. Here's why this matters for every startup betting on OSS — and what founders should learn from it.

The Open Source Darling Just Closed Its Doors​

Cal.com — the scheduling platform that built its entire brand on being "the open source Calendly alternative" — just announced it's going closed source. After five years. The post went up on April 14, 2026, and the Hacker News thread exploded immediately.

The reason? AI-powered security scanning.

In their own words: "Being open source is increasingly like giving attackers the blueprints to the vault."

They're not entirely wrong. But they're also not telling the whole story.

What Actually Happened​

Here's the core argument from Cal.com CEO Bailey Pumfleet:

1. AI can now systematically scan open source codebases for vulnerabilities — what used to require a skilled hacker with weeks of patience can now be done by pointing an AI at a public repo
2. AI security startups are productizing this — multiple platforms now offer automated vulnerability discovery, each surfacing different issues, creating chaos around what's "actually secure"
3. AI found a 27-year-old vulnerability in BSD kernel — and generated working exploits in hours, demonstrating how even battle-tested code is now exposed
4. Their production codebase had significantly diverged — including major rewrites of auth and data handling, meaning the public repo wasn't even their real code anymore

Their solution: close the source, release a separate MIT-licensed version called Cal.diy for hobbyists, and hope the community accepts the split.

The Community Reacts — And It's Not Pretty​

The Hacker News reaction was swift and divided:

The defenders argue this is pragmatic. If AI makes every vulnerability findable, open source becomes a liability for companies handling sensitive data (scheduling = calendar data = meeting participants = business intelligence).

The critics see it differently:

• This was always the plan — build community and trust with OSS, then pull the rug
• "Security" is a convenient justification for what's really a business model pivot
• The code had already diverged from the public repo, meaning the "open" part was already hollow
• Cal.diy is essentially a maintenance dump, not a genuine community project

The truth is probably somewhere in the middle. But the pattern is undeniable.

The Open Source Bait-and-Switch Pattern​

Cal.com isn't the first to do this. It's become a recognizable playbook:

1. Launch as open source — Get free marketing, community contributions, developer trust, and HN/Reddit love
2. Build enterprise features — Use the community as a funnel for paid tiers
3. Diverge the codebase — The public repo becomes a shadow of the real product
4. Go closed source — Cite "security" or "sustainability" as the reason
5. Release a "community edition" — A stripped-down version to soften the blow

We've seen variations of this with HashiCorp (Terraform → BSL), Elasticsearch (SSPL), and now Cal.com. Each time, the community that helped build the product gets left with a forked, maintenance-mode version.

This isn't a coincidence. It's a business model.

Why AI Security Is a Real (But Incomplete) Argument​

To be fair to Cal.com, the AI security concern is legitimate:

• Automated vulnerability scanning is now trivial. Tools can probe an entire codebase in minutes, not months. The "many eyes make bugs shallow" argument assumes those eyes are friendly. AI doesn't discriminate.
• Zero-day discovery is accelerating. The BSD kernel example Cal.com cites — a 27-year-old vulnerability found and exploited in hours — is real. That's terrifying for any security-conscious team.
• The attack surface is asymmetric. Defenders need to fix every vulnerability. Attackers only need to find one. Open source makes that asymmetry worse.

But here's what's incomplete about the argument:

• Security through obscurity doesn't work. Closed source code still has vulnerabilities — they're just harder for good-faith researchers to find and report. You lose the "many eyes" benefit while attackers still reverse-engineer.
• Cal.com's production code had already diverged. The public repo wasn't the attack surface anymore. The "security" argument applies more to the principle than their actual risk.
• The timing is suspicious. This happened right after major enterprise feature launches. The security justification came after the business decision.

What This Means for Founders Building on Open Source​

If you're a founder or developer, Cal.com's move should make you rethink a few things:

1. Don't Build Your Business on Someone Else's Open Source Promise​

If your product depends on an open source tool that could go closed, you need an exit plan. Cal.com users who self-hosted are now stuck on a diverged codebase with no clear upgrade path.

2. Open Source Is a Strategy, Not a Religion​

Cal.com used OSS brilliantly for growth. They got years of free distribution, community goodwill, and contributor labor. Going closed is a rational business move — but let's call it what it is, not dress it up as purely a security decision.

3. License Matters More Than You Think​

Cal.com used AGPL v3, which has strong copyleft requirements. Their move to closed source means they can now monetize without contributing back. If you're choosing an OSS dependency, check the license and the company's trajectory, not just the GitHub stars.

4. Community Trust Is a One-Way Door​

Once you break trust with your open source community, you don't get it back. Cal.diy might keep hobbyists happy, but the developers who contributed PRs, filed issues, and evangelized the product? They're gone. That's a real cost that doesn't show up on a balance sheet.

5. The "AI Security" Argument Will Be Used Again​

Expect more companies to follow Cal.com's playbook. AI-driven security is a legitimate concern, and it's a convenient, hard-to-argue-against justification for going closed. If you're evaluating OSS tools for your stack, factor in the risk of this happening.

Is Open Source Dead for SaaS?​

No. But the landscape is shifting:

• True community-driven projects (Linux, PostgreSQL, Kubernetes) are fine — they're not owned by a single company chasing VC returns
• VC-backed open source SaaS is the vulnerable category — the incentives eventually conflict
• New models are emerging — BSL (Business Source License), SSPL, and custom licenses try to balance openness with sustainability, but they all face community pushback

The Cal.com case is a warning: open source is not a permanent feature of a product. It's a phase. Plan accordingly.

Conclusion​

Cal.com went closed source. They blamed AI security. The community is split. And the pattern will repeat.

For founders: use open source, contribute to open source, but never bet your business on someone else's open source staying open. The license can change. The code can diverge. The promises can break.

Build on foundations you control. Contribute to the commons. But keep your escape route ready.

FAQ​

Q: Why did Cal.com go closed source? A: Cal.com cited AI-driven security threats as the primary reason, arguing that open source codebases are now easier to exploit with AI vulnerability scanners. Critics note the company's production code had already diverged from the public repo and the timing coincides with enterprise feature launches.

Q: What is Cal.diy? A: Cal.diy is the MIT-licensed, community-driven version of Cal.com released alongside the closed-source transition. It's based on an older, diverged version of the codebase and is intended for hobbyists and self-hosters.

Q: Can a company legally change from open source to closed source? A: Yes, for future releases. Existing open source code remains under its original license — users can still fork and use the last open version. But new features, updates, and bug fixes can be released under a closed license. Cal.com retained the right to relicense their own code.

Q: Is "security through obscurity" effective? A: Not as a primary strategy. Most security professionals agree that obscurity can be a layer but should never be the only defense. Closed source doesn't prevent vulnerabilities — it just changes who can find them. You lose the benefit of community security review.

Q: What should I do if my stack depends on a tool that might go closed source? A: Evaluate the license, the company's funding trajectory, and whether a viable fork exists. Consider contributing to community forks. Maintain your own patches if needed. And always have a migration plan ready.

About the Author: Arkin is a startup founder and developer building Orbits Studio, a UGC marketplace platform. He writes about open source, AI, and the business of building software.

The open-source movement hit a wall today — and AI is the bulldozer. Cal.com, once the darling of open-source SaaS, just went closed source, citing AI-driven security threats. Google quietly handed a student's data to ICE without notice, breaking a decade-old promise. And the tools meant to protect us are the same ones being weaponized. This tech news roundup covers the stories that matter most to builders, founders, and anyone paying attention to where trust is eroding in tech.

Meta Description: An attacker bought a 30-plugin WordPress portfolio on Flippa and injected backdoors into every one. Here's how it happened, why it matters, and what every developer should learn from it.

The Attack You Don't See Coming​

Imagine waking up to find that a plugin you've trusted for years — one with hundreds of thousands of installs — has been quietly owned for eight months. Not by a zero-day exploit. Not by a clever hack. But because someone literally bought the company that made it.

That's exactly what happened in April 2026. A buyer who goes by "Kris" purchased a portfolio of 30+ WordPress plugins from their original creators through Flippa, a marketplace for buying and selling online businesses. The very first code commit after the acquisition? A backdoor.

WordPress.org had to close all 31 plugins in a single day. Hundreds of thousands of websites were affected. And the most chilling part: the malware sat dormant for eight months before anyone noticed.

If you build software, maintain dependencies, or run any kind of web property, this story is a masterclass in why supply chain security is the threat most teams still aren't taking seriously.

How the Whole Thing Unfolded​

The Original Creators​

The plugins were built by an India-based team operating under "WP Online Support" starting around 2015. Minesh Shah, Anoop Ranawat, and Pratik Jain grew a portfolio of 30+ free WordPress plugins with premium upsells — things like countdown timers, galleries, sliders, and FAQ widgets. They later rebranded to "Essential Plugin."

By late 2024, revenue had dropped 35-45%. Running a WordPress plugin business is hard — maintaining free plugins, dealing with support, competing with page builders eating your lunch. So Minesh listed the whole business on Flippa.

The Acquisition​

A buyer identified only as "Kris" — with a background in SEO, crypto, and online gambling marketing — bought the entire portfolio for six figures. Flippa even published a case study about the sale in July 2025, celebrating it as a success story.

The new owner created a fresh WordPress.org account ("essentialplugin") and began updating the plugins. On paper, everything looked normal. Plugin updates, compatibility fixes, the usual changelog entries.

The First Commit Was the Backdoor​

On August 8, 2025, version 2.6.7 of Countdown Timer Ultimate was released. The changelog read: "Check compatibility with WordPress version 6.8.2." Clean, boring, the kind of update no one looks twice at.

What the update actually did was add 191 lines of code to class-anylc-admin.php, growing it from 473 to 664 lines. Three new capabilities were introduced:

• A fetch_ver_info() method that called file_get_contents() on the attacker's server and passed the response to @unserialize() — a classic PHP deserialization vector
• A version_info_clean() method that executed @$clean($this->version_cache, $this->changelog) where all three values came from the unserialized remote data — a textbook arbitrary function call
• An unauthenticated REST API endpoint with permission_callback: __return_true — meaning anyone could hit it without logging in

The remote server controlled the function name, the arguments, everything. And it sat there for eight months, dormant, waiting.

The Weaponization​

On April 5-6, 2026, the sleeping backdoor woke up. The plugin's wpos-analytics module phoned home to analytics.essentialplugin.com, downloaded a file called wp-comments-posts.php (deliberately named to look like WordPress core's wp-comments-post.php), and used it to inject a massive block of PHP into wp-config.php.

The injected malware was sophisticated:

• It fetched spam links, redirects, and fake pages from a command-and-control server
• It only showed spam content to Googlebot — making it completely invisible to site owners browsing their own site
• The C2 domain resolved through an Ethereum smart contract, querying public blockchain RPC endpoints — meaning traditional domain takedowns were useless because the attacker could update the smart contract to point to a new domain at any time

Using blockchain for C2 infrastructure is next-level. There's no registrar to subpoena, no hosting provider to send a takedown to. The domain resolution is decentralized by design.

The Forensic Discovery​

Mike Schroder from CaptainCore discovered the attack through backup forensics. By extracting wp-config.php from daily restic backups across eight different dates, he tracked the file size changes:

• November 2025 through April 5, 2026: ~3,345 bytes (normal)
• April 7, 2026: 9,540 bytes (injected)

The injection happened in a 6-hour 44-minute window on April 6, 2026. A normal update that no one would question triggered the payload that had been sleeping for eight months.

Here's the kicker: WordPress.org pushed a forced update (v2.6.9.1) that neutralized the phone-home mechanism in the plugin. But it did not clean wp-config.php. The SEO spam injection was still actively serving hidden content to Googlebot even after the "fix."

Why This Matters Beyond WordPress​

You might be thinking, "I don't use WordPress plugins, so I'm fine." You're not. This attack pattern applies to every software ecosystem:

1. Your Dependencies Are Your Attack Surface​

Every npm package, every pip library, every NuGet dependency, every WordPress plugin — you're trusting the maintainer. When that maintainer changes (sell, burn out, get compromised), your trust model breaks. The event-stream incident in npm, the ua-parser-js hijack, and now this — the pattern is the same.

2. Dormant Backdoors Are Nearly Undetectable​

The code sat there for eight months doing nothing. No suspicious network traffic. No anomalous file writes. No triggers for any security scanner. The malicious code was structured to look like a legitimate analytics module. How many dormant backdoors are sitting in your node_modules right now?

3. Acquisition Is the New Attack Vector​

Buying a legitimate business to weaponize its user base is a supply chain attack that doesn't require any technical exploitation. It's purely social and economic. If you maintain popular open-source software, think about what happens if someone buys your project — or your contributor's project, or the project you forked from.

4. Auto-Updates Are a Double-Edged Sword​

WordPress auto-updates pushed the compromised code to hundreds of thousands of sites automatically. The mechanism designed to keep users safe was weaponized against them. This is the paradox of auto-updates: they protect you from known vulnerabilities but increase your exposure to supply chain attacks.

Practical Steps to Protect Yourself​

For Developers and Founders​

• Audit your dependency tree regularly. Not just direct dependencies — transitive ones too. Tools like npm audit, pip-audit, or Snyk can help, but they only catch known vulnerabilities, not intentional backdoors.
• Pin your dependencies. Don't auto-update production dependencies. Review changelogs before upgrading. If a "compatibility fix" adds 191 lines of code, that's a red flag.
• Monitor file integrity. Set up alerts for unexpected changes to critical files (wp-config.php, .env, config files, entry points).
• Use lockfiles religiously. package-lock.json, poetry.lock, yarn.lock — these are your safety net against silent dependency mutations.

For WordPress Site Owners​

• Remove plugins you're not actively using. Every installed plugin is a potential attack vector.
• Check who maintains your plugins. If ownership recently changed, verify the new maintainer's credibility.
• Monitor wp-config.php and core files. Use file integrity monitoring (Wordfence, Sucuri, or CaptainCore's backup forensics approach).
• Don't blindly trust auto-updates. Especially for plugins from small or recently acquired teams.

For Open-Source Maintainers​

• Add transfer policies to your project. Document what happens if you sell or hand off the project. Some projects now include clauses in their governance docs preventing sale without community review.
• Sign your releases. GPG signatures on tags and releases make it harder for a new owner to quietly inject malicious code.
• Make your code reviewable. If your changelogs are honest and your commits are readable, the community can catch anomalies faster.

The Bigger Picture​

The WordPress plugin ecosystem is uniquely vulnerable because of its size and update mechanics. There are over 60,000 plugins in the WordPress.org directory. Most are maintained by small teams or solo developers. Many generate modest revenue. The economics of selling a declining plugin business are real, and buyers with malicious intent can exploit that.

But the core lesson isn't about WordPress. It's about trust in software supply chains. When you install a dependency, you're trusting not just the current version of the code — you're trusting the maintainer's future decisions, their financial stability, and their integrity.

In 2026, supply chain attacks are no longer theoretical. They're a business model. Someone literally bought a company just to backdoor its customers. If that doesn't make you reconsider your dependency strategy, nothing will.

FAQ​

Q: How many websites were affected by this WordPress plugin backdoor? A: The 31 closed plugins had hundreds of thousands of combined active installations. The exact number of compromised sites is still being determined, as the backdoor only activated in April 2026 after lying dormant since August 2025.

Q: What should I do if I had any Essential Plugin plugins installed? A: Immediately check your wp-config.php for suspicious code blocks, scan your site with a security tool like Wordfence or Sucuri, and remove any Essential Plugin plugins. The WordPress.org forced update only neutralized the phone-home mechanism — it did not clean existing infections.

Q: Can this type of supply chain attack happen to npm or pip packages? A: Yes, and it already has. The event-stream incident (2018) and ua-parser-js hijack (2021) followed similar patterns. Any ecosystem with third-party dependencies is vulnerable to maintainer compromise or acquisition-based attacks.

Q: What is a blockchain-based command-and-control server? A: Instead of using a traditional domain name that can be seized by authorities, the attacker stored their C2 server address in an Ethereum smart contract. The malware queries the blockchain to get the current server address, making takedown nearly impossible without controlling the smart contract.

Q: How can I detect dormant backdoors in my dependencies? A: There's no perfect solution, but you can: pin and lock dependencies, review diffs before updating (especially after ownership changes), use static analysis tools, monitor for unexpected network calls, and implement file integrity monitoring on production systems.

Based on the original forensic investigation by Mike Schroder at CaptainCore.

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.

AI tutoring tools have been everywhere lately. Most of them are just ChatGPT wrappers with a different skin — ask a question, get an answer, move on. Nothing sticks. Nothing adapts. Nothing remembers.

DeepTutor, built by the HKUDS team at Hong Kong University, takes a fundamentally different approach. It's an agent-native, open-source learning platform that builds a persistent profile of how you learn, what you've studied, and where you're heading — then uses that context across every interaction.

It hit 10,000 GitHub stars in 39 days. The v1.0.0 release just dropped with a ground-up architecture rewrite (~200k lines). This isn't a weekend side project. It's infrastructure.

Linus Torvalds merged something quietly significant into the Linux kernel tree: an official document titled AI Coding Assistants. It's not a policy debate. It's not a blog post. It's a .rst file sitting in Documentation/process/ right next to coding-style.rst and submitting-patches.rst.

The world's largest open-source project — 30+ million lines of code, thousands of contributors — just formally defined how AI can (and can't) participate in kernel development.

This isn't a niche Linux story. It's a blueprint that every engineering team dealing with AI-assisted code will eventually need.

Foundation models have transformed natural language, images, and code. But financial markets? Not so much.

Until now.

Kronos is the first open-source foundation model trained specifically for the "language" of financial markets—K-line sequences (OHLCV data). Unlike general-purpose time-series models, Kronos understands the unique, high-noise characteristics of financial data. It's been trained on data from 45+ global exchanges, and it's already accepted by AAAI 2026.

This matters for anyone building fintech products, trading platforms, or quantitative systems. Domain-specific foundation models are the next frontier, and Kronos is proving it's possible for finance.