#web

### Summary The `MCPScanner ` class contains a critical Command Injection vulnerability in the `cloneRepo `method. The application passes the user-supplied githubUrl argument directly to a system shell via execSync without sanitization. This allows an attacker to execute arbitrary commands on the host machine by appending shell metacharacters to the URL. ### Details The vulnerability exists in the src/scanner/MCPScanner.ts file within the cloneRepo method. [https://github.com/kapilduraphe/mcp-watch/blob/0fca7228bd313ae5aa938d61311377e88ce6e682/src/scanner/McpScanner.ts#L181](https://github.com/kapilduraphe/mcp-watch/blob/0fca7228bd313ae5aa938d61311377e88ce6e682/src/scanner/McpScanner.ts#L181) The code uses child_process.execSync to execute a git clone command: Because execSync spawns a shell (defaulting to `/bin/sh` on Unix or` cmd.exe` on Windows), any shell metacharacters present in the url argument will be interpreted by the shell. The application does not validate that the url ...

## Summary A Stored Cross-Site Scripting (XSS) vulnerability was identified in the `/admin/accounts/groups/Grupo` endpoint of the _Grav_ application. This vulnerability allows attackers to inject malicious scripts into the `data[readableName]` parameter. The injected scripts are stored on the server and executed automatically whenever the affected page is accessed by users, posing a significant security risk. --- ## Details **Vulnerable Endpoint:** `POST /admin/accounts/groups/Grupo` **Parameter:** `data[readableName]` The application fails to properly validate and sanitize user input in the `data[readableName]` parameter. This lack of input handling allows attackers to inject arbitrary script content that is stored in the application and executed in the browser of any user who views the affected group configuration. --- ## PoC **Payload:** `<ScRipT>alert('PoC-XSS')</ScRipT>` 1. Navigate to **Accounts > Groups** in the administrative panel. 2. Create a new group or edi...

### Summary - A low privilege user account with page editing privilege can read any server files using "Frontmatter" form. - This includes Grav user account files - /grav/user/accounts/*.yaml. This file stores hashed user password, 2FA secret, and the password reset token. - This can allow an adversary to compromise any registered account by resetting a password for a user to get access to the password reset token from the file or by cracking the hashed password. ### Details _The vulnerability can be found in /user/plugins/form/templates/forms/fields/display/display.html.twig_  ### PoC 1. This PoC was conducted on Grav CMS version 1.7.46 and Admin Plugin version 1.10.46  2. go to “http://grav.local/admin/pages” then create new page with “Page Template” option set to “Form”. ![image](https://g...

## Summary Grav CMS is vulnerable to a Server-Side Template Injection (SSTI) that allows any authenticated user with editor permissions to execute arbitrary code on the remote server, bypassing the existing security sandbox. ## Details Grav CMS uses a custom sandbox to protect the powerful Twig methods such as `registerUndefinedFilterCallback()`. These methods are designed to prevent SSTI attacks by denying the execution of dangerous PHP functions (e.g., `exec()`, `passthru()`, `system()`, etc.) within Twig template directives. The current defense mechanism relies on a blacklist of prohibited functions (PHP, Twig), checked through the `isDangerousFunction()` method in the file `system/src/Grav/Common/Twig.php`: ```php $this->twig->registerUndefinedFilterCallback(function (string $name) use ($config) { $allowed = $config->get('system.twig.safe_filters'); if (is_array($allowed) && in_array($name, $allowed, true) && function_exists($name)) { return new TwigFilter($nam...

maxminddb prior to version 0.27 declared `Reader::open_mmap` as safe despite wrapping an inherently unsafe memmap2 operation with no extra step done to guarantee safety. This could have led to undefined behaviour if the file were to be modified on disk while the memory map was still active.

Werkzeug's `safe_join` function allows path segments with Windows device names. On Windows, there are special device names such as `CON`, `AUX`, etc that are implicitly present and readable in every directory. `send_from_directory` uses `safe_join` to safely serve files at user-specified paths under a directory. If the application is running on Windows, and the requested path ends with a special device name, the file will be opened successfully, but reading will hang indefinitely.

The affected function is unsound due to insufficient checks on public struct field.

Snipe-IT before 8.3.4 allows stored XSS, allowing a low-privileged authenticated user to inject JavaScript that executes in an administrator's session, enabling privilege escalation.

### Summary A DoS can occur that immediately halts the system due to the use of an unsafe function. ### Details According to **RFC 5322**, nested group structures (a group inside another group) are not allowed. Therefore, in lib/addressparser/index.js, the email address parser performs flattening when nested groups appear, since such input is likely to be abnormal. (If the address is valid, it is added as-is.) In other words, the parser flattens all nested groups and inserts them into the final group list. However, the code implemented for this flattening process can be exploited by malicious input and triggers DoS RFC 5322 uses a colon (:) to define a group, and commas (,) are used to separate members within a group. At the following location in lib/addressparser/index.js: https://github.com/nodemailer/nodemailer/blob/master/lib/addressparser/index.js#L90 there is code that performs this flattening. The issue occurs when the email address parser attempts to process the following k...

### Summary XSS vulnerability in OAuth callback server allows JavaScript injection through unsanitized error parameter. Attackers can execute arbitrary JavaScript in the user's browser during OAuth authentication. ### Details **Vulnerable Code:** `spotipy/oauth2.py` lines 1238-1274 (RequestHandler.do_GET) **The Problem:** During OAuth flow, spotipy starts a local HTTP server to receive callbacks. The server reflects the `error` URL parameter directly into HTML without sanitization. **Vulnerable code at line 1255:** ```python status = f"failed ({self.server.error})" ``` **Then embedded in HTML at line 1265:** ```python self._write(f"""<html> <body> <h1>Authentication status: {status}</h1> </body> </html>""") ``` The `error` parameter comes from URL parsing (lines 388-393) without HTML escaping, allowing script injection. **Attack Flow:** 1. User starts OAuth authentication → local server runs on `http://127.0.0.1:8080` 2. Attacker crafts malicious URL: `http://127.0.0.1:8080/?err...