Enterprise Communications Broker Oracle Enterprise Communications Broker

Do you want an email whenever new security vulnerabilities are reported in Oracle Enterprise Communications Broker?

By the Year

In 2022 there have been 0 vulnerabilities in Oracle Enterprise Communications Broker . Last year Enterprise Communications Broker had 2 security vulnerabilities published. Right now, Enterprise Communications Broker is on track to have less security vulnerabilities in 2022 than it did last year.

Year Vulnerabilities Average Score
2022 0 0.00
2021 2 6.25
2020 3 6.93
2019 4 7.65
2018 3 9.13

It may take a day or so for new Enterprise Communications Broker vulnerabilities to show up in the stats or in the list of recent security vulnerabilties. Additionally vulnerabilities may be tagged under a different product or component name.

Recent Oracle Enterprise Communications Broker Security Vulnerabilities

Lodash versions prior to 4.17.21 are vulnerable to Command Injection

CVE-2021-23337 7.2 - High - February 15, 2021

Lodash versions prior to 4.17.21 are vulnerable to Command Injection via the template function.

Command Injection

Lodash versions prior to 4.17.21 are vulnerable to Regular Expression Denial of Service (ReDoS)

CVE-2020-28500 5.3 - Medium - February 15, 2021

Lodash versions prior to 4.17.21 are vulnerable to Regular Expression Denial of Service (ReDoS) via the toNumber, trim and trimEnd functions.

The X.509 GeneralName type is a generic type for representing different types of names

CVE-2020-1971 5.9 - Medium - December 08, 2020

The X.509 GeneralName type is a generic type for representing different types of names. One of those name types is known as EDIPartyName. OpenSSL provides a function GENERAL_NAME_cmp which compares different instances of a GENERAL_NAME to see if they are equal or not. This function behaves incorrectly when both GENERAL_NAMEs contain an EDIPARTYNAME. A NULL pointer dereference and a crash may occur leading to a possible denial of service attack. OpenSSL itself uses the GENERAL_NAME_cmp function for two purposes: 1) Comparing CRL distribution point names between an available CRL and a CRL distribution point embedded in an X509 certificate 2) When verifying that a timestamp response token signer matches the timestamp authority name (exposed via the API functions TS_RESP_verify_response and TS_RESP_verify_token) If an attacker can control both items being compared then that attacker could trigger a crash. For example if the attacker can trick a client or server into checking a malicious certificate against a malicious CRL then this may occur. Note that some applications automatically download CRLs based on a URL embedded in a certificate. This checking happens prior to the signatures on the certificate and CRL being verified. OpenSSL's s_server, s_client and verify tools have support for the "-crl_download" option which implements automatic CRL downloading and this attack has been demonstrated to work against those tools. Note that an unrelated bug means that affected versions of OpenSSL cannot parse or construct correct encodings of EDIPARTYNAME. However it is possible to construct a malformed EDIPARTYNAME that OpenSSL's parser will accept and hence trigger this attack. All OpenSSL 1.1.1 and 1.0.2 versions are affected by this issue. Other OpenSSL releases are out of support and have not been checked. Fixed in OpenSSL 1.1.1i (Affected 1.1.1-1.1.1h). Fixed in OpenSSL 1.0.2x (Affected 1.0.2-1.0.2w).

NULL Pointer Dereference

Prototype pollution attack when using _.zipObjectDeep in lodash before 4.17.20.

CVE-2020-8203 7.4 - High - July 15, 2020

Prototype pollution attack when using _.zipObjectDeep in lodash before 4.17.20.

Prototype Pollution

In nghttp2 before version 1.41.0, the overly large HTTP/2 SETTINGS frame payload causes denial of service

CVE-2020-11080 7.5 - High - June 03, 2020

In nghttp2 before version 1.41.0, the overly large HTTP/2 SETTINGS frame payload causes denial of service. The proof of concept attack involves a malicious client constructing a SETTINGS frame with a length of 14,400 bytes (2400 individual settings entries) over and over again. The attack causes the CPU to spike at 100%. nghttp2 v1.41.0 fixes this vulnerability. There is a workaround to this vulnerability. Implement nghttp2_on_frame_recv_callback callback, and if received frame is SETTINGS frame and the number of settings entries are large (e.g., > 32), then drop the connection.

Improper Neutralization

Some HTTP/2 implementations are vulnerable to window size manipulation and stream prioritization manipulation

CVE-2019-9511 7.5 - High - August 13, 2019

Some HTTP/2 implementations are vulnerable to window size manipulation and stream prioritization manipulation, potentially leading to a denial of service. The attacker requests a large amount of data from a specified resource over multiple streams. They manipulate window size and stream priority to force the server to queue the data in 1-byte chunks. Depending on how efficiently this data is queued, this can consume excess CPU, memory, or both.

Allocation of Resources Without Limits or Throttling

Some HTTP/2 implementations are vulnerable to resource loops, potentially leading to a denial of service

CVE-2019-9513 7.5 - High - August 13, 2019

Some HTTP/2 implementations are vulnerable to resource loops, potentially leading to a denial of service. The attacker creates multiple request streams and continually shuffles the priority of the streams in a way that causes substantial churn to the priority tree. This can consume excess CPU.

An allocation of memory without limits

CVE-2018-16865 7.8 - High - January 11, 2019

An allocation of memory without limits, that could result in the stack clashing with another memory region, was discovered in systemd-journald when many entries are sent to the journal socket. A local attacker, or a remote one if systemd-journal-remote is used, may use this flaw to crash systemd-journald or execute code with journald privileges. Versions through v240 are vulnerable.

Allocation of Resources Without Limits or Throttling

An allocation of memory without limits

CVE-2018-16864 7.8 - High - January 11, 2019

An allocation of memory without limits, that could result in the stack clashing with another memory region, was discovered in systemd-journald when a program with long command line arguments calls syslog. A local attacker may use this flaw to crash systemd-journald or escalate his privileges. Versions through v240 are vulnerable.

Allocation of Resources Without Limits or Throttling

stdlib/canonicalize.c in the GNU C Library (aka glibc or libc6) 2.27 and earlier

CVE-2018-11236 9.8 - Critical - May 18, 2018

stdlib/canonicalize.c in the GNU C Library (aka glibc or libc6) 2.27 and earlier, when processing very long pathname arguments to the realpath function, could encounter an integer overflow on 32-bit architectures, leading to a stack-based buffer overflow and, potentially, arbitrary code execution.

Memory Corruption

An AVX-512-optimized implementation of the mempcpy function in the GNU C Library (aka glibc or libc6) 2.27 and earlier may write data beyond the target buffer

CVE-2018-11237 7.8 - High - May 18, 2018

An AVX-512-optimized implementation of the mempcpy function in the GNU C Library (aka glibc or libc6) 2.27 and earlier may write data beyond the target buffer, leading to a buffer overflow in __mempcpy_avx512_no_vzeroupper.

Memory Corruption

An integer overflow in the implementation of the posix_memalign in memalign functions in the GNU C Library (aka glibc or libc6) 2.26 and earlier could cause these functions to return a pointer to a heap area

CVE-2018-6485 9.8 - Critical - February 01, 2018

An integer overflow in the implementation of the posix_memalign in memalign functions in the GNU C Library (aka glibc or libc6) 2.26 and earlier could cause these functions to return a pointer to a heap area that is too small, potentially leading to heap corruption.

Memory Corruption

Stay on top of Security Vulnerabilities

Want an email whenever new vulnerabilities are published for Red Hat Enterprise Linux Workstation or by Oracle? Click the Watch button to subscribe.

Oracle
Vendor

subscribe