Scan Another

CVE Scan for gethomepage/homepage:latest

Docker image vulnerability scanner

23 Known Vulnerabilities in this Docker Image

0
Critical
8
High
12
Medium
2
Low
0
Info/ Unspecified/ Unknown
CVE IDSeverityPackageAffected VersionFixed VersionCVSS Score
CVE-2026-116576highpkg:npm/systeminformation@5.33.13<5.33.165.33.167.8

Summary

On Windows, systeminformation@5.33.15 builds a PowerShell command using the value passed to services(). The default sanitizer removes ASCII quotes but keeps Unicode curly quotes, spaces, and parentheses. A crafted service name can use those characters to break out of the generated filter string and run a PowerShell expression. The expression runs with the permissions of the Node.js process.

This report confirms version 5.33.15. Other package versions have not been checked.

Details

In lib/processes.js, services() sanitizes the caller's string with sanitizeShellString() and later inserts each resulting name into a Get-CimInstance Win32_Service -Filter command. The Windows branch passes that command to util.powerShell().

The sanitizer in lib/util.js removes the ASCII double quote, but it does not remove U+201C or U+201D, the left and right curly double quotation marks. It also permits spaces and parentheses when called in its default, non-strict mode. PowerShell accepts the curly marks as string delimiters, so an input can end the filter string and place a command expression in the generated command.

For example, the input below uses curly quotation marks to end the generated filter string and execute New-Item. I reproduced this call on Windows against the checked-out systeminformation@5.33.15 source; it created a marker file with the Node.js process account.

Proof of concept

Run this on Windows in a disposable directory with Node.js and PowerShell available:

mkdir si-command-injection-repro
cd si-command-injection-repro
npm init -y
npm install systeminformation@5.33.15

Save the following as poc.cjs, then run node poc.cjs:

'use strict';

const fs = require('node:fs');
const path = require('node:path');
const si = require('systeminformation');

(async () => {
  const markerName = `si-injection-${process.pid}.txt`;
  const markerPath = path.join(process.cwd(), markerName);
  fs.rmSync(markerPath, { force: true });

  try {
    await si.services(`not-a-service” (New-Item -Name ${markerName} -ItemType File -Force) “`);
    console.log(`markerCreated=${fs.existsSync(markerPath)}`);
  } finally {
    fs.rmSync(markerPath, { force: true });
  }
})().catch((error) => {
  console.error(error);
  process.exitCode = 1;
});

Expected output:

markerCreated=true

The Windows run returned an array and created the marker (markerCreated: true). A benign input left the marker absent. The script removes the marker afterward. I did not identify an application network route that forwards remote input to services(), so remote exploitability depends on the consuming application.

Impact

An application that passes attacker-controlled input to services() on Windows can execute PowerShell commands with the Node.js process account's permissions. Depending on that account, commands may read or change accessible files, alter application data, or disrupt the service. I searched this repository for HTTP servers, route handlers, and listener calls and found none. services() is exposed through the package API and getDynamicData(), so a consuming application could make the input network-reachable if it forwards request data. A separate loopback HTTP harness did trigger the command through a query parameter, but that server was test code and is not part of this repository. The project's docs/security.html already warns that arbitrary untrusted input to services() needs caution because package sanitization does not cover every case.

Package URL(s):
  • pkg:npm/systeminformation@5.33.13
CVE-2026-102276highpkg:npm/brace-expansion@5.0.9>=4.0.0,<5.0.105.0.107.5
CVE-2026-102278highpkg:npm/brace-expansion@5.0.9>=4.0.0,<5.0.115.0.117.5
CVE-2026-109869highpkg:npm/undici@6.28.0>=8.0.0,<8.12.28.12.27.5
CVE-2026-19534highpkg:npm/undici@6.28.0>=6.7.0,<6.28.16.28.17.5
CVE-2026-87018highpkg:npm/undici@6.28.0>=8.0.0,<8.12.28.12.27.5
CVE-2026-109383highpkg:npm/undici@6.28.0>=4.0.0,<6.29.16.29.17.4
CVE-2026-109829highpkg:npm/undici@8.11.2>=8.0.0,<8.12.28.12.27.4
CVE-2026-101910mediumpkg:npm/ip-address@10.5.0>=10.2.0,<=10.5.010.5.16.9
CVE-2026-101911mediumpkg:npm/ip-address@10.5.0<=10.7.010.7.16.3

Severity Levels

Exploitation could lead to severe consequences, such as system compromise or data loss. Requires immediate attention.

Vulnerability could be exploited relatively easily and lead to significant impact. Requires prompt attention.

Exploitation is possible but might require specific conditions. Impact is moderate. Should be addressed in a timely manner.

Exploitation is difficult or impact is minimal. Address when convenient or as part of regular maintenance.

Severity is not determined, informational, or negligible. Review based on context.

Sliplane Icon
About Sliplane

Sliplane is a cloud platform that makes deploying and scaling your apps simple. Launch in minutes and grow as you go, containers included.

Try Sliplane for free

About the CVE Scanner

What is a CVE?

CVE stands for Common Vulnerabilities and Exposures. It is a standardized identifier for known security vulnerabilities, allowing developers and organizations to track and address potential risks effectively. For more information, visit cve.mitre.org.

About the CVE Scanner

The CVE Scanner is a powerful tool that helps you identify known vulnerabilities in your Docker images. By scanning your images against a comprehensive database of Common Vulnerabilities and Exposures (CVEs), you can ensure that your applications are secure and up-to-date. For more details, checkout the NIST CVE Database.

How the CVE Scanner Works

The CVE Scanner analyzes your Docker images against a comprehensive database of known vulnerabilities. It uses Docker Scout under the hood to provide detailed insights into affected packages, severity levels, and available fixes, empowering you to take immediate action.

Why CVE Scanning is Essential for Your Docker Images

With the rise of supply chain attacks, ensuring the security of your applications has become more critical than ever. CVE scanning plays a vital role in identifying vulnerabilities that could be exploited by attackers, especially those introduced through dependencies and third-party components. Regularly scanning and securing your Docker images is essential to protect your applications from these evolving threats.

Benefits of CVE Scanning

  • Enhanced Security: Detect and mitigate vulnerabilities before they are exploited.
  • Compliance: Meet industry standards and regulatory requirements for secure software.
  • Proactive Maintenance: Stay ahead of potential threats by addressing vulnerabilities early.

The Importance of Patching Docker Images

Patching your Docker images is a critical step in maintaining the security and stability of your applications. By regularly updating your images to include the latest security patches, you can address known vulnerabilities and reduce the risk of exploitation. This proactive approach ensures that your applications remain resilient against emerging threats and helps maintain compliance with security best practices.

Want to deploy this image?

Try out Sliplane - a simple Docker hosting solution. It provides you with the tools to deploy, manage and scale your containerized applications.