| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| The package grunt before 1.3.0 are vulnerable to Arbitrary Code Execution due to the default usage of the function load() instead of its secure replacement safeLoad() of the package js-yaml inside grunt.file.readYAML. |
| This affects the package json before 10.0.0. It is possible to inject arbritary commands using the parseLookup function. |
| This affects all versions of package github.com/russellhaering/goxmldsig. There is a crash on nil-pointer dereference caused by sending malformed XML signatures. |
| This affects all versions of package safe-eval. It is possible for an attacker to run an arbitrary command on the host machine. |
| This affects the package MintegralAdSDK from 0.0.0. The SDK distributed by the company contains malicious functionality that tracks any URL opened by the app and reports it back to the company, along with performing advertisement attribution fraud. Mintegral can remotely activate hooks on the UIApplication, openURL, SKStoreProductViewController, loadProductWithParameters and NSURLProtocol methods along with anti-debug and proxy detection protection. If those hooks are active MintegralAdSDK sends obfuscated data about every opened URL in an application to their servers. Note that the malicious functionality is enabled even if the SDK was not enabled to serve ads. |
| This affects the package express-fileupload before 1.1.8. If the parseNested option is enabled, sending a corrupt HTTP request can lead to denial of service or arbitrary code execution. |
| This affects the package Gerapy from 0 and before 0.9.3. The input being passed to Popen, via the project_configure endpoint, isn’t being sanitized. |
| PKCE support is not implemented in accordance with the RFC for OAuth 2.0 for Native Apps. Without the use of PKCE, the authorization code returned by an authorization server is not enough to guarantee that the client that issued the initial authorization request is the one that will be authorized. An attacker is able to obtain the authorization code using a malicious app on the client-side and use it to gain authorization to the protected resource. This affects the package com.google.oauth-client:google-oauth-client before 1.31.0. |
| The issue occurs because tagName user input is formatted inside the exec function is executed without any checks. |
| This affects all versions of package fast-http. There is no path sanitization in the path provided at fs.readFile in index.js. |
| This affects all versions of package rollup-plugin-dev-server. There is no path sanitization in readFile operation inside the readFileFromContentBase function. |
| This affects all versions of package rollup-plugin-serve. There is no path sanitization in readFile operation. |
| This affects all versions of package rollup-plugin-server. There is no path sanitization in readFile operation performed inside the readFileFromContentBase function. |
| This affects all versions of package marked-tree. There is no path sanitization in the path provided at fs.readFile in index.js. |
| This affects all versions of package marscode. There is no path sanitization in the path provided at fs.readFile in index.js. |
| In all versions of package casperjs, the mergeObjects utility function is susceptible to Prototype Pollution. |
| This affects all versions of package node-import. The "params" argument of module function can be controlled by users without any sanitization.b. This is then provided to the “eval” function located in line 79 in the index file "index.js". |
| This affects the package thenify before 3.3.1. The name argument provided to the package can be controlled by users without any sanitization, and this is provided to the eval function without any sanitization. |
| mosc through 1.0.0 is vulnerable to Arbitrary Code Execution. User input provided to `properties` argument is executed by the `eval` function, resulting in code execution. |
| goliath through 1.0.6 allows request smuggling attacks where goliath is used as a backend and a frontend proxy also being vulnerable. It is possible to conduct HTTP request smuggling attacks by sending the Content-Length header twice. Furthermore, invalid Transfer Encoding headers were found to be parsed as valid which could be leveraged for TE:CL smuggling attacks. |