| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Deserialization of Untrusted Data vulnerability in OpenText™ Directory Services allows Object Injection.
The vulnerability could lead to remote code execution, denial of service, or privilege escalation.
This issue affects Directory Services: before 24.4.16, from 25.1 before 25.1.9, from 25.2 before 25.2.9, from 25.3 before 25.3.8, from 25.4 before 25.4.5, from 26.1 before 26.1.2. |
| Deserialization of untrusted data in Microsoft Office Outlook allows an unauthorized attacker to perform spoofing over a network. |
| Deserialization of untrusted data in Azure SDK allows an unauthorized attacker to execute code over a network. |
| Altec DocLink (now maintained by Beyond Limits Inc.) version 4.0.336.0 exposes insecure .NET Remoting endpoints over TCP and HTTP/SOAP via Altec.RDCHostService.exe using the ObjectURI "doclinkServer.soap". The service does not require authentication and is vulnerable to unsafe object unmarshalling, allowing remote attackers to read arbitrary files from the underlying system by specifying local file paths. Additionally, attackers can coerce SMB authentication via UNC paths and write arbitrary files to server locations. Because writable paths may be web-accessible under IIS, this can result in unauthenticated remote code execution or denial of service through file overwrite. |
| seroval facilitates JS value stringification, including complex structures beyond JSON.stringify capabilities. In versions 1.4.0 and below, improper input handling in the JSON deserialization component can lead to arbitrary JavaScript code execution. Exploitation is possible via overriding constant value and error deserialization, allowing indirect access to unsafe JS evaluation. At minimum, attackers need the ability to perform 4 separate requests on the same function, and partial knowledge of how the serialized data is used during later runtime processing. This vulnerability affects the fromJSON and fromCrossJSON functions in a client-to-server transmission scenario. This issue has been fixed in version 1.4.0. |
| Uncontrolled Resource Consumption, Deserialization of Untrusted Data vulnerability in hexpm hex_core (hex_api modules), hexpm hex (mix_hex_api modules), erlang rebar3 (r3_hex_api modules) allows Object Injection, Excessive Allocation. This vulnerability is associated with program files src/hex_api.erl, src/mix_hex_api.erl, apps/rebar/src/vendored/r3_hex_api.erl and program routines hex_core:request/4, mix_hex_api:request/4, r3_hex_api:request/4.
This issue affects hex_core: from 0.1.0 before 0.12.1; hex: from 2.3.0 before 2.3.2; rebar3: from 3.9.1 before 3.27.0. |
| Deserialization of untrusted data in the LanguageModel class of Flair from versions 0.4.1 to latest are vulnerable to arbitrary code execution when loading a malicious model. |
| c3p0, a JDBC Connection pooling library, is vulnerable to attack via maliciously crafted Java-serialized objects and `javax.naming.Reference` instances. Several c3p0 `ConnectionPoolDataSource` implementations have a property called `userOverridesAsString` which conceptually represents a `Map<String,Map<String,String>>`. Prior to v0.12.0, that property was maintained as a hex-encoded serialized object. Any attacker able to reset this property, on an existing `ConnectionPoolDataSource` or via maliciously crafted serialized objects or `javax.naming.Reference` instances could be tailored execute unexpected code on the application's `CLASSPATH`. The danger of this vulnerability was strongly magnified by vulnerabilities in c3p0's main dependency, mchange-commons-java. This library includes code that mirrors early implementations of JNDI functionality, including ungated support for remote `factoryClassLocation` values. Attackers could set c3p0's `userOverridesAsString` hex-encoded serialized objects that include objects "indirectly serialized" via JNDI references. Deserialization of those objects and dereferencing of the embedded `javax.naming.Reference` objects could provoke download and execution of malicious code from a remote `factoryClassLocation`. Although hazard presented by c3p0's vulnerabilites are exarcerbated by vulnerabilities in mchange-commons-java, use of Java-serialized-object hex as the format for a writable Java-Bean property, of objects that may be exposed across JNDI interfaces, represents a serious independent fragility. The `userOverridesAsString` property of c3p0 `ConnectionPoolDataSource` classes has been reimplemented to use a safe CSV-based format, rather than rely upon potentially dangerous Java object deserialization. c3p0-0.12.0+ and above depend upon mchange-commons-java 0.4.0+, which gates support for remote `factoryClassLocation` values by configuration parameters that default to restrictive values. c3p0 additionally enforces the new mchange-commons-java `com.mchange.v2.naming.nameGuardClassName` to prevent injection of unexpected, potentially remote JNDI names. There is no supported workaround for versions of c3p0 prior to 0.12.0. |
| The OVRI Payment plugin for WordPress contains malicious .htaccess files in version 1.7.0. The files contain directives to prevent the execution of certain scripts while allowing execution of known malicious PHP files. If moved outside of the plugin's directory, they may interfere with the proper function of a site. |
| IM-LogicDesigner module of intra-mart Accel Platform contains insecure deserialization issue. This can be exploited only when IM-LogicDesigner is deployed on the system. Arbitrary code may be executed when some crafted file is imported by a user with the administrative privilege. |
| mchange-commons-java, a library that provides Java utilities, includes code that mirrors early implementations of JNDI functionality, including support for remote `factoryClassLocation` values, by which code can be downloaded and invoked within a running application. If an attacker can provoke an application to read a maliciously crafted `jaxax.naming.Reference` or serialized object, they can provoke the download and execution of malicious code. Implementations of this functionality within the JDK were disabled by default behind a System property that defaults to `false`, `com.sun.jndi.ldap.object.trustURLCodebase`. However, since mchange-commons-java includes an independent implementation of JNDI derefencing, libraries (such as c3p0) that resolve references via that implementation could be provoked to download and execute malicious code even after the JDK was hardened. Mirroring the JDK patch, mchange-commons-java's JNDI functionality is gated by configuration parameters that default to restrictive values starting in version 0.4.0. No known workarounds are available. Versions prior to 0.4.0 should be avoided on application CLASSPATHs. |
| LangGraph Checkpoint defines the base interface for LangGraph checkpointers. Prior to version 4.0.0, a Remote Code Execution vulnerability exists in LangGraph's caching layer when applications enable cache backends that inherit from `BaseCache` and opt nodes into caching via `CachePolicy`. Prior to `langgraph-checkpoint` 4.0.0, `BaseCache` defaults to `JsonPlusSerializer(pickle_fallback=True)`. When msgpack serialization fails, cached values can be deserialized via `pickle.loads(...)`. Caching is not enabled by default. Applications are affected only when the application explicitly enables a cache backend (for example by passing `cache=...` to `StateGraph.compile(...)` or otherwise configuring a `BaseCache` implementation), one or more nodes opt into caching via `CachePolicy`, and the attacker can write to the cache backend (for example a network-accessible Redis instance with weak/no auth, shared cache infrastructure reachable by other tenants/services, or a writable SQLite cache file). An attacker must be able to write attacker-controlled bytes into the cache backend such that the LangGraph process later reads and deserializes them. This typically requires write access to a networked cache (for example a network-accessible Redis instance with weak/no auth or shared cache infrastructure reachable by other tenants/services) or write access to local cache storage (for example a writable SQLite cache file via permissive file permissions or a shared writable volume). Because exploitation requires write access to the cache storage layer, this is a post-compromise / post-access escalation vector. LangGraph Checkpoint 4.0.0 patches the issue. |
| Deserialization of Untrusted Data vulnerability in Stylemix uListing ulisting allows Object Injection.This issue affects uListing: from n/a through <= 2.2.0. |
| SolarWinds Web Help Desk was found to be susceptible to an untrusted data deserialization vulnerability that could lead to remote code execution, which would allow an attacker to run commands on the host machine. This could be exploited without authentication. |
| SolarWinds Web Help Desk was found to be susceptible to an unauthenticated AjaxProxy deserialization remote code execution vulnerability that, if exploited, would allow an attacker to run commands on the host machine. This vulnerability is a patch bypass of CVE-2024-28988, which in turn is a patch bypass of CVE-2024-28986. |
| A vulnerability was determined in PluXml up to 5.8.22. Affected is the function FileCookieJar::__destruct of the file core/admin/medias.php of the component Media Management Module. Executing a manipulation of the argument File can lead to deserialization. The attack can be launched remotely. The exploit has been publicly disclosed and may be utilized. The vendor was informed early about this issue and announced that "[w]e fix this issue in the next version 5.8.23". A patch for it is ready. |
| Bio-Formats versions up to and including 8.3.0 perform unsafe Java deserialization of attacker-controlled memoization cache files (.bfmemo) during image processing. The loci.formats.Memoizer class automatically loads and deserializes memo files associated with images without validation, integrity checks, or trust enforcement. An attacker who can supply a crafted .bfmemo file alongside an image can trigger deserialization of untrusted data, which may result in denial of service, logic manipulation, or potentially remote code execution in environments where suitable gadget chains are present on the classpath. |
| Calero VeraSMART versions prior to 2022 R1 expose an unauthenticated .NET Remoting HTTP service on TCP port 8001. The service publishes default ObjectURIs (including EndeavorServer.rem and RemoteFileReceiver.rem) and permits the use of SOAP and binary formatters with TypeFilterLevel set to Full. An unauthenticated remote attacker can invoke the exposed remoting endpoints to perform arbitrary file read and write operations via the WebClient class. This allows retrieval of sensitive files such as WebRoot\\web.config, which may disclose IIS machineKey validation and decryption keys. An attacker can use these keys to generate a malicious ASP.NET ViewState payload and achieve remote code execution within the IIS application context. Additionally, supplying a UNC path can trigger outbound SMB authentication from the service account, potentially exposing NTLMv2 hashes for relay or offline cracking. |
| Deserialization of Untrusted Data vulnerability in Apache Camel LevelDB component.
The Camel-LevelDB DefaultLevelDBSerializer class deserializes data read from the LevelDB aggregation repository using java.io.ObjectInputStream without applying any ObjectInputFilter or class-loading restrictions. An attacker who can write to the LevelDB database files used by a Camel application can inject a crafted serialized Java object that, when deserialized during normal aggregation repository operations, results in arbitrary code execution in the context of the application.
This issue affects Apache Camel: from 4.10.0 before 4.10.8, from 4.14.0 before 4.14.5, from 4.15.0 before 4.18.0.
Users are recommended to upgrade to version 4.18.0, which fixes the issue. For the 4.10.x LTS releases, users are recommended to upgrade to 4.10.9, while for 4.14.x LTS releases, users are recommended to upgrade to 4.14.5 |
| A maliciously crafted QPY file can potential execute arbitrary-code embedded in the payload without privilege escalation when deserialising QPY formats < 13. A python process calling Qiskit 0.18.0 through 1.4.1's `qiskit.qpy.load()` function could potentially execute any arbitrary Python code embedded in the correct place in the binary file as part of specially constructed payload. |
