Smaury

**Name of the Vulnerable Software and Affected Versions** OpenEXR versions 3.3.0 through 3.3.2 **Description** OpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. A heap-based buffer overflow occurs during a write operation when decompressing ZIPS-packed deep scan-line EXR files with a maliciously forged chunk header. **Recommendations** Update to version 3.3.3 or later.

**Name of the Vulnerable Software and Affected Versions** MaterialX version 1.39.2 **Description** MaterialX is an open standard for the exchange of rich material and look-development content across applications and renderers. Nested imports of MaterialX files can lead to a crash due to stack memory exhaustion. This occurs because the library lacks a limit on the depth of the "import chain" when parsing file imports, utilizing recursion without depth restrictions. Constructing a deeply nested chain of MaterialX files referencing each other can exhaust the stack memory, causing a process crash. **Recommendations** Update to version 1.39.3 or later.

**Name of the Vulnerable Software and Affected Versions** MaterialX version 1.39.2 **Description** MaterialX is an open standard for the exchange of rich material and look-development content across applications and renderers. When parsing shader nodes in a MTLX file, the MaterialXCore code accesses a potentially null pointer, which can lead to crashes with maliciously crafted files. An attacker could intentionally crash a target program that uses OpenEXR by sending a malicious MTLX file. **Recommendations** Update to version 1.39.3 or later.

**Name of the Vulnerable Software and Affected Versions** MaterialX versions prior to 1.39.3 **Description** MaterialX is an open standard for the exchange of rich material and look-development content across applications and renderers. When parsing shader nodes in a MTLX file, the MaterialXCore code accesses a potentially null pointer, which can lead to crashes with maliciously crafted files. An attacker could intentionally crash a target program that uses MaterialX by sending a malicious MTLX file. **Recommendations** Update to MaterialX version 1.39.3 or later.

**Name of the Vulnerable Software and Affected Versions** MaterialX versions 1.39.2 and below **Description** MaterialX is an open standard for the exchange of rich material and look-development content across applications and renderers. The MaterialX XML parsing logic can potentially crash due to stack exhaustion when parsing an MTLX file with multiple nested nodegraph implementations. An attacker could intentionally crash a target program that uses OpenEXR by sending a malicious MTLX file. **Recommendations** Update to version 1.39.3 or later.

**Name of the Vulnerable Software and Affected Versions** OpenEXR versions prior to 3.3.3 **Description** OpenEXR is an image storage format used in the motion picture industry. Versions prior to 3.3.3 trust unvalidated dataWindow size values from file headers, potentially leading to excessive memory allocation and performance degradation when processing malicious files. **Recommendations** Update to version 3.3.3 or later.

**Name of the Vulnerable Software and Affected Versions** OpenEXR versions 3.3.2 **Description** OpenEXR is an image storage format used in the motion picture industry. A NULL pointer dereference can occur in a write operation when reading a deep scanline image with a large sample count in reduceMemory mode in version 3.3.2, potentially causing a target application to crash. **Recommendations** Update to version 3.3.3 or later.

**Name of the Vulnerable Software and Affected Versions** OpenEXR versions prior to 3.3.3 **Description** OpenEXR, an image storage format used in the motion picture industry, contains a flaw. A heap-based buffer overflow can occur during a read operation when decompressing DWAA-packed scan-line EXR files with a maliciously forged chunk. The issue is due to bad pointer math. **Recommendations** Update to version 3.3.3 or later.

**Name of the Vulnerable Software and Affected Versions** OpenVSX versions v0.9.0 through v0.20.0 **Description** The issue allows a user to edit all namespace details, including name, description, website, support link, and social media links, even if the user is not a namespace Owner or Contributor. This is possible through the `/user/namespace/{namespace}/details` API endpoint and also affects the `/user/namespace/{namespace}/details/logo` endpoint, allowing a user to change the logo. **Recommendations** For OpenVSX versions v0.9.0 through v0.20.0, consider restricting access to the `/user/namespace/{namespace}/details` and `/user/namespace/{namespace}/details/logo` API endpoints to only allow authorized users, such as namespace Owners or Contributors, to edit namespace details and change logos. At the moment, there is no information about a newer version that contains a fix for this vulnerability.

Name of the Vulnerable Software and Affected Versions: SPID.AspNetCore.Authentication versions prior to 3.4.0 Description: The issue is related to the validation logic of SAML assertions in the SPID.AspNetCore.Authentication library. An attacker could create an arbitrary SAML response that would be accepted by Service Providers (SPs) using vulnerable SDKs, allowing them to impersonate any Spid and/or CIE user. The vulnerability is based on the fact that there is no guarantee that the first signature refers to the root object, and if an attacker injects a signed element as the first element, all other signatures will not be verified. The only requirement is to have a legitimately signed XML element from the Identity Provider (IdP), which is easily accomplished using the public metadata of the IdP. Recommendations: For versions prior to 3.4.0, upgrade to version 3.4.0 or later to resolve the issue. As a temporary workaround, consider verifying all signatures within the SAML response and do not accept unsigned XML elements. Restrict access to the vulnerable `VerifySignature` function until a patch is available. Avoid using the `signedDocument` parameter in the affected API endpoint until the issue is resolved.

Name of the Vulnerable Software and Affected Versions: CIE.AspNetCore.Authentication versions prior to 2.1.0 Description: The issue concerns the validation logic of SAML assertions within SAML responses in CIE.AspNetCore.Authentication. In affected versions, there is no guarantee that the first signature refers to the root object, allowing an attacker to inject a signed element as the first element, which would prevent the verification of other signatures. This could enable an attacker to craft an arbitrary SAML response that would be accepted by Service Providers (SPs) using vulnerable SDKs, allowing them to impersonate any Spid and/or CIE user. The only requirement for an attacker is to have a legitimately signed XML element from the Identity Provider (IdP), which can be easily obtained using the public metadata of the IdP. Recommendations: For versions prior to 2.1.0, upgrade to version 2.1.0 or later to address the issue. As a temporary workaround, consider verifying all signatures within the SAML response and not accepting unsigned XML elements to minimize the risk of exploitation. Restrict access to the vulnerable `VerifySignature` function until a patch is available. Avoid using the `signedDocument` parameter in the affected API endpoint until the issue is resolved.

**Name of the Vulnerable Software and Affected Versions** Bref versions prior to 2.1.17 **Description** The issue arises when Bref is used with the Event-Driven Function runtime and the handler is a `RequestHandlerInterface`. During the conversion of a Lambda event to a PSR7 object, if the request is a MultiPart, each part is parsed, and the `Content-Type` header of each part is read using the `Riverline/multipart-parser` library. This library performs slow multi-byte string operations on the header value, specifically using the `mb convert encoding` function with parameters read from the header value. An attacker could send crafted requests to force the server into long operations, resulting in a long billed duration. The attack requires the Lambda to use the Event-Driven Function runtime, implement at least an endpoint accepting POST requests, and the attacker can send requests up to 6MB long. If the Lambda uses a PHP runtime <= php-82, the impact is higher. **Recommendations** For Bref versions prior to 2.1.17, upgrade to version 2.1.17 or later to resolve the issue. As a temporary workaround, consider performing additional validation on the headers parsed via the `StreamedPart::parseHeaderContent` function to allow only legitimate headers with a reasonable length. Restrict access to the `StreamedPart::parseHeaderContent` function until a patch is available. Avoid using the `Content-Type` header in the affected API endpoint until the issue is resolved.

**Name of the Vulnerable Software and Affected Versions** pgAdmin versions prior to 8.4 **Description** The issue is related to a path-traversal vulnerability in the session handling code of pgAdmin, which can lead to unsafe deserialization and remote code execution. This vulnerability can be exploited by an unauthenticated attacker on Windows or an authenticated attacker on POSIX/Linux systems, allowing them to gain code execution. The vulnerability is associated with the incorrect serialization of the `pga4 session` cookie file. **Recommendations** For pgAdmin versions prior to 8.4, update to version 8.4 or later to resolve the issue. As a temporary workaround, consider restricting access to the session handling code to minimize the risk of exploitation. Avoid using the `pga4 session` cookie file until the issue is resolved. At the moment, there is no other information about additional mitigation measures.

**Name of the Vulnerable Software and Affected Versions** Element Android versions 0.91.0 through 1.6.12 **Description** A third-party malicious application installed on the same phone can force Element Android to share files stored under the `files` directory in the application's private data directory to an arbitrary room. The impact of the attack is reduced by the fact that the databases stored in this folder are encrypted. However, it contains some other potentially sensitive information, such as the FCM token. **Recommendations** For Element Android versions 0.91.0 through 1.6.11, update to version 1.6.12 to resolve the issue. For forks of Element Android which have set `android:exported="false"` in the `AndroidManifest.xml` file for the `IncomingShareActivity` activity, no action is required as they are not impacted.

**Name of the Vulnerable Software and Affected Versions** Element Android versions 1.4.3 through 1.6.10 **Description** The issue allows a third-party malicious application to start any internal activity by passing some extra parameters, potentially making Element Android display an arbitrary web page, executing arbitrary JavaScript, bypassing PIN code protection, and enabling account takeover by spawning a login screen to send credentials to an arbitrary home server. **Recommendations** For Element Android versions 1.4.3 through 1.6.10, update to version 1.6.12 to resolve the issue. At the moment, there is no known workaround to mitigate the issue for these versions.

**Name of the Vulnerable Software and Affected Versions** Bref versions prior to 2.1.13 **Description** The issue arises when Bref is used with the Event-Driven Function runtime and the handler is a `RequestHandlerInterface`. In this scenario, the Lambda event is converted to a PSR7 object. During the conversion process, if the request is a MultiPart, each part is parsed, and for each part that contains a file, it is extracted and saved in `/tmp` with a random filename starting with `bref upload `. However, the temporary files are not deleted after the request has been processed, allowing an attacker to fill the Lambda instance disk by performing multiple MultiPart requests containing files. **Recommendations** For versions prior to 2.1.13, update to version 2.1.13 or later to resolve the issue. As a temporary workaround, consider implementing a mechanism to delete the temporary files after the request has been processed and the response has been generated. Restrict access to the `/tmp` directory to minimize the risk of exploitation. Avoid using the `RequestHandlerInterface` handler with the Event-Driven Function runtime until the issue is resolved.

**Name of the Vulnerable Software and Affected Versions** Bref versions prior to 2.1.13 **Description** The vulnerability occurs when Bref is used with the Event-Driven Function runtime and the handler is a `RequestHandlerInterface`. In this scenario, the Lambda event is converted to a PSR7 object. During the conversion process, if the request is a MultiPart, each part is parsed and its content added in the `$files` or `$parsedBody` arrays. The conversion process produces a different output compared to the one of plain PHP when keys ending with an open square bracket (`[`) are used. This difference in body parsing might lead to vulnerabilities and/or undefined behaviors based on the application logic. **Recommendations** For versions prior to 2.1.13, update to version 2.1.13 or later to patch the vulnerability. As a temporary workaround, consider using the PHP function `parse str` to parse the body parameters and mimic the plain PHP behavior. Restrict access to the vulnerable `RequestHandlerInterface` to minimize the risk of exploitation until the issue is resolved.

**Name of the Vulnerable Software and Affected Versions** Bref versions prior to 2.1.13 **Description** The issue arises when Bref is used in combination with an API Gateway with the v2 format, as it does not handle multiple values headers. If PHP generates a response with two headers having the same key but different values, only the latest one is kept. This can lower application security if an application relies on multiple headers with the same key being set for security reasons. For example, if an application sets multiple `Content-Security-Policy` headers, Bref would just reflect the latest one. **Recommendations** For versions prior to 2.1.13, update to version 2.1.13 to resolve the issue. As a temporary workaround, consider concatenating all multiple value headers' values with a comma (`,`) as separator and return a single header with all the values to the API Gateway.

**Name of the Vulnerable Software and Affected Versions** GLPI versions prior to 9.5.13 GLPI versions prior to 10.0.7 **Description** The issue is related to a lack of authorization, allowing a user with the Technician profile to view and generate a personal token for a Super-Admin. This can be exploited to negotiate a GLPI session and hijack the Super-Admin account, resulting in a privilege escalation. **Recommendations** For versions prior to 9.5.13, update to version 9.5.13 or later to resolve the issue. For versions prior to 10.0.7, update to version 10.0.7 or later to resolve the issue. As a temporary workaround, consider restricting access to the personal token generation feature for users with the Technician profile until a patch is applied.

**Name of the Vulnerable Software and Affected Versions** pfSense version 2.5.2 **Description** The issue allows sed data injection in diag routes.php. Authenticated users can inject sed-specific code and write an arbitrary file in an arbitrary location. The data is retrieved by executing the netstat utility, and then its output is parsed via the sed utility. Although common protection mechanisms against command injection are used, such as the escapeshellarg function for the arguments, the sed-specific code injection is still possible. **Recommendations** For pfSense version 2.5.2, consider disabling the diag routes.php functionality until a patch is available to prevent sed data injection. Restrict access to the netstat utility and sed utility to minimize the risk of exploitation. Avoid using the sed utility to parse the output of the netstat utility in the affected diag routes.php file until the issue is resolved.