ghsa

## Summary The xDS interface in Kgateway versions 2.0.0 through 2.0.4 lacks authentication, allowing any client with unrestricted network access to the xDS port to retrieve potentially sensitive configuration data including certificate data, backend service information, routing rules, and cluster metadata. ## Description ### Impact Kgateway xDS interface did not have authorization, so anonymous clients with unrestricted network access could gain access to the xDS data. This could expose sensitive information about your gateway configuration, certificate data, backend services, and routing topology to unauthorized parties. ### Patches Upgrade to version 2.0.5 or 2.1.0. These versions enable JWT-based authentication for the xDS interface by default, ensuring that only authenticated clients can access the xDS configuration data. ### Workarounds If immediate upgrade is not possible, NetworkPolicies can be used to block access to kgateway's xDS port, restricting network access to on...

### Summary The expected `protocDigest` is ignored when protoc is taken from the `PATH`. ### Details The documentation for the `protocDigest` parameter says: > ... Users may wish to specify this if using a `PATH`-based binary ... However, when specifying `<protoc>PATH</protoc>` the `protocDigest` is not actually checked because the code returns here already https://github.com/ascopes/protobuf-maven-plugin/blob/59097aae8062c461129a13dcda2f4116b90a8765/protobuf-maven-plugin/src/main/java/io/github/ascopes/protobufmavenplugin/protoc/ProtocResolver.java#L91-L93 before the digest check: https://github.com/ascopes/protobuf-maven-plugin/blob/59097aae8062c461129a13dcda2f4116b90a8765/protobuf-maven-plugin/src/main/java/io/github/ascopes/protobufmavenplugin/protoc/ProtocResolver.java#L106 ### PoC Specify: ```xml <protoc>PATH</protoc> <protocDigest>sha256:0000000000000000000000000000000000000000000000000000000000000000</protocDigest> ``` And notice how the `protoc` on the `PATH` is not rejec...

## Summary Cross-namespace Secret access vulnerability in DiscoveryServiceCertificate allows users to bypass RBAC and access Secrets in unauthorized namespaces. ## Affected Versions All versions prior to v0.13.4 ## Patched Versions v0.13.4 and later ## Impact Users with permission to create DiscoveryServiceCertificate resources in one namespace can indirectly read Secrets from other namespaces, completely bypassing Kubernetes RBAC security boundaries. ## Workarounds Restrict DiscoveryServiceCertificate create permissions to cluster administrators only until patched version is deployed. ## Credit Thanks to @debuggerchen for the responsible disclosure.

### Impact OctoPrint versions up to and including 1.11.3 are affected by a vulnerability that allows injection of arbitrary HTML and JavaScript into Action Command notification and prompt popups generated by the printer. An attacker who successfully convinces a victim to print a specially crafted file could exploit this issue to disrupt ongoing prints, extract information (including sensitive configuration settings, if the targeted user has the necessary permissions for that), or perform other actions on behalf of the targeted user within the OctoPrint instance. ### Patches The vulnerability will be patched in version 1.11.4. ### Workaround OctoPrint administrators can mitigate the risk by disabling popups: - for Action Command notifications, uncheck _OctoPrint Settings -> Printer Notifications -> Enable popups_ - for Action Command prompts, set _OctoPrint Settings -> Printer Dialogs -> Enable support -> Never_ It is also strongly recommended to ensure that files being printed o...

### Impact When downloadinging comic images, Dosage constructs target file names from different aspects of the remote comic (page URL, image URL, page content, etc.). While the basename is properly stripped of directory-traversing characters, the file extension is taken from the HTTP `Content-Type` header. This allows a remote attacker (or a Man-in-the-Middle, if the comic is served over HTTP) to write arbitrary files outside the target directory (if additional conditions are met). ### Patches Fixed in release 3.2. The [fix is small and self-contained](https://github.com/webcomics/dosage/commit/336a9684191604bc49eed7296b74bd582151181e), so distributors might elect to backport the fix to older versions. ### Workarounds No

The overly permissive sandbox configuration in DSPy allows attackers to steal sensitive files in cases when users build an AI agent which consumes user input and uses the “PythonInterpreter” class.

### Impact The `/api/images/cache` which is used to download media posters from the server accepted an `url` parameter, which was directly passed to the cache package and that downloaded the poster from this URL. This URL parameter can be used to make the jellysweep server download arbitrary content. The API endpoint can only be used by authenticated users. ### Patches Fixed in `v0.13.0`. The affected (and now fixed) library was also moved to `internal/` because it wasn't meant to be imported. ### References https://github.com/jon4hz/jellysweep/security/code-scanning/28

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