Sandbox bypass vulnerability in Jenkins Pipeline: Groovy Libraries Plugin and Pipeline: Deprecated Groovy Libraries Plugin

[Severity: HIGH]

Pipeline: Groovy Libraries Plugin and older releases of the Pipeline: Deprecated Groovy Libraries Plugin (formerly Pipeline: Shared Groovy Libraries Plugin) define the l`ibrary` Pipeline step, which allows Pipeline authors to dynamically load Pipeline libraries. The return value of this step can be used to instantiate classes defined in the loaded library.

In Pipeline: Groovy Libraries Plugin 612.v84da_9c54906d and earlier and in Pipeline: Deprecated Groovy Libraries Plugin 583.vf3b_454e43966 and earlier, the `library` step can be used to invoke sandbox-generated synthetic constructors in crafted untrusted libraries and construct any subclassable type. This is similar to SECURITY-582 in the [2017-08-07 security advisory](https://www.jenkins.io/security/advisory/2017-08-07/#multiple-groovy-language-features-allowed-script-security-plugin-sandbox-bypass), but in a different plugin.

This vulnerability allows attackers with permission to define untrusted Pipeline libraries and to define and run sandboxed Pipelines, to bypass the sandbox protection and execute arbitrary code in the context of the Jenkins controller JVM.

Pipeline: Groovy Libraries Plugin 613.v9c41a_160233f rejects improper calls to sandbox-generated synthetic constructors when using the `library` step.

Pipeline: Deprecated Groovy Libraries Plugin 588.v576c103a_ff86 no longer contains the `library` step. It has been moved into the Pipeline: Groovy Libraries Plugin.


Content-Security-Policy protection for user content disabled by Jenkins NeuVector Vulnerability Scanner Plugin

[Severity: HIGH]

Jenkins sets the Content-Security-Policy header to static files served by Jenkins (specifically `DirectoryBrowserSupport`), such as workspaces, `/userContent`, or archived artifacts, unless a Resource Root URL is specified.

NeuVector Vulnerability Scanner Plugin 1.20 and earlier globally disables the `Content-Security-Policy` header for static files served by Jenkins whenever the 'NeuVector Vulnerability Scanner' build step is executed. This allows cross-site scripting (XSS) attacks by users with the ability to control files in workspaces, archived artifacts, etc.

Jenkins instances with [Resource Root URL](https://www.jenkins.io/doc/book/security/user-content/#resource-root-url) configured are unaffected.


Content-Security-Policy protection for user content can be disabled in Jenkins 360 FireLine Plugin

[Severity: HIGH]

Jenkins sets the Content-Security-Policy header to static files served by Jenkins (specifically `DirectoryBrowserSupport`), such as workspaces, `/userContent`, or archived artifacts, unless a Resource Root URL is specified.

360 FireLine Plugin 1.7.2 and earlier globally disables the `Content-Security-Policy` header for static files served by Jenkins whenever the 'Execute FireLine' build step is executed, if the option 'Open access to HTML with JS or CSS' is checked. This allows cross-site scripting (XSS) attacks by users with the ability to control files in workspaces, archived artifacts, etc.

Jenkins instances with [Resource Root URL](https://www.jenkins.io/doc/book/security/user-content/#resource-root-url) configured are unaffected.


Jenkins Compuware Topaz for Total Test Plugin allows attackers with Overall/Read permission to enumerate credentials IDs of credentials stored in Jenkins

[Severity: MEDIUM]

Jenkins Compuware Topaz for Total Test Plugin 2.4.8 and earlier does not perform permission checks in several HTTP endpoints, allowing attackers with Overall/Read permission to enumerate credentials IDs of credentials stored in Jenkins.


Liferay Portal and Liferay DXP Vulnerable to XSS in the CKEditor Integration with the Frontend Editor Module

[Severity: MEDIUM]

A Cross-site scripting (XSS) vulnerability in the Frontend Editor module's integration with CKEditor in Liferay Frontend Editor CKEditor Web before 5.0.46 from Liferay Portal (7.3.2 through 7.4.3.14), and Liferay DXP 7.3 before update 6, and 7.4 before update 15 allows remote attackers to inject arbitrary web script or HTML via the (1) name, or (2) namespace parameter.


Withdrawn: Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution') in @xmldom/xmldom and xmldom

[Severity: CRITICAL]

## Withdrawn

This advisory has been withdrawn because the maintainers of `@xmldom/xmldom` and multiple third parties disputed the validity of the issue. Attempts to create or replicate a proof of concept have been unsuccessful.

## Original Description

### Impact
A prototype pollution vulnerability exists in the function copy in dom.js in the xmldom (published as @xmldom/xmldom) package.

### Patches
Update to `@xmldom/xmldom@~0.7.6`, `@xmldom/xmldom@~0.8.3` (dist-tag `latest`) or `@xmldom/xmldom@>=0.9.0-beta.2` (dist-tag `next`).

### Workarounds
None

### References
https://github.com/xmldom/xmldom/pull/437

### For more information
If you have any questions or comments about this advisory:
* Email us at security@xmldom.org
* Add information to https://github.com/xmldom/xmldom/issues/436


Apache Airflow may allow authenticated users who have been deactivated to continue using the UI or API

[Severity: HIGH]

In Apache Airflow, prior to version 2.4.1, deactivating a user wouldn't prevent an already authenticated user from being able to continue using the UI or API.


Withdrawn: CVE Rejected: JXPath vulnerable to remote code execution when interpreting untrusted XPath expressions

[Severity: CRITICAL]

## This advisory has been withdrawn due to the CVE being rejected.

## Original advisory text
Those using JXPath to interpret untrusted XPath expressions may be vulnerable to a remote code execution attack. All JXPathContext class functions processing a XPath string are vulnerable except `compile()` and `compilePath()` function. The XPath expression can be used by an attacker to load any Java class from the classpath resulting in code execution.


When matrix-nio receives forwarded room keys, the receiver doesn't check if it requested the key from the forwarder

[Severity: HIGH]

When matrix-nio before 0.20 requests a room key from our devices, it correctly accepts key forwards only if they are a response to a previous request. However, it doesn't check that the device that responded matches the device the key was requested from.

This allows a malicious homeserver to insert room keys of questionable validity into the key store in some situations, potentially assisting in an impersonation attack.

### For more information
If you have any questions or comments about this advisory, e-mail us at [poljar@termina.org.uk](mailto:poljar@termina.org.uk).


matrix-js-sdk subject to user impersonation due to key/device identifier confusion in SAS verification

[Severity: HIGH]

## Impact

An attacker cooperating with a malicious homeserver could interfere with the verification flow between two users, injecting its own cross-signing user identity in place of one of the users’ identities, leading to the other device trusting/verifying the user identity under the control of the homeserver instead of the intended one.

The vulnerability is a bug in the matrix-js-sdk, caused by checking and signing user identities and devices in two separate steps, and inadequately fixing the keys to be signed between those steps.

Even though the attack is partly made possible due to the design decision of treating cross-signing user identities as Matrix devices on the server side (with their device ID set to the public part of the user identity key), no other examined implementations were vulnerable.

## Patches

The matrix-js-sdk has been modified to double check that the key signed is the one that was verified instead of just referencing the key by ID. An additional check has been made to report an error when one of the device ID matches a cross-signing key.

## Workarounds

As this attack requires coordination between a malicious homeserver and an attacker -- if you trust your homeserver no particular workaround is needed.

As a potential way of detecting compromise, it’s possible to review your device list or the device list of other users for devices with IDs in the form of a base64 cross-signing key (`5XaczGNlfz0bl8R1IX5qn+tBoue2tWJqLMh+SDUuvCk`) instead of classical device ID (`SEHACYDHMG`).

## References
Blog post: https://matrix.org/blog/2022/09/28/upgrade-now-to-address-encryption-vulns-in-matrix-sdks-and-clients

## For more information
If you have any questions or comments about this advisory, e-mail us at security@matrix.org


Dompdf allows remote file inclusion because URI validation failure does not halt font registration

[Severity: HIGH]

`registerFont` in `FontMetrics.php` in Dompdf before 2.0.1 allows remote file inclusion because a URI validation failure does not halt font registration, as demonstrated by a `@font-face` rule.


Scala subject to file deletion, code execution due to Java deserialization chain with LazyList object deserialization

[Severity: CRITICAL]

Scala 2.13.x before 2.13.9 has a Java deserialization chain in its JAR file. On its own, it cannot be exploited. There is only a risk in conjunction with LazyList object deserialization within an application. In such situations, it allows attackers to erase contents of arbitrary files, make network connections, or possibly run arbitrary code (specifically, Function0 functions) via a gadget chain.


Nepxion Discovery vulnerable to potential Information Disclosure due to  Server-Side Request Forgery

[Severity: MEDIUM]

Nepxion Discovery is a solution for Spring Cloud. Discovery is vulnerable to a potential Server-Side Request Forgery (SSRF). RouterResourceImpl uses RestTemplate’s getForEntity to retrieve the contents of a URL containing user-controlled input, potentially resulting in Information Disclosure. There is no patch available for this issue at time of publication. There are no known workarounds.


Jenkins Compuware Common Configuration Plugin vulnerable to Improper Restriction of XML External Entity Reference

[Severity: HIGH]

Jenkins Compuware Common Configuration Plugin 1.0.14 and earlier does not configure its XML parser to prevent XML external entity (XXE) attacks.

This allows attackers able to change the contents of the Topaz Workbench CLI home directory on agents to have Jenkins parse a crafted file that uses external entities for extraction of secrets from the Jenkins controller or server-side request forgery.


@netlify/ipx vulnerable to Full Response SSRF and Stored XSS via Cache Poisoning and Improper Host Validation

[Severity: MEDIUM]

### Impact

By sending specially crafted headers an attacker can bypass the source image domain allowlist, causing the handler to load and return arbitrary images. Because the response is cached globally, this image will then be served to visitors without requiring those headers to be set. XSS can be achieved by requesting a malicious SVG with embedded scripts, which would then be served from the site domain. Note that this does not apply to images loaded in `<img>` tags, as scripts do not execute in this context. The image URL can be set in the header independently of the request URL, meaning any site images that have not previously been cached can have their cache poisoned.

### Patches
This problem has been fixed in version 1.2.3

### Workarounds

The problem is no longer exploitable on Netlify as the CDN now sanitizes the relevant header. Cached content can be cleared by re-deploying the site.


arr-pm vulnerable to arbitrary shell execution when extracting or listing files contained in a malicious rpm.

[Severity: HIGH]

### Impact

Arbitrary shell execution is possible when using RPM::File#files and RPM::File#extract if the RPM contains a malicious "payload compressor" field.

This vulnerability impacts the `extract` and `files` methods of the `RPM::File` class in the affected versions of this library.

### Patches

Version 0.0.12 is available with a fix for these issues.

### Workarounds

When using an affected version of this library (arr-pm), ensure any RPMs being processed contain valid/known payload compressor values. Such values include: gzip, bzip2, xz, zstd, and lzma.

You can check the payload compressor field in an rpm by using the rpm command line tool. For example:

```
% rpm -qp example-1.0-1.x86_64.rpm --qf "%{PAYLOADCOMPRESSOR}\n"
gzip
```

### Impact on known dependent projects

This library is used by [fpm](https://github.com/jordansissel/fpm). The vulnerability may impact fpm only when using the flag `-s rpm` or `--input-type rpm` to convert a malicious rpm to another format. It does not impact creating rpms.

### References

* https://github.com/jordansissel/ruby-arr-pm/pull/14
* https://github.com/jordansissel/ruby-arr-pm/pull/15

### Credit

Thanks to @joernchen for reporting this problem and contributing to the resolution :)

### For more information

If you have any questions or comments about this advisory:
* Open an issue in [the arr-pm issue tracker](https://github.com/jordansissel/ruby-arr-pm/)


Apache Kafka vulnerability can lead to brokers hitting OutOfMemoryException, causing Denial of Service

[Severity: HIGH]

A security vulnerability has been identified in Apache Kafka. It affects all releases since 2.8.0. The vulnerability allows malicious unauthenticated clients to allocate large amounts of memory on brokers. This can lead to brokers hitting OutOfMemoryException and causing denial of service. Example scenarios: - Kafka cluster without authentication: Any clients able to establish a network connection to a broker can trigger the issue. - Kafka cluster with SASL authentication: Any clients able to establish a network connection to a broker, without the need for valid SASL credentials, can trigger the issue. - Kafka cluster with TLS authentication: Only clients able to successfully authenticate via TLS can trigger the issue. We advise the users to upgrade the Kafka installations to one of the 3.2.3, 3.1.2, 3.0.2, 2.8.2 versions.


XWiki Platform Security Parent POM vulnerable to overwriting of security rules of a page with a final page having the same reference

[Severity: HIGH]

### Impact

A bug in the security cache is storing rules associated to document Page1.Page2 and space Page1.Page2 in the same cache entry.

That means that it's possible to overwrite the rights of a space or a document by creating the page of the space with the same name and checking the right of the new one first so that they end up in the security cache and are used for the other too.

### Patches

The problem has been patched in XWiki 12.10.11, 13.10.1, 13.4.6.

### Workarounds

No workaround other than patching.

### References

https://jira.xwiki.org/browse/XWIKI-14075
https://jira.xwiki.org/browse/XWIKI-18983

### For more information
If you have any questions or comments about this advisory:
* Open an issue in [Jira XWiki.org](https://jira.xwiki.org)
* Email us at [Security Mailing List](mailto:security@xwiki.org)


Docker supplementary group permissions not set up properly, allowing attackers to bypass primary group restrictions

[Severity: MEDIUM]

Moby is an open-source project created by Docker to enable software containerization. A bug was found in Moby (Docker Engine) where supplementary groups are not set up properly. If an attacker has direct access to a container and manipulates their supplementary group access, they may be able to use supplementary group access to bypass primary group restrictions in some cases, potentially gaining access to sensitive information or gaining the ability to execute code in that container.  This bug is fixed in Moby (Docker Engine) 20.10.18. Users should update to this version when it is available. Running containers should be stopped and restarted for the permissions to be fixed. For users unable to upgrade, this problem can be worked around by not using the `"USER $USERNAME"` Dockerfile instruction. Instead by calling `ENTRYPOINT ["su", "-", "user"]` the supplementary groups will be set up properly.

Thanks to Steven Murdoch for reporting this issue.

----

### Impact

If an attacker has direct access to a container and manipulates their supplementary group access, they may be able to use supplementary group access to bypass primary group restrictions in some cases, potentially gaining access to sensitive information or gaining the ability to execute code in that container.

### Patches

 This bug is fixed in Moby (Docker Engine) 20.10.18. Users should update to this version when it is available.

### Workarounds

This problem can be worked around by not using the `"USER $USERNAME"` Dockerfile instruction. Instead by calling `ENTRYPOINT ["su", "-", "user"]` the supplementary groups will be set up properly.

### References

https://www.benthamsgaze.org/2022/08/22/vulnerability-in-linux-containers-investigation-and-mitigation/

### For more information

If you have any questions or comments about this advisory:

* [Open an issue](https://github.com/moby/moby/issues/new)
* Email us at [security@docker.com](mailto:security@docker.com)


Cosign bundle can be crafted to successfully verify a blob even if the embedded rekorBundle does not reference the given signature

[Severity: MEDIUM]

## Summary

A number of vulnerabilities have been found in `cosign verify-blob`, where Cosign would successfully verify an artifact when verification should have failed.

## Vulnerability 1: Bundle mismatch causes invalid verification.

### Summary
A cosign bundle can be crafted to successfully verify a blob even if the embedded rekorBundle does not reference the given signature.

### Details
Cosign supports "bundles" which intend to allow offline verification of the signature and rekor inclusion. By using the --bundle flag in cosign sign-blob, cosign will create a JSON file called a "bundle". These bundles include three fields: base64Signature, cert, and rekorBundle. The desired behavior is that the verification of these bundles would:

- verify the provided blob using the included signature and certificate
- verify the rekorBundle SET
- verify the rekorBundle payload references the given artifact.

It appears that step three is not being performed, allowing "any old rekorBundle" to pass validation, even if the rekorBundle payload does not reference the provided blob or the certificate and signature in the rekorBundle do not match those at the top level.

### Steps to reproduce
Enable keyless signing:

```
export COSIGN_EXPERIMENTAL=1
```
Create two random blobs:
```
dd bs=1 count=50 </dev/urandom >blob1
dd bs=1 count=50 </dev/urandom >blob2
```
Sign each blob:
```
cosign sign-blob blob1 --bundle bundle1
cosign sign-blob blob2 --bundle bundle2
```
Create a falsified bundle including the base64Signature and cert fields from bundle1 and the rekorBundle from bundle2:
```
jq --slurpfile bundle2 bundle2 '.rekorBundle = $bundle2[0].rekorBundle' bundle1 > invalidBundle
```
Now, the falsified bundle can be used to verify blob1:
```
$ cosign verify-blob blob1 --bundle invalidBundle
tlog entry verified offline
Verified OK
```

### Patches

Users should update to the latest version of Cosign, `1.12.0`.

### Workaround

If you extract the signature and certificate from the `bundle`, you may use it for verification as follows and avoid using an invalid bundle:
```
$ cosign verify-blob blob1 --signature $(jq -r '.base64Signature' bundle1) --certificate $(jq -r '.cert' bundle1)
```

Note that this will make a network call to Rekor to fetch the Rekor entry. However, you may then be subject to Vulnerability 4.

##  Vulnerability 2: Certificate Identities are not checked in some cases

### Summary

When providing identity flags, the email and issuer of a certificate is not checked when verifying a Rekor bundle, and the GitHub Actions identity is never checked.

### Details

Users who provide an offline Rekor bundle (`--bundle`) when verifying a blob using `cosign verify-blob` and include flags that check identity such as `--certificate-email` and `--certificate-oidc-issuer` are impacted. Additionally, users who provide the GitHub Actions verification flags such as `--certificate-github-workflow-name` when running `cosign verify-blob` without a bundle, key reference, or certificate are impacted.

When providing these flags, Cosign ignored their values. If a certificate's identity did not match the provided flags, Cosign would still successfully verify the blob.

### Patches

Users should update to the latest version of Cosign, `1.12.0`.

### Workarounds

There are no workarounds, users should update.

##  Vulnerability 3: Invalid Rekor bundle without the experimental flag will result in successful verification

### Summary

Providing an invalid Rekor bundle without the experimental flag results in a successful verification.

### Details

Users who provide an offline Rekor bundle (`--bundle`) that was invalid (invalid signed entry timestamp, expired certificate, or malformed) when verifying a blob with `cosign verify-blob` and do not set the `COSIGN_EXPERIMENTAL=1` flag are impacted.

When an invalid bundle was provided, Cosign would fallback to checking Rekor log inclusion by requesting proof of inclusion from the log. However, without the `COSIGN_EXPERIMENTAL` flag, Cosign would exit early and successfully verify the blob.

### Patches

Users should update to the latest version of Cosign, `1.12.0`.

### Workarounds

There are no workarounds, users should update.

##  Vulnerability 4: Invalid transparency log entry will result in successful verification

### Summary

An invalid transparency log entry will result in immediate success for verification.

### Details

Users who provide a signature and certificate to `verify-blob` will fetch the associated Rekor entry for verification. If the returned entry was invalid (invalid signed entry timestamp, invalid inclusion proof, malformed entry with missing verification), then `cosign` [exits](https://github.com/sigstore/cosign/blob/42c6e2a6dd9d92d19077c8e6b7d66d155a5ea28c/cmd/cosign/cli/verify/verify_blob.go#L357) early and succeeds unconditionally.

### Patches

Users should update to the latest version of Cosign, `1.12.0`.

### Workarounds

There are no workarounds, users should update.

## For more information
If you have any questions or comments about this advisory:
* Open an issue in [cosign](https://github.com/sigstore/cosign)
* Send us a message on [Slack](https://sigstore.slack.com/).


ReactPHP's HTTP server parses encoded cookie names so malicious `__Host-` and `__Secure-` cookies can be sent

[Severity: MEDIUM]

### Impact

In ReactPHP's HTTP server component versions below v1.7.0, when ReactPHP is processing incoming HTTP cookie values, the cookie names are url-decoded. This may lead to cookies with prefixes like `__Host-` and `__Secure-` confused with cookies that decode to such prefix, thus leading to an attacker being able to forge cookie which is supposed to be secure. See also CVE-2020-7070 and CVE-2020-8184 for more information.

### Patches

* https://github.com/reactphp/http/commit/663c9a3b77b71463fa7fcb76a6676ffd16979dd6 - Fixed in [reactphp/http `v1.7.0`](https://github.com/reactphp/http/releases/tag/v1.7.0)

### Workarounds

Infrastructure or DevOps can place a reverse proxy in front of the ReactPHP HTTP server to filter out any unexpected `Cookie` request headers.

### References

* CVE-2020-7070, https://bugs.php.net/bug.php?id=79699 and https://github.com/php/php-src/commit/6559fe912661ca5ce5f0eeeb591d928451428ed0
* CVE-2020-8184, https://hackerone.com/reports/895727 and https://github.com/rack/rack/commit/1f5763de6a9fe515ff84992b343d63c88104654c
* Originally introduced via https://github.com/reactphp/http/pull/175

### Credits

* Thanks to Marco Squarcina (TU Wien) for reporting this and working with us to coordinate this security advisory

### For more information

If you have any questions or comments about this advisory:

* [Join the discussion](https://github.com/orgs/reactphp/discussions/465)
* Email us at support@reactphp.org


linked_list_allocator vulnerable to out-of-bound writes on `Heap` initialization and `Heap::extend`

[Severity: HIGH]

## Impact
_What kind of vulnerability is it? Who is impacted?_

This vulnerability impacts all the initialization functions on the `Heap` and `LockedHeap` types, including `Heap::new`, `Heap::init`, `Heap::init_from_slice`, and `LockedHeap::new`. It also affects multiple uses of the `Heap::extend` method.

### Initialization Functions

The heap initialization methods were missing a minimum size check for the given heap size argument. This could lead to **_out-of-bound writes_** when a heap was initialized with a size smaller than `3 * size_of::<usize>` because of metadata write operations.

### `Heap::extend`

This vulnerability impacts three specific uses of the `Heap::extend` method:

- When calling `Heap::extend` with a size smaller than two `usize`s (e.g., 16 on `x86_64`), the size was erroneously rounded up to the minimum size, which could result in an **_out-of-bounds write_**.
- Calling `Heap::extend` on an empty heap tried to construct a heap starting at address 0, which is also an **_out-of-bounds write_**.
  - One specific way to trigger this accidentally is to call `Heap::new` (or a similar constructor) with a heap size that is smaller than two `usize`s. This was treated as an empty heap as well.
- Calling `Heap::extend` on a heap whose size is not a multiple of the size of two `usize`s resulted in _unaligned writes_. It also left the heap in an unexpected state, which might lead to subsequent issues. We did not find a way to exploit this undefined behavior yet (apart from DoS on platforms that fault on unaligned writes).

## Patches
_Has the problem been patched? What versions should users upgrade to?_

We published a patch in version `0.10.2` and recommend all users to upgrade to it. This patch release includes the following changes:

- The initialization functions now panic if the given size is not large enough to store the necessary metadata. Depending on the alignment of the heap bottom pointer, the minimum size is between `2 * size_of::<usize>` and `3 * size_of::<usize>`.
- The `extend` method now panics when trying to extend an unitialized heap.
- Extend calls with a size smaller than `size_of::<usize>() * 2` are now buffered internally and not added to the list directly. The buffered region will be merged with future `extend` calls.
- The `size()` method now returns the _usable_ size of the heap, which might be slightly smaller than the `top() - bottom()` difference because of alignment constraints.

## Workarounds
_Is there a way for users to fix or remediate the vulnerability without upgrading?_

To avoid this issue, ensure that the heap is only initialized with a size larger than `3 * size_of::<usize>` and that the `Heap::extend` method is only called with sizes larger than `2 * size_of::<usize>()`. Also, ensure that the total heap size is (and stays) a multiple of `2 * size_of::<usize>()`.

## For more information

If you have any questions or comments about this advisory:
* Open an issue in this repository
* Email @phil-opp at [security@phil-opp.com](mailto:security@phil-opp.com)

## Acknowledgements

This issue was responsibly reported by Evan Richter at ForAllSecure and found with [Mayhem](https://forallsecure.com/mayhem-for-code) and [cargo fuzz](https://github.com/rust-fuzz/cargo-fuzz).


XWiki Platform Web Templates vulnerable to Missing Authorization, Exposure of Private Personal Information to Unauthorized Actor

[Severity: HIGH]

### Impact
Through the suggestion feature, string and list properties of objects the user shouldn't have access to can be accessed. This includes private personal information like email addresses and salted password hashes of registered users but also other information stored in properties of objects. Sensitive configuration fields like passwords for LDAP or SMTP servers could be accessed. By exploiting an additional vulnerability, this issue can even be exploited on [private wikis](https://www.xwiki.org/xwiki/bin/view/Documentation/AdminGuide/Access%20Rights/#HPrivateWiki) at least for string properties.

### Patches
The issue is patched in version 13.10.4 and 14.2. Password properties are no longer displayed and rights are checked for other properties.

### Workarounds
The template file `suggest.vm` can be replaced by a patched version without upgrading or restarting XWiki unless it has been [overridden](https://extensions.xwiki.org/xwiki/bin/view/Extension/Skin%20Application#HHowtooverrideatemplate), in which case the overridden template should be patched, too. This might need adjustments for older versions, though.

### References
* https://jira.xwiki.org/browse/XWIKI-18849

### For more information
If you have any questions or comments about this advisory:
* Open an issue in [Jira XWiki.org](https://jira.xwiki.org)
* Email us at [security mailing-list](mailto:security@xwiki.com)


XWiki Platform Web Templates vulnerable to Unauthorized User Registration Through the Distribution Wizard

[Severity: HIGH]

### Impact
By passing a template of the distribution wizard to the xpart template, user accounts can be created even when user registration is disabled. This also circumvents any email verification. Before versions 14.2 and 13.10.4, this can also be exploited on a private wiki, thus potentially giving the attacker access to the wiki. Depending on the configured default rights of users, this could also give attackers write access to an otherwise read-only public wiki. Users can also be created when an external authentication system like LDAP is configured, but authentication fails unless the authentication system supports a bypass/local accounts are enabled in addition to the external authentication system.

### Patches
This issue has been patched in XWiki 13.10.5 and 14.3RC1.

### Workarounds
It is possible to replace `xpart.vm`, the entry point for this attack, by a patched version from the [patch](https://github.com/xwiki/xwiki-platform/commit/70c64c23f4404f33289458df2a08f7c4be022755) without updating XWiki.

### References
* https://jira.xwiki.org/browse/XWIKI-19558

### For more information
If you have any questions or comments about this advisory:
* Open an issue in [Jira XWiki.org](https://jira.xwiki.org/)
* Email us at [Security Mailing List](mailto:security@xwiki.org)


Buildah's incorrect handling of the supplementary groups may lead to data disclosure, modification

[Severity: HIGH]

An incorrect handling of the supplementary groups in the Buildah container engine might lead to the sensitive information disclosure or possible data modification if an attacker has direct access to the affected container where supplementary groups are used to set access permissions and is able to execute a binary code in that container.


Harbor fails to validate the user permissions when reading job execution logs through the P2P preheat execution logs

[Severity: MEDIUM]

### Impact
Harbor fails to validate the user permissions when reading job execution logs through the P2P preheat execution logs - API call

  GET /projects/{project_name}/preheat/policies/{preheat_policy_name}/executions/{execution_id}/tasks/{task_id}/logs

By sending a request that attempts to read P2P preheat execution logs and specifying different job ids, malicious authenticatedusers could read all the job logs stored in the Harbor database.

### Patches
This and similar issues are fixed in Harbor v2.5.2 and later. Please upgrade as soon as possible.

### Workarounds
There are no workarounds available.

### For more information
If you have any questions or comments about this advisory:
* Open an issue in [the Harbor GitHub repository](https://github.com/goharbor/harbor)

### Credits
Thanks to [Gal Goldstein](https://www.linkedin.com/in/gal-goldshtein/) and [Daniel Abeles](https://www.linkedin.com/in/daniel-abeles/) from [Oxeye Security](https://www.oxeye.io/) for reporting this issue.


Gluu Oxauth before v4.4.1 vulnerable to Server-Side Request Forgery attacks via a crafted request_uri parameter

[Severity: CRITICAL]

Gluu Oxauth before v4.4.1 allows attackers to execute blind SSRF (Server-Side Request Forgery) attacks via a crafted request_uri parameter.


gomatrixserverlib and Dendrite vulnerable to incorrect parsing of the event default power level in event auth

[Severity: MEDIUM]

### Impact

The power level parsing within gomatrixserverlib was failing to parse the `"events_default"` key of the `m.room.power_levels` event, defaulting the event default power level to zero in all cases.

In rooms where the `"events_default"` power level had been changed, this could result in events either being incorrectly authorised or rejected by Dendrite servers.

### Patches

gomatrixserverlib contains a fix as of commit `723fd49` and Dendrite 0.9.3 has been updated accordingly.

### Workarounds

Matrix rooms where the `"events_default"` power level has not been changed from the default of zero are not vulnerable.

### For more information

If you have any questions or comments about this advisory, e-mail us at [security@matrix.org](mailto:security@matrix.org).


Keycloak XSS via use of malicious payload as group name when creating new group from admin console

[Severity: MEDIUM]

A flaw was found in Keycloak. This flaw allows a privileged attacker to use the malicious payload as the group name while creating a new group from the admin console, leading to a stored Cross-site scripting (XSS) attack.


Venice vulnerable to Partial Path Traversal issue within the functions `load-file` and `load-resource`

[Severity: MEDIUM]

### Impact
A partial path traversal issue exists within the functions `load-file` and `load-resource`. These functions can be limited to load files from a list of load paths.

Assuming Venice has been configured with the load paths: `[ "/Users/foo/resources" ]`

When passing **relative** paths to these two vulnerable functions everything is fine:
`(load-resource "test.png")`   => loads the file "/Users/foo/resources/test.png"
`(load-resource "../resources-alt/test.png")`   => rejected, outside the load path

When passing **absolute** paths to these two vulnerable functions Venice may return files outside the configured load paths:
`(load-resource "/Users/foo/resources/test.png")`   => loads the file "/Users/foo/resources/test.png"
`(load-resource "/Users/foo/resources-alt/test.png")`   => loads the file "/Users/foo/resources-alt/test.png" !!!
The latter call suffers from the _Partial Path Traversal_ vulnerability.

This issue’s scope is limited to absolute paths whose name prefix matches a load path. E.g. for a load-path `"/Users/foo/resources"`, the actor can cause loading a resource also from `"/Users/foo/resources-alt"`, but not from `"/Users/foo/images"`.

Versions of Venice before and including v1.10.16 are affected by this issue.

### Patches
Upgrade to Venice >= 1.10.17, if you are on a version < 1.10.17

### Workarounds
If you cannot upgrade the library, you can control the functions that can be used in Venice with a sandbox. If it is appropriate, the functions `load-file` and `load-resource` can be blacklisted in the sandbox.

### References
  * [PR](https://github.com/jlangch/venice/pull/4/commits/c942c73136333bc493050910f171a48e6f575b23)

### For more information
If you have any questions or comments about this advisory:
* Open an issue in [GitHub Venice](https://github.com/jlangch/venice)
* Email us at [juerg.ch](mailto:juerg.ch@ggaweb.ch)

### Credits

I want to publicly recognize the contribution of [Jonathan Leitschuh](https://github.com/JLLeitschuh) for reporting this issue.


OpenZeppelin Contracts's GovernorVotesQuorumFraction updates to quorum may affect past defeated proposals

[Severity: HIGH]

### Impact

This issue concerns instances of Governor that use the module `GovernorVotesQuorumFraction`, a mechanism that determines quorum requirements as a percentage of the voting token's total supply. In affected instances, when a proposal is passed to lower the quorum requirement, past proposals may become executable if they had been defeated only due to lack of quorum, and the number of votes it received meets the new quorum requirement.

Analysis of instances on chain found only one proposal that met this condition, and we are actively monitoring for new occurrences of this particular issue.

### Patches

This issue has been patched in v4.7.2.

### Workarounds

Avoid lowering quorum requirements if a past proposal was defeated for lack of quorum.

### References

https://github.com/OpenZeppelin/openzeppelin-contracts/pull/3561

### For more information

If you have any questions or comments about this advisory, or need assistance deploying the fix, email us at [security@openzeppelin.com](mailto:security@openzeppelin.com).


Bots using py-cord as Discord API wrapper are vulnerable to shutdowns through remote code execution

[Severity: HIGH]

### Impact
py-cord is a an API wrapper for Discord written in Python. Bots using py-cord version 2.0.0 are vulnerable to remote shutdown if they are added to the server with the `application.commands` scope without the `bot` scope. Currently, it appears that all public bots that use slash commands are affected.

### Patches
This issue has been patched in version 2.0.1.

### Workarounds
There are currently no recommended workarounds - please upgrade to a patched version.

### References
https://github.com/Pycord-Development/pycord/pull/1568

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


@acrontum/filesystem-template vulnerable to Command Injection due to fetchRepo API missing sanitization

[Severity: CRITICAL]

The package @acrontum/filesystem-template before 0.0.2 is vulnerable to Arbitrary Command Injection due to the fetchRepo API missing sanitization of the href field of external input.


Go Ethereum allows attackers to use manipulation of time-difference values to achieve replacement of main-chain blocks

[Severity: MEDIUM]

Go Ethereum (aka geth) through 1.10.21 allows attackers to increase rewards by mining blocks in certain situations, and using a manipulation of time-difference values to achieve replacement of main-chain blocks, aka Riskless Uncle Making (RUM), as exploited in the wild in 2020 through 2022.


NextAuth.js before 4.10.3 and 3.29.10 sending verification requests (magic link) to unwanted emails

[Severity: CRITICAL]

### Impact
`next-auth` users who are using the `EmailProvider` either in versions before `4.10.3` or `3.29.10` are affected.

If an attacker could forge a request that sent a comma-separated list of emails (eg.: `attacker@attacker.com,victim@victim.com`) to the sign-in endpoint, NextAuth.js would send emails to both the attacker and the victim's e-mail addresses. The attacker could then login as a newly created user with the email being `attacker@attacker.com,victim@victim.com`. This means that basic authorization like `email.endsWith("@victim.com")` in the `signIn` callback would fail to communicate a threat to the developer and would let the attacker bypass authorization, even with an `@attacker.com` address.

### Patches
We patched this vulnerability in `v4.10.3` and `v3.29.10` by normalizing the email value that is sent to the sign-in endpoint before accessing it anywhere else. We also added a `normalizeIdentifier` callback on the `EmailProvider` configuration, where you can further tweak your requirements for what your system considers a valid e-mail address. (E.g.: strict RFC2821 compliance)

To upgrade, run one of the following:
```sh
npm i next-auth@latest
```
```sh
yarn add next-auth@latest
```
```sh
pnpm add next-auth@latest
```

(This will update to the latest v4 version, but you can change `latest` to `3` if you want to stay on v3. This is not recommended. v3 is unmaintained.)

### Workarounds
If for some reason you cannot upgrade, you can normalize the incoming request like the following, using Advanced Initialization:
```ts
// pages/api/auth/[...nextauth].ts

function normalize(identifier) {
  // Get the first two elements only,
  // separated by `@` from user input.
  let [local, domain] = identifier.toLowerCase().trim().split("@")
  // The part before "@" can contain a ","
  // but we remove it on the domain part
  domain = domain.split(",")[0]
  return `${local}@${domain}`
}

export default async function handler(req, res) {
  if (req.body.email) req.body.email = normalize(req.body.email)
  return await NextAuth(req, res, {/* your options */ })
}
```

### References
- EmailProvider: https://next-auth.js.org/providers/email
- Normalize the email address: https://next-auth.js.org/providers/email#normalizing-the-email-address
- Email syntax: https://en.wikipedia.org/wiki/Email_address#Local-part
- `signIn` callback: https://next-auth.js.org/configuration/callbacks#sign-in-callback
- Advanced Initialization: https://next-auth.js.org/configuration/initialization#advanced-initialization
- `nodemailer` address: https://nodemailer.com/message/addresses

### For more information

If you have any concerns, we request responsible disclosure, outlined here: https://next-auth.js.org/security#reporting-a-vulnerability

### Timeline

The issue was reported 26th of July, a response was sent out in less than 1 hour and after identifying the issue a patch was published within 5 working days.

### Acknowledgments

We would like to thank [Socket](https://socket.dev) for disclosing this vulnerability in a responsible manner and following up until it got published.


Eclipse Californium denial of service (DoS) via Datagram Transport Layer Security (DTLS) handshake on parameter mismatch

[Severity: HIGH]

In Eclipse Californium versions 2.0.0 to 2.7.2 and 3.0.0-3.5.0 a DTLS resumption handshake falls back to a DTLS full handshake on a parameter mismatch without using a HelloVerifyRequest. Especially, if used with certificate based cipher suites, that results in message amplification (DDoS other peers) and high CPU load (DoS own peer). The misbehavior occurs only with DTLS_VERIFY_PEERS_ON_RESUMPTION_THRESHOLD values larger than 0.


Jenkins Job Configuration History Plugin does not require POST requests for several HTTP endpoints

[Severity: MEDIUM]

Jenkins Job Configuration History Plugin 1155.v28a_46a_cc06a_5 and earlier does not require POST requests for several HTTP endpoints, resulting in cross-site request forgery (CSRF) vulnerabilities.

These vulnerabilities allow attackers to delete entries from job, agent, and system configuration history, or restore older versions of job, agent, and system configurations.

Job Configuration History Plugin 1156.v536a_97b_8d649 requires POST requests for the affected HTTP endpoints.


Jenkins HashiCorp Vault Plugin does not perform permission checks in several HTTP endpoints that perform Vault connection tests

[Severity: MEDIUM]

A missing permission check in Jenkins HashiCorp Vault Plugin 354.vdb_858fd6b_f48 and earlier allows attackers with Overall/Read permission to obtain credentials stored in Vault with attacker-specified path and keys.


Jenkins rpmsign-plugin does not perform a permission check in a method implementing form validation

[Severity: MEDIUM]

Jenkins rpmsign-plugin Plugin 0.5.0 and earlier does not perform a permission check in a method implementing form validation.

This allows attackers with Item/Read permission but without Item/Workspace or Item/Configure permission to check whether attacker-specified file patterns match workspace contents. A sequence of requests can be used to effectively list workspace contents.

rpmsign-plugin Plugin 0.5.1 requires Item/Workspace permission to validate patterns with workspace contents.


Jenkins Deployer Framework Plugin allows attackers with Item/Read permission to read deployment logs

[Severity: MEDIUM]

Jenkins Deployer Framework Plugin 85.v1d1888e8c021 and earlier does not perform a permission check in an HTTP endpoint.

This allows attackers with Item/Read permission to read deployment logs.

Deployer Framework Plugin 86.v7b_a_4a_55b_f3ec requires Deploy Now/Deploy permission to read deployment logs.


Jenkins Deployer Framework Plugin does not restrict application path of applications when configuring a deployment

[Severity: MEDIUM]

Jenkins Deployer Framework Plugin 85.v1d1888e8c021 and earlier does not restrict the application path of the applications when configuring a deployment, allowing attackers with Item/Configure permission to upload arbitrary files from the Jenkins controller file system to the selected service.


Jenkins rhnpush-plugin does not perform a permission check in a method implementing form validation

[Severity: MEDIUM]

Jenkins rhnpush-plugin Plugin 0.5.1 and earlier does not perform a permission check in a method implementing form validation.

This allows attackers with Item/Read permission but without Item/Workspace or Item/Configure permission to check whether attacker-specified file patterns match workspace contents. A sequence of requests can be used to effectively list workspace contents.

rhnpush-plugin Plugin 0.5.2 requires Item/Workspace permission to validate patterns with workspace contents.


Jenkins Compuware ISPW Operations Plugin does not perform permission checks in several HTTP endpoints

[Severity: MEDIUM]

Jenkins BMC AMI DevX Code Pipeline Operations Plugin 1.0.8 and earlier does not perform permission checks in several HTTP endpoints.

This allows attackers with Overall/Read permission to enumerate hosts and ports of Compuware configurations and credentials IDs of credentials stored in Jenkins. Those credentials IDs can be used as part of an attack to capture the credentials using another vulnerability.

BMC AMI DevX Code Pipeline Operations Plugin 1.0.9 requires the appropriate permissions to enumerate hosts and ports of Compuware configurations and credentials IDs.


Jenkins Repository Connector Plugin allows attackers with Overall/Read permission to enumerate credentials IDs

[Severity: MEDIUM]

Jenkins Repository Connector Plugin 2.2.0 and earlier does not perform permission checks in several HTTP endpoints.

This allows attackers with Overall/Read permission to enumerate credentials IDs of credentials stored in Jenkins. Those can be used as part of an attack to capture the credentials using another vulnerability.

As of publication of this advisory, there is no fix.


Jenkins Repository Connector Plugin does not perform a permission check in a method implementing form validation

[Severity: MEDIUM]

Jenkins Repository Connector Plugin 2.2.0 and earlier does not perform a permission check in a method implementing form validation.

This allows attackers with Overall/Read permission to check for the existence of an attacker-specified file path on the Jenkins controller file system. A sequence of requests can be used to effectively list the Jenkins controller file system.

As of publication of this advisory, there is no fix.


Jenkins Android Signing Plugin allows attackers to check whether attacker-specified file patterns match workspace contents

[Severity: MEDIUM]

Jenkins Android Signing Plugin 2.2.5 and earlier does not perform a permission check in a method implementing form validation.

This allows attackers with Item/Read permission but without Item/Workspace or Item/Configure permission to check whether attacker-specified file patterns match workspace contents. A sequence of requests can be used to effectively list workspace contents.


Jenkins Files Found Trigger Plugin allows attackers to check for existence of attacker-specified file path on Jenkins controller file system

[Severity: MEDIUM]

Jenkins Files Found Trigger Plugin 1.5 and earlier does not perform a permission check in a method implementing form validation.

This allows attackers with Overall/Read permission to check for the existence of an attacker-specified file path on the Jenkins controller file system. A sequence of requests can be used to effectively list the Jenkins controller file system.

As of publication of this advisory, there is no fix.


Jenkins Openstack Heat Plugin does not perform permission checks in methods implementing form validation

[Severity: MEDIUM]

Jenkins openstack-heat Plugin 1.5 and earlier does not perform permission checks in methods implementing form validation.

This allows attackers with Overall/Read permission to check for the existence of an attacker-specified file path on the Jenkins controller file system. A sequence of requests can be used to effectively list the Jenkins controller file system.

As of publication of this advisory, there is no fix.


Jenkins Google Cloud Backup Plugin allows attackers with Overall/Read permission to request a manual backup.

[Severity: MEDIUM]

Jenkins Google Cloud Backup Plugin 0.6 and earlier does not perform a permission check in an HTTP endpoint.

This allows attackers with Overall/Read permission to request a manual backup.

Additionally, this HTTP endpoint does not require POST requests, resulting in a cross-site request forgery (CSRF) vulnerability.

As of publication of this advisory, there is no fix.


Jenkins Coverity Plugin allows attackers with Overall/Read permission to enumerate credentials IDs

[Severity: MEDIUM]

Jenkins Coverity Plugin 1.11.4 and earlier does not perform a permission check in an HTTP endpoint.

This allows attackers with Overall/Read permission to enumerate credentials IDs of credentials stored in Jenkins. Those can be used as part of an attack to capture the credentials using another vulnerability.

As of publication of this advisory, there is no fix.


Jenkins Buckminster Plugin does not perform a permission check in a method implementing form validation

[Severity: MEDIUM]

Jenkins Buckminster Plugin 1.1.1 and earlier does not perform a permission check in a method implementing form validation.

This allows attackers with Overall/Read permission to check for the existence of an attacker-specified file path on the Jenkins controller file system. A sequence of requests can be used to effectively list the Jenkins controller file system.

As of publication of this advisory, there is no fix.


Slack Morphism for Rust before 0.41.0 can leak Slack OAuth client information in application debug logs

[Severity: HIGH]

### Impact
Potential/accidental leaking of Slack OAuth client information in application debug logs.

### Patches
More strict and secure debug formatting was introduced in v0.41 for OAuth secret types to avoid the possibility of printing sensitive information in application logs.

### Workarounds
Don't print/output in logs request and responses for OAuth and client configurations.

### For more information
If you have any questions or comments about this advisory:
* Open an issue in the [repo](https://github.com/abdolence/slack-morphism-rust)
* Email us at [me@abdolence.dev](mailto:me@abdolence.dev)


Apache Xalan Java XSLT library integer truncation issue when processing malicious XSLT stylesheets

[Severity: HIGH]

The Apache Xalan Java XSLT library is vulnerable to an integer truncation issue when processing malicious XSLT stylesheets. This can be used to corrupt Java class files generated by the internal XSLTC compiler and execute arbitrary Java bytecode.

A fix for this issue was published in September 2022 as part of an anticipated 2.7.3 release.


LTI 1.3 Tool Library's Nonce Claim Value not validated against nonce value sent in Authentication Request before v5.0

[Severity: HIGH]

### Impact

Nonce Claim Value was not being validated against the nonce value sent in the Authentication Request.

### Patches

Users should upgrade to version 5.0 immediately

### Workarounds

None.


LTI 1.3 Tool Library's function used to generate random nonces not sufficiently cryptographically complex before v5.0

[Severity: HIGH]

### Impact

The function used to generate random nonces was not sufficiently cryptographically complex. As a result values may be predictable and tokens may be forgable.

### Patches

Users should upgrade to version 5.0 immediately

### Workarounds

None.


aws-iam-authenticator allow-listed IAM identity may be able to modify their username, escalate privileges before v0.5.9

[Severity: HIGH]

A security issue was discovered in aws-iam-authenticator where an allow-listed IAM identity may be able to modify their username and escalate privileges.


Argo CD improper access control bug can allow malicious user to escalate privileges to admin level

[Severity: HIGH]

# Impact

## Impacts for versions starting with v1.0.0
All unpatched versions of Argo CD starting with v1.0.0 are vulnerable to an improper access control bug, allowing a malicious user to potentially escalate their privileges to admin-level.

To perform the following exploits, an authorized Argo CD user must have push access to an Application's source git or Helm repository or `sync` and `override` access to an Application. Once a user has that access, different exploitation levels are possible depending on their other RBAC privileges:

1. If that user has `update` access to the Application, they can modify any resource on the Application's destination cluster. If the destination cluster is or can be made to be the same as the cluster hosting Argo CD, the user can escalate their Argo CD permissions to admin-level.
2. If the user has `delete` access to the Application, they can delete any resource on the Application's destination cluster. (This exploit is possible starting with v0.8.0.)
3. If the user has `get` access to the Application, they can view any resource on the Application's destination cluster (except for the contents of Secrets) and list [actions](https://argo-cd.readthedocs.io/en/stable/operator-manual/resource_actions/) available for that resource.
4. If the user has `get` access to the Application, they can view the logs of any Pods on the Application's destination cluster.
5. If the user has `action/{some action or *}` access on the Application, they can run an action for any resource (which supports the allowed action(s)) on the Application's destination cluster. (Some actions are available in Argo CD by default, and others may be configured by an Argo CD admin.)

See the [Argo CD RBAC documentation](https://argo-cd.readthedocs.io/en/stable/operator-manual/rbac/#rbac-resources-and-actions) for an explanation of the privileges available in Argo CD.

## Events exploit
A related exploit is possible for a user with `get` access to an Application **even if they do not have access to the Application's source git or Helm repository or `sync` and `override` access to the Application**. The user can access any Event in the Application's destination cluster if they know the involved object's name, UID, and namespace.

## Impacts for versions starting with v0.8.0
The same bug exists starting with v0.8.0, but only the following exploits were possible before v1.0.0:

- The `delete exploit` (#2 above).
- The logs exploit (#4 above).
- The Events exploit described above.

## Impacts for versions starting with v0.5.0
The same bug exists starting with v0.5.0 (when RBAC was implemented), but only the Events exploit described above was possible before v0.8.0.

Patches
A patch for this vulnerability has been released in the following Argo CD versions:

- v2.3.2
- v2.2.8
- v2.1.14

**Versions 2.0.x and earlier users**: See the changelog for links to upgrade instructions for your version. It is imperative to upgrade quickly, but some limited mitigations are described in the next section.

**argo-helm chart users**: Argo CD users deploying v2.3.x with argo-helm can upgrade the chart to version 4.2.2. Argo CD 2.2 and 2.1 users can set the global.image.tag value to the latest in your current release series (v2.2.8, or v2.1.14). Since charts for the 2.2 and 2.1 series are no longer maintained, you will need to either leave the value override in place or upgrade to the 4.x chart series (and therefore to Argo CD 2.3).

## Workarounds
The only certain way to avoid the vulnerability is to upgrade.

## Mitigations

- To avoid privilege escalation:
    - Limit who has push access to Application source repositories or sync + override access to Applications.
- Limit which repositories are available in projects where users have update access to Applications.
    - To avoid unauthorized resource inspection/tampering:
    - Limit who has delete, get, or action access to Applications.

These mitigations can help limit potential damage, but they are not a substitute for upgrading. It is necessary to upgrade immediately.


SatyaLab opendiamond 10.1.1 vulnerable to path traversal because Flask send_file function used unsafely

[Severity: CRITICAL]

The cmusatyalab/opendiamond repository through 10.1.1 on GitHub allows absolute path traversal because the Flask send_file function is used unsafely. A patch is available on the `master` branch of the repository.


Temporary Directory Hijacking to Local Privilege Escalation Vulnerability in org.springframework.boot:spring-boot

[Severity: HIGH]

spring-boot versions prior to version `v2.2.11.RELEASE` was vulnerable to temporary directory hijacking. This vulnerability impacted the `org.springframework.boot.web.server.AbstractConfigurableWebServerFactory.createTempDir` method.

The vulnerable method is used to create a work directory for embedded web servers such as Tomcat and Jetty. The directory contains configuration files, JSP/class files, etc. If a local attacker got the permission to write in this directory, they could completely take over the application (ie. local privilege escalation).

#### Impact Location

This vulnerability impacted the following source location:

```java
	/**
	 * Return the absolute temp dir for given web server.
	 * @param prefix server name
	 * @return the temp dir for given server.
	 */
	protected final File createTempDir(String prefix) {
		try {
			File tempDir = File.createTempFile(prefix + ".", "." + getPort());
			tempDir.delete();
			tempDir.mkdir();
			tempDir.deleteOnExit();
			return tempDir;
		}
```
\- https://github.com/spring-projects/spring-boot/blob/ce70e7d768977242a8ea6f93188388f273be5851/spring-boot-project/spring-boot/src/main/java/org/springframework/boot/web/server/AbstractConfigurableWebServerFactory.java#L165-L177

This vulnerability exists because `File.mkdir` returns `false` when it fails to create a directory, it does not throw an exception. As such, the following race condition exists:

```java
File tmpDir =File.createTempFile(prefix + ".", "." + getPort()); // Attacker knows the full path of the file that will be generated
// delete the file that was created
tmpDir.delete(); // Attacker sees file is deleted and begins a race to create their own directory before Jetty.
// and make a directory of the same name
// SECURITY VULNERABILITY: Race Condition! - Attacker beats java code and now owns this directory
tmpDir.mkdirs(); // This method returns 'false' because it was unable to create the directory. No exception is thrown.
// Attacker can write any new files to this directory that they wish.
// Attacker can read any files created by this process.
```

### Prerequisites

This vulnerability impacts Unix-like systems, and very old versions of Mac OSX and Windows as they all share the system temporary directory between all users.

### Patches

This vulnerability was inadvertently fixed as a part of this patch: https://github.com/spring-projects/spring-boot/commit/667ccdae84822072f9ea1a27ed5c77964c71002d

This vulnerability is patched in versions `v2.2.11.RELEASE` or later.

### Workarounds

Setting the `java.io.tmpdir` system environment variable to a directory that is exclusively owned by the executing user will fix this vulnerability for all operating systems.


Hyperledger Fabric vulnerable to Improper Input Validation in orderer/common/cluster consensus request

[Severity: HIGH]

### Impact
If a consensus client sends a malformed consensus request to an orderer it may crash the orderer node.
This fix checks for the malformed consensus request and returns an error to the consensus client.

### Specific Go Packages Affected
github.com/hyperledger/fabric/orderer/common/cluster

### Patches
Fixed in v2.2.7 and v2.4.5.

### Workarounds
None, users must upgrade to v2.2.7 or v2.4.5.

### References
https://github.com/hyperledger/fabric/releases/tag/v2.2.7
https://github.com/hyperledger/fabric/releases/tag/v2.4.5

### For more information
If you have any questions or comments about this advisory:
* Open an issue in [Hyperledger Fabric repository](https://github.com/hyperledger/fabric/issues)

### Credits
Thank you to Haosheng Wang of OPPO ZIWU Security Lab for this disclosure.


Snipe-IT 6.0.2 vulnerable to Cross-site Scripting via arbitrary file upload in Update Branding Settings

[Severity: MEDIUM]

An arbitrary file upload vulnerability in the Update Branding Settings component of Snipe-IT v6.0.2 allows attackers to execute arbitrary code via a crafted file.


Missing permission checks in Jenkins XebiaLabs XL Release Plugin allow enumerating credentials IDs

[Severity: MEDIUM]

XebiaLabs XL Release Plugin 22.0.0 and earlier does not perform permission checks in several HTTP endpoints.

This allows attackers with Overall/Read permission to enumerate credentials IDs of credentials stored in Jenkins. Those can be used as part of an attack to capture the credentials using another vulnerability.

An enumeration of credentials IDs in XebiaLabs XL Release Plugin 22.0.1 requires Overall/Administer permission.


URL previews of unusual or maliciously-crafted pages can crash Synapse media repositories or Synapse monoliths

[Severity: HIGH]

### Impact

URL previews of some web pages can exhaust the available stack space for the Synapse process due to unbounded recursion.
This is sometimes recoverable and leads to an error for the request causing the problem, but in other cases the Synapse process may crash altogether.

It is possible to exploit this maliciously, either by malicious users on the homeserver, or by remote users sending URLs that a local user's client may automatically request a URL preview for.
Remote users are not able to exploit this directly, because [the URL preview endpoint is authenticated](https://spec.matrix.org/v1.2/client-server-api/#get_matrixmediav3preview_url).

### Am I affected?

* deployments with `url_preview_enabled: false` set in configuration are not affected.
* deployments with `url_preview_enabled: true` set in configuration **are** affected.
* deployments with no configuration value set for `url_preview_enabled` are not affected, because the default is `false`.

### Patches

Administrators of homeservers with URL previews enabled are advised to upgrade to v1.61.1 or higher.

### Workarounds

* URL previews can be disabled in the configuration file by setting `url_preview_enabled: false`.
* Deployments using workers can choose to offload URL previews to one or more dedicated worker(s), ensuring that a process crash does not disrupt other functionality of Synapse.

### For more information

If you have any questions or comments about this advisory, e-mail us at [security@matrix.org](mailto:security@matrix.org).


Improper authorization in Jenkins Embeddable Build Status Plugin bypasses ViewStatus permission requirement

[Severity: MEDIUM]

Embeddable Build Status Plugin 2.0.3 and earlier does not correctly perform the ViewStatus permission check in the HTTP endpoint it provides for \"unprotected\" status badge access.

This allows attackers without any permissions to obtain the build status badge icon for any attacker-specified job and/or build.

Embeddable Build Status Plugin 2.0.4 requires ViewStatus permission to obtain the build status badge icon.


Insufficiently Protected Credentials via Insecure Temporary File in org.apache.nifi:nifi-single-user-utils

[Severity: MEDIUM]

### Impact

`org.apache.nifi.authentication.single.user.writer.StandardLoginCredentialsWriter` contains a local information disclosure vulnerability due to writing credentials (username and password) to a file that is readable by all other users on unix-like systems. On unix-like systems, the system's temporary directory is shared between all users on that system. As such, files written to that directory without setting the correct file permissions can allow other users on that system to view the contents of the files written to those temporary files.

### Source

An insecure temporary file is created here:
 - https://github.com/apache/nifi/blob/6a1c7c72d5b91b9ce5d5cb5b86e3155d21e2c19b/nifi-commons/nifi-single-user-utils/src/main/java/org/apache/nifi/authentication/single/user/writer/StandardLoginCredentialsWriter.java#L75

The username and password credentials are written to this file here:
 - https://github.com/apache/nifi/blob/6a1c7c72d5b91b9ce5d5cb5b86e3155d21e2c19b/nifi-commons/nifi-single-user-utils/src/main/java/org/apache/nifi/authentication/single/user/writer/StandardLoginCredentialsWriter.java#L85-L95

### Patches

The vulnerability has been patched in version `1.16`.

### Prerequisites

This vulnerability impacts Unix-like systems, and very old versions of Mac OSX and Windows as they all share the system temporary directory between all users.

### Workarounds

Setting the `java.io.tmpdir` system environment variable to a directory that is exclusively owned by the executing user will fix this vulnerability for all operating systems.

### References

 - https://issues.apache.org/jira/browse/NIFI-9785
 - https://github.com/apache/nifi/commit/859d5fe
 - https://github.com/apache/nifi/pull/5856
 - https://nifi.apache.org/security.html#CVE-2022-26850
 - https://twitter.com/JLLeitschuh/status/1511736635645435904?s=20&t=I3w3zF6Y2DUvWYsEFqERjg


Potential Authorization Header Exposure in NPM Packages @finastra/nestjs-proxy, @ffdc/nestjs-proxy

[Severity: MEDIUM]

The nestjs-proxy library did not have a way to control when Authorization headers should should be forwarded for specific backend services configured by the application developer. This could have resulted in sensitive information such as OAuth bearer access tokens being inadvertently exposed to such services that should not see them.

A new feature has been introduced in the patched version of nestjs-proxy that allows application developers to opt out of forwarding the Authorization headers on a per service basis using the `forwardToken` config setting. Developers are advised to review the README for this library on Github or NPM for further details on how this configuration can be applied.

### Patches
- This issue has been fixed in version 0.7.0 of `@finastra/nestjs-proxy`.
- Users of `@ffdc/nestjs-proxy` are advised that this package has been deprecated and is no longer being maintained or receiving updates. Please update your package.json file to use `@finastra/nestjs-proxy` instead.

### References
- https://github.com/Finastra/finastra-nodejs-libs/pull/231
- https://github.com/Finastra/finastra-nodejs-libs/blob/master/libs/proxy/README.md


Rundeck's Key Storage converter plugin mechanism's encryption layer not working in 4.2.0, 4.2.1, 4.3.0

[Severity: HIGH]

### Impact

The Key Storage converter plugin mechanism was not enabled correctly in Rundeck 4.2.0 and 4.2.1, resulting in use of the encryption layer for Key Storage possibly not working. Any credentials created or overwritten using Rundeck 4.2.0 or 4.2.1 might result in them being written in plaintext to the backend storage.

If you are using a "[Storage Converter](https://docs.rundeck.com/docs/manual/key-storage/key-storage.html#key-data-storage-converter)" plugin, such as `jasypt-encryption` configured via the `rundeck.storage.converter.1.type=jasypt-encryption` setting, and you installed 4.2.0 or 4.2.1 then please upgrade to one of the patched versions.

If you *do not* use a "[Storage Converter](https://docs.rundeck.com/docs/manual/key-storage/key-storage.html#key-data-storage-converter)" plugin, this would not affect you.

### Patches

Rundeck 4.3.2 and 4.2.3 have fixed the code and upon upgrade will re-encrypt any plain text values. The fix is also included in 4.4.0 and later releases.

Note: 4.3.0 does not have the vulnerability, but does not include the patch to re-encrypt plain text values if 4.2.0 or 4.2.1 were used.  The previously release 4.3.1 and 4.2.2 versions missed some re-encryption use cases that have been fixed in the versions mentioned above.

### Workarounds

To prevent plaintext credentials from being stored in Rundeck 4.2.0/4.2.1, write access to key storage can be disabled via ACLs. After upgrading to 4.3.1 or later, write access can be restored.

This aclpolicy document can be used to deny all write access to storage:

```
---
by:
  group: '.*'
context:
  application: rundeck
for:
  storage:
  - deny:
    - create
    - update
description: deny create or update for storage in application context
---
by:
  group: '.*'
context:
  project: .*
for:
  storage:
  - deny:
    - create
    - update
description: deny create or update for storage in project context
```

To remove plaintext credentials, the metadata of stored keys can be used to detect if the key was stored with encryption enabled or not.  In the case of the “jasypt-encryption” plugin, encrypted values will have a metadata field of “jasypt-encryption:encrypted”:”true” in the JSON metadata.  If you are using the relational database as your key storage backend (rundeck.storage.provider.1.type=db), you can query for keys that are unencrypted. Here is an example query for Mysql:

```
select id,dir,name from storage where json_data not like "%jasypt-encryption:encrypted\":\"true%" and namespace is null and dir like "keys%"
```

### References

Configuration Settings for Storage Converters: https://docs.rundeck.com/docs/administration/configuration/plugins/configuring.html#storage-converter-plugins

About Storage Converters:
https://docs.rundeck.com/docs/manual/key-storage/key-storage.html#key-data-storage-converter

### For more information
If you have any questions or comments about this advisory:
* Open an issue in [our forums](https://community.pagerduty.com/forum/c/process-automation)
* Enterprise Customers can open a [Support ticket](https://support.rundeck.com)


Configuration API in EdgeXFoundry 2.1.0 and earlier exposes message bus credentials to local unauthenticated users

[Severity: MEDIUM]

### Impact
The /api/v2/config endpoint exposes message bus credentials to local unauthenticated users.  In security-enabled mode, message bus credentials are supposed to be kept in the EdgeX secret store and require authentication to access.  This vulnerability bypasses the access controls on message bus credentials when running in security-enabled mode.  (No credentials are required when running in security-disabled mode.)  As a result, attackers could intercept data or inject fake data into the EdgeX message bus.

### Patches
Users should upgrade to EdgeXFoundry Kamakura release (2.2.0) or to the June 2022 EdgeXFoundry LTS Jakarta release (2.1.1).

The issue has been patched in the following docker containers and snaps:

#### Patched go modules
github.com/edgexfoundry/device-sdk-go/v2 >= v2.1.1
github.com/edgexfoundry/app-functions-sdk-go/v2 >= v2.1.1

#### Patched docker containers
URL: https://hub.docker.com/r/edgexfoundry
- docker.io/edgexfoundry/core-metadata:>=2.1.1
- docker.io/edgexfoundry/core-metadata-arm64:>=2.1.1
- docker.io/edgexfoundry/core-data:>=2.1.1
- docker.io/edgexfoundry/core-data-arm64:>=2.1.1
- docker.io/edgexfoundry/core-command:>=2.1.1
- docker.io/edgexfoundry/core-command-arm64:>=2.1.1
- docker.io/edgexfoundry/support-notifications:>=2.1.1
- docker.io/edgexfoundry/support-notifications-arm64:>=2.1.1
- docker.io/edgexfoundry/support-scheduler:>=2.1.1
- docker.io/edgexfoundry/support-scheduler-arm64:>=2.1.1
- docker.io/edgexfoundry/sys-mgmt-agent:>=2.1.1
- docker.io/edgexfoundry/sys-mgmt-agent-arm64:>=2.1.1
- docker.io/edgexfoundry/security-proxy-setup:>=2.1.1
- docker.io/edgexfoundry/security-proxy-setup-arm64:>=2.1.1
- docker.io/edgexfoundry/security-secretstore-setup:>=2.1.1
- docker.io/edgexfoundry/security-secretstore-setup-arm64:>=2.1.1
- docker.io/edgexfoundry/security-bootstrapper:>=2.1.1
- docker.io/edgexfoundry/security-bootstrapper-arm64:>=2.1.1
- docker.io/edgexfoundry/app-rfid-llrp-inventory:>=2.1.1
- docker.io/edgexfoundry/app-rfid-llrp-inventory-arm64:>=2.1.1
- docker.io/edgexfoundry/app-service-configurable:>=2.1.1
- docker.io/edgexfoundry/app-service-configurable-arm64:>=2.1.1
- docker.io/edgexfoundry/device-camera:>=2.2.0
- docker.io/edgexfoundry/device-camera-arm64:>=2.2.0
- docker.io/edgexfoundry/device-gpio:>=2.1.1
- docker.io/edgexfoundry/device-gpio-arm64:>=2.1.1
- docker.io/edgexfoundry/device-modbus:>=2.1.1
- docker.io/edgexfoundry/device-modbus-arm64:>=2.1.1
- docker.io/edgexfoundry/device-mqtt:>=2.1.1
- docker.io/edgexfoundry/device-mqtt-arm64:>=2.1.1
- docker.io/edgexfoundry/device-rest:>=2.1.1
- docker.io/edgexfoundry/device-rest-arm64:>=2.1.1
- docker.io/edgexfoundry/device-rfid-llrp:>=2.1.1
- docker.io/edgexfoundry/device-rfid-llrp-arm64:>=2.1.1
- docker.io/edgexfoundry/device-snmp:>=2.1.1
- docker.io/edgexfoundry/device-snmp-arm64:>=2.1.1
- docker.io/edgexfoundry/device-virtual:>=2.1.1
- docker.io/edgexfoundry/device-virtual-arm64:>=2.1.1

#### Patched snaps
URL: https://snapcraft.io/edgexfoundry
edgexfoundry  2.1/stable  (will be automatically upgraded to 2.1.1)

### Workarounds
No workaround available.

### References
* https://github.com/edgexfoundry/edgex-go/security/advisories/GHSA-g63h-q855-vp3q
* https://github.com/edgexfoundry/device-sdk-go/pull/1161 (patch against Kamakura)
* https://github.com/edgexfoundry/edgex-go/pull/4016 (patch against Kamakura)
* https://github.com/edgexfoundry/edgex-go/pull/4039 (cherry-pick patch against Jakarta)
* https://github.com/edgexfoundry/device-sdk-go/pull/1167 (differs from patch on main: don't copy PW in vs delete it after)

### For more information
If you have any questions or comments about this advisory:
* Contact us in the [Slack #security channel](https://slack.edgexfoundry.org/)
* Open an issue in [edgex-go](https://github.com/edgexfoundry/edgex-go)
* Email us at [EdgeX-TSC-Security@lists.edgexfoundry.org](mailto:EdgeX-TSC-Security@lists.edgexfoundry.org)


Compromised child renderer processes could obtain IPC access without nodeIntegrationInSubFrames being enabled

[Severity: LOW]

### Impact
This vulnerability allows a renderer with JS execution to obtain access to a new renderer process with `nodeIntegrationInSubFrames` enabled which in turn allows effective access to `ipcRenderer`.

Please note the misleadingly named `nodeIntegrationInSubFrames` option does not implicitly grant Node.js access rather it depends on the existing `sandbox` setting.  If your application is sandboxed then `nodeIntegrationInSubFrames` just gives access to the sandboxed renderer APIs (which includes `ipcRenderer`).

If your application then additionally exposes IPC messages without IPC `senderFrame` validation that perform privileged actions or return confidential data this access to `ipcRenderer` can in turn compromise your application / user even with the sandbox enabled.

### Patches
This has been patched and the following Electron versions contain the fix:

* `18.0.0-beta.6`
* `17.2.0`
* `16.2.6`
* `15.5.5`

### Workarounds
Ensure that all IPC message handlers appropriately validate `senderFrame` as per our [security tutorial here](https://github.com/electron/electron/blob/main/docs/tutorial/security.md#17-validate-the-sender-of-all-ipc-messages).

### For more information

If you have any questions or comments about this advisory, email us at [security@electronjs.org](mailto:security@electronjs.org).


Stored Cross-site Scripting vulnerabilities in Jenkins promoted Builds (Simple) plugin providing additional parameter types

[Severity: HIGH]

Jenkins Promoted Builds (Simple) Plugin 1.9 and earlier does not escape the name and description of Promotion Level parameters on views displaying parameters. This results in stored cross-site scripting (XSS) vulnerabilities exploitable by attackers with Item/Configure permission.

Exploitation of this vulnerability requires that parameters are listed on another page, like the \"Build With Parameters\" and \"Parameters\" pages provided by Jenkins (core), and that those pages are not hardened to prevent exploitation. Jenkins (core) has prevented exploitation of vulnerabilities of this kind on the \"Build With Parameters\" and \"Parameters\" pages since 2.44 and LTS 2.32.2 as part of the [SECURITY-353 / CVE-2017-2601](https://www.jenkins.io/security/advisory/2017-02-01/#persisted-cross-site-scripting-vulnerability-in-parameter-names-and-descriptions) fix. Additionally, several plugins have previously been updated to list parameters in a way that prevents exploitation by default, see [SECURITY-2617 in the 2022-04-12 security advisory for a list](https://www.jenkins.io/security/advisory/2022-04-12/#SECURITY-2617).


Sandbox bypass vulnerability through implicitly allowlisted platform Groovy files in Jenkins Pipeline: Groovy Plugin

[Severity: HIGH]

Pipeline: Groovy Plugin allows pipelines to load Groovy source files. This is intended to be used to allow Global Shared Libraries to execute without sandbox protection.

In Pipeline: Groovy Plugin 2689.v434009a_31b_f1 and earlier, any Groovy source files bundled with Jenkins core and plugins could be loaded this way and their methods executed. If a suitable Groovy source file is available on the classpath of Jenkins, sandbox protections can be bypassed.

The Jenkins security team has been unable to identify any Groovy source files in Jenkins core or plugins that would allow attackers to execute dangerous code. While the severity of this issue is declared as High due to the potential impact, successful exploitation is considered very unlikely.

Pipeline: Groovy Plugin 2692.v76b_089ccd026 restricts which Groovy source files can be loaded in Pipelines.

Groovy source files in public plugins intended to be executed in sandboxed pipelines have been identified and added to an allowlist. The new extension point `org.jenkinsci.plugins.workflow.cps.GroovySourceFileAllowlist` allows plugins to add specific Groovy source files to that allowlist if necessary, but creation of plugin-specific Pipeline DSLs is strongly discouraged.


Authentication bypass and denial of service (DoS) vulnerabilities in Apple Game Center auth adapter

[Severity: HIGH]

### Impact
Weak validation of the Apple certificate URL in the Apple Game Center authentication adapter allows to bypass authentication and makes the server vulnerable to DoS attacks.

### Patches
The vulnerability has been fixed by improving the URL validation and adding additional checks of the resource the URL points to before downloading it.


Hashicorp Consul HTTP health check endpoints returning an HTTP redirect may be abused as SSRF vector

[Severity: HIGH]

A vulnerability was identified in Consul and Consul Enterprise (“Consul”) such that HTTP health check endpoints returning an HTTP redirect may be abused as a vector for server-side request forgery (SSRF). This vulnerability, CVE-2022-29153, was fixed in Consul 1.9.17, 1.10.10, and 1.11.5.


MantisBT vulnerable to XSS due to improper escape in manage_plugin_page.php and manage_plugin_uninstall.php

[Severity: MEDIUM]

An XSS issue was discovered in MantisBT before 2.25.3. Improper escaping of a Plugin name allows execution of arbitrary code (if CSP allows it) in manage_plugin_page.php and manage_plugin_uninstall.php when a crafted plugin is installed.


Untrusted users can modify some Pipeline libraries in Jenkins Pipeline: Deprecated Groovy Libraries Plugin

[Severity: HIGH]

Multibranch Pipelines by default limit who can change the Pipeline definition from the Jenkinsfile. This is useful for SCMs like GitHub: Jenkins can build content from users without commit access, but who can submit pull requests, without granting them the ability to modify the Pipeline definition. In that case, Jenkins will just use the Pipeline definition in the pull request’s destination branch instead.

In Pipeline: Deprecated Groovy Libraries Plugin 564.ve62a_4eb_b_e039 and earlier the same protection does not apply to uses of the `library` step with a `retriever` argument pointing to a library in the current build’s repository and branch (e.g., `library(…, retriever: legacySCM(scm))`). This allows attackers able to submit pull requests (or equivalent), but not able to commit directly to the configured SCM, to effectively change the Pipeline behavior by changing the library behavior in their pull request, even if the Pipeline is configured to not trust them.

Pipeline: Deprecated Groovy Libraries Plugin 566.vd0a_a_3334a_555 and 2.21.3 aborts library retrieval if the library would be retrieved from the same repository and revision as the current build, and the revision being built is untrusted.


Path traversal and improper access control allows leaking out-of-bound files from Argo CD repo-server

[Severity: HIGH]

### Impact

All unpatched versions of Argo CD starting with v1.3.0 are vulnerable to a path traversal bug, compounded by an improper access control bug, allowing a malicious user with read-only repository access to leak sensitive files from Argo CD's repo-server.

A malicious Argo CD user who has been granted [`get` access for a repository](https://argo-cd.readthedocs.io/en/stable/operator-manual/rbac/#rbac-resources-and-actions) containing a Helm chart can craft an API request to the `/api/v1/repositories/{repo_url}/appdetails` endpoint to leak the contents of out-of-bounds files from the repo-server.

The malicious payload would reference an out-of-bounds file, and the contents of that file would be returned as part of the response. Contents from a non-YAML file may be returned as part of an error message. The attacker would have to know or guess the location of the target file.

Sensitive files which could be leaked include files from other Applications' source repositories (potentially decrypted files, if you are using a decryption plugin) or any secrets which have been mounted as files on the repo-server.

### Patches

A patch for this vulnerability has been released in the following Argo CD versions:

* v2.3.0
* v2.2.6
* v2.1.11

The patches do two things:
 1) prevent path traversal
 2) limit `/api/v1/repositories/{repo_url}/appdetails` access to users who either A) have been granted Application `create` privileges or B) have been granted Application `get` privileges _and_ are requesting details for a `repo_url` that has already been used for the given Application

### Workarounds

The only certain way to avoid the vulnerability is to upgrade.

To mitigate the problem, you can
* avoid storing secrets in git
* avoid mounting secrets as files on the repo-server
* avoid decrypting secrets into files on the repo-server
* carefully [limit who has `get` access for repositories](https://argo-cd.readthedocs.io/en/stable/operator-manual/rbac/#rbac-resources-and-actions)

### References

* [Security documentation for the repo-server component](https://argo-cd.readthedocs.io/en/stable/operator-manual/security/#git-helm-repositories)
* [Argo CD RBAC configuration documentation](https://argo-cd.readthedocs.io/en/stable/operator-manual/rbac/#)

### For more information

Open an issue in [the Argo CD issue tracker](https://github.com/argoproj/argo-cd/issues) or [discussions](https://github.com/argoproj/argo-cd/discussions)
Join us on [Slack](https://argoproj.github.io/community/join-slack) in channel #argo-cd


Sensitive parameter values captured in build metadata files by Jenkins Parameterized Trigger Plugin

[Severity: LOW]

Jenkins Parameterized Trigger Plugin 2.43 and earlier captures environment variables passed to builds triggered using Jenkins Parameterized Trigger Plugin, including password parameter values, in their `build.xml` files. These values are stored unencrypted and can be viewed by users with access to the Jenkins controller file system.

Existing `build.xml` files are not automatically updated to remove captured environment variables. They need to be manually cleaned up. To help with this, the plugin will report environment variables stored in `build.xml` as unloadable data in the Old Data Monitor, that allows discarding this data. Build records are only loaded from disk when needed however, so some builds stored in Jenkins may not immediately appear there.


CSRF vulnerability and missing permission checks in Jenkins Extended Choice Parameter Plugin allow SSRF

[Severity: MEDIUM]

Extended Choice Parameter Plugin 346.vd87693c5a_86c and earlier does not perform a permission check on form validation methods. This allows attackers with Overall/Read permission to connect to an attacker-specified URL.

Additionally, these form validation methods do not require POST requests, resulting in a cross-site request forgery (CSRF) vulnerability.


CSRF vulnerability and missing permission checks in Jenkins kubernetes-cd Plugin allow capturing credentials

[Severity: HIGH]

A missing permission check in Jenkins Kubernetes Continuous Deploy Plugin 2.3.1 and earlier allows attackers with Overall/Read permission to connect to an attacker-specified SSH server using attacker-specified credentials IDs obtained through another method, capturing credentials stored in Jenkins.


Exposure of Private Personal Information to an Unauthorized Actor in alextselegidis/easyappointments

[Severity: CRITICAL]

The software is a booking management system that has a public form to place bookings, and a private area for the calendar and management of services, users, settings, etc. There is a backend API that allows data manipulation, including listing the appointments for a specific time range. This happens on this endpoint: /index.php/backend_api/ajax_get_calendar_events Unfortunately, there is no authentication / permissions-check on that endpoint, the only required parameters in a POST request are "startDate", "endDate" and "csrfToken". Because the csrfToken can be obtained by any unauthenticated user just visiting the public form (and is valid for the backend as well), any attacker can query the backend API and obtain all sorts of private information about the appointment, in JSON format.


Improper Input Validation and Allocation of Resources Without Limits or Throttling in poi-scratchpad

[Severity: MEDIUM]

A shortcoming in the HMEF package of poi-scratchpad (Apache POI) allows an attacker to cause an Out of Memory exception. This package is used to read TNEF files (Microsoft Outlook and Microsoft Exchange Server). If an application uses poi-scratchpad to parse TNEF files and the application allows untrusted users to supply them, then a carefully crafted file can cause an Out of Memory exception. This issue affects poi-scratchpad version 5.2.0 and prior versions. Users are recommended to upgrade to poi-scratchpad 5.2.1.


Spring Cloud Gateway vulnerable to Code Injection when Gateway Actuator endpoint enabled, exposed, unsecured

[Severity: CRITICAL]

In Spring Cloud Gateway versions prior to 3.1.1+ and 3.0.7+ , applications are vulnerable to a code injection attack when the Gateway Actuator endpoint is enabled, exposed, and unsecured. A remote attacker could make a maliciously crafted request resulting in arbitrary remote execution on the remote host.


Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') in view_component

[Severity: HIGH]

This is an XSS vulnerability that has the potential to impact anyone using translations with the view_component gem. Data received via user input and passed as an interpolation argument to the `translate` method is not properly sanitized before display.

Versions 2.29.1 and 2.49.1 have been released and fully mitigate the vulnerability.

Avoid passing user input to the `translate` function, or sanitize the inputs before passing them.

### For more information
If you have any questions or comments about this advisory:
* Open an issue in the [github/view_component](http://github.com/github/view_component) project


crossbeam-utils Unsoundness of AtomicCell<{i,u}64> arithmetics on 32-bit targets that support Atomic{I,U}64

[Severity: HIGH]

### Impact

The affected versions of this crate incorrectly assumed that the alignment of `{i,u}64` was always the same as `Atomic{I,U}64`.

However, the alignment of `{i,u}64` on a 32-bit target can be smaller than `Atomic{I,U}64`.

This can cause the following problems:

- Unaligned memory accesses
- Data race

Crates using `fetch_*` methods with `AtomicCell<{i,u}64>` are affected by this issue.

32-bit targets without `Atomic{I,U}64` and 64-bit targets are not affected by this issue.
32-bit targets with `Atomic{I,U}64` and `{i,u}64` have the same alignment are also not affected by this issue.

The following is a complete list of the builtin targets that may be affected. (last update: nightly-2022-02-11)

- armv7-apple-ios (tier 3)
- armv7s-apple-ios (tier 3)
- i386-apple-ios (tier 3)
- i586-unknown-linux-gnu
- i586-unknown-linux-musl
- i686-apple-darwin (tier 3)
- i686-linux-android
- i686-unknown-freebsd
- i686-unknown-haiku (tier 3)
- i686-unknown-linux-gnu
- i686-unknown-linux-musl
- i686-unknown-netbsd (tier 3)
- i686-unknown-openbsd (tier 3)
- i686-wrs-vxworks (tier 3)

([script to get list](https://gist.github.com/taiki-e/3c7891e8c5f5e0cbcb44d7396aabfe10))

### Patches

This has been fixed in crossbeam-utils 0.8.7.

Affected 0.8.x releases have been yanked.

### References

https://github.com/crossbeam-rs/crossbeam/pull/781

### License

This advisory is in the public domain.


Invalid drop of partially-initialized instances in the pooling instance allocator for modules with defined `externref` globals

[Severity: MEDIUM]

### Impact

There exists a bug in the pooling instance allocator in Wasmtime's runtime where a failure to instantiate an instance for a module that defines an `externref` global will result in an invalid drop of a `VMExternRef` via an uninitialized pointer.

As instance slots may be reused between consecutive instantiations, the value of the uninitialized pointer may be from a previous instantiation and therefore under the control of an attacker via a module's initial values for its globals. If the attacker can somehow determine an address under their control inside the mapped memory representing the instance pool, it is possible to trick the runtime to call `drop_in_place` on a trait object under the attacker's control and therefore cause remote code execution.

Exploiting the bug to cause remote code execution would be very difficult as attackers cannot determine the addresses of globals from code executing within the WebAssembly VM and the memory space for the instance pool cannot be statically determined. Operating system mitigations, such as [address space layout randomization](https://en.wikipedia.org/wiki/Address_space_layout_randomization), would additionally increase the difficulty for attackers to determine useful executable code to target with an exploit. It is also very unlikely that attackers will be able to directly influence the conditions that trigger the bug as described below.

When the conditions to trigger the bug are met, however, it is much easier to exploit this bug to cause a denial of service by crashing the host with an invalid memory read.

The following engine configuration (via [Config](https://docs.rs/wasmtime/0.34.0/wasmtime/struct.Config.html)) is required to be impacted by this bug:

* support for the reference types proposal must be enabled (this is the default for `Config`).
* a pooling allocation strategy must be configured via [Config::allocation_strategy](https://docs.rs/wasmtime/0.34.0/wasmtime/struct.Config.html#method.allocation_strategy), which is **not the default allocation strategy**.

A module must be instantiated with **all the following characteristics**:

* The module defines at least one table or memory.
* The module defines at least one `externref` global.

During instantiation, **one of the following** must occur to cause the instantiation to fail:

* a call to `mprotect` or `VirtualAlloc` fails (e.g. out-of-memory conditions).
* a resource limiter was configured in the associated `Store` (via [Store::limiter](https://docs.rs/wasmtime/0.34.0/wasmtime/struct.Store.html#method.limiter) or [Store::limiter_async](https://docs.rs/wasmtime/0.34.0/wasmtime/struct.Store.html#method.limiter_async)) and the limiter returns `false` from the initial call to `memory_growing` or `table_growing`. **Stores do not have a resource limiter set by default**.

This results in a partially-initialized instance being dropped and that attempts to drop the uninitialized `VMExternRef` representing the defined `externref` global.

We have reason to believe that the effective impact of this bug is relatively small because the usage of `externref` is still uncommon and without a resource limiter configured on the `Store`, which is not the default configuration, it is only possible to trigger the bug from an error returned by `mprotect` or `VirtualAlloc`.

Note that on Linux with the `uffd` feature enabled, it is only possible to trigger the bug from a resource limiter as the call to `mprotect` is skipped; if no resource limiter is used, then this configuration is not vulnerable.

### Patches

The bug has been fixed in 0.34.1 and 0.33.1; users are encouraged to upgrade as soon as possible.

### Workarounds

If it is not possible to upgrade to 0.34.1 or 0.33.1 of the `wasmtime` crate, it is recommend that support for the reference types proposal be disabled by passing `false` to [Config::wasm_reference_types](https://docs.rs/wasmtime/latest/wasmtime/struct.Config.html#method.wasm_reference_types).

Doing so will prevent modules that use `externref` from being loaded entirely.

### For more information

If you have any questions or comments about this advisory:

* Reach out to us on [the Bytecode Alliance Zulip chat](https://bytecodealliance.zulipchat.com/#narrow/stream/217126-wasmtime)
* Open an issue in [the bytecodealliance/wasmtime repository](https://github.com/bytecodealliance/wasmtime/)


Improper Neutralization of Special Elements used in an OS Command in Jenkins Pipeline: Groovy Plugin

[Severity: HIGH]

Jenkins Pipeline: Groovy Plugin prior to 2656.vf7a_e7b_75a_457, 2.94.1, and 2.92.1 uses the same checkout directories for distinct SCMs when reading the script file (typically Jenkinsfile) for Pipelines, allowing attackers with Item/Configure permission to invoke arbitrary OS commands on the controller through crafted SCM contents.


Improper Neutralization of Special Elements used in an OS Command in Jenkins Pipeline: Shared Groovy Libraries Plugin

[Severity: HIGH]

Jenkins Pipeline: Shared Groovy Libraries Plugin prior to 561.va_ce0de3c2d69, 2.21.1, and 2.18.1 uses the same checkout directories for distinct SCMs for Pipeline libraries, allowing attackers with Item/Configure permission to invoke arbitrary OS commands on the controller through crafted SCM contents.


Improper Limitation of a Pathname to a Restricted Directory in Jenkins Pipeline: Shared Groovy Libraries Plugin

[Severity: MEDIUM]

Jenkins Pipeline: Shared Groovy Libraries Plugin does not restrict the names of resources passed to the libraryResource step, allowing attackers able to configure Pipelines permission to read arbitrary files on the Jenkins controller file system.


Agent-to-controller security bypass in Jenkins HashiCorp Vault Plugin allows reading arbitrary files

[Severity: MEDIUM]

Jenkins HashiCorp Vault Plugin 336.v182c0fbaaeb7 and earlier implements functionality that allows agent processes to read arbitrary files on the Jenkins controller file system.

This allows attackers able to control agent processes to read arbitrary files on the Jenkins controller file system.

This vulnerability is only exploitable in Jenkins 2.318 and earlier, LTS 2.303.2 and earlier. See the [LTS upgrade guide](https://www.jenkins.io/doc/upgrade-guide/2.303/#upgrading-to-jenkins-lts-2-303-3).


gobase subject to Incorrect routing of some HTTP requests when using httpauth due to a race condition

[Severity: LOW]

### Impact
Incorrect routing of some HTTP requests when using httpauth due to a race condition

### Patches
Upgrade to version 0.7.2 for fix

### Workarounds
None

### For more information
If you have any questions or comments about this advisory:
* Email us at [nbosscher@blue-giraffe.ca](mailto:nbosscher@blue-giraffe.ca)