Raw vector
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:XSummary
CVE-2024-52046 is a critical-severity Deserialization of Untrusted Data (CWE-502) vulnerability in Apache Mina. Its CVSS base score is 10.0 (Critical).
Operationally, exploitation aligns with the MITRE ATT&CK technique Exploit Public-Facing Application (T1190); ranked in the top 2% of CVEs by exploit likelihood; it is not currently listed in the CISA KEV catalog.
The strongest mitigations our analysis identified map to SA-11 (Developer Testing and Evaluation) and SI-10 (Information Input Validation) — see the control section below for these in your framework.
Deeper analysis AI-assisted summary
Synthesised by an AI model from the NVD description and linked references — a reading aid, not an authoritative source.
The vulnerability is an instance of unsafe deserialization (CWE-502) in the ObjectSerializationDecoder component of Apache MINA. The decoder relies on Java’s native serialization mechanism to handle incoming data via IoBuffer#getObject without input validation or class filtering, enabling attackers to supply malicious serialized objects. It affects MINA core versions 2.0.X, 2.1.X, and 2.2.X; the issue is resolved in releases 2.0.27, 2.1.10, and 2.2.4. An application is exposed only when it explicitly invokes the affected method, which commonly occurs when a ProtocolCodecFilter configured with ObjectSerializationCodecFactory is placed in the filter chain. The FtpServer, SSHd, and Vysper sub-projects are unaffected.
An unauthenticated remote attacker can send a crafted serialized payload over the network to any MINA-based service that processes untrusted input through the vulnerable decoder. Successful exploitation results in arbitrary remote code execution with the privileges of the Java process, corresponding to the maximum CVSS 4.0 score of 10.0.
Apache advisory information states that simply upgrading is insufficient. Operators must also configure the ObjectSerializationDecoder instance to explicitly accept only required classes by calling one of the new accept methods that take a ClassNameMatcher, a Java regexp Pattern, or wildcard patterns; the decoder rejects all classes by default after the fix. The referenced Apache, OpenWall, and NetApp notices reiterate these upgrade-plus-configuration steps.
EPSS for the CVE rose from lower values to a peak of 0.8249 on 2026-02-18 before receding to the current score of 0.5538, indicating post-disclosure exploitation interest that later moderated.
OWASP Top 10 for Web (2025)
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2024-3562
Vulnerability Data
The ObjectSerializationDecoder in Apache MINA uses Java’s native deserialization protocol to process incoming serialized data but lacks the necessary security checks and defenses. This vulnerability allows attackers to exploit the deserialization process by sending specially crafted malicious serialized data, potentially…
more
leading to remote code execution (RCE) attacks. This issue affects MINA core versions 2.0.X, 2.1.X and 2.2.X, and will be fixed by the releases 2.0.27, 2.1.10 and 2.2.4. It's also important to note that an application using MINA core library will only be affected if the IoBuffer#getObject() method is called, and this specific method is potentially called when adding a ProtocolCodecFilter instance using the ObjectSerializationCodecFactory class in the filter chain. If your application is specifically using those classes, you have to upgrade to the latest version of MINA core library. Upgrading will not be enough: you also need to explicitly allow the classes the decoder will accept in the ObjectSerializationDecoder instance, using one of the three new methods: /** * Accept class names where the supplied ClassNameMatcher matches for * deserialization, unless they are otherwise rejected. * * @param classNameMatcher the matcher to use */ public void accept(ClassNameMatcher classNameMatcher) /** * Accept class names that match the supplied pattern for * deserialization, unless they are otherwise rejected. * * @param pattern standard Java regexp */ public void accept(Pattern pattern) /** * Accept the wildcard specified classes for deserialization, * unless they are otherwise rejected. * * @param patterns Wildcard file name patterns as defined by * {@link org.apache.commons.io.FilenameUtils#wildcardMatch(String, String) FilenameUtils.wildcardMatch} */ public void accept(String... patterns) By default, the decoder will reject *all* classes that will be present in the incoming data. Note: The FtpServer, SSHd and Vysper sub-project are not affected by this issue.
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise Techniques
CVEs Like This One
Affected Assets
Mitigating Controls
Mitigating Controls (NIST 800-53 r5) AI
Developer testing and evaluation can uncover deserialization flaws before deployment.
Input validation directly stops deserialization of untrusted data by ensuring inputs are valid before processing.
Engineering principles such as safe deserialization and input sanitization structurally prevent the weakness from being introduced.
Integrity verification tools can detect malformed or tampered serialized data after the fact.
Mitigating Controls (NIST CSF 2.0) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.
PR.PS-02 addresses only post-deployment updates/patching and cannot prevent introduction of unsafe deserialization code, yet it can remediate some instances when the flaw exists in outdated libraries or components.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
Security testing includes validation of deserialization routines and the use of untrusted data, reducing the likelihood that unsafe object reconstruction will be deployed.
Requiring vetted libraries, regular updates and SAST before release reduces the likelihood that deserialization logic will accept and act on attacker-controlled serialized objects.
Regular scanning of third-party libraries and timely patching reduce the likelihood that unsafe deserialization vulnerabilities remain active.
Mandatory malware scanning of data received over networks or storage media intercepts malicious serialized payloads before they are deserialized by the target application.