ghsa

A SSRF vulnerability exists, bypassing existing controls on the software. This can allow a user to request internal services for a full read SSRF, returning any data from the internal network. the application is using a whitelist, but the whitelist can be bypassed with @ and encoded value of @ (%40) GET /proxy/?url=http://development.demo.geonode.org%40geoserver:8080/geoserver/web This will trick the application that the first host is a whitelisted address, but the browser will use @ or %40 as a credential to the host geoserver on port 8080, this will return the data to that host on the response. 

### Impact When a response is processed, the issuer of the Identity Provider is not sufficiently validated. This could allow a malicious identity provider to craft a Saml2 response that is processed as if issued by another identity provider. It is also possible for a malicious end user to cause stored state intended for one identity provider to be used when processing the response from another provider. An application is impacted if they rely on any of these features in their authentication/authorization logic: * the issuer of the generated identity and claims * items in the stored request state (AuthenticationProperties) ### Patches Patched in version 2.9.2 and 1.0.3. All previous versions are vulnerable. ### Workarounds The `AcsCommandResultCreated` notification can be used to add the validation required if an upgrade to patched packages is not possible. ### References The patch is linked to https://github.com/Sustainsys/Saml2/issues/712 and https://github.com/Sustainsys/Saml2/is...

### Summary Faktory web dashboard can suffer from denial of service by a crafted malicious url query param `days`. ### Details The vulnerability is related to how the backend reads the `days` URL query parameter in the Faktory web dashboard. The value is used directly without any checks to create a string slice. If a very large value is provided, the backend server ends up using a significant amount of memory and causing it to crash. ### PoC To reproduce this vulnerability, please follow these steps: Start the Faktory Docker and limit memory usage to 512 megabytes for better demonstration: ``` $ docker run --rm -it -m 512m \ -p 127.0.0.1:7419:7419 \ -p 127.0.0.1:7420:7420 \ contribsys/faktory:latest ``` Send the following request. The Faktory server will exit after a few seconds due to out of memory: ``` $ curl 'http://localhost:7420/?days=922337' ``` ### Impact **Server Availability**: The vulnerability can crash the Faktory server, affecting its availability. **Denial of...

`ExpandableDetailsNote` allows annotating build log content with additional information that can be revealed when interacted with. Jenkins 2.423 and earlier, LTS 2.414.1 and earlier does not escape the value of the `caption` constructor parameter of `ExpandableDetailsNote`. This results in a stored cross-site scripting (XSS) vulnerability exploitable by attackers able to provide `caption` parameter values. As of publication, the related API is not used within Jenkins (core), and the Jenkins security team is not aware of any affected plugins. Jenkins 2.424, LTS 2.414.2 escapes `caption` constructor parameter values.

Jenkins creates a temporary file when a plugin is deployed directly from a URL. Jenkins 2.423 and earlier, LTS 2.414.1 and earlier creates this temporary file in the system temporary directory with the default permissions for newly created files. If these permissions are overly permissive, they may allow attackers with access to the Jenkins controller file system to read and write the file before it is installed in Jenkins, potentially resulting in arbitrary code execution. This vulnerability only affects operating systems using a shared temporary directory for all users (typically Linux). Additionally, the default permissions for newly created files generally only allow attackers to read the temporary file, but not write to it. This issue complements SECURITY-2823, which affected plugins uploaded from an administrator’s computer. Jenkins 2.424, LTS 2.414.2 creates the temporary file in a subdirectory with more restrictive permissions. As a workaround, you can change your default ...

In Jenkins 2.423 and earlier, LTS 2.414.1 and earlier, uploaded files processed via the Stapler web framework and the Jenkins API `MultipartFormDataParser` create temporary files in the system temporary directory with the default permissions for newly created files. If these permissions are overly permissive, attackers with access to the system temporary directory may be able to read and write the file before it is used. This vulnerability only affects operating systems using a shared temporary directory for all users (typically Linux). Additionally, the default permissions for newly created files generally only allow attackers to read the temporary file, but not write to it. Jenkins 2.424, LTS 2.414.2 creates the temporary files in a subdirectory with more restrictive permissions. As a workaround, you can change your default temporary-file directory using the Java system property `java.io.tmpdir`, if you’re concerned about this issue but unable to immediately update Jenkins.

Jenkins Build Failure Analyzer Plugin 2.4.1 and earlier does not escape Failure Cause names in build logs. This results in a stored cross-site scripting (XSS) vulnerability exploitable by attackers able to create or update Failure Causes. Build Failure Analyzer Plugin 2.4.2 escapes Failure Cause names in build logs.

Jenkins allows filtering builds in the build history widget by specifying an expression that searches for matching builds by name, description, parameter values, etc. Jenkins 2.50 through 2.423 (both inclusive), LTS 2.60.1 through 2.414.1 (both inclusive) does not exclude sensitive build variables (e.g., password parameter values) from this search. This allows attackers with Item/Read permission to obtain values of sensitive variables used in builds by iteratively testing different characters until the correct sequence is discovered. Jenkins 2.424, LTS 2.414.2 excludes sensitive variables from this search.

Jenkins Build Failure Analyzer Plugin 2.4.1 and earlier does not perform a permission check in a connection test HTTP endpoint. This allows attackers with Overall/Read permission to connect to an attacker-specified hostname and port using attacker-specified username and password. Additionally, this HTTP endpoint does not require POST requests, resulting in a cross-site request forgery (CSRF) vulnerability. Build Failure Analyzer Plugin 2.4.2 requires POST requests and Overall/Administer permission for the affected HTTP endpoint.

Jenkins Build Failure Analyzer Plugin 2.4.1 and earlier does not require POST requests for an HTTP endpoint, resulting in cross-site request forgery (CSRF) vulnerabilities. This vulnerability allows attackers to delete Failure Causes. Build Failure Analyzer Plugin 2.4.2 requires POST requests for the affected HTTP endpoint.