# Vulnerability patching of npm/gem dependencies in discourse

**URL:** https://meta.discourse.org/t/vulnerability-patching-of-npm-gem-dependencies-in-discourse/385400
**Category:** Self-hosting
**Tags:** docker
**Created:** [13 oktober 2025 om 06:20 UTC](https://meta.discourse.org/t/vulnerability-patching-of-npm-gem-dependencies-in-discourse/385400 "2025-10-13T06:20:50Z")
**Posts on this page:** 1
**Showing post:** 3

<div class="post-metadata">

### Author: ![harishg33](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/harishg33/32/496490_2.png) [@harishg33](https://meta.discourse.org/u/harishg33)
#### Post date: [13 oktober 2025 om 18:27 UTC](https://meta.discourse.org/t/vulnerability-patching-of-npm-gem-dependencies-in-discourse/385400/3 "2025-10-13T18:27:36Z")

</div>

Sorry for being unclear.

Our current build process starts with the discourse base image mentioned in the previous message, and then runs a script, which is just the bootstrap step of the supported installation process ( the launcher script ), but without running the steps which require an active redis/db connection.

So the bootstrap step, I assume, installs all the ruby dependencies and the npm dependencies of discourse. The versions which are showing up in the vulnerability list, are the dependencies of the discourse application itself mostly.

I also did some digging and found out that the golang dependencies it is tagging is from a npm dependency called `esbuild`, which is built using golang. The version of go it uses has a standard library vulnerability, which is getting tagged. So I think solving this would require a recompilation of that library, so I am not sure if it is even worth the effort.

But the other vulnerabilities are either direct ruby/npm dependencies or transitive dependencies of discourse. My question was mainly about updating the versions of those, just before installing them. I understand it would be difficult for developers of discourse to work on fixing those. I was just trying to understand if there was a way to check if the “upgrade” causes an issue or not, as my guess was that some dependencies might actually cause issues only in certain code paths.

---

_[View the full topic](https://meta.discourse.org/t/vulnerability-patching-of-npm-gem-dependencies-in-discourse/385400)._