OpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. In versions 3.3.2 through 3.3.0, there is a heap-based buffer overflow during a write operation when decompressing ZIPS-packed deep scan-line EXR files with a maliciously forged chunk header. This is fixed in version 3.3.3.

Read more

MaterialX is an open standard for the exchange of rich material and look-development content across applications and renderers. In version 1.39.2, 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. This is fixed in version 1.39.3.

Read more

MaterialX is an open standard for the exchange of rich material and look-development content across applications and renderers. In version 1.39.2, 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. This is fixed in version 1.39.3.

Read more

This vulnerability allows remote attackers to bypass authentication on affected installations of Samsung MagicINFO 9 Server. The specific flaw exists within the downloadChangedFiles function. The issue results from the lack of proper validation of a user-supplied path prior to using it in file operations, allowing attackers to download from a remote origin a Web Shell and execute arbitrary code on the MagicINFO Server.

Read more

This vulnerability allows remote attackers to execute arbitrary code on affected installations of Samsung MagicINFO 9 Server. Authentication is not required to exploit this vulnerability. The specific flaw exists within the MagicInfoWebAuthorClient app. The issue results from the lack of proper validation of user-supplied data, which can allow the upload of arbitrary files. An attacker can leverage this vulnerability to execute code in the context of SYSTEM.

Read more

A library injection issue was addressed with additional restrictions. This issue is fixed in macOS Sequoia 15.4, macOS Sonoma 14.7.5, macOS Ventura 13.7.5. Apps that appear to use App Sandbox may be able to launch without restrictions.

Read more

In OpenVSX version v0.9.0 to v0.20.0, the /user/namespace/{namespace}/details API allows a user to edit all namespace details, even if the user is not a namespace Owner or Contributor. The details include: name, description, website, support link and social media links. The same issues existed in /user/namespace/{namespace}/details/logo and allowed a user to change the logo.

Read more

CIE.AspNetCore.Authentication is affected by a SAML Response Signature Verification Bypass. An attacker could create an arbitrary SAML response that would be accepted by SPs using vulnerable SDKs, allowing him to impersonate any Spid and/or CIE user. This issue has been addressed in version 2.1.0 and all users are advised to upgrade. There are no known workarounds for this vulnerability.

Read more

SPID.AspNetCore.Authentication is an AspNetCore Remote Authenticator for SPID. Authentication using Spid and CIE is based on the SAML2 standard which provides two entities: Identity Provider (IDP): the system that authenticates users and provides identity information (SAML affirmation) to the Service Provider, in essence, is responsible for the management of the credentials and identity of users; Service Provider (SP): the system that provides a service to the user and relies on the Identity Provider to authenticate the user, receives SAML assertions from the IdP to grant access to resources. The validation logic of the signature is central as it ensures that you cannot create a SAML response with arbitrary assertions and then impersonate other users. There is no guarantee that the first signature refers to the root object, it follows that if an attacker injects an item signed as the first element, all other signatures will not be verified. The only requirement is to have an XML element legitimately signed by the IdP, a condition that is easily met using the IdP's public metadata. An attacker could create an arbitrary SAML response that would be accepted by SPs using vulnerable SDKs, allowing him to impersonate any Spid and/or CIE user. This vulnerability has been addressed in version 3.4.0 and all users are advised to upgrade. There are no known workarounds for this vulnerability.

Read more

Karmada is a Kubernetes management system that allows users to run cloud-native applications across multiple Kubernetes clusters and clouds. Prior to version 1.12.0, both in karmadactl and karmada-operator, it is possible to supply a filesystem path, or an HTTP(s) URL to retrieve the custom resource definitions(CRDs) needed by Karmada. The CRDs are downloaded as a gzipped tarfile and are vulnerable to a TarSlip vulnerability. An attacker able to supply a malicious CRD file into a Karmada initialization could write arbitrary files in arbitrary paths of the filesystem. From Karmada version 1.12.0, when processing custom CRDs files, CRDs archive verification is utilized to enhance file system robustness. A workaround is available. Someone who needs to set flag `--crd` to customize the CRD files required for Karmada initialization when using `karmadactl init` to set up Karmada can manually inspect the CRD files to check whether they contain sequences such as `../` that would alter file paths, to determine if they potentially include malicious files. When using karmada-operator to set up Karmada, one must upgrade one's karmada-operator to one of the fixed versions.

Read more