Building a stronger security process for Meteor

Security
1

Security is an area I have been thinking about for some time. A recent security-related PR brought the topic back to my attention, and I have also noticed more people in the community raising similar concerns.

I believe this is a good moment to discuss how we can improve security across Meteor and include concrete initiatives in our next roadmap. I would like to hear some ideas about what we can do, process, tools, and etc.

An initial audit

As a small baseline, I created a full application with Meteor 3.5.1 and ran npm audit.

The result was:

  • 8 moderate vulnerabilities
  • 0 high vulnerabilities
  • 0 critical vulnerabilities

Seven findings came from development tooling, mainly through the Rspack and webpack-dev-server dependency chain.

Running the audit without development dependencies left one moderate finding related to qs, included through url inside meteor-node-stubs. Wich already is solved in this PR

A few proposes

GitHub Security Advisory and CVEs

Meteor already has a security email address and a SECURITY.md. We could build on them with a clearer GitHub Security Advisory process:

  1. A user, researcher, or contributor privately reports a possible vulnerability.
  2. A maintainer validates the report and creates a private draft advisory.
  3. The reporter and necessary contributors can collaborate privately.
  4. The team identifies the affected versions, severity, mitigation, fix, and required backports.
  5. If no CVE exists, a maintainer can request one through GitHub.
  6. The corrected packages or Meteor versions are released.
  7. The advisory is published together with the security release and communication to users.

This would give maintainers a central place to coordinate fixes without disclosing vulnerabilities too early.

Automating Dependency Security Audits

There is already an open PR proposing automated npm security audits proposed by @harry97. This could help us detect vulnerable dependencies earlier, monitor Meteor’s npm packages continuously, and gradually introduce blocking checks for new high- or critical-severity findings without letting existing audit noise disrupt development.

Using Security Analysis Tools

We should also evaluate security analysis tools that can identify risks beyond npm dependencies. The StepSecurity PR opened @storyteller, for example, highlights possible improvements to GitHub Actions, token permissions, and third-party workflow dependencies. These tools could become part of periodic repository reviews, with maintainers validating each recommendation before adopting it.

But this PR bring me up a few questions: what tools should we use? what open source solutions do we have in the market?

Publishing an SBOM for Meteor Releases

Meteor could generate and publish a Software Bill of Materials for each release. An SBOM would provide a machine-readable inventory of the included packages and versions, helping maintainers and users quickly determine whether a release contains a vulnerable component. It would also improve supply-chain visibility and support organizations with security or compliance requirements.

Opening the discussion

npm audit cannot determine by itself whether every finding is exploitable in a Meteor application. It is only one input in a broader process of detection, triage, correction, and communication.

The goal of this proposal is not to suggest that Meteor is insecure. It is to make our security work more continuous, visible, and predictable.

These are only some initial ideas. We would like to hear from the community: what else can we improve in the framework, tooling, documentation, release process, or project governance. The idea is make Meteor and the applications built with it more secure?

6 Likes
2

Currently WeKan uses only GitHub Advisories, where I request CVE and publish advisory.

Vulnerabilities are also added to Hall of Fame:

https://wekan.fi/hall-of-fame/

Security and other maintenance processes are described at AGENTS.md and CLAUDE.md:

GitHub workflows builds releases for all platforms:

WeKan Security remediation and logging:

FerretDB Security remediation and logging:

Admin Panel / Problems:

3

This somewhat gets into the broader issue we have with our packaging system…

There is no easy way to publish a security update(embargoed or not) in core without doing a full-blown release or doing a form of fork.

I think we could brainstorm some scenarios and how it is expected of us to react to it, eh

A) We/Researcher/AI finds a core package vulnerability and reports to us; how fast could we publish a fix when we get one? How could we warn people that they should update their package? We should be able to give our users an easy path to update without having to fight a dependency graph or forking the package.

B) We/Researcher/AI find a non-core package vulnerability and reports to us; How could we fix this? Should we fix this? Should we fork and call it a day? What if our fix actually breaks the package? I think this is a very important conversation we should be having, especially now that AIs are VERY good at security stuff.

Thanks a lot for bringing this up @italojs

1 Like
4

Hmm, forking packages…

https://www.npmjs.com/search?q=%40wekanteam

5

For WeKan, if I’m awake:

  1. Fix may take from some minutes to some hours
  2. If I run all tests, one at a time, that can take over 1 hour. Running more tests at the same time can be flaky, some tests fail.
  3. When I change version number, GitHub Actions builds for all platforms, maybe within 1 hour for most platforms.
  4. Snap gets updates automatically. Others depend on whoever installed those, did they make any automatic update script. Some test Docker version first, update production later.
  5. If something does not work, someone complains at GitHub issues or email to support. Having all tests pass successfully does not quarantee that everything works, there can be corner cases etc.
6

This is why I started this:

We need to scan the NPM dependencies not just generally but also the ones within Atmosphere packages which needs a custom code. And this process needs to be integrated in our CI so no PR flies under the radar.

3 Likes
7

1.We/Researcher/AI finds a core package vulnerability and reports to us
We can enable the Private vulnerability reporting from github and use it similar as @xet7 shared, so we can automated it with LLM, creatting a private fix-PR in the same moment we receive the report.
BTW I would like to know what tools exists around code-security, woulbe be nice have an attacker LLM reporting issues and a defensive LLM solving them.
I cant see how a security fix can break the meteor version but it’s a problem for the another moment lol

B) We/Researcher/AI find a non-core package vulnerability and reports to us; How could we fix this? Should we fix this? Should we fork and call it a day? What if our fix actually breaks the package? I think this is a very important conversation we should be having, especially now that AIs are VERY good at security stuff.
IMO we cant garantee the security of a non-core package and we shouldnt fix it, we just mantain pkgs inside meteor org. Imagine the scenario, 1 popular npm pkg gets vulnerable, how many pkgs should we update/fix? it’s a lot, we havent capacity for that.

8

BTW I would like to know what tools exists around code-security, woulbe be nice have an attacker LLM reporting issues and a defensive LLM solving them.

  • GitHub Dependabot and CodeQL
  • WeKan tests that are run with build.sh of repo wekan/wekan, those check that those 61 vulnerabilities at wekan/wekan/security are not reintroduced to code

https://wekan.fi/hall-of-fame/

9

I’m very interested in this also. The most recent info I’ve seen is that LLMs are, of course, great at discovering vulnerabilities, but not yet good at patching them.

Per Gemini, cited on this forum post:

While every engineering team would buy a magic button that instantly fixes vulnerable code, the reality is that generative AI is currently much better at breaking things than fixing them.

More details at the link.

But… that was 22 days ago. Things may have improved since then!

10

@vikr00001

The most recent info I’ve seen is that LLMs are, of course, great at discovering vulnerabilities, but not yet good at patching them.

NOTE: Also other AI can fix security issues, OpenAI Codex ChatGPT is NOT the only one. Most AI is trained with same code from Internet. Also Claude has fixed many security issues already.

For WeKan, when I have received responsible security disclousure, Claude and ChatGPT Pro have fixed many vulnerabilities, and those security researchers have confirmed that those vulnerabilities are now fixed. AI has added tests, that check that those vulnerabilities are not reintroduced to codebase. If someone tries to override permissions, those attempts are logged to Admin Panel Problems Security.

Currently I mostly use ChatGPT Pro, because Claude does not work well enough.

1 Like
11

Good to hear! Please let us know of any results in case you try out the new chatGPT Astra model.

12

@vikr00001

Good to hear! Please let us know of any results in case you try out the new chatGPT Astra model.

I don’t know yet how to try Astra. I use VSCodium Flatpak Sandbox at Asahi Fedora.

Kuvakaappaus - 2026-09-05 21-40-09
Kuvakaappaus - 2026-09-05 21-40-09419×864 34.6 KB

13

Why Asahi Fedora or Asahi Ubuntu

Apple Silicon is silent.

Linux filesystem is fast.

Flatpak has sandboxing for VSCodium.

Why not macOS

macOS asks a lot of permissions.

APFS filesystem previously corrupted my local Thunderbird emails.

APFS filesystem is very slow.

Why not Win11

NTFS filesystem is slow.

Installing Meteor is slow.

Why not Omarchy Mac

Snap does not work well enough. I build WeKan Snap packages.

Snap: snapd is installable from the AUR, but it is not recommended for Arch Linux, especially not on Hyperland (there are AppArmor, cgroups, and boot issues).

Why not Claude

Claude:

  • Can fix security issues, but doesn’t behave well enough
  • Apologizes too often after making a mistake several times, and often confuses two things
  • Claude macOS asks for extra permissions to access other programs, asks permission repeatedly
  • Claude macOS logged out by itself, and asks to log in again. ChatGPT stays logged in.

ChatGPT:

  • Writes more formally and behaves well
  • Seems to work faster than Claude

For maintaining, I use Claude for OSS, ChatGPT for OSS, etc, listed at WeKan sponsors page:

https://wekan.fi/sponsors/

2 Likes
14

I don’t see it in Codex yet either.

15

Right now the release process for core packages and the Meteor bundle is too slow and requires a lot of work.

Meteor needs to move towards a leaner and lighter architecture extracting core packages (at the very least) to NPM; that way, vulnerable packages can be auditable and addressed granularly.

Bundled tooling like Node.js and Mongo should be able to be upgraded independently; they should be only batteries included recommendations, but we should have good tooling for replacement as well as documentation.

I would completely get rid of atmosphere, phasing out into a new more modern NPM based plugin system, there is a lot of effort being put into NPM security and it’s the de facto standard, where most security tooling speaks the same language.

Making the architecture simpler there would be a great start IMO.

Not to mention the business case, Meteor is not a packages product, and I believe that trying to keep its own thing is actually in the way of security and fast iteration.

A few years back we had talked about this, I wonder how far it got @nachocodoner

1 Like
16

For a long time, the community has discussed what to do with this Meteor-specific system. Some prefer relying on NPM, and it is true that Atmosphere packages fit some cases better than others. Still, controlling the Meteor lifecycle remains important, as seen with Rspack integration, the current CapacitorJS work, build-time asset serving, runtime module loading for client and server, and Meteor’s integrated testing setup with MongoDB.

This dependency is still a topic. The Meteor core team has not decided to move fully to NPM, as the roadmap focuses on broader priorities like reactive performance, native experience, TypeScript, and testing. A full migration does not seem very realistic, since it would add burden and breaking changes for a community that has already dealt with this for a long time. AI might help, but there is still no clear gain compared to focusing on core improvements, developer experience, and product-oriented features.

From: Atmosphere CLI improvements: interactive search and install from git

My take on Atmosphere packages is basically the above. I agree with this long-term vision, and it would be really good to move towards NPM only, with security auditing and fixes that we would get for free, along with many other benefits. I also agree that making core packages and bundled tooling more independent could help the release process and allow things like Node.js or MongoDB to evolve with less coupling. We are doing this though with other modern integrated tool like Rspack, CapacitorJS, etc.

However, the effort required to reach that point is huge and could have a strong impact on the Meteor community and the migrations needed, raise your hand/like if you’re not tired of breaking changes since the Meteor 3 async transition, bundler changes, and so on. Until now, the incremental and more effective modernization path has been to keep Atmosphere packages, since they control the Meteor lifecycle well and can properly support other integrations and benefits, as happened with Rspack, CapacitorJS, and soon Rstest. Atmosphere is well-tested and mature, and in the short term we can still build tailored improvements for package discoverability, or even security auditing and fixes for our specific case, as discussed here.

With AI, we could likely move faster and more reliably at some point when dealing with the existing architecture. But I would still try to ship and honor small, quick gains around what we already have, what the community knows and understands, and make smaller and cheaper changes in terms of time, resources, and migrations.

We talk many times about reworks, but touching the architecture of an existing legacy system can be really tricky. The only way we have been able to advance over these years has been by moving piece by piece and prioritizing specific areas. Maybe after we wrap up native, testing, and other fronts, we can dedicate more effort to POCs for replacing Atmosphere with NPM. We are also very open to receiving them and evaluating a strategy for small adoption across the different cases. But this is definitely a hard task that will require strong attention. Maybe for security alone, though, it could be worth the time.

I also personally think Meteor should enter a phase where it can enjoy what has already been modernized and have time to recover its presence in the JS ecosystem. Major refactors would also take resources away from those fronts. Anyway, this is a good area for discussion and, above all, for POCs that let us play with initial implementations upfront.

1 Like
17

I wonder if Meteor can gain traction again without those kinds of refactors, I don’t see this as just a simple architectural improvement, I see it as a trust improvement.

Of course, I understand the magnitude of the task, but it can be done gradually, I can certainly help.

The most important part is the core packages, we could map the most critical ones, where vulnerabilities would be the most gnarly and start from there.

I can prepare a Plan + PoC by the end of the week.

By the way, for the consumer it should be a seamless transition, the difference should be that they can easily know a package is vulnerable and upgrade the version faster and more easily for example.

1 Like
18

I just figured out, that I could login to ChatGPT with webbrowser, and at Work tab give it project where it works towards project done, using many subagents to speed up finishing project. I can also shutdown my laptop. This is so cool, I don’t need to use limited resources of my laptop. 32 GB RAM just is not enough. I did just write what GitHub repo to clone, and I can later download .zip package of project and commit myself. I did not need to give ChatGPT direct commit access to GitHub.

19

I built this which gives me full control of a Mac Studio M3 Ultra + Static IP (public nginx) + Tailscale (private network), no matter how much power ChatGPT can give you it will always be consumer level, which needs to be profitable for them and god knows how they handle the data.

image
image1920×963 93 KB

20

@leonardoventurini

no matter how much power ChatGPT can give you it will always be consumer level, which needs to be profitable for them and god knows how they handle the data.

My projects are WeKan FLOSS prototypes with MIT license, there is not anything secret. For those, faster progress is nice at ChatGPT remote servers.

For private projects, that needs local models, not connected to Internet.