Closed artem-smotrakov closed 4 years ago
There are 33 vulnerabilities that are not associated with any CVE from NVD Database. This can be the Delta between the Security Advisory Database and the NVD Database.
That means gathering vulnerabilities from Security Advisory Database makes sense.
GhsaId : GHSA-7fhm-mqm4-2wp7 Description : Withdrawn GitHub has withdrawn this advisory in place of GHSA-vh95-rmgr-6w4m and GHSA-6chw-6frg-f759. The reason for withdrawing is that some mistakes were made during the ingestion of CVE-2020-7598 which caused this advisory to be published with incorrect information.
In order to provide accurate advisory information, new advisories were created:
GhsaId : GHSA-6chw-6frg-f759 Description : Affected versions of acorn are vulnerable to Regular Expression Denial of Service. A regex in the form of /[x-\ud800]/u causes the parser to enter an infinite loop. The string is not valid UTF16 which usually results in it being sanitized before reaching the parser. If an application processes untrusted input and passes it directly to acorn, attackers may leverage the vulnerability leading to Denial of Service. DatabaseId : 2027 Origin : UNSPECIFIED Identifiers : [GHSA-6chw-6frg-f759] References : [https://github.com/acornjs/acorn/issues/929, https://github.com/advisories/GHSA-6chw-6frg-f759] Severity : MODERATE Published At : 2020-04-03T21:48:38Z
GhsaId : GHSA-mr6r-mvw4-736g Description : # VVE-2020-0001
Earlier today, we received a responsible disclosure of a potential issue from @montyly (security researcher at @trailofbits) for Vyper users who make assumptions about what values certain interface types can return.
We determined the issue to be mild and unlikely to be exploited, with an easy workaround while the correct resolution is in process. The issue stems from a number of things, which we will detail here.
(1) The ABI Specification is under-defined such that function return type is not always reflected in how you use it
This means that a function which returns uint8
under the hood actually returns a 32 byte integer, making it identical to a function that returns uint256
. This allows users to read an interface that returns a uint8
value to be stored into a uint256
variable without any explicit casting or input validation.
(2) Vyper doesn't have uint8
types
When Vyper was originally created, it only had one numeric type, but we added just enough types to be able to work with the majority of ERC interfaces that exist.
Unfortunately, we never added uint8
, because it's only majority usage was for ERC20.decimals()
as the return type, which isn't reflected in the method ID. Because of (1), it didn't matter that we didn't have these types implemented because you could capture the return value as uint256
and use it just fine.
(3) ERC20.decimals()
returns uint8
ERC20.decimal()
(which is an optional function) returns a uint8
type. While it was never intentioned to be used directly within a smart contract (hence being optional), someone could easily make the decision to rely on it to perform important functionality within their Vyper smart contract. This might lead to a scenario where an unexpectedly large value (> 255) returned by calling this function (which a malicious contract writer might write) would allow an attacker to manipulate or bypass certain logic depending on this value.
In summary, because of (1), it isn't necessary to have to cast the return value of a function that returns uint8
to uint256
, and because of (2) it isn't possible to have the type system protect against this type of error. This could lead to scenarios like (3) where this behavior can be exploited.
We are currently refactoring our typing system so we can implement all ABI-compliant integer types, but no currently patched version is available that gives users access to the uint8
type.
There is an easy workaround where you should check that the value returned by an interface which specifies uint8
should be checked to be within the bounds of a uint8
integer. As an example:
...
# returns uint8, but we implicitly cast to uint256 without checking
decimals: uint256 = ERC20(_token).decimal()
# FIX: Insert this line
assert decimals < 256
...
Depending on how you use this value, it may not be necessary to insert this check.
If you have any questions or comments about this advisory:
GhsaId : GHSA-vg44-fw64-cpjx Description : ### Impact
Anybody using this library to sign with a BIP44 account other than the first account may be affected. If a user is signing with the first account (i.e. the account at index 0
), or with the legacy MEW/MyCrypto HD path, they are not affected.
The vulnerability impacts cases where the user signs a personal message or transaction without first adding the account. This includes cases where the user has already added the account in a previous session (i.e. they added the account, reset the application, then signed something). The serialization/deserialization process does restore a previously added account, but it doesn't restore the index instructing the keyring to use that account for signing. As a result, after serializing then deserializing the keyring state, the account at index 0
is always used for signing even if it isn't the current account.
This has been patched (#14) in version >=0.2.1 of eth-ledger-bridge-keyring
, and in version >=0.2.2 of @metamask/eth-ledger-bridge-keyring
. Users are encouraged to migrate to the new package name.
To work around this problem without updating, you should remove then re-add the account before use. As long as the account was added during the lifetime of that process, signing with that account should work correctly.
If you have any questions or comments about this advisory:
GhsaId : GHSA-pcqq-5962-hvcw Description : ### Impact Some regexes are vulnerable to regular expression denial of service (REDoS) due to overlapping capture groups. This allows remote attackers to overload a server by setting the User-Agent header in an HTTP(S) request to maliciously crafted long strings.
Please update uap-ruby
to >= v2.6.0
https://github.com/ua-parser/uap-core/security/advisories/GHSA-cmcx-xhr8-3w9p
Reported in uap-core
by Ben Caller @bcaller
DatabaseId : 1976
Origin : UNSPECIFIED
Identifiers : [GHSA-pcqq-5962-hvcw]
References : [https://github.com/ua-parser/uap-ruby/security/advisories/GHSA-pcqq-5962-hvcw, https://github.com/advisories/GHSA-pcqq-5962-hvcw]
Severity : HIGH
Published At : 2020-03-10T18:02:49Z
GhsaId : GHSA-p94w-42g3-f7h4
Description : ### Impact
The verifyVerifiableCredential()
method check the cryptographic integrity of the Verifiable Credential, but it does not check if the credential.issuer
DID matches the signer of the credential.
The verifier is impacted by this vulnerability.
Patch will be available in version 0.2.2.
In case you trust certain issuers for certain credentials as a verifier, trust the issuer's public key from the credential.proof.verificationMethod
field.
If you have any questions or comments about this advisory:
GhsaId : GHSA-ff5x-w9wg-h275
Description : ### Impact
The verifyVerifiablePresentation()
method check the cryptographic integrity of the Verifiable Presentation, but it does not check if the credentialSubject.id
DID matches the signer of the VP proof.
The verifier is impacted by this vulnerability.
Patch will be available in version 0.2.2.
verifiablePresentation.proof.n.verificationMethod
using getAddressFromPubKey()
from crypt-util@0.1.5
and match it with the credentialSubject.id
address from the credential.If you have any questions or comments about this advisory:
GhsaId : GHSA-9r27-994c-4xch Description : ### Impact Any website using discord-markdown with user-generated markdown is vulnerable to having code injected into the page where the markdown is displayed.
This has been patched in version 2.3.1
Escape the characters <>&
before sending plain code blocks to discord-markdown.
https://github.com/brussell98/discord-markdown/issues/13 DatabaseId : 1946 Origin : UNSPECIFIED Identifiers : [GHSA-9r27-994c-4xch] References : [https://github.com/brussell98/discord-markdown/security/advisories/GHSA-9r27-994c-4xch, https://github.com/advisories/GHSA-9r27-994c-4xch] Severity : HIGH Published At : 2020-02-24T17:34:02Z
GhsaId : GHSA-27gm-ghr9-4v95
Description : ### Impact
A cross-site scripting (XSS) vulnerability was discovered in: the core parser, paste
and visualchars
plugins. The vulnerability allowed arbitrary JavaScript execution when inserting a specially crafted piece of content into the editor via the clipboard or APIs. This impacts all users who are using TinyMCE 4.9.6 or lower and TinyMCE 5.1.3 or lower.
This vulnerability has been patched in TinyMCE 4.9.7 and 5.1.4 by improved parser logic and HTML sanitization.
The workarounds available are:
BeforeSetContent
event (see below)editor.on('BeforeSetContent', function(e) {
var sanitizedContent = ...; // Manually sanitize content here
e.content = sanitizedContent;
});
Tiny Technologies would like to thank Michal Bentkowski for discovering this vulnerability.
https://www.tiny.cloud/docs/release-notes/release-notes514/#securityfixes
If you have any questions or comments about this advisory:
GhsaId : GHSA-2r3v-q9x3-7g46 Description : ### Background Several scripts part of SimpleSAMLphp display a web page with links obtained from the request parameters. This allows us to enhance usability, as the users are presented with links they can follow after completing a certain action, like logging out.
The following scripts were not checking the URLs obtained via the HTTP request before displaying them as the target of links that the user may click on:
www/logout.php
modules/core/www/no_cookie.php
The issue allowed attackers to display links targeting a malicious website inside a trusted site running SimpleSAMLphp, due to the lack of security checks involving the link_href
and retryURL
HTTP parameters, respectively. The issue was resolved by including a verification of the URLs received in the request against a white list of websites specified in the trusted.url.domains
configuration option.
All SimpleSAMLphp versions prior to 1.14.4.
A remote attacker could craft a link pointing to a trusted website running SimpleSAMLphp, including a parameter pointing to a malicious website, and try to fool the victim into visiting that website by clicking on a link in the page presented by SimpleSAMLphp.
Upgrade to the latest version.
This security issue was discovered and reported by John Page (hyp3rlinx). DatabaseId : 1883 Origin : UNSPECIFIED Identifiers : [GHSA-2r3v-q9x3-7g46] References : [https://github.com/simplesamlphp/simplesamlphp/security/advisories/GHSA-2r3v-q9x3-7g46, https://github.com/advisories/GHSA-2r3v-q9x3-7g46] Severity : LOW Published At : 2020-01-24T21:27:16Z
GhsaId : GHSA-769f-539v-f5jg Description : ### Impact
We have identified that some gamification module ZIP archives have been built with phpunit dev dependencies. PHPUnit contains a php script that would allow, on a webserver, an attacker to perform a RCE.
This vulnerability impacts
You can read PrestaShop official statement about this vulnerability here.
In the security patch, we look for the unwanted vendor/phpunit folder and remove it if we find it. This allows users to fix the security issue when upgrading.
Users can also simply remove the unwanted vendor/phpunit folder.
https://nvd.nist.gov/vuln/detail/CVE-2017-9841
If you have any questions or comments about this advisory, email us at security@prestashop.com DatabaseId : 1864 Origin : UNSPECIFIED Identifiers : [GHSA-769f-539v-f5jg] References : [https://github.com/PrestaShop/gamification/security/advisories/GHSA-769f-539v-f5jg, https://github.com/advisories/GHSA-769f-539v-f5jg] Severity : HIGH Published At : 2020-01-08T03:10:44Z
GhsaId : GHSA-wqq8-mqj9-697f Description : ### Impact
We have identified that some autoupgrade module ZIP archives have been built with phpunit dev dependencies. PHPUnit contains a php script that would allow, on a webserver, an attacker to perform a RCE.
This vulnerability impacts
You can read PrestaShop official statement about this vulnerability here.
In the security patch, we look for the unwanted vendor/phpunit folder and remove it if we find it. This allows users to fix the security issue when upgrading.
Users can also simply remove the unwanted vendor/phpunit folder.
https://nvd.nist.gov/vuln/detail/CVE-2017-9841
If you have any questions or comments about this advisory, email us at security@prestashop.com DatabaseId : 1863 Origin : UNSPECIFIED Identifiers : [GHSA-wqq8-mqj9-697f] References : [https://github.com/PrestaShop/autoupgrade/security/advisories/GHSA-wqq8-mqj9-697f, https://github.com/advisories/GHSA-wqq8-mqj9-697f] Severity : HIGH Published At : 2020-01-08T03:10:30Z
GhsaId : GHSA-f884-gm86-cg3q Description : ### Impact
We have identified that some ps_facetedsearch module ZIP archives have been built with phpunit dev dependencies. PHPUnit contains a php script that would allow, on a webserver, an attacker to perform a RCE.
This vulnerability impacts
In the security patch, we look for the unwanted vendor/phpunit folder and remove it if we find it. This allows users to fix the security issue when upgrading.
Users can also simply remove the unwanted vendor/phpunit folder.
https://nvd.nist.gov/vuln/detail/CVE-2017-9841
If you have any questions or comments about this advisory, email us at security@prestashop.com DatabaseId : 1862 Origin : UNSPECIFIED Identifiers : [GHSA-f884-gm86-cg3q] References : [https://github.com/PrestaShop/ps_facetedsearch/security/advisories/GHSA-f884-gm86-cg3q, https://github.com/advisories/GHSA-f884-gm86-cg3q] Severity : HIGH Published At : 2020-01-07T17:20:47Z
GhsaId : GHSA-4ppp-gpcr-7qf6 Description : ### Impact
Waitress would header fold a double Content-Length
header and due to being unable to cast the now comma separated value to an integer would set the Content-Length
to 0 internally.
So a request with:
Content-Length: 10
Content-Length: 10
would get transformed to:
Content-Length: 10, 10
Which would Waitress would then internally set to Content-Lenght: 0
.
Waitress would then treat the request as having no body, thereby treating the body of the request as a new request in HTTP pipelining.
This issue is fixed in Waitress 1.4.0. This brings a range of changes to harden Waitress against potential HTTP request confusions, and may change the behaviour of Waitress behind non-conformist proxies.
The Pylons Project recommends upgrading as soon as possible, while validating that the changes in Waitress don't cause any changes in behavior.
Various reverse proxies may have protections against sending potentially bad HTTP requests to the backend, and or hardening against potential issues like this. If the reverse proxy doesn't use HTTP/1.1 for connecting to the backend issues are also somewhat mitigated, as HTTP pipelining does not exist in HTTP/1.0 and Waitress will close the connection after every single request (unless the Keep Alive header is explicitly sent... so this is not a fool proof security method).
GhsaId : GHSA-4j6x-w426-6rc6 Description : ## Default Express middleware security check is ignored in production
All Cube.js deployments that use affected versions of @cubejs-backend/api-gateway
with default express authentication middleware in production environment are affected.
@cubejs-backend/api-gateway@0.11.17
Override default authentication express middleware: https://cube.dev/docs/@cubejs-backend-server-core#options-reference-check-auth-middleware
If you have any questions or comments about this advisory:
DatabaseId : 1767 Origin : UNSPECIFIED Identifiers : [GHSA-4j6x-w426-6rc6] References : [https://github.com/cube-js/cube.js/security/advisories/GHSA-4j6x-w426-6rc6, https://github.com/advisories/GHSA-4j6x-w426-6rc6] Severity : HIGH Published At : 2019-11-08T17:31:17Z
GhsaId : GHSA-7cg8-pq9v-x98q Description : ## sandbox breach via rewrite transformer
The realms-shim is intended to provide a "safe evaluator" which executes arbitrary strings code with limited authority. This provides a "sandbox" which only has access to the specific objects and power that the caller chooses to expose. The evaluate()
function it implements takes two additional arguments: endowments
(which are exposed in the global lexical scope), and an options bag. The transforms
option is a list of functions that are applied to the string of code, to apply Babel-like transformations before it gets executed (e.g. to implement syntax extensions).
A bug was found in the transformation pipeline that exposed a primal-Realm object to one of the transform functions. The confined code could use this to escape the sandbox and compromise the Realm which created it. This generally leads to a full compromise of the application.
All uses of the Realms shim that evaluate unaudited third-party code are vulnerable.
The bug is fixed in the 1.2.1 version of realms-shim
. All users should upgrade to this release.
The evaluate()
function (and the accompanying transforms
option) is available to all confined code, hence the only way to prevent its use would be to carefully audit the confined code for calls to evaluate()
that use the transformation feature. Given how flexible JavaScript is, this should not be considered a reliable workaround. Upgrading to the latest realms-shim is the recommended mitigation.
If you have any questions or comments about this advisory:
security
(at agoric.com
)@agoric
DatabaseId : 1743 Origin : UNSPECIFIED Identifiers : [GHSA-7cg8-pq9v-x98q] References : [https://github.com/Agoric/realms-shim/security/advisories/GHSA-7cg8-pq9v-x98q, https://github.com/advisories/GHSA-7cg8-pq9v-x98q] Severity : CRITICAL Published At : 2019-10-21T21:58:55Z
GhsaId : GHSA-v7x3-7hw7-pcjg Description : ## Go Modules Vulnerability Disclosure
Temporary repository tokens were leaked into Pull Requests comments in during certain Go Modules update failure scenarios.
The problem has been patched. Self-hosted users should upgrade to v19.38.7 or later.
Disable Go Modules support.
Blog post: https://renovatebot.com/blog/go-modules-vulnerability-disclosure
If you have any questions or comments about this advisory:
DatabaseId : 1749 Origin : UNSPECIFIED Identifiers : [GHSA-v7x3-7hw7-pcjg] References : [https://github.com/renovatebot/renovate/security/advisories/GHSA-v7x3-7hw7-pcjg, https://github.com/advisories/GHSA-v7x3-7hw7-pcjg] Severity : MODERATE Published At : 2019-10-21T16:02:33Z
GhsaId : GHSA-67cx-rhhq-mfhq Description : ## Local file disclosure through LaTeX injection
An external audit of the Indico codebase has discovered a vulnerability in Indico's LaTeX sanitization code, which could have malicious users to run unsafe LaTeX commands on the server. Such commands allowed for example to read local files (e.g. indico.conf
).
As far as we know it is not possible to write files or execute code using this vulnerability.
You need to update to Indico 2.2.3 as soon as possible. We also released Indico 2.1.10 in case you cannot update to 2.2 for some reason. See https://docs.getindico.io/en/stable/installation/upgrade/ for instructions on how to update.
Setting XELATEX_PATH = None
in indico.conf
will result in an error when building a PDF, but without being able to run xelatex, the vulnerability cannot be abused.
If you have any questions or comments about this advisory:
DatabaseId : 1730 Origin : UNSPECIFIED Identifiers : [GHSA-67cx-rhhq-mfhq] References : [https://github.com/indico/indico/security/advisories/GHSA-67cx-rhhq-mfhq, https://github.com/advisories/GHSA-67cx-rhhq-mfhq] Severity : HIGH Published At : 2019-10-11T18:28:07Z
GhsaId : GHSA-mgv2-57vj-99xc Description : ## Test breaking
In v1.2.0, tests are broken: all tests are always succeeding. If tests are looking for security vulnerabilities, these were compromised.
Users should upgrade to v1.2.1
Users who don't use eye.js for looking for vulnerabilities are safe. Upgrading will just fix some bugs.
If you have any questions or comments about this advisory:
DatabaseId : 1727 Origin : UNSPECIFIED Identifiers : [GHSA-mgv2-57vj-99xc] References : [https://github.com/arguiot/EyeJS/security/advisories/GHSA-mgv2-57vj-99xc, https://github.com/advisories/GHSA-mgv2-57vj-99xc] Severity : LOW Published At : 2019-10-07T16:54:24Z
GhsaId : GHSA-85rf-xh54-whp3 Description : ## Malicious URL drafting attack against iodines static file server may allow path traversal
A path traversal vulnerability was detected in iodine's static file service. This vulnerability effects any application running iodine's static file server on an effected iodine version.
Malicious URL drafting may cause the static file server to attempt a response containing data from files that shouldn't be normally accessible from the public folder.
The vulnerability was patched in version 0.7.34. Please upgrade to the latest version.
A possible workaround would be to disable the static file service and it's X-Sendfile
support, sending static files using a secure or nginx.
However, it would be better to upgrade iodine to the latest version, as it also contains non-security related fixes.
If you have any questions or comments about this advisory:
DatabaseId : 1726 Origin : UNSPECIFIED Identifiers : [GHSA-85rf-xh54-whp3] References : [https://github.com/boazsegev/iodine/security/advisories/GHSA-85rf-xh54-whp3, https://github.com/advisories/GHSA-85rf-xh54-whp3] Severity : MODERATE Published At : 2019-10-07T16:52:13Z
GhsaId : GHSA-6jg8-7333-554w Description : ## realms-shim / SES sandbox escapes
The realms-shim
package implements the Realms proposal. The SES package builds upon Realms to build secure sandboxes for executing untrusted Javascript code. Sandboxed code cannot modify the primordial objects (aka "prototype poisoning") within the sandbox, nor can it interact with other objects unless it is first given a reference to those objects. This provides an "object-capability safe" execution environment.
Several bugs were found in realms-shim
, which allow the confined code to escape the sandbox and compromise the "primal realm" (the one which created the sandbox). This generally leads to a full compromise of the application, since the primal realm includes access to e.g. require('fs')
, from which the attacker can rewrite the application's source code.
Until very recently, the only convenient way to use the realms-shim
package was to include it as a git submodule (the first tagged release was made on 18-Sep-2019), or to use SES. Consequently the vulnerable population includes users of SES-0.6.2 or older, users of realms-shim-1.1.2 or older, and users of any package that use a git-submodule to include the realms-shim.
The bugs have been fixed in realms-shim-1.2.0, which has been incorporated into SES-0.6.3 . All users should upgrade to one of these releases.
SES and the Realms feature are designed to protect against arbitrary and unreviewed attacker-supplied code. Applications which rely upon this property must upgrade to the newer versions of the libraries to fix the problem.
Other applications might be in a position to have humans review the code before executing it under a Realm, or accept very limited subsets of Javascript. In these cases, the review process might be changed to exclude these attacks.
However, given how flexible Javascript is, this should not be considered a reliable workaround. Upgrading to the newer realms-shim and SES is the recommended mitigation.
If you have any questions or comments about this advisory:
security
(at agoric.com
)@agoric
DatabaseId : 1724 Origin : UNSPECIFIED Identifiers : [GHSA-6jg8-7333-554w] References : [https://github.com/Agoric/realms-shim/security/advisories/GHSA-6jg8-7333-554w, https://github.com/advisories/GHSA-6jg8-7333-554w] Severity : CRITICAL Published At : 2019-10-04T17:56:12Z
GhsaId : GHSA-cxw4-9qv9-vx5h Description : ## Denial of service due to reference expansion in versions earlier than 4.0
The CBOR library supports optional tags that enable CBOR objects to contain references to objects within them. Versions earlier than 4.0 resolved those references automatically. While this by itself doesn't cause much of a security problem, a denial of service can happen if those references are deeply nested and used multiple times (so that the same reference to the same object occurs multiple times), and if the decoded CBOR object is sent to a serialization method such as EncodeToBytes
, ToString
, or ToJSONString
, since the objects referred to are expanded in the process and take up orders of magnitude more memory than if the references weren't resolved.
The impact of this problem on any particular system varies. In general, the risk is higher if the system allows users to send arbitrary CBOR objects without authentication, or exposes a remote endpoint in which arbitrary CBOR objects can be sent without authentication.
This problem is addressed in version 4.0 by disabling reference resolution by default. Users should use the latest version of this library, which is 4.0 at the time of this writing.
Since version 3.6, an encoding option (resolvereferences=true
or resolvereferences=false
) in CBOREncodeOptions sets whether the CBOR processor will resolve these kinds of references when decoding a CBOR object. Set resolvereferences=false
to disable reference resolution.
In version 3.6, if the method used CBORObject.Read()
or CBORObject.DecodeFromBytes()
to decode a serialized CBOR object, call the overload that takes CBOREncodeOptions
as follows:
CBORObject.DecodeFromBytes(bytes, new CBOREncodeOptions("resolvereferences=false"));
In versions 3.5 and earlier, this issue is present only if the CBOR object is an array or a map. If the application does not expect a decoded CBOR object to be an array or a map, it should check the CBOR object's type before decoding that object, as follows:
if (cbor.Type != CBORType.Array && cbor.Type != CBORType.Map) {
cbor.DecodeFromBytes();
}
Alternatively, for such versions, the application can use WriteTo
to decode the CBOR object to a so-called "limited memory stream", that is, a Stream
that throws an exception if too many bytes would be written. How to write such a limited-memory stream is nontrivial and beyond the scope of this advisory.
using(var stream = new LimitedMemoryStream(100000)) { // Limit to 100000 bytes
stream.WriteTo();
return stream.ToBytes();
}
To check whether a byte array representing a CBOR object might exhibit this problem, check whether the array contains the byte 0xd8 followed immediately by either 0x19 or 0x1d. This check catches all affected CBOR objects but may catch some non-affected CBOR objects (notably integers and byte strings).
See the Wikipedia article Billion laughs attack and the related issue in Kubernetes.
If you have any questions or comments about this advisory:
DatabaseId : 1720 Origin : UNSPECIFIED Identifiers : [GHSA-cxw4-9qv9-vx5h] References : [https://github.com/peteroupc/CBOR/security/advisories/GHSA-cxw4-9qv9-vx5h, https://github.com/advisories/GHSA-cxw4-9qv9-vx5h] Severity : HIGH Published At : 2019-09-30T19:42:28Z
GhsaId : GHSA-v6cj-r88p-92rm Description : ## Denial of Service
Affected Centra versions will, when not in stream mode, buffer responses to requests into memory with no size limit. This issue affects anyone requesting content from untrusted sources.
Version 2.4.0 resolves the issue by limiting the size of buffered response body.
Attempting workarounds isn't recommended. Updating is preferred.
If you have any questions or comments about this advisory, open an issue in ethanent/centra.
DatabaseId : 1718 Origin : UNSPECIFIED Identifiers : [GHSA-v6cj-r88p-92rm] References : [https://github.com/ethanent/centra/security/advisories/GHSA-v6cj-r88p-92rm, https://github.com/advisories/GHSA-v6cj-r88p-92rm] Severity : LOW Published At : 2019-09-30T19:31:59Z
GhsaId : GHSA-mc84-xr9p-938r Description : ## Generated code uses repository configuration that downloads over HTTP instead of HTTPS
Gradle users were using the http://repo.spring.io/plugins-release repositories in plain HTTP, and not HTTPS, so a man-in-the-middle attack was possible at build time.
Maven users should at least upgrade to 6.3.0 while Gradle users should update to 6.3.1.
If you are not able to upgrade make sure not to use a Maven repository via http
in your build file.
Replace all custom repository definitions in build.gradle
or pom.xml
with their https
version.
e.g.
<repository>
<id>oss.sonatype.org-snapshot</id>
<url>https://oss.sonatype.org/content/repositories/snapshots</url> // <-- must be httpS
<releases>
<enabled>false</enabled>
</releases>
<snapshots>
<enabled>true</enabled>
</snapshots>
</repository>
maven { url "https://repo.spring.io/plugins-release" } // <-- must be httpS
If you have any questions or comments about this advisory:
DatabaseId : 1694 Origin : UNSPECIFIED Identifiers : [GHSA-mc84-xr9p-938r] References : [https://github.com/jhipster/generator-jhipster/security/advisories/GHSA-mc84-xr9p-938r, https://github.com/advisories/GHSA-mc84-xr9p-938r] Severity : HIGH Published At : 2019-09-23T18:31:05Z
GhsaId : GHSA-mwp6-j9wf-968c Description : Account takeover and privilege escalation is possible in applications generated by generator-jhipster before 6.3.0. This is due to a vulnerability in the generated java classes: CWE-338: Use of Cryptographically Weak Pseudo-Random Number Generator (PRNG)
Generated applications must be manually patched, following instructions in the release notes: https://www.jhipster.tech/2019/09/13/jhipster-release-6.3.0.html
DatabaseId : 1678 Origin : UNSPECIFIED Identifiers : [GHSA-mwp6-j9wf-968c] References : [https://github.com/jhipster/generator-jhipster/security/advisories/GHSA-mwp6-j9wf-968c, https://github.com/advisories/GHSA-mwp6-j9wf-968c] Severity : CRITICAL Published At : 2019-09-13T21:33:25Z
GhsaId : GHSA-9mrq-cjgh-32g2 Description : ## rel noopener vulnerability
Clicking on smartbanner View link and navigating to 3rd party page leaves window.opener
exposed. It may allow hostile 3rd parties to abuse window.opener
, e.g. by redirection or injection on the original page with smartbanner.
rel="noopener"
is automatically populated to links as of v1.14.1
which is a recommended upgrade to resolve the vulnerability.
If you can not upgrade to v1.14.1
:
If View link is going to a 3rd party page, limit smartbanner.js to be used on iOS that decreases the scope of the vulnerability since as of Safari 12.1, rel="noopener"
is imposed on all target="_blank"
links.
Following combination of smartbanner meta tags can be used to achieve the above:
<meta name="smartbanner:enabled-platforms" content="none">
<meta name="smartbanner:include-user-agent-regex" content="Mobile.*Safari">
If you have any questions or comments about this advisory:
DatabaseId : 1676 Origin : UNSPECIFIED Identifiers : [GHSA-9mrq-cjgh-32g2] References : [https://github.com/ain/smartbanner.js/security/advisories/GHSA-9mrq-cjgh-32g2, https://github.com/advisories/GHSA-9mrq-cjgh-32g2] Severity : LOW Published At : 2019-09-13T13:22:33Z
GhsaId : GHSA-4vr3-9v7h-5f8v Description : ## Leaking cached authenticated requests
If you've been using one MemoryCacheMethod
object in multiple instances of Gw2WebApiClient
and are requesting authenticated endpoints with different access tokens, then you are likely to run into this bug.
When using an instance of MemoryCacheMethod
and using it with multiple instances of Gw2WebApiClient
, there's a possibility that cached authenticated responses are leaking to another request to the same endpoint, but with a different Guild Wars 2 access token. The latter request wouldn't start however, and would return the first cached response immediately. This means that the second response (or later responses) may contain the same data as the first response, therefore leaking data from another authenticated endpoint.
The occurence of this is limited however. The Guild Wars 2 API doesn't use the Expires
header on most (if not all) authenticated endpoints. This header is checked when caching responses. If this header isn't available, the response isn't cached at all. You should still update to at least version 0.3.1 in order to be certain that it won't happen.
This bug has been fixed in version 0.3.1. When using an authenticated endpoint, it will prepend the SHA-1 hash of the access token to the cache id.
For version 0.3.0 and lower, you can use one separate instance of MemoryCacheMethod
per Gw2WebApiClient
if you need to use it.
If you have any questions or comments about this advisory, you can open an issue in the Gw2Sharp repository or contact me on Discord.
DatabaseId : 1534 Origin : UNSPECIFIED Identifiers : [GHSA-4vr3-9v7h-5f8v] References : [https://github.com/Archomeda/Gw2Sharp/security/advisories/GHSA-4vr3-9v7h-5f8v, https://github.com/advisories/GHSA-4vr3-9v7h-5f8v] Severity : LOW Published At : 2019-06-18T15:38:41Z
GhsaId : GHSA-886v-mm6p-4m66 Description : ## Urgent Upgrade
The static file server module included with GUN had a serious vulnerability:
curl --path-as-is
allowed reads on any parent directory or files.This did not work via the browser or via curl without as-is option.
This has been fixed since version 0.2019.416
and higher.
Most NodeJS users who use the default setup, such as:
npm start
node examples/http.js
Heroku
1-click-deployDocker
Now
If you have a custom NodeJS code then you are probably safe unless you have something like require('http').createServer(Gun.serve(__dirname))
in it.
If you have not upgraded, it is mandatory or else it is highly likely your environment variables and AWS (or other) keys could be leaked.
It was reported and fixed by JK0N, but I did not understand the --path-as-is
condition.
Joonas Loppi from function61 rediscovered it and explained the urgency to me to fix it.
DatabaseId : 1467 Origin : UNSPECIFIED Identifiers : [GHSA-886v-mm6p-4m66] References : [https://github.com/amark/gun/security/advisories/GHSA-886v-mm6p-4m66, https://github.com/advisories/GHSA-886v-mm6p-4m66] Severity : HIGH Published At : 2019-06-05T09:48:02Z
GhsaId : GHSA-mh6f-8j2x-4483
Description : The NPM package flatmap-stream
is considered malicious. A malicious actor added this package as a dependency to the NPM event-stream
package in version 3.3.6
. Users of event-stream
are encouraged to downgrade to the last non-malicious version, 3.3.4
, or upgrade to the latest 4.x version.
Users of flatmap-stream
are encouraged to remove the dependency entirely.
DatabaseId : 1007 Origin : UNSPECIFIED Identifiers : [GHSA-mh6f-8j2x-4483] References : [https://github.com/dominictarr/event-stream/issues/116, https://github.com/advisories/GHSA-mh6f-8j2x-4483] Severity : CRITICAL Published At : 2018-11-26T23:58:21Z
GhsaId : GHSA-hhxm-4f85-rgr8 Description : ### Logs password in plaintext
Logs the password used in plaintext. The password should masked in logs to prevent it leaking.
Has the problem been patched? What versions should users upgrade to?
none
Are there any links users can visit to find out more information?
RubyGems
many_versioned_gem
< 0.2.2
0.2.3 DatabaseId : 1103 Origin : UNSPECIFIED Identifiers : [GHSA-hhxm-4f85-rgr8] References : [https://github.com/advisories/GHSA-hhxm-4f85-rgr8] Severity : HIGH Published At : 2019-02-05T16:25:34Z
GhsaId : GHSA-cgpw-2gph-2r9g Description : Microsoft is aware of a denial of service vulnerability in ASP.NET Core when a malformed request is terminated. An attacker who successfully exploited this vulnerability could cause a denial of service attack.
The update addresses the vulnerability by correcting how ASP.NET Core handles such requests.
DatabaseId : 744 Origin : UNSPECIFIED Identifiers : [GHSA-cgpw-2gph-2r9g] References : [https://github.com/aspnet/Announcements/issues/311, https://github.com/advisories/GHSA-cgpw-2gph-2r9g] Severity : MODERATE Published At : 2018-10-16T19:59:59Z
GhsaId : GHSA-3m2r-q8x3-xmf7 Description : Microsoft made an internal discovery of a security vulnerability in version 2.x of ASP.NET Core where a specially crafted request can cause excess resource consumption in Kestrel.
DatabaseId : 743 Origin : UNSPECIFIED Identifiers : [GHSA-3m2r-q8x3-xmf7] References : [https://github.com/aspnet/Announcements/issues/300, https://github.com/advisories/GHSA-3m2r-q8x3-xmf7] Severity : MODERATE Published At : 2018-10-16T19:59:48Z
GhsaId : GHSA-hxxf-q3w9-4xgw
Description : Version 3.7.2 of the popular package eslint-scope
and version 5.0.2 were published without authorization ( see https://github.com/eslint/eslint-scope/issues/39 ). These versions contained apparently malicious code that attempted to steal npm login tokens. They have both been unpublished and are no longer available.
npm is aware of this issue and is providing updates on this issue at this page: https://status.npmjs.org/incidents/dn7c1fgrr7ng
DatabaseId : 307 Origin : UNSPECIFIED Identifiers : [GHSA-hxxf-q3w9-4xgw] References : [https://eslint.org/blog/2018/07/postmortem-for-malicious-package-publishes, https://github.com/advisories/GHSA-hxxf-q3w9-4xgw] Severity : CRITICAL Published At : 2018-07-12T19:52:02Z
firstPatchedVersion
. Then we can update the Resolution
field in Vulnerability
class to PATCHED
or UNPATCHED
.
"firstPatchedVersion": {
"identifier": "2.9.10.4"
}
severity
as this does not indicate the actual CVSS scorepublishedAt
as this does not align with the actual published date from the NVD DatabaseupdatedAt
as this does not align with the actual updated date from the NVD Databasepackage
field holds the artifact
or identifier
of the GitHub project.
pom.xml
of a MAVEN
project, we may have to parse through all the pom.xml
recursively and gather the artifact
PackageManager
spackage
and ecosystem
parameter can be used only with securityVulnerabilities
securityAdvisories
, then we would not be able to associate the advisory to a specific GitHub project as package
and ecosystem
fields would be missing.@sourabhsparkala
withdrawnAt if the advisory has been withdrawn on the account of being FALSE POSITIVE
If an advisory has been withdrawn, it means that it's not valid, doesn't it? If so, it looks like that we should not use the advisory.
publishedAt as this does not align with the actual published date from the NVD Database updatedAt as this does not align with the actual updated date from the NVD Database
Well, the advisories don't have to align with NVD. In fact, the differences between NVD and GitHub advisories may be the most interesting. However, publishedAt
and updatedAt
fields don't look interesting.
Considering the reviews from @artem-smotrakov
The following enhancements would be associated with this:
The GitHub GraphQL API allow requesting published security advisories and vulnerabilities. This information may be useful to fill out the
OssFeatures.VULNERABILITIES
feature. According to this page, they use not only NVD.For example, the following query returns a list of vulnerabilities for jackson-databind (use the explorer to send the query):
This query returns 10 latest security advisories:
Here is a list of thing to do:
VULNERABILITIES
feature.