ghsa

## Description An XML External Entity (XXE) vulnerability was identified. The application accepts XML input through a specific endpoint ``/geoserver/wms`` operation ``GetMap``. However, this input is not sufficiently sanitized or restricted, allowing an attacker to define external entities within the XML request. An XML External Entity attack is a type of attack that occurs when XML input containing a reference to an external entity is processed by a weakly configured XML parser. This attack may lead to the disclosure of confidential data, denial of service, port scanning from the perspective of the machine where the parser is located, and other system impacts. By exploiting this vulnerability, an attacker can: - Read arbitrary files from the server's file system. - Conduct Server-Side Request Forgery (SSRF) to interact with internal systems. - Execute Denial of Service (DoS) attacks by exhausting resources. ## Resolution Update to GeoServer 2.25.6, GeoServer 2.26.3, or GeoServer ...

### Summary A reflected cross-site scripting (XSS) vulnerability exists in the WMS GetFeatureInfo HTML output format that enables a remote attacker to execute arbitrary JavaScript code in a victim's browser through specially crafted SLD_BODY parameters. ### Details The WMS service setting that controls HTML auto-escaping is either disabled by default, or completely missing, in the affected versions (see workarounds). ### Impact If an attacker can control a script that is executed in the victim's browser, then they can typically fully compromise that user. Amongst other things, the attacker can: 1. Perform any action within the application that the user can perform. 2. View any information that the user is able to view. 3. Modify any information that the user is able to modify. 4. Initiate interactions with other application users, including malicious attacks, that will appear to originate from the initial victim user. ### Workarounds Changing any of the following WMS service sett...

### Impact body-parser 2.2.0 is vulnerable to denial of service due to inefficient handling of URL-encoded bodies with very large numbers of parameters. An attacker can send payloads containing thousands of parameters within the default 100KB request size limit, causing elevated CPU and memory usage. This can lead to service slowdown or partial outages under sustained malicious traffic. ### Patches This issue is addressed in version 2.2.1.

A credential disclosure vulnerability was found in Grype, affecting versions `v0.68.0` through `v0.104.0`. If registry credentials are defined and the output of grype is written using the `--file` or `--output json=<file>` option, the registry credentials will be included unsanitized in the output file. ## Impact In Grype versions `v0.68.0` through `v0.104.0`, when registry authentication is configured, those credentials can be incorrectly included in the output of a Grype scan (regardless of whether those credentials are actively being used for the current scan). Users that do not have registry authentication configured are not affected by this issue. Registry credentials can be set via the Grype configuration file (e.g. `registry.auth[].username`, `registry.auth[].password`, `registry.auth[].token`) or environment variables (e.g., `GRYPE_REGISTRY_AUTH_USERNAME`, `GRYPE_REGISTRY_AUTH_PASSWORD`, `GRYPE_REGISTRY_AUTH_TOKEN`). In order for the authentication details to be improperly ...

### Impact OMERO.web uses the jquery-form library throughout to handle form submission and response processing. Due to some unpatched potential vulnerabilities in jquery-form, OMERO.web 5.29.2 and earlier may be susceptible to XSS attacks. ### Patches User should upgrade OMERO.web to 5.29.3 or higher. ### Workarounds None. ### Resources https://github.com/jquery-form/form/issues/604

### Summary The BIP-322 signature verification does not enforce the SIGHASH value to be SIGHASH_ALL, and therefore is not strictly following the [spec](https://bips.dev/322/). ### Impact Non-compliant BIP-322 signatures in proof of possessions can be accepted by the chain.

### Summary Adversarial validators can send large vote extensions by using non-existing protobuf tags. This will result in the rejection of the subsequent block proposal. Eventually, all block proposals will be rejected by all validators. ### Impact A small group of adversarial validators can cause a chain halt.

### Summary Multiple path traversal and unsafe path handling vulnerabilities were discovered in eKuiper prior to the fixes implemented in PR [lf-edge/ekuiper#3911](https://github.com/lf-edge/ekuiper/pull/3911). The issues allow attacker-controlled input (rule names, schema versions, plugin names, uploaded file names, and ZIP entries) to influence file system paths used by the application. In vulnerable deployments, this can permit files to be created, overwritten, or extracted outside the intended directories, potentially enabling disclosure of sensitive files, tampering with configuration or plugin binaries, denial of service, or other host compromise scenarios. Several components used unvalidated user input when constructing filesystem paths or when extracting archives. In each case, input was accepted and used directly in path operations (join, create, delete, extract) without sufficient sanitization or canonicalization, allowing the input to include path separators, `..` segments,...

### Impact An attacker who uses this vulnerability can craft a PDF which leads to a memory usage of up to 1 GB per stream. This requires parsing the content stream of a page using the LZWDecode filter. This is a follow up to [GHSA-jfx9-29x2-rv3j](https://github.com/py-pdf/pypdf/security/advisories/GHSA-jfx9-29x2-rv3j) to align the default limit with the one for *zlib*. ### Patches This has been fixed in [pypdf==6.4.0](https://github.com/py-pdf/pypdf/releases/tag/6.4.0). ### Workarounds If users cannot upgrade yet, use the line below to overwrite the default in their code: ```python pypdf.filters.LZW_MAX_OUTPUT_LENGTH = 75_000_000 ```

### Summary Inserting unsanitized data into the blog tag field in Formwork CMS results in stored cross‑site scripting (XSS). Any user with credentials to the Formwork CMS who accesses or edits an affected blog post will have attacker‑controlled script executed in their browser. Because the issue is persistent and impacts privileged administrative workflows, the severity is elevated. ### Details Formwork CMS fails to properly sanitize data inserted into tags, before saving them and rendering them into the edit blog interface. When a specially crafted tag becomes saved as a tag into the system, it is unable to be removed. Any attempt to remove the tag from the affected post, causes the XSS to trigger once again. Additionally, once the malicious tag is present, managing standard tags becomes impossible. This is due to script execution on attempted modification. This leads to a form of interface lockout where the payload continually reinserts itself due to the stored, unsafe rendering....