VRT Sign in

High Oracle Retail Applications Posting (Spring-LDAP) CVEs

1 CVE

Look up CVE IDs Status Exploitation Severity

Reset

Overview 1 match · 0 protected · 0 exploited · 0 CISA KEV · 0 public PoC · 0 EPSS ≥ 0.5

1match 0protected0.0% 0exploited0.0% 0CISA KEV0.0% 0public PoC0.0% 0EPSS ≥ 0.50.0%

Protected by Waratek 0 0.0% Rule in development 0 0.0% Mitigation candidate 0 0.0% No exploit published 1 100.0%

Critical 0 0.0% High 1 100.0% Medium 0 0.0% Low 0 0.0% None 0 0.0% Unknown 0 0.0%

blocked by ARMR today 0 0.0% partly blocked 0 0.0% not blocked 1 100.0% not established 0 0.0% unrecorded 0 0.0%

Exploited 0 0.0% Working exploit published 0 0.0% Proof of concept only 0 0.0% Forecast only 0 0.0% No public exploit 1 100.0%

split by StatusSeverityProtectionExploit maturity peak 1 / month

Nov 171 No exploit published1 High1 not blocked1 No public exploit1

Nov 17

1 match Sign in to download these CVEs as CSV or JSON, or to follow them in a feed.

CVE	Severity	Published▾	Status	Exploitation	Description
CVE-2017-8028	High	2017-11-27	No exploit published	No public exploit	In Pivotal Spring-LDAP versions 1.3.0 - 2.3.1, when connected to some LDAP servers, when no additional attributes are bound, and when using LDAP BindAuthenticator with org.springframework.ldap.core.support.DefaultTlsDirContextAuthenticationStrategy as the authentication strategy, and setting userSearch, authentication is allowed with an arbitrary password when the username is correct. This occurs because some LDAP vendors require an explicit operation for the LDAP bind to take effect.

CVE

Severity

Published▾

Status

Exploitation

Description

CVE-2017-8028

High

2017-11-27

No exploit published

No public exploit

In Pivotal Spring-LDAP versions 1.3.0 - 2.3.1, when connected to some LDAP servers, when no additional attributes are bound, and when using LDAP BindAuthenticator with org.springframework.ldap.core.support.DefaultTlsDirContextAuthenticationStrategy as the authentication strategy, and setting userSearch, authentication is allowed with an arbitrary password when the username is correct. This occurs because some LDAP vendors require an explicit operation for the LDAP bind to take effect.