Raw vector
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HSummary
CVE-2022-23302 is a high-severity Deserialization of Untrusted Data (CWE-502) vulnerability in Oracle Business Intelligence. Its CVSS base score is 8.8 (High).
Operationally, ranked in the top 0.9% of CVEs by exploit likelihood; it is not currently listed in the CISA KEV catalog.
The strongest mitigations our analysis identified map to CM-5 (Access Restrictions for Change) and SA-22 (Unsupported System Components) — 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.
JMSSink in all versions of Log4j 1.x is vulnerable to deserialization of untrusted data when the attacker has write access to the Log4j configuration or when the configuration references an LDAP service under attacker control. The flaw allows an attacker to supply a TopicConnectionFactoryBindingName value that triggers JNDI lookups, resulting in remote code execution in the same manner as CVE-2021-4104. The issue affects only Log4j 1.x deployments that explicitly enable JMSSink, which is not the default configuration; Apache Log4j 1.2 reached end of life in August 2015.
An attacker with the ability to modify the logging configuration or to influence an LDAP server referenced by that configuration can achieve arbitrary code execution on the affected application host. The vulnerability carries a CVSS 3.1 score of 8.8, reflecting network-accessible exploitation with low attack complexity and high impact on confidentiality, integrity, and availability.
Advisories from Apache, NetApp, and Oracle state that users should migrate to Log4j 2, which resolves this and numerous other issues present in the 1.x series. The project documentation explicitly notes that Log4j 1.2 is no longer maintained.
EPSS for the CVE rose from a low baseline to a peak of 0.0763 on 2025-01-22 before receding to the current value of 0.0078, indicating a measurable increase in observed exploitation interest after public disclosure.
OWASP Top 10 for Web (2025)
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2022-0721
Vulnerability Data
JMSSink in all versions of Log4j 1.x is vulnerable to deserialization of untrusted data when the attacker has write access to the Log4j configuration or if the configuration references an LDAP service the attacker has access to. The attacker can…
more
provide a TopicConnectionFactoryBindingName configuration causing JMSSink to perform JNDI requests that result in remote code execution in a similar fashion to CVE-2021-4104. Note this issue only affects Log4j 1.x when specifically configured to use JMSSink, 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.
- CWE(s)
Related Threats
Likely ATT&CK TechniquesAI
Techniques this vulnerability likely enables, inferred from its description, weakness type, and attributed-actor tradecraft. Confidence is per-technique.
CVEs Like This One
Affected Assets
Mitigating Controls
Control response
Mitigating Controls (NIST 800-53 r5) AI
Directly requires replacement of the unsupported Log4j 1.2 component whose JMSSink deserialization flaw is the root cause.
Enforces access restrictions that block unauthorized modification of the Log4j configuration file or referenced LDAP settings needed to trigger the JNDI lookup.
Least-functionality principle disables or removes the non-default JMSSink feature that enables the remote-code-execution path.
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.