WaratekVRT Sign in
Reset
More filters (2)
Columns
Published to 2017-06-30✕Vendor org.apache.qpid✕
Overview 2 matches · 1 protected · 0 exploited · 0 CISA KEV · 0 public PoC · 0 EPSS ≥ 0.5
2matches 1protected50.0% 0exploited0.0% 0CISA KEV0.0% 0public PoC0.0% 0EPSS ≥ 0.50.0%
Protected by Waratek 1 50.0% Rule in development 0 0.0% Mitigation candidate 0 0.0% No exploit published 1 50.0%
Critical 0 0.0% High 2 100.0% Medium 0 0.0% Low 0 0.0% None 0 0.0% Unknown 0 0.0%
blocked by ARMR today 1 50.0% partly blocked 0 0.0% not blocked 1 50.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 2 100.0%
split by peak 1 / month
No exploit published: 1Protected by Waratek: 1 High: 2 not blocked: 1blocked by ARMR today: 1 No public exploit: 2
Jul 161 Protected by Waratek1 High1 blocked by ARMR today1 No public exploit1 Aug 160 Sep 160 Oct 160 Nov 160 Dec 160 Jan 170 Feb 170 Mar 170 Apr 170 May 171 No exploit published1 High1 not blocked1 No public exploit1
Jul 16Aug 16Sep 16Oct 16Nov 16Dec 16Jan 17Feb 17Mar 17Apr 17May 17
2 matches Sign in to download these CVEs as CSV or JSON, or to follow them in a feed.
CVE Severity Published▾ Status Exploitation Description
CVE-2016-8741 High 2017-05-15 No exploit published No public exploit The Apache Qpid Broker for Java can be configured to use different so called AuthenticationProviders to handle user authentication. Among the choices are the SCRAM-SHA-1 and SCRAM-SHA-256 AuthenticationProvider types. It was discovered that these AuthenticationProviders in Apache Qpid Broker for Java 6.0.x before 6.0.6 and 6.1.x before 6.1.1 prematurely terminate the SCRAM SASL negotiation if the provided user name does not exist thus allowing remote attacker to determine the existence of user accounts. The Vulnerability does not apply to AuthenticationProviders other than SCRAM-SHA-1 and SCRAM-SHA-256.
CVE-2016-4974 High 2016-07-13 Protected by Waratek No public exploit Apache Qpid AMQP 0-x JMS client before 6.0.4 and JMS (AMQP 1.0) before 0.10.0 does not restrict the use of classes available on the classpath, which might allow remote authenticated users with permission to send messages to deserialize arbitrary objects and execute arbitrary code by leveraging a crafted serialized object in a JMS ObjectMessage that is handled by the getObject function.