#auth

## 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 Stored Cross-Site Scripting (XSS) vulnerability was identified in the `/admin/pages/[page]` endpoint of the _Grav_ application. This vulnerability allows attackers to inject malicious scripts into the `data[header][metadata]`, `data[header][taxonomy][category]`, and `data[header][taxonomy][tag]` parameters. These scripts are stored in the page frontmatter and executed automatically whenever the affected page is accessed or rendered in the administrative interface. --- ## Details **Vulnerable Endpoint:** `POST /admin/pages/[page]` **Parameters:** - `data[header][metadata]` - `data[header][taxonomy][category]` - `data[header][taxonomy][tag]` The application fails to properly sanitize user input when saving page metadata or taxonomy fields via the Admin Panel. As a result, an attacker with access to the admin interface can inject a malicious script using these parameters, and the script will be stored in the page's YAML frontmatter. When the page or met...

### Summary Due to a broken access control vulnerability in the `/admin/pages/{page_name}` endpoint, an editor ( user with full permissions to pages ) can change the functionality of a form after submission. ### Details Due to improper authorization checks when modifying critical fields on a POST request to `/admin/pages/{page_name}`, an editor with only permissions to change basic content on the form is now able to change the functioning of the form through modifying the content of the `data[_json][header][form]` which is the YAML frontmatter which includes the `process` section which dictates what happens after a user submits the form which include some important actions that could lead to further vulnerabilities. ### PoC - Have Admin and Form plugins installed - Connect to panel as admin, create user and give him permission for pages all - Now connect as that user and notice you cant edit any process field in the panel - Change anything in the content of the form and save - Inter...

## 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...

A vulnerability exists in Keycloak's server distribution where enabling debug mode (`--debug`) insecurely defaults to binding the Java Debug Wire Protocol (JDWP) port to all network interfaces (`0.0.0.0`). This exposes the debug port to the local network, allowing an attacker on the same network segment to attach a remote debugger and achieve remote code execution within the Keycloak Java virtual machine. Red Hat evaluates this as a Moderate impact vulnerability due to the requirement of running debug mode and untrusted network. Also, for Red Hat Single Sign-On, this must as well be bound to 0.0.0.0 address, which is not recommended in production scenarios.

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.

Mattermost versions 11.0.x <= 11.0.2, 10.12.x <= 10.12.1, 10.11.x <= 10.11.4, 10.5.x <= 10.5.12 fail to validate user permissions when deleting comments in Boards, which allows an authenticated user with the editor role to delete comments created by other users.