fix: add "SVR.JS" heading and remove static Markdown part of vulnerability page
This commit is contained in:
parent
ae1e0e0023
commit
19b0a1bca6
2 changed files with 5 additions and 71 deletions
|
|
@ -1,5 +1,4 @@
|
|||
import ReactMarkdown from "react-markdown";
|
||||
import { VULNERABILITY } from "@/constants/guidelines";
|
||||
import { useEffect, useState } from "react";
|
||||
import { Skeleton } from "@/components/ui/skeleton";
|
||||
import clientPromise from "@/lib/db";
|
||||
|
|
@ -63,7 +62,7 @@ const Vulnerabilities = async () => {
|
|||
className="wrapper container py-24 md:py-28 gap-2 flex flex-col"
|
||||
>
|
||||
<h1 className="text-3xl md:text-5xl pb-1 md:pb-2 font-bold text-black dark:bg-clip-text dark:text-transparent dark:bg-gradient-to-b dark:from-white dark:to-neutral-400">
|
||||
SVR.JS Vulnerabilities
|
||||
SVR.JS vulnerabilities
|
||||
</h1>
|
||||
<p className="md:text-lg text-muted-foreground text-start mb-6">
|
||||
Some older versions of SVR.JS are vulnerable to cyberattacks. It's
|
||||
|
|
@ -74,12 +73,15 @@ const Vulnerabilities = async () => {
|
|||
</p>
|
||||
{error && <p className="text-red-500">{error.message}</p>}
|
||||
|
||||
<h2 className="text-2xl md:text-3xl py-1 md:py-2 font-bold text-black dark:bg-clip-text dark:text-transparent dark:bg-gradient-to-b dark:from-white dark:to-neutral-400">
|
||||
SVR.JS
|
||||
</h2>
|
||||
{reversedDownloads.map((download) => (
|
||||
<div
|
||||
key={download._id}
|
||||
className="flex-start flex-col prose max-w-full md:prose-lg dark:prose-invert gap-2"
|
||||
>
|
||||
<h2 className="mb-0 md:mb-0">{download.version}</h2>
|
||||
<h3 className="mb-0 md:mb-0">{download.version}</h3>
|
||||
<ul>
|
||||
{(download.bullets ?? []).map((bullet, index) => (
|
||||
<li key={index}>
|
||||
|
|
@ -100,10 +102,6 @@ const Vulnerabilities = async () => {
|
|||
</div>
|
||||
))}
|
||||
|
||||
<div className="prose max-w-full md:prose-lg dark:prose-invert mb-6 md:mb-9">
|
||||
<ReactMarkdown>{VULNERABILITY}</ReactMarkdown>
|
||||
</div>
|
||||
|
||||
{/* Section with MODS content */}
|
||||
{reversedMods.map((mod) => (
|
||||
<div
|
||||
|
|
|
|||
|
|
@ -369,70 +369,6 @@ By contributing to our project, you agree that your contributions will be licens
|
|||
Thank you for considering contributing to our project!
|
||||
`;
|
||||
|
||||
export const VULNERABILITY = `
|
||||
|
||||
### Fixed in SVR.JS 3.15.0 and in SVR.JS 3.14.16 LTS
|
||||
- An attacker could send a HTTP forward proxy request with malformed URL not using CONNECT method to possibly crash the server.
|
||||
|
||||
### 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
|
||||
|
||||
### 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
|
||||
|
||||
### 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
|
||||
|
||||
### 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).
|
||||
|
||||
`;
|
||||
|
||||
export const CHANGE_LOGS = `
|
||||
## SVR.JS 3.14.17 LTS
|
||||
*Released on June 13, 2024*
|
||||
|
|
|
|||
Loading…
Reference in a new issue