aswin1906/github-advisory-2021.csv huggingface dataset:
Cross-Site Request Forgery in remdex/livehelperchat
Published: 2021-12-10T20:26:34Z
Aliases: CVE-2021-4049

An attacker is able to log out a user if a logged-in user visits the attacker's website. While this cannot harm a user's account, it can be a great annoyance and is a valid CSRF.
Remote code injection in Log4j
Published: 2021-12-10T00:40:56Z
Aliases: CVE-2021-44228

# Summary

Log4j versions prior to 2.16.0 are subject to a remote code execution vulnerability via the ldap JNDI parser.
As per [Apache's Log4j security guide](https://logging.apache.org/log4j/2.x/security.html): Apache Log4j2 <=2.14.1 JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled. From log4j 2.16.0, this behavior has been disabled by default.

Log4j version 2.15.0 contained an earlier fix for the vulnerability, but that patch did not disable attacker-controlled JNDI lookups in all situations. For more information, see the `Updated advice for version 2.16.0` section of this advisory.

# Impact

Logging untrusted or user controlled data with a vulnerable version of Log4J may result in Remote Code Execution (RCE) against your application. This includes untrusted data included in logged errors such as exception traces, authentication failures, and other unexpected vectors of user controlled input. 

# Affected versions

Any Log4J version prior to v2.15.0 is affected to this specific issue.

The v1 branch of Log4J which is considered End Of Life (EOL) is vulnerable to other RCE vectors so the recommendation is to still update to 2.16.0 where possible.

## Security releases
Additional backports of this fix have been made available in versions 2.3.1, 2.12.2, and 2.12.3

## Affected packages
Only the `org.apache.logging.log4j:log4j-core` package is directly affected by this vulnerability. The `org.apache.logging.log4j:log4j-api` should be kept at the same version as the `org.apache.logging.log4j:log4j-core` package to ensure compatability if in use.

# Remediation Advice

## Updated advice for version 2.16.0

The Apache Logging Services team provided updated mitigation advice upon the release of version 2.16.0, which [disables JNDI by default and completely removes support for message lookups](https://logging.apache.org/log4j/2.x/changes-report.html#a2.16.0).
Even in version 2.15.0, lookups used in layouts to provide specific pieces of context information will still recursively resolve, possibly triggering JNDI lookups. This problem is being tracked as [CVE-2021-45046](https://nvd.nist.gov/vuln/detail/CVE-2021-45046). More information is available on the [GitHub Security Advisory for CVE-2021-45046](https://github.com/advisories/GHSA-7rjr-3q55-vv33).

Users who want to avoid attacker-controlled JNDI lookups but cannot upgrade to 2.16.0 must [ensure that no such lookups resolve to attacker-provided data and ensure that the the JndiLookup class is not loaded](https://issues.apache.org/jira/browse/LOG4J2-3221).

Please note that Log4J v1 is End Of Life (EOL) and will not receive patches for this issue. Log4J v1 is also vulnerable to other RCE vectors and we recommend you migrate to Log4J 2.16.0 where possible.
Unsafe Deserialization in jackson-databind
Published: 2021-12-09T19:16:34Z
Aliases: CVE-2020-36183

FasterXML jackson-databind 2.x before 2.9.10.8 and 2.6.7.5 mishandles the interaction between serialization gadgets and typing, related to org.docx4j.org.apache.xalan.lib.sql.JNDIConnectionPool.
pimcore is vulnerable to Cross-Site Request Forgery (CSRF)
Published: 2021-12-16T14:28:10Z
Aliases: CVE-2021-4082

pimcore is vulnerable to Cross-Site Request Forgery (CSRF)
Prototype Pollution in record-like-deep-assign
Published: 2021-12-10T18:55:39Z
Aliases: CVE-2021-23402

All versions of package record-like-deep-assign are vulnerable to Prototype Pollution via the main functionality.

### PoC
```js
const deepAssign = require('record-like-deep-assign');
let obj = {};
console.log("Before being polluted: " + obj.polluted);
EVIL_JSON = JSON.parse('{"__proto__":{"polluted":true}}');
deepAssign({}, EVIL_JSON);
console.log("After being polluted: " + obj.polluted);
```
Improper Certificate Validation and Improper Validation of Certificate with Host Mismatch in Apache Sling Commons Messaging Mail
Published: 2021-12-16T14:12:49Z
Aliases: CVE-2021-44549

Apache Sling Commons Messaging Mail provides a simple layer on top of JavaMail/Jakarta Mail for OSGi to send mails via SMTPS. To reduce the risk of "man in the middle" attacks additional server identity checks must be performed when accessing mail servers. For compatibility reasons these additional checks are disabled by default in JavaMail/Jakarta Mail. The SimpleMailService in Apache Sling Commons Messaging Mail 1.0 lacks an option to enable these checks for the shared mail session. A user could enable these checks nevertheless by accessing the session via the message created by SimpleMessageBuilder and setting the property mail.smtps.ssl.checkserveridentity to true. Apache Sling Commons Messaging Mail 2.0 adds support for enabling server identity checks and these checks are enabled by default. - https://javaee.github.io/javamail/docs/SSLNOTES.txt - https://javaee.github.io/javamail/docs/api/com/sun/mail/smtp/package-summary.html - https://github.com/eclipse-ee4j/mail/issues/429
kimai2 is vulnerable to Cross-site Scripting
Published: 2021-12-03T20:40:38Z
Aliases: CVE-2021-3985

kimai2 is vulnerable to Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting').
Instance config inline secret exposure in Grafana
Published: 2021-12-08T19:52:40Z
Aliases: CVE-2021-41090

### Impact
Some inline secrets are exposed in plaintext over the Grafana Agent HTTP server:

* Inline secrets for metrics instance configs in the base YAML file are exposed at `/-/config` 
* Inline secrets for integrations are exposed at `/-/config`
* Inline secrets for Consul ACL tokens and ETCD basic auth when configured for the scraping service at `/-/config`.
* Inline secrets for the Kafka receiver for OpenTelemetry-Collector tracing at `/-/config`.
* Inline secrets for metrics instance configs loaded from the scraping service are exposed at `/agent/api/v1/configs/{name}`.

Inline secrets will be exposed to anyone being able to reach these endpoints.

Secrets found in these sections are used for:

* Delivering metrics to a Prometheus Remote Write system 
* Authenticating against a system for discovering Prometheus targets 
* Authenticating against a system for collecting metrics (scrape_configs and integrations)
* Authenticating against a Consul or ETCD for storing configurations to distribute in scraping service mode 
* Authenticating against Kafka for receiving traces

Non-inlined secrets, such as `*_file`-based secrets, are not impacted by this vulnerability. 

### Patches

Download [v0.20.1](https://github.com/grafana/agent/releases/tag/v0.20.1) or any version past [v0.21.2](https://github.com/grafana/agent/releases/tag/v0.21.2) to patch Grafana Agent. These patches obfuscate the listed impacted secrets from the vulnerable endpoints.

The patches also disable the endpoints by default. Pass the command-line flag `--config.enable-read-api` to opt-in and re-enable the endpoints.  
 
### Workarounds
If for some reason you cannot upgrade, use non-inline secrets where possible. Not all configuration options may have a non-inline equivalent.

You also may desire to restrict API access to Grafana Agent, with some combination of:

* Restrict network interfaces Grafana Agent listens on through `http_listen_address` in the `server` block. `127.0.0.1` is the most restrictive, `0.0.0.0` is the default. 
* Configure Grafana Agent to use HTTPS with client authentication. 
* Use firewall rules to restrict external access to Grafana Agent's API.
Improper Authentication in Flask-AppBuilder
Published: 2021-12-09T19:09:07Z
Aliases: CVE-2021-41265

### Impact
Improper authentication on the REST API. Allows for a malicious actor with a carefully crafted request to successfully authenticate and gain access to existing protected REST API endpoints. Only affects non database authentication types, and new REST API endpoints.

### Patches
Upgrade to Flask-AppBuilder 3.3.4

### For more information
If you have any questions or comments about this advisory:
* Open an issue in https://github.com/dpgaspar/Flask-AppBuilder
OpenZeppelin Contracts initializer reentrancy may lead to double initialization
Published: 2021-12-14T21:47:33Z
Aliases: CVE-2022-39384

### Impact

Initializer functions that are invoked separate from contract creation (the most prominent example being minimal proxies) may be reentered if they make an untrusted non-view external call.

Once an initializer has finished running it can never be re-executed. However, an exception put in place to support multiple inheritance made reentrancy possible in the scenario described above, breaking the expectation that there is a single execution.

Note that upgradeable proxies are commonly initialized together with contract creation, where reentrancy is not feasible, so the impact of this issue is believed to be minor.

### Patches

A fix is included in the version v4.4.1 of `@openzeppelin/contracts` and `@openzeppelin/contracts-upgradeable`.

### Workarounds

Avoid untrusted external calls during initialization.

### References
https://github.com/OpenZeppelin/openzeppelin-contracts/pull/3006

### Credits

This issue was identified and reported by @chaitinblockchain through [our bug bounty on Immunefi](https://immunefi.com/bounty/openzeppelin/).

### For more information

If you have any questions or comments about this advisory, or need assistance executing the mitigation, email us at security@openzeppelin.com.
ReDos vulnerability on guest checkout email validation
Published: 2021-12-07T22:01:47Z
Aliases: CVE-2021-43805

### Impact
Denial of service vulnerability that could be exploited during a guest checkout. The regular expression used to validate a guest order's email was subject to exponential backtracking through a fragment like `a.a.`.

Before the patch, it can be reproduced in the console like this:

```ruby
irb(main)> Spree::EmailValidator::EMAIL_REGEXP.match "a@a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.@"
processing time: 54.293660s
=> nil
```

To reproduce in the browser, fill in the "Customer Email" field with that fake email address during a guest checkout. Before that, you should open the browser dev tools and change the `type` attribute for that field from `email` to `text`. After entering a fake address and pressing the "Save & Continue" button, the browser will take a long term to perform the request before showing an error message for the invalid address. Eventually, making the email string even longer could lead to the exhaustion of server resources.


### Patches
Versions 3.1.4, 3.0.4, and 2.11.13 have been patched to use a different regular expression.

There's an improbable chance that some orders in your system end up having associated an email address that is no longer valid. We've added a task to check precisely that:

```bash
bin/rails solidus:check_orders_with_invalid_email
```

The above will print information for every affected order if any.

### Workarounds

If a prompt upgrade is not an option, please, add the following to `config/application.rb`:

```ruby
config.after_initialize do
  Spree::EmailValidator.send(:remove_const, :EMAIL_REGEXP)
  Spree::EmailValidator::EMAIL_REGEXP = URI::MailTo::EMAIL_REGEXP
end
```

### References

- https://en.wikipedia.org/wiki/ReDoS
- https://snyk.io/blog/redos-and-catastrophic-backtracking/

### For more information
If you have any questions or comments about this advisory:
* Open an [issue](https://github.com/solidusio/solidus/issues) or a [discussion](https://github.com/solidusio/solidus/discussions) in Solidus.
* Email us at [security@solidus.io](mailto:security@soliidus.io)
* Contact the core team on [Slack](http://slack.solidus.io/)
Infinite loop in xz
Published: 2021-12-16T19:16:40Z
Aliases: CVE-2020-16845

Go before 1.13.15 and 14.x before 1.14.7 can have an infinite read loop in ReadUvarint and ReadVarint in encoding/binary via invalid inputs.
Prototype Pollution in sey
Published: 2021-12-16T14:29:34Z
Aliases: CVE-2021-23663

All versions of package `sey` are vulnerable to Prototype Pollution via the `deepmerge()` function.
A vulnerability in Atomix v3.1.5 allows attackers to cause a denial of service (DoS) via a Raft session flooding attack using Raft OpenSessionRequest messages.
Published: 2021-12-17T20:41:09Z
Aliases: CVE-2020-35210

A vulnerability in Atomix v3.1.5 allows attackers to cause a denial of service (DoS) via a Raft session flooding attack using Raft OpenSessionRequest messages.
Unsafe Deserialization in jackson-databind
Published: 2021-12-09T19:15:36Z
Aliases: CVE-2020-24750

FasterXML jackson-databind 2.x before 2.6.7.5 and from 2.7.x before 2.9.10.6 mishandles the interaction between serialization gadgets and typing, related to com.pastdev.httpcomponents.configuration.JndiConfiguration.
Prototype Pollution in comb
Published: 2021-12-16T14:30:56Z
Aliases: CVE-2021-23561

All versions of package comb are vulnerable to Prototype Pollution via the `deepMerge()` function.
Code injection via unsafe YAML loading
Published: 2021-12-09T18:35:22Z
Aliases: CVE-2021-43811

### Impact
Sockeye uses YAML to store model and data configurations on disk.  Versions below 2.3.24 use unsafe YAML loading, which can be made to execute arbitrary code embedded in config files.

An attacker can add malicious code to the config file of a trained model and attempt to convince users to download and run it.  If users run the model, the embedded code will run locally.

### Patches
The issue is fixed in version 2.3.24 and above by #964.

### For more information
If you have any questions or comments about this advisory:
* Open an issue in [awslabs/sockeye](https://github.com/awslabs/sockeye)
* Email us at [sockeye-dev](mailto:sockeye-dev@amazon.com)

### Attribution
This vulnerability was reported by Masatoshi Yoshizawa of yamory Security Team.
Observable Discrepancy in Argo
Published: 2021-12-09T19:59:24Z
Aliases: CVE-2020-11576

Fixed in v1.5.1, Argo version v1.5.0 was vulnerable to a user-enumeration vulnerability which allowed attackers to determine the usernames of valid (non-SSO) accounts because /api/v1/session returned 401 for an existing username and 404 otherwise.

### Specific Go Packages Affected
github.com/argoproj/argo-cd/util/session
github.com/argoproj/argo-cd/server/session
Unsafe Deserialization in jackson-databind
Published: 2021-12-09T19:15:46Z
Aliases: CVE-2020-36182

FasterXML jackson-databind 2.x before 2.9.10.8 and 2.6.7.5 mishandles the interaction between serialization gadgets and typing, related to org.apache.tomcat.dbcp.dbcp2.cpdsadapter.DriverAdapterCPDS.
pimcore is vulnerable to Cross-site Scripting
Published: 2021-12-16T14:27:58Z
Aliases: CVE-2021-4081

pimcore is vulnerable to Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Cross site scripting in remdex/livehelperchat
Published: 2021-12-10T20:33:29Z
Aliases: CVE-2021-4050

livehelperchat is vulnerable to Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
"Verify All" Returns Success Despite Validation Failures in Singularity
Published: 2021-12-20T18:24:43Z
Aliases: CVE-2020-13846

### Impact

The `--all / -a` option to `singularity verify` returns success even when some objects in a SIF container are not signed, or cannot be verified.

The SIF objects that are not verified are reported in `WARNING` log messages, but a `Container Verified` message and exit code of `0`  are returned.

Workflows that verify a container using `--all / -a` and use the exit code as an indicator of success are vulnerable to running SIF containers that have unsigned, or modified, objects that may be exploited to introduce malicious behavior.

```
$ singularity verify -a image.sif 
WARNING: Missing signature for SIF descriptor 2 (JSON.Generic)
WARNING: Missing signature for SIF descriptor 3 (FS)
Container is signed by 1 key(s):

Verifying partition: Def.FILE:
12045C8C0B1004D058DE4BEDA20C27EE7FF7BA84
[LOCAL]   Unit Test <unit@test.com>
[OK]      Data integrity verified

INFO:    Container verified: image.sif

$ echo $?
0
```


### Patches

Singularity 3.6.0 has a new implementation of sign/verify that fixes this issue.

All users are advised to upgrade to 3.6.0. Note that Singularity 3.6.0 uses a new signature format that is necessarily incompatible with Singularity < 3.6.0 - e.g. Singularity 3.5.3 cannot verify containers signed by 3.6.0.

Version 3.6.0 includes a `--legacy-insecure` flag for the `singularity verify` command, that will perform verification of the older, and insecure, legacy signatures for compatibility with existing containers. This does not guarantee that containers have not been modified since signing, due to other issues in the legacy signature format.

### Workarounds

If you are unable to update to 3.6.0 ensure that you do not rely on the return code of `singularity verify --all / -a` as an indicator of trust in a container.

Note that other issues in the sign/verify implementation in Singularity < 3.6.0 allow additional means to introduce malicious behavior to a signed container.


### For more information

General questions about the impact of the advisory / changes made in the 3.6.0 release can be asked in the:

* [Singularity Slack Channel](https://bit.ly/2m0g3lX)
* [Singularity Mailing List](https://groups.google.com/a/lbl.gov/forum/??sdf%7Csort:date#!forum/singularity)

Any sensitive security concerns should be directed to: security@sylabs.io

See our Security Policy here: https://sylabs.io/security-policy
Command injection in github-todos
Published: 2021-12-10T20:30:52Z
Aliases: CVE-2021-44684

naholyr github-todos 3.1.0 is vulnerable to command injection. The range argument for the _hook subcommand is concatenated without any validation, and is directly used by the exec function.
Path traversal when MessageBus::Diagnostics is enabled
Published: 2021-12-17T19:59:13Z
Aliases: CVE-2021-43840

### Impact

Users who deployed message bus with diagnostics features enabled (default off) were vulnerable to a path traversal bug, which could lead to disclosure of secret information on a machine if an unintended user were to gain access to the diagnostic route. The impact is also greater if there is no proxy for your web application as the number of steps up the directories is not bounded. For deployments which uses a proxy, the impact varies. For example, If a request goes through a proxy like Nginx with `merge_slashes` enabled, the number of steps up the directories that can be read is limited to 3 levels. 

### Patches

Patched in 3.3.7.

### Workarounds

Disable MessageBus::Diagnostics in production like environments.
Path manipulation in matyhtf/framework
Published: 2021-12-04T00:00:53Z
Aliases: CVE-2021-43676

matyhtf framework v3.0.5 is affected by a path manipulation vulnerability in Smarty.class.php. The issue was fixed in version 3.0.6.
Unsafe Deserialization in jackson-databind
Published: 2021-12-09T19:16:02Z
Aliases: CVE-2020-36185

FasterXML jackson-databind 2.x before 2.9.10.8 mishandles the interaction between serialization gadgets and typing, related to `org.apache.tomcat.dbcp.dbcp2.datasources.SharedPoolDataSource`.
Path Traversal in com.linecorp.armeria:armeria
Published: 2021-12-02T22:25:54Z
Aliases: CVE-2021-43795

### Impact

An attacker can access an Armeria server's local file system beyond its restricted directory by sending an HTTP request whose path contains `%2F` (encoded `/`), such as `/files/..%2Fsecrets.txt`, bypassing Armeria's path validation logic.

### Patches

Armeria 1.13.4 or above contains the hardened path validation logic that handles `%2F` properly. 

### Workarounds

This vulnerability can be worked around by inserting a decorator that performs an additional validation on the request path, e.g.

```java
Server
  .builder()
  .serviceUnder(
    "/files",
    FileService
      .of(...)
      .decorate((delegate, ctx, req) -> {
        String path = req.headers().path();
        if (path.contains("%2f") || path.contains("%2F")) {
          return HttpResponse.of(HttpStatus.BAD_REQUEST);
        }
        return delegate.serve(ctx, req);
      })
  )
  .build()
```

### For more information

If you have any questions or comments about this advisory:
* Open an issue in [line/armeria](https://github.com/line/armeria)
* Chat with us at [Slack](https://armeria.dev/s/slack)

### Credits

This vulnerability was originally reported by Abdallah Zaher ([elcayser-0x0a](https://hackerone.com/elcayser-0x0a?type=user)).
Code injection in FreeIPA
Published: 2021-12-06T18:17:38Z
Aliases: CVE-2019-14867

A flaw was found in IPA, all 4.6.x versions before 4.6.7, all 4.7.x versions before 4.7.4 and all 4.8.x versions before 4.8.3, in the way the internal function ber_scanf() was used in some components of the IPA server, which parsed kerberos key data. An unauthenticated attacker who could trigger parsing of the krb principal key could cause the IPA server to crash or in some conditions, cause arbitrary code to be executed on the server hosting the IPA server.
Code Injection in total.js
Published: 2021-12-10T17:26:06Z
Aliases: CVE-2021-23389

The package total.js before 3.4.9 are vulnerable to Arbitrary Code Execution via the U.set() and U.get() functions.
Incorrect Comparison in NumPy
Published: 2021-12-18T00:00:41Z
Aliases: CVE-2021-34141

Incomplete string comparison in the numpy.core component in NumPy1.9.x, which allows attackers to fail the APIs via constructing specific string objects.
lxml's HTML Cleaner allows crafted and SVG embedded scripts to pass through
Published: 2021-12-13T18:14:36Z
Aliases: CVE-2021-43818

### Impact
The HTML Cleaner in lxml.html lets certain crafted script content pass through, as well as script content in SVG files embedded using data URIs.

Users that employ the HTML cleaner in a security relevant context should upgrade to lxml 4.6.5.

### Patches
The issue has been resolved in lxml 4.6.5.

### Workarounds
None.

### References
The issues are tracked under the report IDs GHSL-2021-1037 and GHSL-2021-1038.
Unsafe Deserialization in jackson-databind
Published: 2021-12-09T19:16:51Z
Aliases: CVE-2020-36187

FasterXML jackson-databind 2.x before 2.9.10.8 mishandles the interaction between serialization gadgets and typing, related to org.apache.tomcat.dbcp.dbcp.datasources.SharedPoolDataSource.
yetiforcecrm is vulnerable to Cross-site Scripting
Published: 2021-12-17T20:00:12Z
Aliases: CVE-2021-4121

yetiforcecrm is vulnerable to Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting').
livehelperchat is vulnerable to Cross-Site Request Forgery (CSRF)
Published: 2021-12-17T20:00:16Z
Aliases: CVE-2021-4123

livehelperchat is vulnerable to Cross-Site Request Forgery (CSRF).
Remote code injection in Log4j
Published: 2021-12-14T21:46:35Z

### Impact
Logging untrusted or user controlled data with a vulnerable version of Log4J may result in Remote Code Execution (RCE) against your application. This includes untrusted data included in logged errors such as exception traces, authentication failures, and other unexpected vectors of user controlled input.

More Details:
https://github.com/advisories/GHSA-jfh8-c2jp-5v3q

### Patches
Version 1.11.1 of the Splunk Logging for Java library.

There is also a backport to version 1.6.2 released as a patch: 1.6.2-0-0.

### Workarounds
If upgrading is not possible, then ensure the -Dlog4j2.formatMsgNoLookups=true system property is set on both client- and server-side components.

### References
https://github.com/advisories/GHSA-jfh8-c2jp-5v3q

### For more information
If you have any questions or comments about this advisory:
* Open an issue in https://github.com/splunk/splunk-library-javalogging/issues
* Email us at [devinfo@splunk.com](mailto:devinfo@splunk.com)