ghsa

Centreon updateDirectory SQL Injection Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Centreon. Authentication is required to exploit this vulnerability. The specific flaw exists within the updateDirectory function. The issue results from the lack of proper validation of a user-supplied string before using it to construct SQL queries. An attacker can leverage this vulnerability to execute code in the context of the service account. Was ZDI-CAN-22294.

### Impact Versions from 1.2.0 to 1.3.1 of Astro-Shield allow to bypass the allow-lists for cross-origin resources by introducing valid `integrity` attributes to the injected code. This implies that the injected SRI hash would be added to the generated CSP header, which would lead the browser to believe that the injected resource is legit. To exploit this vulnerability, the attacker needs to first inject code into the rendered pages by exploiting other not-related potential vulnerabilities. ### Patches Version [1.3.2](https://github.com/kindspells/astro-shield/releases/tag/1.3.2) provides a patch. ### Workarounds - To not use the middleware functionality of Astro-Shield. - To use the middleware functionality of Astro-Shield ONLY for content that cannot be controlled in any way by external users. ### References _Are there any links users can visit to find out more?_

### Summary Piccolo's admin panel provides the ability to upload media files and view them within the admin panel. If SVG is an allowed file type for upload; the default; an attacker can upload an SVG which when loaded under certain contexts allows for arbitrary access to the admin page. This access allows the following actions for example: - The ability for an attacker to gain access to all data stored within the admin page - The ability for an attacker to make any action within the admin page such as creating, modifying or deleting table records As the SVG is executed from the context of an authenticated admin session, any actions they may be able to make can be made by the attacker. *N.b. The relevant session cookies are inaccessible from JavaScript due to httponly being set so all exploits must be present within the SVG file* ### PoC _Complete instructions, including specific configuration details, to reproduce the vulnerability._ Currently, this requires the ability for a ...

### Summary The Casa OS Login page has disclosed the username enumeration vulnerability in the login page which was patched in `CasaOS v0.4.7`. ### Details It is observed that the attacker can enumerate the CasaOS username using the application response. If the username is incorrect the application gives the error "**User does not exist**" with success code "**10006**", If the password is incorrect the application gives the error "**User does not exist or password is invalid**" with success code "**10013**". ### PoC 1. If the Username is invalid application gives "User does not exist" with success code "**10006**".  2. If the Password is invalid application gives "**User does not exist or password is invalid**" with success code "**10013**".  ### Impact Using...

JJWT (aka Java JWT) through 0.12.5 ignores certain characters and thus a user might falsely conclude that they have a strong key. The impacted code is the setSigningKey() method within the DefaultJwtParser class and the signWith() method within the DefaultJwtBuilder class.

Bonita before 10.1.0.W11 allows stored XSS via a UI screen in the administration panel.

### Impact A random segment of ~1-10kb of Node.js heap memory allocated either side of a known buffer will be leaked into the final executable. This memory _could_ contain sensitive information such as environment variables, secrets files, etc. ### Patches This issue is patched in 18.3.1 ### Workarounds No workarounds, please update to a patched version of `@electron/packager` immediately if impacated.

### Impact A user can reuse an expired session by controlling the `x-workos-session` header. ### Patches Patched in https://github.com/workos/authkit-nextjs/releases/tag/v0.4.2

### Summary The permission `view_other_timesheet` performs differently for the Kimai UI and the API, thus returning unexpected data through the API. ### Details When setting the `view_other_timesheet` permission to true, on the frontend, users can only see timesheet entries for teams they are a part of. When requesting all timesheets from the API, however, all timesheet entries are returned, regardless of whether the user shares team permissions or not. Example: There are projects P1 and P2, Teams T1 and T2, users U1 and U2 and Timesheet entries E1 and E2. U1 is team leader of team T1 and has access to P1. U2 is in Team T2 and has access to both P1 and P2. U2 creates E1 for P1 and E2 for P2. In the UI, U1 with `view _other_timesheet` perms sees E1 as he is a part of T1 that has access to P1. In the API, however, he has access to E1 **and E2**. Additionally, if U1 is not a team leader T1, he does not see any timesheet from a user other than himself in the UI, but still all timesheets...

### Impact In code which applies _un-sanitized string values into metric names or labels_, like this: ```swift let lang = try? request.query-get(String.self, at: "lang") Counter ( label: "language", dimensions: [("lang", lang ?? "unknown" )] ) ``` an attacker could make use of this and send a `?lang` query parameter containing newlines, `}` or similar characters which can lead to the attacker taking over the exported format -- including creating unbounded numbers of stored metrics, inflating server memory usage, or causing "bogus" metrics. ### Patches The default strategy to sanitize labels was moved deeper into the library, preventing illegal characters from appearing in name, label keys and values. Metric names and label names are now validated against the following requirement: `[a-zA-Z_:][a-zA-Z0-9_:]*` (for metric names) and `[a-zA-Z_][a-zA-Z0-9_]*` (for metric label names). Label values are not validated as they are allowed to contain any unicode characters. Developers...