We have discovered more security vulnerabilites, this time in SVR.JS itself. We have patched SVR.JS, but we recommend to upgrade your SVR.JS web server to patched versions immediately.
Patched versions:
- SVR.JS 3.9.2 and newer
- SVR.JS 3.4.30 LTS and newer
Unpatched versions didn’t properly sanitize URLs for SVR.JS mods and server-side JavaScript, leaving them vulnerable. You can view our security advisory.
UPDATE: We have discovered and mitigated even more security vulnerabilites in SVR.JS itself. We recommend to upgrade your SVR.JS web server to patched versions immediately.
Patched versions:
- SVR.JS 3.9.3 and newer
- SVR.JS 3.4.31 LTS and newer
Unpatched versions didn’t properly enforce access control for non-proxy SVR.JS mods and server-side JavaScript, leaving them vulnerable. You can view our security advisory.
UPDATE 2: We have discovered and mitigated security vulnerabilites in SVR.JS itself even further. We strongly recommend to upgrade your SVR.JS web server to patched versions immediately.
Patched versions:
- SVR.JS 3.9.6 and newer
- SVR.JS 3.4.34 LTS and newer
Unpatched versions did allow access of temp directory inside SVR.JS installation directory to the public, leading to information leakage. You can view our security advisory.
UPDATE 3: SVR.JS versions from 3.9.6 to 3.10.1 had a bug with wrong mod loading order. The bug is related to mod access control vulnerability mitigation. The bug didn’t affect LTS versions. The bug is fixed in SVR.JS 3.10.2 and newer.
UPDATE 4: It seems like we had patched a lot more vulnerabilities in SVR.JS. There is a list of them:
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.
We’re feeling like we’re doing too many updates. You can track latest discovered SVR.JS vulnerabilites.