#git

# Exposure of Password Hashes Leading to privilege escalation **Severity Rating:** Medium **Vector:** Privilege Escalation **CVE:** XXX **CWE:** 200 - Exposure of Sensitive Information **CVSS Score:** 6.2 **CVSS Vector:** CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:L ## Analysis It was observed that if a users is given read access on the user account management section of the admin panel can view the password hashes of all users, including the admin user. This exposure can potentially lead to privilege escalation if an attacker can crack these password hashes. An attacker with read access can: * View and potentially crack the password hashes. * Gain administrative access by cracking the admin password hash. * Escalate privileges and compromise the entire admin panel. ## Proof of Concept 1) Give read access to user accounts to a random user as shown in the following figures:  ![grav2...

# 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”. ![image](https://g...

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

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.

# Summary Affected versions of Better Auth allow an external request to configure `baseURL` when it isn’t defined through any other means. This can be abused to poison the router’s base path, causing all routes to return 404 for all users. This issue is only exploitable when `baseURL` is not explicitly configured (e.g., `BETTER_AUTH_URL` is missing) *and* the attacker is able to make the very first request to the server after startup. In properly configured environments or typical managed hosting platforms, this fallback behavior cannot be reached. # Details A combination of `X-Forwarded-Host` and `X-Forwarded-Proto` is implicitly trusted. This allows the first request to configure baseURL whenever it is not explicitly configured. Here's the code that reads the headers: <img width="631" height="219" alt="headers" src="https://github.com/user-attachments/assets/b3fb0078-a62f-4058-9d0b-4afbd30c4953" /> Here's the call to `getBaseURL()`, the result is assigned to `ctx.baseURL`. <i...

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

### Impact `CiliumNetworkPolicy`s which use `egress.toGroups.aws.securityGroupsIds` to reference AWS security group IDs that do not exist or are not attached to any network interface may unintentionally allow broader outbound access than intended by the policy authors. In such cases, the toCIDRset section of the derived policy is not generated, which means outbound traffic may be permitted to more destinations than originally intended. ### Patches This issue has been patched in: * Cilium v1.18.4 * Cilium v1.17.10 * Cilium v1.16.17 ### This issue affects: - Cilium v1.18 between v1.18.0 and v1.18.3 inclusive - Cilium v1.17 between v1.17.0 and v1.17.9 inclusive - Cilium v1.16.16 and below ### Workarounds There is no workaround to this issue. ### Acknowledgements The Cilium community has worked together with members of Isovalent to prepare these mitigations. Special thanks to @SeanEmac for reporting this issue and to @fristonio for the patch. ### For more information If you t...

### Impact In an instance which is using the XWiki Jetty package (XJetty), a context is exposed to statically access any file located in the webapp/ folder. It allows accessing files which might contains credentials, like http://myhots/webapps/xwiki/WEB-INF/xwiki.cfg, http://myhots/webapps/xwiki/WEB-INF/xwiki.properties or http://myhots/webapps/xwiki/WEB-INF/hibernate.cfg.xml. ### Patches This has been patched in 16.10.11, 17.4.4, 17.7.0. ### Workarounds The workaround is to modify the start_xwiki.sh script following https://github.com/xwiki/xwiki-platform/compare/8b68d8a70b43f25391b3ee48477d7eb71b95cf4b...99a04a0e2143583f5154a43e02174155da7e8e10. ### For more information If you have any questions or comments about this advisory: * Open an issue in [Jira XWiki.org](https://jira.xwiki.org/) * Email us at [Security Mailing List](mailto:security@xwiki.org) ### Attribution Vulnerability reported by Joseph Huber.