Source
ghsa
`shaman::cryptoutil::write_u64v_le` and other functions mentioned above cannot garantee memory safety of get_unchecked later if both length are zero. `shaman` is unmaintained.
### Impact Missing authentication in the `/api/v1/usage-report/summary` endpoint allows anyone to retrieve aggregate API usage counts. While no sensitive data is disclosed, the endpoint may reveal information about service activity or uptime. ### Patches Upgrade to >v1.70.1 ### Workarounds Any **ONE** of these is sufficient to block this reporting: - Disable usage reporting by setting configuration option `usage_report.enabled` or environment variable `LAKEFS_USAGE_REPORT_ENABLED` to `false`. - Using load-balancer or application level firewall - blocking the request route /api/v1/usage-report/summary.
## Summary A command injection vulnerability in MotionEye allows attackers to achieve Remote Code Execution (RCE) by supplying malicious values in configuration fields exposed via the Web UI. Because MotionEye writes user-supplied values directly into Motion configuration files without sanitization, attackers can inject shell syntax that is executed when the Motion process restarts. This issue enables full takeover of the MotionEye container and potentially the host environment (depending on container privileges). ## Details ### Root Cause: MotionEye accepts arbitrary strings from fields such as **image_file_name** and **movie_filename** in the Web UI. These are written directly into **/etc/motioneye/camera-*.conf**. When MotionEye restarts the Motion service (motionctl.start), the Motion binary reads this configuration. Because Motion treats these fields as shell-expandable, injected characters (e.g. $(), backticks) are interpreted as shell commands. ### Vulnerability flow: Dashboa...
### Summary OpenMage versions v20.15.0 and earlier are affected by a stored Cross-Site Scripting (XSS) vulnerability that could be abused by an admin with direct database access or the admin notification feed source to inject malicious scripts into vulnerable fields. Malicious JavaScript may be executed in a victim’s browser when they browse to the page containing the vulnerable field. ### Details Unescaped translation strings and URLs are printed into contexts inside `app/code/core/Mage/Adminhtml/Block/Notification/Grid/Renderer/Actions.php`. A malicious translation or polluted data can inject script. - Link labels use __() without escaping. - ’deleteConfirm()’ embeds a message without escaping. ### PoC 1. Add XSS to admin locale (e.g. app/locale/en_US/local.csv): ``` "Read Details","<img src=x onerror=alert(123)>" "Mark as Read","<script>alert(123)</script>" ``` 2. Flush Cache. Make sure locale is set to en_US. 3. Add any admin notification (e.g. via test.php) ...
### Impact Due to insufficient access-level checks, any non-admin user having access to _manage_config_columns_page.php_ (typically project managers having MANAGER role) can use the _Copy From_ action to retrieve the columns configuration from a private project they have no access to. Access to the reverse operation (_Copy To_) is correctly controlled, i.e. it is not possible to alter the private project's configuration. ### Patches The vulnerability will be fixed in MantisBT version 2.27.2. ### Workarounds None ### Credits Thanks to [d3vpoo1](https://github.com/jrckmcsb) for reporting the issue.
When a user edits their profile to change their e-mail address, the system saves it without validating that it actually belongs to the user. ### Impact This could result in storing an invalid email address, preventing the user from receiving system notifications. Notifications sent to another person's email address could lead to information disclosure. ### Patches Fixed in 2.27.2. ### Workarounds None ### Credits Thanks to @ncrcs for discovering and reporting the issue.
The Metro Development Server, which is opened by the React Native CLI, binds to external interfaces by default. The server exposes an endpoint that is vulnerable to OS command injection. This allows unauthenticated network attackers to send a POST request to the server and run arbitrary executables. On Windows, the attackers can also execute arbitrary shell commands with fully controlled arguments.
A lack of server-side validation for note length in MantisBT allows attackers to permanently corrupt issue activity logs by submitting extremely long notes (tested with 4,788,761 characters). Once such a note is added: ### Impact - The entire activity stream becomes unviewable (UI fails to render). - New notes cannot be displayed, effectively breaking all future collaboration on the issue. ### Patches Fixed in 2.27.2. ### Workarounds None ### Credits Thanks to Mazen Mahmoud (@TheAmazeng) for reporting the vulnerability.
Due to an incorrect use of loose (`==`) instead of strict (`===`) comparison in the [authentication code][1], PHP type juggling will cause interpretation of certain MD5 hashes as numbers, specifically those matching scientific notation. [1]: https://github.com/mantisbt/mantisbt/blob/0fb502dd613991e892ed2224ac5ea3e40ba632bc/core/authentication_api.php#L782 ### Impact On MantisBT instances configured to use the *MD5* login method, user accounts having a password hash evaluating to zero (i.e. matching regex `^0+[Ee][0-9]+$`) are vulnerable, allowing an attacker knowing the victim's username to login without knowledge of their actual password, using any other password having a hash evaluating to zero, for example `comito5` (0e579603064547166083907005281618). No password bruteforcing for individual users is needed, thus $g_max_failed_login_count does not protect against the attack. ### Patches Fixed in 2.27.2. ### Workarounds Check the database for vulnerable accounts, and change tho...
Blogs in Liferay Portal 7.4.0 through 7.4.3.111, and older unsupported versions, and Liferay DXP 2023.Q4.0 through 2023.Q4.10, 2023.Q3.1 through 2023.Q3.10, 7.4 GA through update 92, and older unsupported versions does not check permission of images in a blog entry, which allows remote attackers to view the images in a blog entry via crafted URL.