Source
ghsa
### Impact For optimizing the scalar multiplication algorithm in circuit for some curves, gnark uses fake-GLV algorithm in case the curve doesn't support true-GLV. For this to work, we need to compute the scalar decomposition using the Half GCD method in gnark-crypto. However, for some of the inputs the algorithm didn't converge quickly enough. In case the prover accepts untrusted witness, it could lead to denial of service as the prover gets stuck in a very slowly converging loop. Thanks to @feltroidprime for reporting the issue and proposing a fix. ### Patches The issue has been patched in gnark-crypto commit https://github.com/Consensys/gnark-crypto/commit/56600883e0e9f9b159e9c7000b94e76185ec3d0d. The dependency update is implemented in gnark commit https://github.com/Consensys/gnark/commit/68be6cede36e387ab760725beabd3c96cc94e6dc. ### Workarounds This update doesn't require recompiling the circuits as the issue is in the hint function. The users can update the gnark-crypto d...
### Impact The Eventlet WSGI parser is vulnerable to HTTP Request Smuggling due to improper handling of HTTP trailer sections. This vulnerability could enable attackers to: - Bypass front-end security controls - Launch targeted attacks against active site users - Poison web caches ### Patches Problem has been patched in eventlet 0.40.3. The patch just drops trailers. If a backend behind eventlet.wsgi proxy requires trailers, then this patch BREAKS your setup. ### Workarounds Do not use eventlet.wsgi facing untrusted clients. ### References - Patch https://github.com/eventlet/eventlet/pull/1062 - This issue is similar to https://github.com/advisories/GHSA-9548-qrrj-x5pj
## Summary It is possible to redirect a user to another origin if the "proceed_to" value in the session store is set to a protocol-relative URL. ## Details The google_sign_in gem persists an optional URL for redirection after authentication. If this URL is set to a protocol-relative URL, it improperly passes the "same origin" check, and it's possible for the user to be redirected to another origin after authentication, possibly resulting in exposure of authentication information if this attack is chained with other attacks. Normally the value of this URL is only written and read by the library or the calling application. However, it may be possible to set this session value from a malicious site with a form submission. ## Impact Any Rails applications using the google_sign_in gem may be vulnerable, if this vector can be chained with another attack that is able to modify the OAuth2 request parameters. ## Workarounds No known workarounds. ## Credits This issue was responsibly r...
# Summary A denial of service vulnerability was discovered in ntpd-rs where an attacker can induce a message storm between two NTP servers running ntpd-rs. # Details Since ntpd-rs version 1.2.0, when configured as a server, incorrectly responded to all NTP messages sent to the server's port with a time reply, including to responses from other servers. As a consequence, a message with a spoofed IP address of another server could cause two servers running ntpd-rs to continually respond to each other, consuming significant amounts of resources. # Impact Any time server running ntpd-rs with version between 1.2.0 and 1.6.1 inclusive which allows non-NTS traffic is affected. Client-only configurations are not affected. Affected users are recommended to upgrade to version 1.6.2 as soon as possible. # Workarounds Should upgrading not be possible, the impact of the issue can be mitigated by: - Whitelisting access to only IP addresses of clients using the server, using the ignore filter ...
### Impact Open Source Harness git LFS server (Gitness) exposes api to retrieve and upload files via git LFS. Implementation of upload git LFS file api is vulnerable to arbitrary file write. Due to improper sanitization for upload path, a malicious authenticated user who has access to Harness Gitness server api can use a crafted upload request to write arbitrary file to any location on file system, may even compromise the server. Users using git LFS are vulnerable. ### Patches Users have to upgrade to v3.3.0 . All previous versions are affected by this vulnerability.
Sending AWS chunk data with no Content-Length HTTP header causes the panic, every time. ### Reproduction Setup versity server running on port 7071, no SSL (for ease of packet tracing with tshark). Problem can be reproduced with or without SSL on the versity end. Use nginx to reverse proxy on port 7070. This does have to be SSL enabled for the repro to occur. nginx config: ``` upstream tony_versity { server 127.0.0.1:7071; keepalive 15; } server { listen 7070 ssl ; access_log /var/log/nginx/tony_versity_proxy.access.log; error_log /var/log/nginx/tony_versity_proxy.error.log; # Allow any size file to be uploaded. client_max_body_size 0; # Allow special characters in headers ignore_invalid_headers off; # Disable buffering proxy_buffering off; proxy_request_buffering off; # Load configuration files for the default server block. include /etc/nginx/default.d/*.conf; ssl_certificate "/WS/TEMP/lh.crt"; ss...
### Impact A vulnerability has been identified within Rancher Manager in which it did not enforce request body size limits on certain public (unauthenticated) and authenticated API endpoints. This allows a malicious user to exploit this by sending excessively large payloads, which are fully loaded into memory during processing. This could result in: - Denial of Service (DoS): The server process may crash or become unresponsive when memory consumption exceeds available resources. - Unauthenticated and authenticated exploitation: While the issue was initially observed in unauthenticated `/v3-public/*` endpoints, the absence of request body size limits also affected several authenticated APIs, broadening the potential attack surface. It's worth noting that other areas in Rancher do implement safeguards: requests proxied to Kubernetes APIs are subject to built-in size limits enforced by the [Kubernetes API server itself](https://github.com/kubernetes/kubernetes/blob/v1.33.4/staging/src/k8s...
The protections against path traversal attacks in the UI config module are insufficient, still partially allowing for attacks in very specific cases. The path is checked without checking for the file separator. This could allow attackers access to files within another folder which starts with the same path. For example, the default UI config directory is placed at `/etc/opencast/ui-config`. Without this patch, an attacker can get access to files in a folder `/etc/opencast/ui-config-hidden` if those files are readable by Opencast. General path traversal is not possible. For example, an attacker **cannot** exploit this to access files in `/etc/opencast/encoding` or even in `/etc/opencast/` directly. ### How dangerous is this? Theoretically, this vulnerability may be exploited to get access to some non-public files. However, given the default structure of Opencast's configuration, this is extremely unlikely to hit any users. There can be but one `ui-config` folders. This makes it quit...
A security flaw has been discovered in AiondaDotCom mcp-ssh up to 1.0.3. Affected by this issue is some unknown functionality of the file server-simple.mjs. Performing manipulation results in command injection. The attack can be initiated remotely. Upgrading to version 1.0.4 and 1.1.0 can resolve this issue. The patch is named cd2566a948b696501abfa6c6b03462cac5fb43d8. It is advisable to upgrade the affected component.
### Impact A denial-of-service was found in Exiv2 version v0.28.5: a quadratic algorithm in the ICC profile parsing code in `jpegBase::readMetadata()` can cause Exiv2 to run for a long time. Exiv2 is a command-line utility and C++ library for reading, writing, deleting, and modifying the metadata of image files. The denial-of-service is triggered when Exiv2 is used to read the metadata of a crafted jpg image file. ### Patches The bug is fixed in version v0.28.6. ### References Issue: https://github.com/Exiv2/exiv2/issues/3333 Fixes: https://github.com/Exiv2/exiv2/pull/3335 (main branch), https://github.com/Exiv2/exiv2/pull/3345 (0.28.x branch) ### For more information Please see our [security policy](https://github.com/Exiv2/exiv2/security/policy) for information about Exiv2 security.