Raw vector
CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:N/I:L/A:HSummary
CVE-2023-34050 is a medium-severity Deserialization of Untrusted Data (CWE-502) vulnerability in Vmware Spring Advanced Message Queuing Protocol. Its CVSS base score is 5.0 (Medium).
Operationally, exploitation aligns with the MITRE ATT&CK technique Exploit Public-Facing Application (T1190); ranked in the top 27% of CVEs by exploit likelihood; it is not currently listed in the CISA KEV catalog.
Deeper analysis AI-assisted summary
Synthesised by an AI model from the NVD description and linked references — a reading aid, not an authoritative source.
In Spring AMQP versions 1.0.0 to 2.4.16 and 3.0.0 to 3.0.9, the addition of allowed-list patterns for deserializable class names left a default configuration in which all classes could be deserialized when no list was supplied. The issue affects applications that use the SimpleMessageConverter or SerializerMessageConverter without configuring allowed-list patterns, exposing them to deserialization of untrusted data (CWE-502) with a CVSS 3.1 score of 5.0.
An attacker who obtains write access to a RabbitMQ broker can send a message containing a malicious serialized payload. When the vulnerable converter processes the message, the payload is deserialized, enabling the attacker to influence object instantiation and achieve limited integrity impact together with high availability impact on the receiving application.
The Spring security advisory at https://spring.io/security/cve-2023-34050 recommends configuring allowed-list patterns to restrict deserializable classes and upgrading to a patched release. The associated EPSS score has remained at 0.4304 with no material increase since disclosure.
OWASP Top 10 for Web (2025)
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2023-38167
Vulnerability Data
In spring AMQP versions 1.0.0 to 2.4.16 and 3.0.0 to 3.0.9 , allowed list patterns for deserializable class names were added to Spring AMQP, allowing users to lock down deserialization of data in messages from untrusted sources; however by default,…
more
when no allowed list was provided, all classes could be deserialized. Specifically, an application is vulnerable if * the SimpleMessageConverter or SerializerMessageConverter is used * the user does not configure allowed list patterns * untrusted message originators gain permissions to write messages to the RabbitMQ broker to send malicious content
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise Techniques
CVEs Like This One
Affected Assets
Mitigating Controls
Likely Mitigating Controls AI
Per-CVE control mapping for this CVE has not run yet; the list below is derived from the weakness types (CWEs) cited in the NVD entry.
Penetration testing supplies malicious serialized objects, detecting unsafe deserialization and supporting corrective actions.
Evaluation of untrusted data handling (deserialization testing) reveals unsafe processing, which the required remediation process addresses.
Untrusted serialized data can be deserialized and observed inside the chamber, blocking gadget-chain exploitation outside the sandbox.
Validates or rejects untrusted serialized data before deserialization occurs.
Identifies and blocks malicious code introduced through deserialization of untrusted data at system boundaries.
Integrity verification of serialized information can detect tampering before deserialization occurs.
Provenance of associated data allows detection of untrusted sources before deserialization or processing occurs.
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.