Source
ghsa
### Impact A malicious message can crash CloudCore by triggering a null-pointer dereference in the UDS Server. Since the UDS Server only communicates with the CSI Driver on the cloud side, the attack is limited to the local host network. As such, an attacker would already need to be an authenticated user of the Cloud. It will be affected only when users turn on the unixsocket switch in the config file `cloudcore.yaml` as below: ``` modules: cloudHub: ... unixsocket: address: xxx enable: true ``` ### Patches This bug has been fixed in Kubeedge 1.11.0, 1.10.1, and 1.9.3. Users should update to these versions to resolve the issue. ### Workarounds Disable the unixsocket switch of CloudHub in the config file `cloudcore.yaml`. ### References NA ### Credits Thanks David Korczynski and Adam Korczynski of ADA Logics for responsibly disclosing this issue in accordance with the [kubeedge security policy](https://github.com/kubeedge/kubeedge/security/policy) during a se...
### Impact Jsrsasign supports JWS(JSON Web Signatures) and JWT(JSON Web Token) validation. However JWS or JWT signature with non Base64URL encoding special characters or number escaped characters may be validated as valid by mistake. For example, even if a string of non Base64URL encoding characters such as `!@$%` or `\11` is inserted into a valid JWS or JWT signature value string, it will still be a valid JWS or JWT signature by mistake. When jsrsasign's JWS or JWT validation is used in OpenID connect or OAuth2, this vulnerability will affect to authentication or authorization. By our internal assessment, CVSS 3.1 score will be 7.5. CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N ### Patches Users validate JWS or JWT signatures should upgrade to 10.5.25. ### Workarounds Validate JWS or JWT signature if it has Base64URL and dot safe string before executing JWS.verify() or JWS.verifyJWT() method. ### ACKNOWLEDGEMENT Thanks to Adi Malyanker and Or David for this vulnerability report...
### Impact The existing URI path filters in OctoRPKI (version < 1.4.3) mitigating Path traversal vulnerability could be bypassed by an attacker. In case a malicious TAL file is parsed, it was possible to write files outside the base cache folder. ### Patches The issue was fixed in version 1.4.3 ### References [CVE-2021-3907](https://www.cvedetails.com/cve/CVE-2021-3907/)
### Impact An authenticated customer can perform SQL injection ### Patches Issue is fixed in 2.1.1
### Impact A malicious message response from KubeEdge can crash the CSI Driver controller server by triggering a nil-pointer dereference panic. As a consequence, the CSI Driver controller will be in denial of service. An attacker would already need to be an authenticated user of the Cloud, and only when the authenticated user launches the `csidriver` then CloudCore may be attacked. ### Patches This bug has been fixed in Kubeedge 1.11.0, 1.10.1, and 1.9.3. Users should update to these versions to resolve the issue. ### Workarounds At the time of writing, no workaround exists. ### References NA ### Credits Thanks David Korczynski and Adam Korczynski of ADA Logics for responsibly disclosing this issue in accordance with the [kubeedge security policy](https://github.com/kubeedge/kubeedge/security/policy) during a security audit sponsored by CNCF and facilitated by OSTIF. ### For more information If you have any questions or comments about this advisory: * Open an issue in [KubeEdge re...
XSS in /dashboard/blocks/stacks/view_details/ - old browsers only. When using an older browser with built-in XSS protection disabled, insufficient sanitation where built urls are outputted can be exploited for Concrete 8.5.7 and below as well as Concrete 9.0 through 9.0.2 to allow XSS. This cannot be exploited in modern-day web browsers due to an automatic input escape mechanism. Concrete CMS Security team ranked this vulnerability 3.1with CVSS v3.1 Vector AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:L/A:N. Sanitation has been added where built urls are output. Credit to Credit to Bogdan Tiron from FORTBRIDGE (https://www.fortbridge.co.uk/ ) for reporting
Concrete 8.5.7 and below as well as Concrete 9.0 through 9.0.2 allow traversal in /index.php/ccm/system/file/upload which could result in an Arbitrary File Delete exploit. This was remediated by sanitizing /index.php/ccm/system/file/upload to ensure Concrete doesn’t allow traversal and by changing isFullChunkFilePresent to have an early false return when input doesn't match expectations.Concrete CMS Security team ranked this 5.8 with CVSS v3.1 vector AV:N/AC:H/PR:H/UI:N/S:C/C:N/I:N/A:H. Credit to Siebene for reporting.
Versions of Rails::Html::Sanitizer prior to version 1.4.3 are vulnerable to XSS with certain configurations of Rails::Html::Sanitizer which allows an attacker to inject content when the application developer has overridden the sanitizer's allowed tags to allow both `select` and `style` elements. Code is only impacted if allowed tags are being overridden. This may be done via application configuration: ```ruby# In config/application.rbconfig.action_view.sanitized_allowed_tags = ["select", "style"]``` see https://guides.rubyonrails.org/configuring.html#configuring-action-view Or it may be done with a `:tags` option to the Action View helper `sanitize`: ```<%= sanitize @comment.body, tags: ["select", "style"] %>``` see https://api.rubyonrails.org/classes/ActionView/Helpers/SanitizeHelper.html#method-i-sanitize It may also be done with Rails::Html::SafeListSanitizer directly: ```ruby# class-level optionRails::Html::SafeListSanitizer.allowed_tags = ["select", "style"]``` or with ...
Concrete CMS Versions 9.0.0 through 9.0.2 and 8.5.7 and below can download zip files over HTTP and execute code from those zip files which could lead to an RCE. Fixed by enforcing ‘concrete_secure’ instead of ‘concrete’. Concrete now only makes requests over https even a request comes in via http. Concrete CMS security team ranked this 8 with CVSS v3.1 vector: AV:N/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H Credit goes to Anna for reporting HackerOne 1482520.
All versions of package deep-get-set are vulnerable to Prototype Pollution via the 'deep' function. **Note:** This vulnerability derives from an incomplete fix of [CVE-2020-7715](https://security.snyk.io/vuln/SNYK-JS-DEEPGETSET-598666)