ghsa

Due to insufficient validation of parameters reflected in error messages by the legacy HTTP query API and the logging endpoint, it is possible to inject and execute malicious JavaScript within the browser of a targeted OpenTSDB user. This issue shares the same root cause as CVE-2018-13003, a reflected XSS vulnerability with the suggestion endpoint.

Due to insufficient validation of parameters passed to the legacy HTTP query API, it is possible to inject crafted OS commands into multiple parameters and execute malicious code on the OpenTSDB host system. This exploit exists due to an incomplete fix that was made when this vulnerability was previously disclosed as CVE-2020-35476. Regex validation that was implemented to restrict allowed input to the query API does not work as intended, allowing crafted commands to bypass validation.

The vulnerability was found Moodle which exists because the application allows a user to control path of the older to create in TinyMCE loaders. A remote user can send a specially crafted HTTP request and create arbitrary folders on the system.

The vulnerability was found Moodle which exists due to insufficient sanitization of user-supplied data in external Wiki method for listing pages. A remote attacker can send a specially crafted request to the affected application and execute limited SQL commands within the application database.

RosarioSIS 10.8.4 is vulnerable to CSV injection via the Periods Module.

### Impact When debug logging is enabled (via `DEBUG` environment variable), the Kubernetes client may log all response bodies into the debug log -- including sensitive data from `Secret` resources. When running in a Kubernetes cluster, this might expose sensitive information to users who are _not_ authorised to access secrets, but have access to Pod logs (either directly using kubectl, or by Pod logs being shipped elsewhere). ### Patches Upgrade to 3.5.0 or newer. ### Workarounds Disable debug logging entirely, or exclude the `kubernetes:client` debug item (for example, using `DEBUG=*,-kubernetes:client`). ### References - https://cwe.mitre.org/data/definitions/532.html

### Impact The impact of this path traversal and arbitrary extension is limited (creation of arbitrary files and appending data to existing files) but when combined with the SQL Injection, the exported data `RESTRICTED DIFFUSION 9 / 9` can be controlled and a webshell can be uploaded. Attackers can use that to execute arbitrary PHP code on the server with the permissions of the webserver. ### Patches Update to version 10.5.18 or apply this patch manually https://github.com/pimcore/pimcore/commit/7f788fa44bc18bc1c9182c25e26b770a1d30b62f.patch ### Workarounds Apply patch https://github.com/pimcore/pimcore/commit/7f788fa44bc18bc1c9182c25e26b770a1d30b62f.patch manually. ### References https://github.com/pimcore/pimcore/pull/14498

appium-desktop v1.14.1 and prior is vulnerable to OS Command Injection.

The Apache Spark UI offers the possibility to enable ACLs via the configuration option spark.acls.enable. With an authentication filter, this checks whether a user has access permissions to view or modify the application. If ACLs are enabled, a code path in HttpSecurityFilter can allow someone to perform impersonation by providing an arbitrary user name. A malicious user might then be able to reach a permission check function that will ultimately build a Unix shell command based on their input, and execute it. This will result in arbitrary shell command execution as the user Spark is currently running as. This issue was disclosed earlier as CVE-2022-33891, but incorrectly claimed version 3.1.3 (which has since gone EOL) would not be affected. NOTE: This vulnerability only affects products that are no longer supported by the maintainer. Users are recommended to upgrade to a supported version of Apache Spark, such as version 3.4.0.

In AVideo, a normal user can make a Meeting Schedule where the user can invite another user in that Meeting, but I found out that it did not properly sanitize the malicious characters when creating a Meeting Room. This leads the attacker to put malicious scripts. Impact: Since any USER including the ADMIN can see the meeting room that was created by the attacker this can lead to cookie hijacking and takeover of any accounts without user interaction. Step to Reproduce: 1. As normal USER go to Meet -> Schedule https://demo.avideo.com/plugin/Meet/ 2. In "Meet topic" field put XSS payload Example: "><img src=x onerror=alert('Pawned+by+Gonz')> 3. Then click Save 4. Now as ADMIN go to Meet -> Schedule -> Upcoming https://demo.avideo.com/plugin/Meet/ 5. Then the XSS payload that normal USER created will be executed Video POC: https://youtu.be/Nke0Bmv5F-o