#git

### 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 All versions of ArgoCD starting from v2.4 have a bug where the ArgoCD repo-server component is vulnerable to a Denial-of-Service attack vector. Specifically, it's possible to crash the repo server component through an out of memory error by pointing it to a malicious Helm registry. The loadRepoIndex() function in the ArgoCD's helm package, does not limit the size nor time while fetching the data. It fetches it and creates a byte slice from the retrieved data in one go. If the registry is implemented to push data continuously, the repo server will keep allocating memory until it runs out of it. ### Patches A patch for this vulnerability has been released in the following Argo CD versions: v2.10.5 v2.9.10 v2.8.14 ### For more information If you have any questions or comments about this advisory: Open an issue in [the Argo CD issue tracker](https://github.com/argoproj/argo-cd/issues) or [discussions](https://github.com/argoproj/argo-cd/discussions) Join us on [Slack](https...

### Impact When the following conditions are met: - Automated CSP headers generation for SSR content is enabled - The web application serves content that can be partially controlled by external users Then it is possible that the CSP headers generation feature might be "allow-listing" malicious injected resources like inlined JS, or references to external malicious scripts. ### Patches Available in version 1.3.0 . ### Workarounds - Do not enable CSP headers generation. - Use it only for dynamically generated content that cannot be controlled by external users in any way. ### References _Are there any links users can visit to find out more?_

Server-side Template Injection (SSTI) vulnerability in Winter CMS v.1.2.3 allows a remote attacker to execute arbitrary code via a crafted payload to the CMS Pages field and Plugin components.

An issue in aliyundrive-webdav v.2.3.3 and before allows a remote attacker to execute arbitrary code via a crafted payload to the sid parameter in the `action_query_qrcode` component.

This Metasploit module exploits a buffer overflow at the administration interface (8080 or 4117) of WatchGuard Firebox and XTM appliances which is built from a cherrypy python backend sending XML-RPC requests to a C binary called wgagent using pre-authentication endpoint /agent/login. This vulnerability impacts Fireware OS before 12.7.2_U2, 12.x before 12.1.3_U8, and 12.2.x through 12.5.x before 12.5.9_U2. Successful exploitation results in remote code execution as user nobody.

The FoF Pretty Mail extension version 1.1.2 for Flarum suffers from a local file inclusion vulnerability.

The FoF Pretty Mail extension version 1.1.2 for Flarum suffers from a server-side template injection vulnerability.

The FoF Pretty Mail extension version 1.1.2 for Flarum suffers from a command injection vulnerability.

Red Hat Security Advisory 2024-1570-03 - Updated images are now available for Red Hat Advanced Cluster Security. Issues addressed include a denial of service vulnerability.