excerpt: Learn about potential security risks associated with outdated SVR.JS web server versions. Stay informed and safeguard your web applications from potential threats with timely updates.
date: 2023-12-21 20:29:44
---
Some older versions of SVR.JS are vulnerable to cyberattacks. It's recommended to update your SVR.JS version to the newest one.
If you find a security issue with SVR.JS, report it as soon as possible to _vulnerability-reports[at]svrjs[dot]org_. We'll mitigate that vulnerability if it is possible.
### Fixed in SVR.JS 3.13.0 and in SVR.JS 3.4.41 LTS
* An attacker could use user name with newlines on HTTP authentication to inject false log entries. (introduced in SVR.JS 3.0.0)
* An attacker could install problematic SVR.JS mod with newlines in its filename to inject false log entries. (introduced in SVR.JS 3.0.0)
### Fixed in SVR.JS 3.12.1 and in SVR.JS 3.4.39 LTS
* An attacker could inject HTML code into the _extName_ parameter of the _callServerError_ method to perform XSS attack.
* An attacker could inject HTML code into the _serverAdministratorEmail_ config.json property and cause the server to return 500, 502, 503, 504, 506 or 509 error code using a default error page or an error page with a _{contact}_ placeholder to perform XSS attack.
### Fixed in SVR.JS 3.10.2
* SVR.JS mods and server-side JavaScript were executed in the wrong order. So the attacker could bypass access controls if one of the mods had them, but the other one allowed browsing sensitive information. (introduced in SVR.JS 3.9.3; not present in LTS)
### Fixed in SVR.JS 3.9.6 and in SVR.JS 3.4.34 LTS
* An attacker could use URL beginning with "_/temp/_" to leak information from _temp_ directory in SVR.JS installation directory (includes source code through hidden _.modloader_w12345_ and _.serverSideScript_w12345.js_), if web root is in SVR.JS installation directory. [_View the security advisory_](/advisories/svrjs-00004.pdf)
### Fixed in SVR.JS 3.9.3 and in SVR.JS 3.4.31 LTS
* An attacker could use request URL that begins with "_http://_" or with "_https://_" (instead of one that begins with "_/_") to bypass all access controls (including HTTP authentication) in affected versions that use SVR.JS mods or server-side JavaScript not using _href_ or _uobject.pathname_ properties in at least one of path checks. [_View the security advisory_](/advisories/svrjs-00003.pdf)
### Fixed in SVR.JS 3.9.2 and in SVR.JS 3.4.30 LTS
* Affected SVR.JS versions failed to protect the _req.url_ property in SVR.JS mods and server-side JavaScript from path traversal because they didn't detect partial URL sanitation done by WHATWG URL parser and they didn't apply sanitations back to the _req.url_ property. (introduced in SVR.JS 3.3.1) [_View the security advisory_](/advisories/svrjs-00002.pdf)
### Fixed in SVR.JS 3.9.0 and in SVR.JS 3.4.28 LTS
* An attacker could put invalid X-Forwarded-For header value in order to possibly cause problems with web application. (when _enableIPSpoofing_ was enabled)
### Fixed in SVR.JS 3.7.5
* Block list didn't work, and thus attackers could bypass blocks. (introduced in SVR.JS 3.5.0; not present in LTS)
### Fixed in SVR.JS 3.5.6 and in SVR.JS 3.4.16 LTS
* An attacker could use "..." to traverse directories, while SVR.JS is running on Windows. (in web apps, less probable in SVR.JS itself, since Node.JS itself reports that "..." doesn't exist)
### Fixed in SVR.JS 3.3.1
* An attacker could use request URL, that begins with "_http://_" or with "_https://_" to bypass all access controls in affected versions, that use SVR.JS mods or server-side JavaScript.
### Fixed in SVR.JS 3.3.0
* Non-standard codes didn't work, and thus attackers could bypass HTTP authentication. (introduced in SVR.JS 3.2.1)
### Fixed in SVR.JS 3.2.1
* An attacker could access directory listing of directory above web root using "/.." path. (introduced in SVR.JS 3.0.0 and SVR.JS 2.1.3)
### Fixed in SVR.JS 3.1.2
* If SVR.JS script is above (not on) web root directory, then _config.json_ and other sensitive files can be easily accessed. (through security misconfiguration; introduced in SVR.JS 3.0.0)
### Fixed in SVR.JS 3.0.0
* There was a XSS bug in host name indication in default error pages.
### Fixed in SVR.JS 3.0.0 and SVR.JS 2.1.4
* An attacker could append "%00" to the URL in order to bypass access restrictions when SVR.JS is running on Bun.
* An attacker could use encoded characters to bypass access restrictions.
* Fixed access control bypass vulnerability when the server is running on Windows
### Fixed in SVR.JS 3.0.0 and SVR.JS 2.1.3
* Server crashed on malformed URL.
* Path traversal was possible with files.
* Fixed access control bypass vulnerability when the server is running on Windows (partial fix)
### Fixed in SVR.JS 2.1.1
* An attacker could use directory listing to access secret files (through path traversal).
---
## easy-waf integration
### Fixed in easy-waf integration 1.2.4
* An attacker could send a very small chunk of the POST request body (which will not trigger WAF) before the payload to bypass the WAF.
### Fixed in easy-waf integration 1.2.1
* An attacker could access the resource on the server with poorly written SVR.JS mod or server-side JavaScript (that normally would invoke 500 Internal Server Error) to crash the server.
## RedBrick
### Fixed in RedBrick 2.5.4
* An attacker could add HTTP authentication header to the HTTP request when not required to enable web application functionality normally disabled on unauthenticated requests. [_View the security advisory_](/advisories/svrjs-00005.pdf)
### Fixed in RedBrick 2.3.3
* An attacker could use "CGI-BIN" instead of "cgi-bin" to leak source code, while SVR.JS with RedBrick is running on Windows. [_View the security advisory_](/advisories/svrjs-00001.pdf)
* An attacker could leak RedBrick interpreter settings, while SVR.JS with RedBrick is running on Windows. [_View the security advisory_](/advisories/svrjs-00001.pdf)
## reverse-proxy-mod
### Fixed in reverse-proxy-mod 1.1.2
* An attacker could hack the upstream server, replace the web server or application with one that sends an invalid HTTP response code, and make a request to the hacked server through the reverse proxy to crash the reverse proxy server.
### Fixed in reverse-proxy-mod 1.0.4
* An attacker could leak reverse proxy configuration file. [_View the security advisory_](/advisories/svrjs-00001.pdf)
## OrangeCircle
### Fixed in OrangeCircle 1.1.2
* An attacker could add HTTP authentication header to the HTTP request when not required to enable web application functionality normally disabled on unauthenticated requests. [_View the security advisory_](/advisories/svrjs-00005.pdf)
### Fixed in OrangeCircle 1.0.2
* An attacker could leak OrangeCircle configuration, while SVR.JS with YellowSquare is running on Windows. [_View the security advisory_](/advisories/svrjs-00001.pdf)
## YellowSquare
### Fixed in YellowSquare 1.1.2
* An attacker could add HTTP authentication header to the HTTP request when not required to enable web application functionality normally disabled on unauthenticated requests. [_View the security advisory_](/advisories/svrjs-00005.pdf)
### Fixed in YellowSquare 1.0.1
* An attacker could use "JSGI-BIN" instead of "jsgi-bin" to leak source code, while SVR.JS with YellowSquare is running on Windows. [_View the security advisory_](/advisories/svrjs-00001.pdf)
