|
CVE-2026-59889
|
Medium
|
2026-07-14
|
Protected by RASP
|
No public exploit
|
jackson-databind contains the general-purpose data-binding functionality and tree-model for Jackson Data Processor. From 2.18.0 until 2.18.9, 2.21.5, 2.22.1, 3.1.5, and 3.2.1, UnwrappedPropertyHandler.processUnwrapped() replays buffered JSON for a @JsonUnwrapped property and calls prop.deserializeAndSet() without a prop.visibleInView(ctxt.getActiveView()) guard, allowing a property annotated with both @JsonView and @JsonUnwrapped to be written from attacker JSON under a less-privileged active view. This issue is fixed in versions 2.18.9, 2.21.5, 2.22.1, 3.1.5, and 3.2.1.
|
|
CVE-2026-41855
|
Critical
|
2026-06-09
|
Protected by RASP
|
No public exploit
|
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.
|
|
CVE-2026-42779
|
Critical
|
2026-05-01
|
Protected by RASP
|
Proof of concept only
|
The fix for CVE-2026-41635 was not applied to the 2.1.X and 2.2.X branches. Here was the original issue description:
Apache MINA's AbstractIoBuffer.resolveClass() contains two branches, one of them (for static classes or primitive types) does not check the class at all, bypassing the classname allowlist and allowing arbitrary code to be executed.
The fix checks if the class is present in the accepted class filter before calling Class.forName().
Affected versions are Apache MINA 2.1.0 <= 2.1.11, and 2.2.0 <= 2.2.6.
The problem is resolved in Apache MINA 2.1.12, and 2.2.7 by
applying the classname allowlist earlier.
Affected are applications using Apache MINA that call IoBuffer.getObject().
Applications using Apache MINA are advised to upgrade.
|
|
CVE-2026-33929
|
Medium
|
2026-04-14
|
Protected by RASP
|
No public exploit
|
Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') vulnerability in Apache PDFBox Examples.
This issue affects the
ExtractEmbeddedFiles example in Apache PDFBox: from 2.0.24 through 2.0.36, from 3.0.0 through 3.0.7.
Users are recommended to update to version 2.0.37 or 3.0.8 once
available. Until then, they should apply the fix provided in GitHub PR
427.
The ExtractEmbeddedFiles example contained a path traversal vulnerability (CWE-22) mentioned in CVE-2026-23907. However the change in the releases 2.0.36 and 3.0.7 is flawed because it doesn't consider the file path separator. Because of that, a user having writing rights on /home/ABC could be victim to a malicious PDF resulting in a write attempt to any path starting with /home/ABC, e.g. "/home/ABCDEF".
Users who have copied this example into their production code should apply the mentioned change. The example
has been changed accordingly and is available in the project repository.
|
|
CVE-2023-26464
|
High
|
2023-03-10
|
Protected by RASP
|
No public exploit
|
** UNSUPPORTED WHEN ASSIGNED **
When using the Chainsaw or SocketAppender components with Log4j 1.x on JRE less than 1.7, an attacker that manages to cause a logging entry involving a specially-crafted (ie, deeply nested)
hashmap or hashtable (depending on which logging component is in use) to be processed could exhaust the available memory in the virtual machine and achieve Denial of Service when the object is deserialized.
This issue affects Apache Log4j before 2. Affected users are recommended to update to Log4j 2.x.
NOTE: This vulnerability only affects products that are no longer supported by the maintainer.
|
|
CVE-2022-34169
|
High
|
2022-07-19
|
Protected by RASP
|
Proof of concept only
|
The Apache Xalan Java XSLT library is vulnerable to an integer truncation issue when processing malicious XSLT stylesheets. This can be used to corrupt Java class files generated by the internal XSLTC compiler and execute arbitrary Java bytecode. Users are recommended to update to version 2.7.3 or later. Note: Java runtimes (such as OpenJDK) include repackaged copies of Xalan.
|
|
CVE-2022-23305
|
Critical
|
2022-01-18
|
Protected by RASP
|
Proof of concept only
|
By design, the JDBCAppender in Log4j 1.2.x accepts an SQL statement as a configuration parameter where the values to be inserted are converters from PatternLayout. The message converter, %m, is likely to always be included. This allows attackers to manipulate the SQL by entering crafted strings into input fields or headers of an application that are logged allowing unintended SQL queries to be executed. Note this issue only affects Log4j 1.x when specifically configured to use the JDBCAppender, which is not the default. Beginning in version 2.0-beta8, the JDBCAppender was re-introduced with proper support for parameterized SQL queries and further customization over the columns written to in logs. Apache Log4j 1.2 reached end of life in August 2015. Users should upgrade to Log4j 2 as it addresses numerous other issues from the previous versions.
|
|
CVE-2021-4104
|
High
|
2021-12-14
|
Protected by RASP
|
Proof of concept only
|
JMSAppender in Log4j 1.2 is vulnerable to deserialization of untrusted data when the attacker has write access to the Log4j configuration. The attacker can provide TopicBindingName and TopicConnectionFactoryBindingName configurations causing JMSAppender to perform JNDI requests that result in remote code execution in a similar fashion to CVE-2021-44228. Note this issue only affects Log4j 1.2 when specifically configured to use JMSAppender, which is not the default. Apache Log4j 1.2 reached end of life in August 2015. Users should upgrade to Log4j 2 as it addresses numerous other issues from the previous versions.
|