React Router is a router for React. In versions 7.0.0 through 7.14.1, when using Framework Mode, a combination of steps could potentially allow unauthorized remote code execution (RCE) through external requests. This attack requires the application code to have an existing prototype pollution vulnerability, which can then be leveraged in a 2-step attack where the second step triggers unauthorized RCE on the remote server. This does not impact applications using Declarative Mode (`<BrowserRouter>`) or Data Mode (`createBrowserRouter/<RouterProvider>`). This is patched in version 7.14.2.

In an untrusted JMS environment, org.springframework.jms.support.converter.MappingJackson2MessageConverter and org.springframework.jms.support.converter.JacksonJsonMessageConverter allow arbitrary class instantiation, which can lead to unauthorized actions via gadget class deserialization. Affected versions: Spring Framework 7.0.0 through 7.0.7; 6.2.0 through 6.2.18; 6.1.0 through 6.1.27; 5.3.0 through 5.3.48.

JsonKafkaHeaderMapper and the deprecated DefaultKafkaHeaderMapper matched type headers against trusted packages using a prefix check, meaning that trusting any package implicitly trusted all of its subpackages. Combined with Jackson's default bean deserialization, a producer could supply crafted header values that caused the consumer to deserialize arbitrary JDK types. Affected versions: Spring for Apache Kafka 4.0.0 through 4.0.5; 3.3.0 through 3.3.15; 3.2.0 through 3.2.13; 2.9.0 through 2.9.13; 2.8.0 through 2.8.11.

JsonPulsarHeaderMapper matched type headers against trusted packages using a prefix check, meaning that trusting any package implicitly trusted all of its subpackages. Additionally, an empty trusted-packages configuration fell back to trusting all packages rather than applying a safe default allow-list. Affected versions: Spring for Apache Pulsar 2.0.0 through 2.0.5; 1.2.0 through 1.2.17; 1.1.0 through 1.1.17.

Spring for GraphQL applications are vulnerable to Unsafe Deserialization when processing paginated GraphQL queries. An attacker can craft a malicious GraphQL request that can lead to Remote Code Execution when the application exposes a paginated (Connection) field and the classpath contains specific classes that can be leveraged during deserialization. Affected versions: Spring for GraphQL 2.0.0 through 2.0.3; 1.4.0 through 1.4.5; 1.3.0 through 1.3.8.

Unauthenticated PHP Object Injection in Laurits <= 1.5.1 versions.

Unauthenticated PHP Object Injection in LuxeDrive <= 1.4 versions.

Unauthenticated PHP Object Injection in Ashtanga <= 1.2 versions.

Unauthenticated PHP Object Injection in Roisin <= 1.4 versions.

Unauthenticated PHP Object Injection in TechLink <= 1.3 versions.

Unauthenticated PHP Object Injection in Léonie <= 1.2.1 versions.

Unauthenticated PHP Object Injection in Esmée <= 1.4 versions.

Unauthenticated PHP Object Injection in Behold <= 1.5 versions.

Unauthenticated PHP Object Injection in Valeska <= 1.2.2 versions.

Unauthenticated PHP Object Injection in Reina <= 2.1 versions.

Unauthenticated PHP Object Injection in EasyMeals <= 1.5.1 versions.

Unauthenticated PHP Object Injection in ShiftUp <= 1.3 versions.

Unauthenticated PHP Object Injection in Eldon <= 1.4.1 versions.

Unauthenticated PHP Object Injection in Manufaktur Solutions <= 1.1.1 versions.

Unauthenticated PHP Object Injection in Zoya <= 1.4 versions.

Unauthenticated PHP Object Injection in Château <= 1.2.1 versions.

Deserialization of Untrusted Data vulnerability in Elated-Themes Aperitif allows Object Injection. This issue affects Aperitif: from n/a through 1.6.

Deserialization of Untrusted Data vulnerability in Elated-Themes Töbel allows Object Injection. This issue affects Töbel: from n/a through 1.8.1.

Deserialization of Untrusted Data vulnerability in Elated-Themes Askka allows Object Injection. This issue affects Askka: from n/a through 1.3.1.

Unauthenticated PHP Object Injection in EmallShop <= 2.4.21 versions.

Unauthenticated PHP Object Injection in Kapee < 1.7.0 versions.

Unauthenticated PHP Object Injection in Alloggio - Hotel Booking <= 2.1.2 versions.

Unauthenticated PHP Object Injection in Fidalgo <= 1.2.2 versions.

Unauthenticated PHP Object Injection in Santé <= 1.5.1 versions.

Unauthenticated PHP Object Injection in Zermatt <= 1.6.1 versions.

Unauthenticated PHP Object Injection in PressMart <= 1.2.26 versions.

Unauthenticated PHP Object Injection in Alukas < 3.0.0 versions.

Unauthenticated PHP Object Injection in Konsept <= 1.9 versions.

Unauthenticated PHP Object Injection in Hiroshi <= 1.5.1 versions.

Unauthenticated PHP Object Injection in SingleMalt <= 1.5 versions.

An issue in Pivotal CRM v.6.6.04.08 allows a remote attacker to execute arbitrary code via the Pivotal.Core.Common.dll and Pivotal.Engine.Client.Services.Conversion.dll components.

OpenTelemetry Java Instrumentation provides OpenTelemetry auto-instrumentation and instrumentation libraries for Java. In versions prior to 2.26.1, the RMI instrumentation registered a custom endpoint that deserialized incoming data without applying serialization filters. On JDK version 16 and earlier, an attacker with network access to a JMX or RMI port on an instrumented JVM could exploit this to potentially achieve remote code execution. All three of the following conditions must be true to exploit this vulnerability: First, OpenTelemetry Java instrumentation is attached as a Java agent (`-javaagent`) on Java 16 or earlier. Second, JMX/RMI port has been explicitly configured via `-Dcom.sun.management.jmxremote.port` and is network-reachable. Third, gadget-chain-compatible library is present on the classpath. This results in arbitrary remote code execution with the privileges of the user running the instrumented JVM. For JDK >= 17, no action is required, but upgrading is strongly encouraged. For JDK < 17, upgrade to version 2.26.1 or later. As a workaround, set the system property `-Dotel.instrumentation.rmi.enabled=false` to disable the RMI integration.

A serialization vulnerability in Zoho ManageEngine Applications Manager before build 13740 allows for remote code execution on Windows via a payload on an SMB share.

The Hash Form – Drag & Drop Form Builder plugin for WordPress is vulnerable to PHP Object Injection in all versions up to, and including, 1.1.0 via deserialization of untrusted input in the 'process_entry' function. This makes it possible for unauthenticated attackers to inject a PHP Object. No known POP chain is present in the vulnerable software. If a POP chain is present via an additional plugin or theme installed on the target system, it could allow the attacker to delete arbitrary files, retrieve sensitive data, or execute code.

In Laravel Framework through 5.5.40 and 5.6.x through 5.6.29, remote code execution might occur as a result of an unserialize call on a potentially untrusted X-XSRF-TOKEN value. This involves the decrypt method in Illuminate/Encryption/Encrypter.php and PendingBroadcast in gadgetchains/Laravel/RCE/3/chain.php in phpggc. The attacker must know the application key, which normally would never occur, but could happen if the attacker previously had privileged access or successfully accomplished a previous attack.

PrinterLogic Web Stack versions 19.1.1.13 SP9 and below deserializes attacker controlled leading to pre-auth remote code execution.

In Gradle Enterprise before 2021.1.3, a crafted request can trigger deserialization of arbitrary unsafe Java objects. The attacker must have the encryption and signing keys.

Apache Karaf allows monitoring of applications and the Java runtime by using the Java Management Extensions (JMX). JMX is a Java RMI based technology that relies on Java serialized objects for client server communication. Whereas the default JMX implementation is hardened against unauthenticated deserialization attacks, the implementation used by Apache Karaf is not protected against this kind of attack. The impact of Java deserialization vulnerabilities strongly depends on the classes that are available within the targets class path. Generally speaking, deserialization of untrusted data does always represent a high security risk and should be prevented. The risk is low as, by default, Karaf uses a limited set of classes in the JMX server class path. It depends of system scoped classes (e.g. jar in the lib folder).

Pterodactyl is an open-source game server management panel built with PHP 7, React, and Go. A malicious user can modify the contents of a `confirmation_token` input during the two-factor authentication process to reference a cache value not associated with the login attempt. In rare cases this can allow a malicious actor to authenticate as a random user in the Panel. The malicious user must target an account with two-factor authentication enabled, and then must provide a correct two-factor authentication token before being authenticated as that user. Due to a validation flaw in the logic handling user authentication during the two-factor authentication process a malicious user can trick the system into loading credentials for an arbitrary user by modifying the token sent to the server. This authentication flaw is present in the `LoginCheckpointController@__invoke` method which handles two-factor authentication for a user. This controller looks for a request input parameter called `confirmation_token` which is expected to be a 64 character random alpha-numeric string that references a value within the Panel's cache containing a `user_id` value. This value is then used to fetch the user that attempted to login, and lookup their two-factor authentication token. Due to the design of this system, any element in the cache that contains only digits could be referenced by a malicious user, and whatever value is stored at that position would be used as the `user_id`. There are a few different areas of the Panel that store values into the cache that are integers, and a user who determines what those cache keys are could pass one of those keys which would cause this code pathway to reference an arbitrary user. At its heart this is a high-risk login bypass vulnerability. However, there are a few additional conditions that must be met in order for this to be successfully executed, notably: 1.) The account referenced by the malicious cache key must have two-factor authentication enabled. An account without two-factor authentication would cause an exception to be triggered by the authentication logic, thusly exiting this authentication flow. 2.) Even if the malicious user is able to reference a valid cache key that references a valid user account with two-factor authentication, they must provide a valid two-factor authentication token. However, due to the design of this endpoint once a valid user account is found with two-factor authentication enabled there is no rate-limiting present, thusly allowing an attacker to brute force combinations until successful. This leads to a third condition that must be met: 3.) For the duration of this attack sequence the cache key being referenced must continue to exist with a valid `user_id` value. Depending on the specific key being used for this attack, this value may disappear quickly, or be changed by other random user interactions on the Panel, outside the control of the attacker. In order to mitigate this vulnerability the underlying authentication logic was changed to use an encrypted session store that the user is therefore unable to control the value of. This completely removed the use of a user-controlled value being used. In addition, the code was audited to ensure this type of vulnerability is not present elsewhere.

It was found that the original fix for log4j CVE-2021-44228 and CVE-2021-45046 in the OpenShift metering hive containers was incomplete, as not all JndiLookup.class files were removed. This CVE only applies to the OpenShift Metering hive container images, shipped in OpenShift 4.8, 4.7 and 4.6.

Yii is an open source PHP web framework. yiisoft/yii before version 1.1.29 are vulnerable to Remote Code Execution (RCE) if the application calls `unserialize()` on arbitrary user input. An attacker may leverage this vulnerability to compromise the host system. A fix has been developed for the 1.1.29 release. Users are advised to upgrade. There are no known workarounds for this vulnerability.

SPIP before 4.4.9 allows Insecure Deserialization in the public area through the table_valeur filter and the DATA iterator, which accept serialized data. An attacker who can place malicious serialized content (a pre-condition requiring prior access or another vulnerability) can trigger arbitrary object instantiation and potentially achieve code execution. The use of serialized data in these components has been deprecated and will be removed in SPIP 5. This vulnerability is not mitigated by the SPIP security screen.

Zumba Json Serializer is a library to serialize PHP variables in JSON format. In versions 3.2.2 and below, the library allows deserialization of PHP objects from JSON using a special @type field. The deserializer instantiates any class specified in the @type field without restriction. When processing untrusted JSON input, this behavior may allow an attacker to instantiate arbitrary classes available in the application. If a vulnerable application passes attacker-controlled JSON into JsonSerializer::unserialize() and contains classes with dangerous magic methods (such as __wakeup() or __destruct()), this may lead to PHP Object Injection and potentially Remote Code Execution (RCE), depending on available gadget chains in the application or its dependencies. This behavior is similar in risk profile to PHP's native unserialize() when used without the allowed_classes restriction. Applications are impacted only if untrusted or attacker-controlled JSON is passed into JsonSerializer::unserialize() and the application or its dependencies contain classes that can be leveraged as a gadget chain. This issue has been fixed in version 3.2.3. If an immediate upgrade isn't feasible, mitigate the vulnerability by never deserializing untrusted JSON with JsonSerializer::unserialize(), validating and sanitizing all JSON input before deserialization, and disabling @type-based object instantiation wherever possible.

Deserialization of Untrusted Data vulnerability in BoldThemes Celeste celeste allows Object Injection.This issue affects Celeste: from n/a through <= 1.3.6.

The REST Plugin in Apache Struts 2.1.1 through 2.3.x before 2.3.34 and 2.5.x before 2.5.13 uses an XStreamHandler with an instance of XStream for deserialization without any type filtering, which can lead to Remote Code Execution when deserializing XML payloads.