WaratekVRT Sign in
Reset
More filters (3)
Columns
Published from 2017-01-01✕Published to 2017-12-31✕Product script-security✕
Overview 3 matches · 0 protected · 0 exploited · 0 CISA KEV · 0 public PoC · 0 EPSS ≥ 0.5
3matches 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 3 100.0%
Critical 0 0.0% High 2 66.7% Medium 1 33.3% 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 3 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 3 100.0%
split by peak 2 / month
Feb 17Mar 17Apr 17May 17Jun 17Jul 17Aug 17Sep 17Oct 17
3 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-2017-1000107 High 2017-10-05 No exploit published No public exploit Script Security Plugin did not apply sandboxing restrictions to constructor invocations via positional arguments list, super constructor invocations, method references, and type coercion expressions. This could be used to invoke arbitrary constructors and methods, bypassing sandbox protection.
CVE-2017-1000095 Medium 2017-10-05 No exploit published No public exploit The default whitelist included the following unsafe entries: DefaultGroovyMethods.putAt(Object, String, Object); DefaultGroovyMethods.getAt(Object, String). These allowed circumventing many of the access restrictions implemented in the script sandbox by using e.g. currentBuild['rawBuild'] rather than currentBuild.rawBuild. Additionally, the following entries allowed accessing private data that would not be accessible otherwise due to script security: groovy.json.JsonOutput.toJson(Closure); groovy.json.JsonOutput.toJson(Object).
CVE-2016-3102 High 2017-02-09 No exploit published No public exploit The Script Security plugin before 1.18.1 in Jenkins might allow remote attackers to bypass a Groovy sandbox protection mechanism via a plugin that performs (1) direct field access or (2) get/set array operations.