NPM 24 vulnerabilities (2 low, 15 moderate, 7 high)

[zz0rk]

⚠️ Please verify that your question has not already been reported

• I have searched the existing issues and found no similar reports.

🛡️ Security Policy

• I have read and agree to Uptime Kuma's Security Policy.

📝 Describe your problem

Debian 12 server
Node.js Version: 18.20.4+dfsg-1~deb12u1

I am new to NPM and kuma. I've followed the installation instructions.

git clone https://github.com/louislam/uptime-kuma.git
cd uptime-kuma
npm run setup

After run setup I get the following warnings.

24 vulnerabilities (2 low, 15 moderate, 7 high)

I am not sure how to interpret this.

Thank you kindly

📝 Error Message(s) or Log

24 vulnerabilities (2 low, 15 moderate, 7 high)

🐻 Uptime-Kuma Version

uptime-kuma@1.23.16 download-dis

💻 Operating System and Arch

debian 12 server

🌐 Browser

n/a

🖥️ Deployment Environment

• Runtime Environment:
  • Docker: Version X.X.X (Build Y.Y.Y)
  • Docker Compose: Version X.X.X
  • Portainer (BE/CE): Version X.X.X (LTS: Yes/No)
  • MariaDB: Version X.X.X (LTS: Yes/No)
  • Node.js: Version X.X.X (LTS: Yes/No)
  • Kubernetes (K3S/K8S): Version X.X.X (LTS: Yes/No, via [method/tool])
• Database:
  • SQLite: Embedded
  • MariaDB: Embedded/External
• Database Storage:
  • Filesystem:
    • Linux: ext4/XFS/Btrfs/ZFS/F2FS
    • macOS: APFS/ HFS+
    • Windows: NTFS/ReFS
  • Storage Medium: HDD/eMMC/SSD/NVMe
• Uptime Kuma Setup:
  • Number of monitors: X

[siimots]

https://overreacted.io/npm-audit-broken-by-design/

[zz0rk]

Wow ...

As any security professional will tell you, development dependencies actually are an attack vector, and perhaps one of the most dangerous ones because it’s so hard to detect and the code runs with high trust assumptions. This is why the situation is so bad in particular: any real issue gets buried below dozens of non-issues that npm audit is training people and maintainers to ignore. It’s only a matter of time until this happens.

[CommanderStorm]

Hi, thanks for raising this.

I’m aware of the reported vulnerabilities. The majority of them are in development dependencies or we use the non-exploitable part of the code only
=> not shipped or installed into production, so they do not represent a real attack vector for this project.
The scanners (e.g., npm audit) often flag these by default, even when they are not exploitable in practice.

For v1, I am no longer actively maintaining dependencies. If you’d like to contribute dependency updates for v1, I’d be happy to review a PR.

To address your issue, I recommend using v2, which uses more recent dependencies and will receive updates.

Also, if you have suggestions for better tooling that distinguishes between exploitable and non-exploitable issues, we’d be very interested. I ignore npm-audit due to being mostly an false-positive.
Given our test coverage and how risky this makes depnendency updates, our current solutions are not great, but if you have