Source
ghsa
# DOS on the admin panel **Severity Rating:** Medium **Vector:** Denial Of Service **CVE:** XXX **CWE:** 400 - Uncontrolled Resource Consumption **CVSS Score:** 4.9 **CVSS Vector:** CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H ## Analysis A Denial of Service (DoS) vulnerability has been identified in the application related to the handling of `scheduled_at` parameters. Specifically, the application fails to properly sanitize input for cron expressions. By manipulating the `scheduled_at` parameter with a malicious input, such as a single quote, the application admin panel becomes non-functional, causing significant disruptions to administrative operations. The only way to recover from this issue is to manually access the host server and modify the `backup.yaml` file to correct the corrupted cron expression ## Proof of Concept 1) Change the value of `scheduled_at` parameter to `'` as shown in the following figures at the `http://127.0.0.1/admin/tools` endpoint, and observe the...
### 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 - 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”.  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...
### Summary A privilege escalation vulnerability exists in Grav’s Admin plugin due to the absence of username uniqueness validation when creating users. A user with the create user permission can create a new account using the same username as an existing administrator account, set a new password/email, and then log in as that administrator. This effectively allows privilege escalation from limited user-manager permissions to full administrator access. ### Steps to Reproduce 1. Make sure you have two accounts: an admin and a user with create user privilege 2. In the user account, navigate to /grav-admin/admin/accounts/users and click "Add" 3. Enter the name of the admin, complete registration and observe that the existing admin’s email is changed to the value you provided. 4. Log out from user account log in as admin with new credentials ### Impact 1. Full admin takeover by any user with create user permission. 2. Ability to change admin credentials, install/remove plugins, read or...
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.
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.