Products.CMFCore unauthenticated denial of service and crash via unchecked use of input with Python's marshal module

[Severity: HIGH]

### Impact
The use of Python's marshal module to handle unchecked input in a public method on `PortalFolder` objects can lead to an unauthenticated denial of service and crash situation. The code in question is exposed by all portal software built on top of `Products.CMFCore`, such as Plone. All deployments are vulnerable.

### Patches
The code has been fixed in `Products.CMFCore` version 3.2.

### Workarounds
Users can make the affected `decodeFolderFilter` method unreachable by editing the `PortalFolder.py` module in `Products.CMFCore` by hand and then restarting Zope. Go to line 233 of `PortalFolder.py` and remove both the `@security.public` decorator for `decodeFolderFilter` as well as the method's entire docstring. This is safe because the method is not actually used by current code.

### References
- Products.CMFCore security advisory [GHSA-4hpj-8rhv-9x87](https://github.com/zopefoundation/Products.CMFCore/security/advisories/GHSA-4hpj-8rhv-9x87)

### Credits
Thanks go to Nicolas VERDIER from onepoint.

### For more information

If you have any questions or comments about this advisory:

- Open an issue in the [Products.CMFCore issue tracker](https://github.com/zopefoundation/Products.CMFCore/issues)
- Email us at [security@plone.org](mailto:security@plone.org)


MechanicalSoup vulnerable to malicious web server reading arbitrary files on client using file input inside HTML form

[Severity: HIGH]

### Summary
A malicious web server can read arbitrary files on the client using a `<input type="file" ...>` inside HTML form.

### Details
This affects the extremely common pattern of form submission:

```python
b = mechanicalsoup.StatefulBrowser()
b.select_form(...)
b.submit_selected()
```

The problem is with the code in `browser.Browser.get_request_kwargs`:

```python
    if tag.get("type", "").lower() == "file" and multipart:
        filepath = value
        if filepath != "" and isinstance(filepath, str):
            content = open(filepath, "rb")
        else:
            content = ""
        filename = os.path.basename(filepath)
        # If value is the empty string, we still pass it
        # for consistency with browsers (see
        # https://github.com/MechanicalSoup/MechanicalSoup/issues/250).
        files[name] = (filename, content)
```

The file path is taken from the bs4 tag "value" attribute. However, this path will default to whatever the server sends. So if a malicious web server were to send something like:

```html
<html><body>
  <form method="post" enctype="multipart/form-data">
    <input type="text" name="greeting" value="hello" />
    <input type="file" name="evil" value="/home/user/.ssh/id_rsa" />
  </form>
</body></html>
```

then upon `.submit_selected()` the mechanicalsoup browser will happily send over the contents of your SSH private key.

### PoC

```python
import attr
import mechanicalsoup
import requests

class NevermindError(Exception):
    pass

@attr.s
class FakeSession:
    session = attr.ib()

    headers = property(lambda self: self.session.headers)

    def request(self, *args, **kwargs):
        print("requested", args, kwargs)
        raise NevermindError  # don't actually send request

def demonstrate(inputs=None):
    b = mechanicalsoup.StatefulBrowser(FakeSession(requests.Session()))
    b.open_fake_page("""\
<html><body>
<form method="post" enctype="multipart/form-data">
<input type="text" name="greeting" value="hello" />
<input type="file" name="evil" value="/etc/passwd" />
<input type="file" name="second" />
</form>
</body></html>
""", url="http://127.0.0.1:9/")
    b.select_form()
    if inputs is not None:
        b.form.set_input(inputs)
    try:
        b.submit_selected()
    except NevermindError:
        pass

# %%

# unpatched
demonstrate()
# OUTPUT: requested () {'method': 'post', 'url': 'http://127.0.0.1:9/', 'files': {'evil': ('passwd', <_io.BufferedReader name='/etc/passwd'>), 'second': ('', '')}, 'headers': {'Referer': 'http://127.0.0.1:9/'}, 'data': [('greeting', 'hello')]}

# %%

# with the patch, this now works. users MUST open the file manually and
# use browser.set_input() using the file object.
demonstrate({"greeting": "hiya", "evil": open("/etc/hostname", "rb").name, "second": open("/dev/null", "rb")})
# OUTPUT: requested () {'method': 'post', 'url': 'http://127.0.0.1:9/', 'files': {'evil': ('hostname', <_io.BufferedReader name='/etc/hostname'>), 'second': ('null', <_io.BufferedReader name='/dev/null'>)}, 'headers': {'Referer': 'http://127.0.0.1:9/'}, 'data': [('greeting', 'hiya')]}

# %%

# with the patch, this raises a ValueError with a helpful string
demonstrate({"evil": "/etc/hostname"})

# %%

# with the patch, we silently send no file if a malicious server tries the attack:
demonstrate()
```

### Suggested patch

```diff
diff --git a/mechanicalsoup/browser.py b/mechanicalsoup/browser.py
index 285f8bb..68bc65e 100644
--- a/mechanicalsoup/browser.py
+++ b/mechanicalsoup/browser.py
@@ -1,7 +1,8 @@
+import io
 import os
 import tempfile
 import urllib
 import weakref
 import webbrowser

 import bs4
@@ -227,15 +228,21 @@ class Browser:
                     value = tag.get("value", "")

                 # If the enctype is not multipart, the filename is put in
                 # the form as a text input and the file is not sent.
                 if tag.get("type", "").lower() == "file" and multipart:
                     filepath = value
                     if filepath != "" and isinstance(filepath, str):
-                        content = open(filepath, "rb")
+                        content = getattr(tag, "_mechanicalsoup_file", None)
+                        if content is False:
+                            raise ValueError(
+                                """From v1.3.0 onwards, you must pass an open file object directly, for example using `form.set_input({"name": open("/path/to/filename", "rb")})`. This change is to mitigate a security vulnerability where a malicious web server could read arbitrary files from the client."""
+                            )
+                        elif not isinstance(content, io.IOBase):
+                            content = ""
                     else:
                         content = ""
                     filename = os.path.basename(filepath)
                     # If value is the empty string, we still pass it
                     # for consistency with browsers (see
                     # https://github.com/MechanicalSoup/MechanicalSoup/issues/250).
                     files[name] = (filename, content)
diff --git a/mechanicalsoup/form.py b/mechanicalsoup/form.py
index a67195c..82f6015 100644
--- a/mechanicalsoup/form.py
+++ b/mechanicalsoup/form.py
@@ -1,8 +1,9 @@
 import copy
+import io
 import warnings

 from bs4 import BeautifulSoup

 from .utils import LinkNotFoundError

@@ -64,15 +65,24 @@ class Form:
         give it the value ``password``.
         """

         for (name, value) in data.items():
             i = self.form.find("input", {"name": name})
             if not i:
                 raise InvalidFormMethod("No input field named " + name)
-            i["value"] = value
+
+            if isinstance(value, io.IOBase):
+                # Store the actual file object for <input type="file">
+                i._me


Parse Server vulnerable to remote code execution via MongoDB BSON parser through prototype pollution

[Severity: CRITICAL]

### Impact

An attacker can use this prototype pollution sink to trigger a remote code execution through the MongoDB BSON parser.

### Patches

Prevent prototype pollution in MongoDB database adapter.

### Workarounds

Disable remote code execution through the MongoDB BSON parser.

### Credits

- Discovered by hir0ot working with Trend Micro Zero Day Initiative
- Fixed by dbythy
- Reviewed by mtrezza

### References

- https://github.com/parse-community/parse-server/security/advisories/GHSA-462x-c3jw-7vr6
- https://github.com/advisories/GHSA-prm5-8g2m-24gg


Temporal Server vulnerable to Incorrect Authorization and Insecure Default Initialization of Resource

[Severity: LOW]

Insecure defaults in open-source Temporal Server before version 1.20 on all platforms allows an attacker to craft a task token with access to a namespace other than the one specified in the request. Creation of this task token must be done outside of the normal Temporal server flow. It requires the namespace UUID and information from the workflow history for the target namespace. Under these conditions, it is possible to interfere with pending tasks in other namespaces, such as marking a task failed or completed.
If a task is targeted for completion by the attacker, the targeted namespace must also be using the same data converter configuration as the initial, valid, namespace for the task completion payload to be decoded by workers in the target namespace.


Actionpack has possible cross-site scripting vulnerability via User Supplied Values to redirect_to

[Severity: MEDIUM]

The `redirect_to` method in Rails allows provided values to contain characters which are not legal in an HTTP header value. This results in the potential for downstream services which enforce RFC compliance on HTTP response headers to remove the assigned Location header. This vulnerability has been assigned the CVE identifier CVE-2023-28362.

Versions Affected: All. Not affected: None Fixed Versions: 7.0.5.1, 6.1.7.4

# Impact

This introduces the potential for a Cross-site-scripting (XSS) payload to be delivered on the now static redirection page. Note that this both requires user interaction and for a Rails app to be configured to allow redirects to external hosts (defaults to false in Rails >= 7.0.x).

# Releases

The FIXED releases are available at the normal locations.

# Workarounds

Avoid providing user supplied URLs with arbitrary schemes to the `redirect_to` method.


Apache Airflow ODBC Provider, Apache Airflow MSSQL Provider Improper Input Validation vulnerability

[Severity: MEDIUM]

Input Validation vulnerability in Apache Software Foundation Apache Airflow ODBC Provider, Apache Software Foundation Apache Airflow MSSQL Provider.This vulnerability is considered low since it requires DAG code to use `get_sqlalchemy_connection` and someone with access to connection resources specifically updating the connection to exploit it.

This issue affects Apache Airflow ODBC Provider: before 4.0.0; Apache Airflow MSSQL Provider: before 3.4.1.

It is recommended to upgrade to a version that is not affected


XWiki Platform vulnerable to reflected cross-site scripting via xredirect parameter in DeleteApplication page

[Severity: CRITICAL]

### Impact
Users are able to forge an URL with a payload allowing to inject Javascript in the page (XSS).
It's possible to exploit the DeleteApplication page to perform a XSS, e.g. by using URL such as:

> xwiki/bin/view/AppWithinMinutes/DeleteApplication?appName=Menu&resolve=true&xredirect=javascript:alert(document.domain)

This vulnerability exists since XWiki 6.2-milestone-1.

### Patches

The vulnerability has been patched in XWiki 14.10.5 and 15.1-rc-1.

### Workarounds

It's possible to workaround the vulnerability by editing the page AppWithinMinutes.DeleteApplication to perform checks on it, but note that the appropriate fix involves new APIs that have been recently introduced in XWiki. See the referenced jira tickets.

### References

  * Jira ticket about the vulnerability: https://jira.xwiki.org/browse/XWIKI-20614
  * Introduction of the macro used for fixing all those vulnerabilities: https://jira.xwiki.org/browse/XWIKI-20583
  * Commit containing the actual fix in the page: https://github.com/xwiki/xwiki-platform/commit/8f5a889b7cd140770e54f5b4195d88058790e305

### 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)


XWiki Platform vulnerable to reflected cross-site scripting via back and xcontinue parameters in resubmit template

[Severity: CRITICAL]

### Impact
Users are able to forge an URL with a payload allowing to inject Javascript in the page (XSS).
It's possible to exploit the resubmit template to perform a XSS, e.g. by using URL such as:

 > xwiki/bin/view/XWiki/Main?xpage=resubmit&resubmit=javascript:alert(document.domain)&xback=javascript:alert(document.domain)

This vulnerability exists since XWiki 2.5-milestone-2.

### Patches

The vulnerability has been patched in XWiki 14.10.5 and 15.1-rc-1.

### Workarounds

It's possible to workaround the vulnerability by editing the template resubmit.vm to perform checks on it, but note that the appropriate fix involves new APIs that have been recently introduced in XWiki. See the referenced jira tickets.

### References

  * Jira ticket about the vulnerability: https://jira.xwiki.org/browse/XWIKI-20343
  * Introduction of the macro used for fixing all those vulnerabilities: https://jira.xwiki.org/browse/XWIKI-20583
  * Commit containing the actual fix in the page: https://github.com/xwiki/xwiki-platform/commit/dbc92dcdace33823ffd1e1591617006cb5fc6a7f

### 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)

### Attribution

This vulnerability has been reported by René de Sain @renniepak.


XWiki Platform vulnerable to reflected cross-site scripting via xredirect parameter in deletespace template

[Severity: CRITICAL]

### Impact
Users are able to forge an URL with a payload allowing to inject Javascript in the page (XSS).
It's possible to exploit the deletespace template to perform a XSS, e.g. by using URL such as:

> xwiki/bin/deletespace/Sandbox/?xredirect=javascript:alert(document.domain)

This vulnerability exists since XWiki 3.4-milestone-1.

### Patches
The vulnerability has been patched in XWiki 14.10.5 and 15.1-rc-1.

### Workarounds

It's possible to workaround the vulnerability by editing the template deletespace.vm to perform checks on it, but note that the appropriate fix involves new APIs that have been recently introduced in XWiki. See the referenced jira tickets.

### References

  * Jira ticket about the vulnerability: https://jira.xwiki.org/browse/XWIKI-20612
  * Introduction of the macro used for fixing all those vulnerabilities: https://jira.xwiki.org/browse/XWIKI-20583
  * Commit containing the actual fix in the template: https://github.com/xwiki/xwiki-platform/commit/5c20ff5e3bdea50f1053fe99a27e011b8d0e4b34

### 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)


XWiki Platform vulnerable to reflected cross-site scripting via xredirect parameter in restore template

[Severity: CRITICAL]

### Impact
Users are able to forge an URL with a payload allowing to inject Javascript in the page (XSS).
It's possible to exploit the restore template to perform a XSS, e.g. by using URL such as:

> /xwiki/bin/view/XWiki/Main?xpage=restore&showBatch=true&xredirect=javascript:alert(document.domain)

This vulnerability exists since XWiki 9.4-rc-1.

### Patches

The vulnerability has been patched in XWiki 14.10.5 and 15.1-rc-1.

### Workarounds

It's possible to workaround the vulnerability by editing the template restore.vm to perform checks on it, but note that the appropriate fix involves new APIs that have been recently introduced in XWiki. See the referenced jira tickets.

### References

  * Vulnerability in restore template: https://jira.xwiki.org/browse/XWIKI-20352
  * Introduction of the macro used for fixing this vulnerability: https://jira.xwiki.org/browse/XWIKI-20583
  * Commit containing the actual fix in the template: https://github.com/xwiki/xwiki-platform/commit/d5472100606c8355ed44ada273e91df91f682738

### 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)

### Attribution

Both vulnerabilities about the delete and restore templates have been reported by René de Sain @renniepak.


XWiki Platform vulnerable to reflected cross-site scripting via xredirect parameter in delete template

[Severity: CRITICAL]

### Impact

Users are able to forge an URL with a payload allowing to inject Javascript in the page (XSS).
It's possible to exploit the delete template to perform a XSS, e.g. by using URL such as:

> xwiki/bin/get/FlamingoThemes/Cerulean?xpage=xpart&vm=delete.vm&xredirect=javascript:alert(document.domain)

This vulnerability exists since XWiki 6.0-rc-1.

### Patches

The vulnerability has been patched in XWiki 14.10.6 and 15.1. Note that a partial patch has been provided in 14.10.5 but wasn't enough to entirely fix the vulnerability.

### Workarounds

It's possible to workaround the vulnerability by editing the template delete.vm to perform checks on it, but note that the appropriate fix involves new APIs that have been recently introduced in XWiki. See the referenced jira tickets.

### References

  * Jira ticket about the original vulnerability: https://jira.xwiki.org/browse/XWIKI-20341
  * Commit containing the first fix in the template: https://github.com/xwiki/xwiki-platform/commit/e80d22d193df364b07bab7925572720f91a8984a
  * Jira ticket about the second part of the vulnerability found after 14.10.5: https://jira.xwiki.org/browse/XWIKI-20672
  * Commits containing the second fix in the template:
    * https://github.com/xwiki/xwiki-platform/commit/13875a6437d4525ac4aeea25918f2d2dffac9ee1
    * https://github.com/xwiki/xwiki-platform/commit/24ec12890ac7fa6daec8d0b3435cfcba11362fd5
  * Introduction of the macro used for fixing all those vulnerabilities: https://jira.xwiki.org/browse/XWIKI-20583

### 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)

### Attribution

This vulnerability has been reported by René de Sain @renniepak.


When setting EntityOptions.apiPrefilter to a function, the filter is not applied to API requests for a resource by Id

[Severity: MEDIUM]

### Impact
If you used the [apiPrefilter](https://remult.dev/docs/ref_entity.html#apiprefilter) option of the `@Entity` decorator, by setting it to a function that returns a filter that prevents unauthorized access to data, an attacker who knows the `id` of an entity instance she is not authorized to access, can gain read, update and delete access to it.

### Patches
The issue is fixed in version 0.20.6

### Workarounds
Set the `apiPrefilter` option to a filter object instead of a function.

### References
If you're using a minor version < 0.20 and require a patch, please create an issue.


XWiki Platform vulnerable to cross-site scripting via xcontinue parameter in previewactions template

[Severity: CRITICAL]

### Impact
Users are able to forge an URL with a payload allowing to inject Javascript in the page (XSS).
It's possible to exploit the previewactions template to perform a XSS, e.g. by using URL such as:
> <hostname>/xwiki/bin/get/FlamingoThemes/Cerulean?xpage=xpart&vm=previewactions.vm&xcontinue=javascript:alert(document.domain)

This vulnerability exists since XWiki 6.1-rc-1.

### Patches

The vulnerability has been patched in XWiki 14.10.5 and 15.1-rc-1.

### Workarounds

It's possible to workaround the vulnerability by editing the template previewactions.vm to perform checks on it, but note that the appropriate fix involves new APIs that have been recently introduced in XWiki. See the referenced jira tickets.

### References

  * Jira ticket about the vulnerability: https://jira.xwiki.org/browse/XWIKI-20342
  * Introduction of the macro used for fixing this type of vulnerability: https://jira.xwiki.org/browse/XWIKI-20583
  * Commit containing the actual fix in the template: https://github.com/xwiki/xwiki-platform/commit/9f01166b1a8ee9639666099eb5040302df067e4d

### 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)

### Attribution

This vulnerability has been reported by René de Sain @renniepak.


XWiki Platform vulnerable to stored cross-site scripting in ClassEditSheet page via name parameters

[Severity: CRITICAL]

### Impact
A stored XSS can be exploited by users with edit rights by adding a `AppWithinMinutes.FormFieldCategoryClass` class on a page and setting the payload on the page title.
Then, any user visiting `/xwiki/bin/view/AppWithinMinutes/ClassEditSheet` executes the payload.

See https://jira.xwiki.org/browse/XWIKI-20365 for me details.

### Patches
The issue has been patched on XWiki 14.4.8, 14.10.4, and 15.0 ?

### Workarounds
The issue can be fixed by updating `AppWithinMinutes.ClassEditSheet` with this [patch](https://github.com/xwiki/xwiki-platform/commit/1b87fec1e5b5ec00b7a8c3c3f94f6c5e22547392#diff-79e725ec7125cced7d302e1a1f955a76745af26ef28a148981b810e85335d302).

### References
- https://github.com/xwiki/xwiki-platform/commit/1b87fec1e5b5ec00b7a8c3c3f94f6c5e22547392#diff-79e725ec7125cced7d302e1a1f955a76745af26ef28a148981b810e85335d302
- https://jira.xwiki.org/browse/XWIKI-20365

### 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)

### Attribution

This vulnerability has been reported on Intigriti by René de Sain @renniepak.


XWiki vulnerable to stored cross-site scripting via any wiki document and the displaycontent/rendercontent template

[Severity: CRITICAL]

### Impact

Any user who can edit a document in a wiki like the user profile can create a stored XSS attack by putting plain HTML code into that document and then tricking another user to visit that document with the `displaycontent` or `rendercontent` template and plain output syntax. For example, edit any document with the wiki editor and set the content to `<script>alert(1)</script>` , save and then append the parameters `?viewer=displaycontent&sheet=&outputSyntax=plain`. If this displays an alert, the installation is vulnerable. If a user with programming rights is tricked into visiting such a URL, arbitrary actions be performed with this user's rights, impacting the confidentiality, integrity, and availability of the whole XWiki installation.

### Patches
This has been patched in XWiki 14.4.8, 14.10.5 and 15.1RC1 by setting the content type of the response to plain text when the output syntax is not an HTML syntax.

### Workarounds
The [patch](https://github.com/xwiki/xwiki-platform/commit/53e8292a31ec70fba5e1d705a4ac443658b9e6df#diff-e332fba67335bd2202bdac144be7cd244a16cef0ccee741f9c20025a981027d5) can be manually applied to the `rendercontent.vm` template in an existing installation to patch this vulnerability without upgrading.

### References
* https://jira.xwiki.org/browse/XWIKI-20290
* https://github.com/xwiki/xwiki-platform/commit/53e8292a31ec70fba5e1d705a4ac443658b9e6df


Jenkins Team Concert Plugin does not perform permission checks in methods implementing form validation

[Severity: MEDIUM]

Jenkins Team Concert Plugin 2.4.1 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.

Team Concert Plugin 2.4.2 requires Overall/Administer permission for the affected form validation methods.


OpenZeppelin Contracts using MerkleProof multiproofs may allow proving arbitrary leaves for specific trees

[Severity: MEDIUM]

### Impact

When the `verifyMultiProof`, `verifyMultiProofCalldata`, `processMultiProof`, or `processMultiProofCalldata` functions are in use, it is possible to construct merkle trees that allow forging a valid multiproof for an arbitrary set of leaves.

A contract may be vulnerable if it uses multiproofs for verification and the merkle tree that is processed includes a node with value 0 at depth 1 (just under the root). This could happen inadvertently for balanced trees with 3 leaves or less, if the leaves are not hashed. This could happen deliberately if a malicious tree builder includes such a node in the tree.

A contract is not vulnerable if it uses single-leaf proving (`verify`, `verifyCalldata`, `processProof`, or `processProofCalldata`), or if it uses multiproofs with a known tree that has hashed leaves. Standard merkle trees produced or validated with the [@openzeppelin/merkle-tree](https://github.com/OpenZeppelin/merkle-tree) library are safe.

### Patches

The problem has been patched in 4.9.2.

### Workarounds

If you are using multiproofs: When constructing merkle trees hash the leaves and do not insert empty nodes in your trees. Using the [@openzeppelin/merkle-tree](https://www.npmjs.com/package/@openzeppelin/merkle-tree) package eliminates this issue. Do not accept user-provided merkle roots without reconstructing at least the first level of the tree. Verify the merkle tree structure by reconstructing it from the leaves.


GeoServer RCE due to improper control of generation of code in jai-ext`Jiffle` map algebra language

[Severity: CRITICAL]

GeoServer 2, in some configurations, allows remote attackers to execute arbitrary code via `java.lang.Runtime.getRuntime().exec` in `wps:LiteralData` within a `wps:Execute` request, as exploited in the wild in June 2023.

## RCE in Jiffle

The Jiffle map algebra language, provided by jai-ext, allows efficiently execute map algebra over large images. A vulnerability [CVE-2022-24816](https://nvd.nist.gov/vuln/detail/CVE-2022-24816) has been recently found in Jiffle, that allows a Code Injection to be performed by properly crafting a Jiffle invocation.

In the case of GeoServer, the injection can be performed from a remote request.

## Assessment

GeoTools includes the Jiffle language as part of the `gt-process-raster-<version>` module, applications using it should check whether it’s possible to provide a Jiffle script from remote, and if so, upgrade or remove the functionality (see also the GeoServer mitigation, below).

The issue is of particular interest for GeoServer users, as GeoServer embeds Jiffle in the base WAR package. Jiffle is available as a OGC function, for usage in SLD rendering transformations.

This allows for a Remote Code Execution in properly crafted OGC requests, as well as from the administration console, when editing SLD files.

## Mitigations

In case you cannot upgrade at once, then the following mitigation is strongly recommended:

1. Stop GeoServer
2. Open the war file, get into `WEB-INF/lib` and remove the `janino-<version>.jar`
3. Restart GeoServer.

This effectively removes the Jiffle ability to compile scripts in Java code, from any of the potential attack vectors (Janino is the library used to turn the Java code generated from the Jiffle script, into executable bytecode).

GeoServer should still work properly after the removal, but any attempt to use Jiffle will result in an exception.


SwiftNIO vulnerable to Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Response Splitting')

[Severity: MEDIUM]

`NIOHTTP1` and projects using it for generating HTTP responses, including SwiftNIO, can be subject to a HTTP Response Injection attack. This occurs when a HTTP/1.1 server accepts user generated input from an incoming request and reflects it into a HTTP/1.1 response header in some form. A malicious user can add newlines to their input (usually in encoded form) and "inject" those newlines into the returned HTTP response.

This capability allows users to work around security headers and HTTP/1.1 framing headers by injecting entirely false responses or other new headers. The injected false responses may also be treated as the response to subsequent requests, which can lead to XSS, cache poisoning, and a number of other flaws.

This issue was resolved by adding a default channel handler that polices outbound headers. This channel handler is added by default to channel pipelines, but can be removed by users if they are doing this validation themselves.


In Lima, a malicious disk image could read a single file on the host filesystem as a qcow2/vmdk backing file

[Severity: LOW]

> **Note**
>
> The official templates of Lima, and the well-known third party products (Colima, Rancher Desktop, and Finch) are *unlikely* to be affected by this issue.

### Impact
A virtual machine instance with a malicious disk image could read a single file on the host filesystem, even when no filesystem is mounted from the host.

To exploit this issue, the attacker has to embed the target file path (an absolute or a relative path from the instance directory) in a malicious disk image, as the [qcow2 (or vmdk) backing file path string](https://gitlab.com/qemu-project/qemu/-/blob/v8.0.0/docs/interop/qcow2.txt#L23-L34).
As Lima refuses to run as the root, it is practically impossible for the attacker to read the entire host disk via `/dev/rdiskN`.
Also, practically, the attacker cannot read at least the first 512 bytes (MBR) of the target file.

### Patches
Patched in Lima v0.16.0, by prohibiting using a backing file path in the VM base image.

### Workarounds
Do not use an untrusted disk image.


n158 vulnerable to Command Injection due to improper input sanitization in the 'module.exports' function

[Severity: HIGH]

All versions of the package n158 are vulnerable to Command Injection due to improper input sanitization in the 'module.exports' function.

**Note:**

To execute the code snippet and potentially exploit the vulnerability, the attacker needs to have the ability to run Node.js code within the target environment. This typically requires some level of access to the system or application hosting the Node.js environment.


Synapse Denial of service due to incorrect application of event authorization rules during state resolution

[Severity: HIGH]

### Impact
If Synapse and a malicious homeserver are both joined to the same room, the malicious homeserver can trick Synapse into accepting previously rejected events into its view of the current state of that room. This can be exploited in a way that causes all further messages and state changes sent in that room from the vulnerable homeserver to be rejected.

Synapse homeservers are affected by this issue if and only if they are joined to rooms which members of untrusted homeservers are joined or invited to.

- Synapse homeservers in rooms available over public federation **are** affected.
- Synapse homeservers with federation disabled are not affected.
- Synapse homeservers in a closed federation containing only trusted servers are not affected.
- Synapse homeservers which are only joined to rooms with federation disabled[^1] are not affected.

### Patches
Administrators of homeservers with federation enabled are advised to upgrade to 1.68.0 or higher.

### Workarounds
 * Federation can be disabled by setting [`federation_domain_whitelist`](https://matrix-org.github.io/synapse/latest/usage/configuration/config_documentation.html#federation_domain_whitelist) to an empty list (`[]`). from the vulnerable homeserver to be rejected. This issue has been patched in version 1.68.0

### References
- https://github.com/matrix-org/synapse/pull/13723

[^1]: See `m.federate` in the [`m.room.create` definition](https://spec.matrix.org/v1.4/client-server-api/#mroomcreate).

### For more information

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


swift-nio-http2 vulnerable to denial of service via mishandled HPACK variable length integer encoding

[Severity: HIGH]

A program using swift-nio-http2 is vulnerable to a denial of service attack, caused by a network peer sending a specially crafted HPACK-encoded header block. This attack affects all swift-nio-http2 versions from 1.0.0 to 1.19.1. It is fixed in 1.19.2 and later releases.

There are a number of implementation errors in the parsing of HPACK-encoded header blocks that allow maliciously crafted HPACK header blocks to cause crashes in processes using swift-nio-http2. Each of these crashes is triggered instead of an integer overflow.

A malicious HPACK header block could be sent on any of the HPACK-carrying frames in a HTTP/2 connection (HEADERS and PUSH_PROMISE), at any position.

Sending a HPACK header block does not require any special permission, so any HTTP/2 connection peer may send one. For clients, this means any server to which they connect may launch this attack. For servers, anyone they allow to connect to them may launch such an attack.

The attack is low-effort: it takes very little resources to send an appropriately crafted field block. The impact on availability is high: receiving a frame carrying this field block immediately crashes the server, dropping all in-flight connections and causing the service to need to restart. It is straightforward for an attacker to repeatedly send appropriately crafted field blocks, so attackers require very few resources to achieve a substantial denial of service.

The attack does not have any confidentiality or integrity risks in and of itself: swift-nio-http2 is parsing the field block in memory-safe code and the crash is triggered instead of an integer overflow. However, sudden process crashes can lead to violations of invariants in services, so it is possible that this attack can be used to trigger an error condition that has confidentiality or integrity risks.

The risk can be mitigated if untrusted peers can be prevented from communicating with the service. This mitigation is not available to many services.

The issue is fixed by rewriting the parsing code to correctly handle all conditions in the function. The principal issue was found by automated fuzzing by oss-fuzz, but several associated bugs in the same code were found by code audit and fixed at the same time.


ReactPHP's HTTP server continues parsing unused multipart parts after reaching input field and file upload limits

[Severity: MEDIUM]

### Summary

Previous versions of ReactPHP's HTTP server component contain a potential DoS vulnerability that can cause high CPU load when processing large HTTP request bodies. This vulnerability has little to no impact on the default configuration, but can be exploited when explicitly using the  `RequestBodyBufferMiddleware` with very large settings. This might lead to consuming large amounts of CPU time for processing requests and significantly delay or slow down the processing of legitimate user requests.

### Patches

The supplied patch resolves this vulnerability for ReactPHP.

### Workarounds

- Keeping the request body limit using `RequestBodyBufferMiddleware` sensible will mitigate it.

- Infrastructure or DevOps can place a reverse proxy in front of the ReactPHP HTTP server to filter out any excessive HTTP request bodies.

### References

A similar vulnerability was discovered in PHP recently, see also [PHP's security advisory](https://github.com/php/php-src/security/advisories/GHSA-54hq-v5wp-fqgv) (CVE-2023-0662). The fix is based on the [PHP-FPM fix](https://github.com/php/php-src/commit/716de0cff539f46294ef70fe75d548cd66766370#diff-81d659aa9e83177ac08151f99cebf21ab331d22462c72a1039f59947e66f5a35).


pimcore/customer-management-framework-bundle has SQL Injection vulnerability in Segment Assignment query

[Severity: HIGH]

### Impact
An administrator user can use the inheritable segments feature to execute his own blind SQL queries.

A user with administrator privileges can run any SQL query on database. This can be used to retrieve sensitive data, change database information or any other malicious activity against the database.

### Patches
Update to version 3.3.10 or apply this patch manually https://github.com/pimcore/customer-data-framework/commit/76df151737b7964ce5169fdf9e27a0ad801757fe.patch

### Workarounds
Apply https://github.com/pimcore/customer-data-framework/commit/76df151737b7964ce5169fdf9e27a0ad801757fe.patch manually.

### References
https://huntr.dev/bounties/cf398528-819f-456e-88e7-c06d268d3f44/


Gin Web Framework does not properly sanitize filename parameter of Context.FileAttachment function

[Severity: MEDIUM]

The filename parameter of the Context.FileAttachment function is not properly sanitized. A maliciously crafted filename can cause the Content-Disposition header to be sent with an unexpected filename value or otherwise modify the Content-Disposition header. For example, a filename of "setup.bat";x=.txt" will be sent as a file named "setup.bat".

If the FileAttachment function is called with names provided by an untrusted source, this may permit an attacker to cause a file to be served with a name different than provided. Maliciously crafted attachment file name can modify the Content-Disposition header.


Improper Neutralization of Invalid Characters in Data Attribute Names in org.xwiki.commons:xwiki-commons-xml

[Severity: CRITICAL]

### Impact
The HTML sanitizer, introduced in version 14.6-rc-1, allowed the injection of arbitrary HTML code and thus cross-site scripting via invalid data attributes. This can be exploited, e.g., via the link syntax in any content that supports XWiki syntax like comments in XWiki:

```
[[Link1>>https://XWiki.example.com||data-x/onmouseover="alert('XSS1')"]].
```

When a user moves the mouse over this link, the malicious JavaScript code is executed in the context of the user session. When this user is a privileged user who has programming rights, this allows server-side code execution with programming rights, impacting the confidentiality, integrity and availability of the XWiki instance.

Note that this vulnerability does not affect restricted cleaning in HTMLCleaner as there attributes are cleaned and thus characters like `/` and `>` are removed in all attribute names.

### Patches
This problem has been patched in XWiki 14.10.4 and 15.0 RC1 by making sure that data attributes only contain allowed characters.

### Workarounds
There are no known workarounds apart from upgrading to a version including the fix.

### References
* https://jira.xwiki.org/browse/XCOMMONS-2606
* https://github.com/xwiki/xwiki-commons/commit/0b8e9c45b7e7457043938f35265b2aa5adc76a68

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


Mutagen list and monitor operations do not neutralize control characters in text controlled by remote endpoints

[Severity: LOW]

### Impact

Mutagen command line operations, as well as the log output from `mutagen daemon run`, are susceptible to control characters that could be provided by remote endpoints.  This can cause terminal corruption, either intentional or unintentional, if these characters are present in error messages, file paths/names, and/or log output.  This could be used as an attack vector if synchronizing with an untrusted remote endpoint, synchronizing files not under control of the user, or forwarding to/from an untrusted remote endpoint.  On very old systems with terminals susceptible to issues such as [CVE-2003-0069](https://nvd.nist.gov/vuln/detail/CVE-2003-0069), the issue could theoretically cause code execution.

### Patches

The problem has been patched in Mutagen v0.16.6 and v0.17.1.  Earlier versions of Mutagen are no longer supported and will not be patched.  Versions of Mutagen after v0.18.0 will also have the patch merged.

One caveat is that the templating functionality of Mutagen's `list` and `monitor` commands has been only partially patched.  In particular, the `json` template function already provided escaping and no patching was necessary.  However, raw template output has been left unescaped because this raw output may be necessary for commands which embed Mutagen.  To aid these commands, a new `shellSanitize` template function has been added which provides control character neutralization in strings.

### Workarounds

Avoiding synchronization of untrusted files or interaction with untrusted remote endpoints should mitigate any risk.

### References

A similar issue can be seen in kubernetes/kubernetes#101695.


WWBN/AVideo stored XSS vulnerability leads to takeover of any user's account, including admin's account

[Severity: HIGH]

In AVideo, a normal user can make a Meeting Schedule where the user can invite another user in that Meeting, but I found out that it did not properly sanitize the malicious characters when creating a Meeting Room. This leads the attacker to put malicious scripts.

Impact:

Since any USER including the ADMIN can see the meeting room that was created by the attacker this can lead to cookie hijacking and takeover of any accounts without user interaction.

Step to Reproduce:

1. As normal USER go to Meet -> Schedule

https://demo.avideo.com/plugin/Meet/

2. In "Meet topic" field put XSS payload

Example: "><img src=x onerror=alert('Pawned+by+Gonz')>

3. Then click Save

4. Now as ADMIN go to Meet -> Schedule -> Upcoming

https://demo.avideo.com/plugin/Meet/

5. Then the XSS payload that normal USER created will be executed

Video POC: https://youtu.be/Nke0Bmv5F-o


Flask vulnerable to possible disclosure of permanent session cookie due to missing Vary: Cookie header

[Severity: HIGH]

When all of the following conditions are met, a response containing data intended for one client may be cached and subsequently sent by a proxy to other clients. If the proxy also caches `Set-Cookie` headers, it may send one client's `session` cookie to other clients. The severity depends on the application's use of the session, and the proxy's behavior regarding cookies. The risk depends on _all_ these conditions being met.

1. The application must be hosted behind a caching proxy that does not strip cookies or ignore responses with cookies.
2. The application sets [`session.permanent = True`](https://flask.palletsprojects.com/en/2.3.x/api/#flask.session.permanent).
2. The application does not access or modify the session at any point during a request.
4. [`SESSION_REFRESH_EACH_REQUEST`](https://flask.palletsprojects.com/en/2.3.x/config/#SESSION_REFRESH_EACH_REQUEST) is enabled (the default).
5. The application does not set a `Cache-Control` header to indicate that a page is private or should not be cached.

This happens because vulnerable versions of Flask only set the `Vary: Cookie` header when the session is accessed or modified, not when it is refreshed (re-sent to update the expiration) without being accessed or modified.


A potential risk in clusternet which can be leveraged to make a cluster-level privilege escalation

[Severity: MEDIUM]

## Summary:
A potential risk in clusternet which can be leveraged to make a cluster-level privilege escalation.
## Detailed analysis:
The clusternet has a deployment called cluster-hub inside the clusternet-system Kubernetes namespace, which runs on worker nodes
randomly. The deployment has a service account called clusternet-hub, which has a cluster role called clusternet:hub via cluster role binding. The clusternet:hub cluster role has "*" verbs of "*.*" resources. Thus, if a malicious user can access the worker node which runs the clusternet, he/she can leverage the service account to do malicious actions to critical system resources. For example, he/she can leverage the service account to get ALL secrets in the entire cluster, resulting in cluster-level privilege escalation.


XWiki Platform vulnerable to privilege escalation from view right on XWiki.Notifications.Code.LegacyNotificationAdministration

[Severity: CRITICAL]

### Impact

Steps to reproduce:

Open <xwiki-host>/xwiki/bin/view/XWiki/Notifications/Code/LegacyNotificationAdministration?since=%7B%7B%2Fhtml%7D%7D+%7B%7Basync+async%3D%22true%22+cached%3D%22false%22+context%3D%22doc.reference%22%7D%7D%7B%7Bgroovy%7D%7Dprintln%28%22Hello+%22+%2B+%22from+groovy%21%22%29%7B%7B%2Fgroovy%7D%7D%7B%7B%2Fasync%7D%7D, where <xwiki-host> is the URL of your XWiki installation.

This demonstrates an XWiki syntax injection attack via the since-parameter, allowing privilege escalation from view to programming rights.

### Patches

The vulnerability has been patched in XWiki 15.0-rc-1, 14.10.3, 14.4.8 and 14.10.3.

### Workarounds

For versions >= 14.6-rc-1 the workaround is to modify the page `XWiki.Notifications.Code.LegacyNotificationAdministration` to add the missing escaping, as described on https://github.com/xwiki/xwiki-platform/commit/8e7c7f90f2ddaf067cb5b83b181af41513028754#diff-4e13f4ee4a42938bf1201b7ee71ca32edeacba22559daf0bcb89d534e0225949R70

For versions < 14.6-rc-1 the workaround is to modify the file `<xwikiwebapp>/templates/distribution/eventmigration.wiki` to add the missing escaping, as described on https://github.com/xwiki/xwiki-platform/commit/6d74e2e4aa03d19f0be385ab63ae9e0f0e90a766

### References

https://jira.xwiki.org/browse/XWIKI-20287

### 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)


XWiki Platform's async and display macro allow displaying and interacting with any document in restricted mode

[Severity: CRITICAL]

### Impact

It's possible to display any page you cannot access through the combination of the async and display macro.

Steps to reproduce:

1. Enable comments for guests by giving guests comment rights
2. As a guest, create a comment with content ```{{async}}{{display reference="Menu.WebHome" /}}{{/async}}```
3. Open the comments viewer from the menu (appends ?viewer=comments to the URL)

-> the `Menu.WebHome` is displayed while the expectation would be to have an error that the current user is not allowed to see it

### Patches

The vulnerability has been patched in XWiki 15.0-rc-1, 14.10.3, 14.4.8, and 13.10.11.

### Workarounds

There is no known workaround.

### References

https://jira.xwiki.org/browse/XWIKI-20394
https://jira.xwiki.org/browse/XRENDERING-694

### 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)


XWiki Platform vulnerable to privilege escalation from view right using Invitation.InvitationCommon

[Severity: HIGH]

### Impact
Any user with view rights can execute arbitrary Groovy, Python or Velocity code in XWiki leading to full access to the XWiki installation. The root cause is improper escaping of `Invitation.InvitationCommon`. This page is installed by default.

See https://jira.xwiki.org/browse/XWIKI-20283 for the reproduction steps.

### Patches
The vulnerability has been patched in XWiki 15.0-rc-1, 14.10.1, 14.4.8, and 13.10.11.

### Workarounds
The issue can be fixed by applying this [patch](https://github.com/xwiki/xwiki-platform/commit/3d055a0a5ec42fdebce4d71ee98f94553fdbfebf) on `Invitation.InvitationCommon`.

### References
- https://github.com/xwiki/xwiki-platform/commit/3d055a0a5ec42fdebce4d71ee98f94553fdbfebf
- https://jira.xwiki.org/browse/XWIKI-20283

### 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)


Exposure of Sensitive Information to an Unauthorized Actor in org.xwiki.platform:xwiki-platform-office-viewer

[Severity: HIGH]

### Impact

The office document viewer macro was allowing anyone to see any file content from the hosting server, provided that the office server was connected and depending on the permissions of the user running the servlet engine (e.g. tomcat) running XWiki. The same vulnerability also allowed to perform internal requests to resources from the hosting server.

### Patches

The problem has been patched in XWiki 13.10.11, 14.10.1, 14.4.8, 15.0-rc-1.

### Workarounds

It might be possible to workaround this vulnerability by running XWiki in a sandbox with a user with very low privileges on the machine, now to run a servlet engine the user will always need access to some files, so in any case this workaround won't protect all files to be accessed.

### References

  * Original jira ticket: https://jira.xwiki.org/browse/XWIKI-20447
  * Jira ticket related to another exploit using same root cause: https://jira.xwiki.org/browse/XWIKI-20324
  * Jira ticket related to the possibility to exploit the same vulnerability to perform internal requests: https://jira.xwiki.org/browse/XWIKI-20449

### 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)


xwiki-platform-web-templates allows users to be created even when registration is disabled without validation via template macro

[Severity: MEDIUM]

### Impact

If a guest has view rights on any document, it's possible to create a new user using the `distribution/firstadminuser.wiki` in the wrong context.

To reproduce:

* On a wiki with view rights for guests but user registration disabled, open as guest <server>/xwiki/bin/view/Main?sheet=CKEditor.HTMLConverter&language=en&sourceSyntax=xwiki%2F2.1&stripHTMLEnvelope=true&fromHTML=false&toHTML=true&text=%7B%7Btemplate+name%3D%22distribution%2Ffirstadminuser.wiki%22+%2F%7D%7D where <server> is the URL of your XWiki installation.
* Enter username and password of your choice.
* Click "Register and login"

### Patches

The vulnerability has been patched in XWiki 15.0-rc-1 and 14.10.1.

### Workarounds
There is no known workaround other than upgrading.

### References
https://jira.xwiki.org/browse/XWIKI-19852
https://jira.xwiki.org/browse/XWIKI-20400

### 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)


Strapi plugins vulnerable to Server-Side Template Injection and Remote Code Execution in the Users-Permissions Plugin

[Severity: CRITICAL]

### Summary

Strapi through 4.5.5 allows authenticated Server-Side Template Injection (SSTI) that can be exploited to execute arbitrary code on the server.

### Details

Strapi through 4.5.5 allows authenticated Server-Side Template Injection (SSTI) that can be exploited to execute arbitrary code on the server. A remote attacker with access to the Strapi admin panel can inject a crafted payload that executes code on the server into an email template that bypasses the validation checks that should prevent code execution.

### IoC

Using just the request log files, the only IoC to search for is a `PUT` request to URL path `/users-permissions/email-templates`. This IoC only indicates that a Strapi email template was modified on your server and by itself does not indicate if your Strapi server has been compromised. If this IoC is detected, you will need to manually review your email templates on your Strapi server and backups of your database to see if any of the templates contain a `lodash` template delimiter (eg. `<%STUFF HERE%>`) that contains suspicious JavaScript code. Generally speaking these templates should look like the following, you may have minor adjustments but any unrecognized code should be considered suspicious.

Reset Password Template:

```html
<p>We heard that you lost your password. Sorry about that!</p>

<p>But don’t worry! You can use the following link to reset your password:</p>
<p><%= URL %>?code=<%= TOKEN %></p>

<p>Thanks.</p>
```

Email Confirmation Template:

```html
<p>Thank you for registering!</p>

<p>You have to confirm your email address. Please click on the link below.</p>

<p><%= URL %>?confirmation=<%= CODE %></p>

<p>Thanks.</p>
```

Specifically you should look for odd code contained within the `<%STUFF HERE%>` blocks as this is what is used to bypass the lodash templating system. If you find any code that is not a variable name, or a variable name that is not defined in the template you are most likely impacted and should take immediate steps to confirm there are no malicious applications running on your servers.

### Impact

All users on Strapi below 4.5.6 with access to the admin panel and the ability to modify the email templates


Apache Sling Engine vulnerable to cross-site scripting (XSS) that can lead to privilege escalation

[Severity: HIGH]

The SlingRequestDispatcher doesn't correctly implement the RequestDispatcher API resulting in a generic type of include-based cross-site scripting issues on the Apache Sling level. The vulnerability is exploitable by an attacker that is able to include a resource with specific content-type and control the include path (i.e. writing content). The impact of a successful attack is privilege escalation to administrative power.

Please update to Apache Sling Engine version 2.14.0 or newer and enable the "Check Content-Type overrides" configuration option.


org.xwiki.platform:xwiki-platform-skin-skinx vulnerable to basic Cross-site Scripting by exploiting JSX or SSX plugins

[Severity: CRITICAL]

### Impact

There was no check in the author of a JavaScript xobject or StyleSheet xobject added in a XWiki document, so until now it was possible for a user having only Edit Right to create such object and to craft a script allowing to perform some operations when executing by a user with appropriate rights.

### Patches

This has been patched in XWiki 14.9-rc-1 by only executing the script if the author of it has Script right.

### Workarounds

The only known workaround consists in applying [the following patch](https://github.com/xwiki/xwiki-platform/commit/fe65bc35d5672dd2505b7ac4ec42aec57d500fbb) and rebuilding and redeploying `xwiki-platform-skin-skinx`.

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


org.xwiki.platform:xwiki-platform-rendering-xwiki vulnerable to stored cross-site scripting via HTML and raw macro

[Severity: CRITICAL]

### Impact

The HTML macro does not systematically perform a proper neutralization of script-related html tags. As a result, any user able to use the html macro in XWiki, is able to introduce an XSS attack. This can be particularly dangerous since in a standard wiki, any user is able to use the html macro directly in their own user profile page.

### Patches

The problem has been patched in XWiki 14.8RC1. The patch involve that the HTML macro are systematically cleaned up whenever the user does not have script right.

### Workarounds

There's no workaround for this issue.

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


org.xwiki.platform:xwiki-platform-oldcore makes Incorrect Use of Privileged APIs with DocumentAuthors

[Severity: CRITICAL]

### Impact

The Document script API returns directly a DocumentAuthors allowing to set any authors to the document, which in consequence can allow subsequent executions of scripts since this author is used for checking rights.
Example of such attack:

```
{{velocity}}
$doc.setContent('{{velocity}}$xcontext.context.authorReference{{/velocity}}')
$doc.authors.setContentAuthor('xwiki:XWiki.superadmin')
$doc.getRenderedContent()
{{/velocity}}
```

### Patches
The problem has been patched in XWiki 14.10 and 14.4.7 by returning a safe script API.

### Workarounds
There no easy workaround apart of upgrading.

### References

  * https://jira.xwiki.org/browse/XWIKI-20380
  * https://github.com/xwiki/xwiki-platform/commit/905cdd7c421dbf8c565557cdc773ab1aa9028f83

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


Jenkins NeuVector Vulnerability Scanner Plugin disables SSL/TLS certificate and hostname validation

[Severity: MEDIUM]

Jenkins NeuVector Vulnerability Scanner Plugin 1.22 and earlier unconditionally disables SSL/TLS certificate and hostname validation when connecting to a configured NeuVector Vulnerability Scanner server.


Jenkins Image Tag Parameter Plugin improperly introduces option to opt out of SSL/TLS certificate validation

[Severity: MEDIUM]

Jenkins Image Tag Parameter Plugin 2.0 improperly introduces an option to opt out of SSL/TLS certificate validation when connecting to Docker registries.

Job configurations using Image Tag Parameters that were created before 2.0 will have SSL/TLS certificate validation disabled by default.


Jenkins WSO2 Oauth Plugin does not mask the WSO2 Oauth client secret on the global configuration form

[Severity: LOW]

Jenkins WSO2 Oauth Plugin 1.0 and earlier stores the WSO2 Oauth client secret unencrypted in the global config.xml file on the Jenkins controller as part of its configuration.

This client secret can be viewed by users with access to the Jenkins controller file system.

Additionally, the global configuration form does not mask the WSO2 Oauth client secret, increasing the potential for attackers to observe and capture it.


Jenkins Report Portal Plugin allows users with Item/Extended Read permission to view tokens on Jenkins controller

[Severity: MEDIUM]

Jenkins Report Portal Plugin 0.5 and earlier stores ReportPortal access tokens unencrypted in job `config.xml` files on the Jenkins controller as part of its configuration.

These tokens can be viewed by users with Item/Extended Read permission or access to the Jenkins controller file system.

Additionally, the configuration form does not mask these tokens, increasing the potential for attackers to observe and capture them.


Jenkins WSO2 Oauth Plugin stores WSO2 Oauth client secret unencrypted in global config.xml file on Jenkins controller

[Severity: LOW]

Jenkins WSO2 Oauth Plugin 1.0 and earlier stores the WSO2 Oauth client secret unencrypted in the global config.xml file on the Jenkins controller as part of its configuration.

This client secret can be viewed by users with access to the Jenkins controller file system.

Additionally, the global configuration form does not mask the WSO2 Oauth client secret, increasing the potential for attackers to observe and capture it.


thorsten/phpmyfaq vulnerable to DOM cross-site scripting (XSS) via configuration privacy note URL parameter

[Severity: HIGH]

thorsten/phpmyfaq prior to 3.1.12 is vulnerable to DOM cross-site scripting (XSS) because it fails to sanitize user input in the configuration privacy note URL parameter. This has been fixed in 3.1.12.


thorsten/phpmyfaq vulnerable to stored cross-site scripting (XSS) via category field name parameter

[Severity: MEDIUM]

thorsten/phpmyfaq prior to 3.1.12 is vulnerable to stored cross-site scripting (XSS) because it fails to sanitize user input in the `category field name` parameter. This has been fixed in 3.1.12.


thorsten/phpmyfaq vulnerable to stored cross-site scripting (XSS) in FAQ comment username parameter

[Severity: HIGH]

thorsten/phpmyfaq prior to 3.1.12 is vulnerable to stored cross-site scripting (XSS) because it fails to sanitize user input in the FAQ comment username parameter. This has been fixed in 3.1.12.


Jenkins OctoPerf Load Testing Plugin missing permission check allows for unauthorized server connections

[Severity: MEDIUM]

Jenkins OctoPerf Load Testing Plugin Plugin 4.5.2 and earlier does not perform permission checks in several HTTP endpoints.

This allows attackers with Overall/Read permission to connect to a previously configured Octoperf server using attacker-specified credentials.

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

OctoPerf Load Testing Plugin Plugin 4.5.3 requires POST requests and the appropriate permissions for the affected HTTP endpoints.


Jenkins Role-based Authorization Strategy Plugin grants permissions even after they’ve been disabled

[Severity: MEDIUM]

Permissions in Jenkins can be enabled and disabled. Some permissions are disabled by default, e.g., Overall/Manage or Item/Extended Read. Disabled permissions cannot be granted directly, only through greater permissions that imply them (e.g., Overall/Administer or Item/Configure).

Role-based Authorization Strategy Plugin 587.v2872c41fa_e51 and earlier grants permissions even after they’ve been disabled.

This allows attackers to have greater access than they’re entitled to after the following operations took place:

A permission is granted to attackers directly or through groups.

The permission is disabled, e.g., through the script console.

Role-based Authorization Strategy Plugin 587.588.v850a_20a_30162 does not grant disabled permissions.


Payara Server allows remote attackers to load malicious code on the server once a JNDI directory scan is performed

[Severity: CRITICAL]

A JNDI rebind operation in the default ORB listener in Payara Server 4.1.2.191 (Enterprise), 5.20.0 and newer (Enterprise), and 5.2020.1 and newer (Community), when Java 1.8u181 and earlier is used, allows remote attackers to load malicious code on the server once a JNDI directory scan is performed.


HashiCorp Vault’s Microsoft SQL Database Storage Backend Vulnerable to SQL Injection Via Configuration File

[Severity: MEDIUM]

HashiCorp Vault and Vault Enterprise versions 0.8.0 until 1.13.1 are vulnerable to an SQL injection attack when using the Microsoft SQL (MSSQL) Database Storage Backend. When configuring the MSSQL plugin, certain parameters are required to establish a connection (schema, database, and table) are not sanitized when passed to the user-provided MSSQL database. A privileged attacker with the ability to write arbitrary data to Vault's configuration may modify these parameters to execute a malicious SQL command when the Vault configuration is applied. This issue is fixed in versions 1.13.1, 1.12.5, and 1.11.9.


Snappier vulnerable to buffer overrun due to improper restriction of operations within the bounds of a memory buffer

[Severity: HIGH]

### Impact
This is a buffer overrun vulnerability that can affect any user of Snappier 1.1.0. In this release, much of the code was rewritten to use byte references rather than pointers to pinned buffers. This change generally improves performance and reduces workload on the garbage collector. However, when the garbage collector performs compaction and rearranges memory, it must update any byte references on the stack to refer to the updated location. The .NET garbage collector can only update these byte references if they still point within the buffer or to a point one byte past the end of the buffer. If they point outside this area, the buffer itself may be moved while the byte reference stays the same.

There are several places in 1.1.0 where byte references very briefly point outside the valid areas of buffers. These are at locations in the code being used for buffer range checks. While the invalid references are never dereferenced directly, if a GC compaction were to occur during the brief window when they are on the stack then it could invalidate the buffer range check and allow other operations to overrun the buffer.

This should be very difficult for an attacker to trigger intentionally. It would require a repetitive bulk attack with the hope that a GC compaction would occur at precisely the right moment during one of the requests. However, one of the range checks with this problem is a check based on input data in the decompression buffer, meaning malformed input data could be used to increase the chance of success.

Note that any resulting buffer overrun is likely to cause access to protected memory, which will then cause an exception and the process to be terminated. Therefore, the most likely result of an attack is a denial of service.

### Patches
This is patched in release 1.1.1.

### Workarounds
Pinning any buffers to a fixed location before using them for compression or decompression should mitigate some, but not all, of these cases. At least one temporary decompression buffer is internal to the library and never pinned.


Hippo4j allows attacker to obtain sensitive info via ConfigVerifyController function of Tenant Management module

[Severity: MEDIUM]

Insecure Permissions vulnerability found in OpenGoofy Hippo4j v.1.4.3 allows attacker to obtain sensitive information via the ConfigVerifyController function of the Tenant Management module.


angular-server-side-configuration information disclosure vulnerability in monorepo with node.js backend

[Severity: CRITICAL]

### Impact
angular-server-side-configuration detects used environment variables in TypeScript (.ts) files during build time of an Angular CLI project. The detected environment variables are written to a ngssc.json file in the output directory.
During deployment of an Angular based app, the environment variables based on the variables from ngssc.json are inserted into the apps index.html (or defined index file).

With version 15 the environment variable detection was widened to the entire project, relative to the angular.json file from the Angular CLI. In a monorepo setup, this could lead to environment variables intended for a backend/service to be detected and written to the ngssc.json, which would then be populated and exposed via index.html.

This has NO IMPACT, in a plain Angular project that has no backend component.

### Patches
Vulnerability has been mitigated in 15.1.0, by adding an option `searchPattern` which restricts the detection file range by default.

```bash
# Update via npm
npm update angular-server-side-configuration
## Or more specific
npm install angular-server-side-configuration@15.1.0

# Update via pnpm
pnpm update angular-server-side-configuration
## Or more specific
pnpm add angular-server-side-configuration@15.1.0

# Update via yarn
yarn update angular-server-side-configuration
## Or more specific
yarn add angular-server-side-configuration@15.1.0
```

### Workarounds
Manually edit or create ngssc.json or run a script after ngssc.json generation

### References


Versionize::deserialize implementation for FamStructWrapper<T> is lacking bound checks, potentially leading to out of bounds memory accesses

[Severity: MEDIUM]

### Impact

An issue was discovered in the `Versionize::deserialize` implementation provided by the `versionize` crate for `vmm_sys_util::fam::FamStructWrapper`, which can lead to out of bounds memory accesses.

### Patches

The impact started with version 0.1.1. The issue was corrected in version 0.1.10 by inserting a check that verifies, for any deserialized header, the lengths of compared flexible arrays are equal and aborting deserialization otherwise.

### Workarounds
\-

### References
- https://github.com/firecracker-microvm/versionize/pull/53


Moodle's Mustache pix helper contained a potential Mustache injection risk if combined with user input

[Severity: CRITICAL]

The Mustache pix helper contained a potential Mustache injection risk if combined with user input (note: This did not appear to be implemented/exploitable anywhere in the core Moodle LMS).


Non-interactive Tailscale SSH sessions on FreeBSD may use the effective group ID of the tailscaled process

[Severity: MEDIUM]

A vulnerability identified in the implementation of Tailscale SSH in FreeBSD allowed commands to be run with a higher privilege group ID than that specified by Tailscale SSH access rules.

**Affected platforms**: FreeBSD

**Patched Tailscale client versions**: v1.38.2 or later

### What happened?
A difference in the behavior of the FreeBSD `setgroups` system call from POSIX meant that the Tailscale client running on a FreeBSD-based operating system did not appropriately restrict groups on the host when using Tailscale SSH. When accessing a FreeBSD host over Tailscale SSH, the egid of the tailscaled process was used instead of that of the user specified in Tailscale SSH access rules.

### Who is affected?
9 tailnets with 22 FreeBSD nodes running Tailscale SSH since Tailscale v1.34 (released on 2022-12-04) may have had Tailscale SSH sessions with a higher privilege group ID than that specified in Tailscale SSH access rules.

We have notified the affected organizations where we have [security contacts](https://tailscale.com/kb/1224/contact-preferences/#setting-the-security-issues-email).

### What is the impact?
Tailscale SSH commands may have been run with a higher privilege group ID than that specified in Tailscale SSH access rules if they met all of the following criteria:
* The destination node was a FreeBSD device with Tailscale SSH enabled;
* Tailscale SSH access rules permitted access for non-root users; and
* A non-interactive SSH session was used.

### What do I need to do?
If you are running Tailscale on FreeBSD, upgrade to v1.38.2 or later to remediate the issue. Admins of a tailnet can view [FreeBSD nodes with unpatched versions](https://login.tailscale.com/admin/machines?q=version%3A%3C1.38.2+freebsd) in the admin console.

To update the local ports tree in advance of what's available upstream, you can:

1. `cd /usr/ports/security/tailscale`
2. edit the Makefile to set `PORTVERSION` to `1.38.2`
3. `make makesum`
4. `make install`

Tailscale SSH on other platforms is not affected.

### Credits
We would like to thank [Ryan Belgrave](https://www.linkedin.com/in/rbelgrave/) for reporting this issue.

### References
* [TS-2023-003](https://tailscale.com/security-bulletins/#ts-2023-003)


node-bluetooth is vulnerable to Buffer Overflow via the findSerialPortChannel method due to improper user input length validation

[Severity: CRITICAL]

All versions of the package node-bluetooth are vulnerable to Buffer Overflow via the findSerialPortChannel method due to improper user input length validation.


XWiki Platform vulnerable to privilege escalation via async macro and IconThemeSheet from the user profile

[Severity: CRITICAL]

### Impact

One can execute any wiki content with the right of IconThemeSheet author by creating an icon theme with the following content:

```
}}}
{{async async="true"}}
{{groovy}}
  println("Hello from Groovy!")
{{/groovy}}
{{/async}}
{{{
```

Can be done by creating a new page or even through the user profile for users not having edit right.

### Patches

This has been patched in XWiki 14.9, 14.4.6, and 13.10.10.

### Workarounds

An easy workaround is to actually fix the bug in the page `IconThemesCode.IconThemeSheet` by applying the following modification: https://github.com/xwiki/xwiki-platform/commit/48caf7491595238af2b531026a614221d5d61f38#diff-2ec9d716673ee049937219cdb0a92e520f81da14ea84d144504b97ab2bdae243R45

### References

https://jira.xwiki.org/browse/XWIKI-19731

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


XWiki Platform vulnerable to privilege escalation via properties with wiki syntax that are executed with wrong author

[Severity: CRITICAL]

### Impact

It's possible to use the right of an existing document content author to execute a text area property.

To reproduce:

* As an admin with programming rights, create a new user without script or programming right.
* Login with the freshly created user.
* Insert the following text in source mode in the about section:
```
    {{groovy}}println("hello from groovy!"){{/groovy}}
```
* Click "Save & View"

### Patches

This has been patched in XWiki 14.10, 14.4.7, and 13.10.11.

### Workarounds

No known workaround.

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

### For more information
If you have any questions or comments about this advisory:

* Open an issue in [Jira](http://jira.xwiki.org/)
* Email us at [Security ML](mailto:security@xwiki.org)


Unprivileged XWiki Platform users can make arbitrary select queries using DatabaseListProperty and suggest.vm

[Severity: MEDIUM]

### Impact

Any user with edit right can execute arbitrary database select and access data stored in the database.

To reproduce:
 * In admin, rights, remove scripting rights for {{XWikiAllGroup}}.
 * Create a new user without any special privileges.
 * Create a page "Private.WebHome" with {{TOKEN_42}} as content. Go to "page administration" and explicitly set all rights for "Admin" to remove them for all other users.
 * Logout and login as the unprivileged user. Ensure that the previously created page cannot be viewed.
 * Create a new page "ExploitClass.WebHome" and then open it in the class editor (first, make the user an advanced user).
 * Add a field named {{ContentList}} of type {{Database List}}
 * Enter in field "Hibernate Query" the following content: {noformat}select doc.content, doc.fullName from XWikiDocument as doc where doc.fullName = 'Private.WebHome'{noformat}
 * Save the class.
 * Open [http://localhost:8080/xwiki/bin/view/ExploitClass/?xpage=suggest&classname=ExploitClass.WebHome&fieldname=ContentList&firCol=doc.fullName&secCol=-]

### Patches

The problem has been patched on XWiki 13.10.11, 14.4.7, and 14.10.

### Workarounds

There is no workaround for this vulnerability other than upgrading.

### References

https://jira.xwiki.org/browse/XWIKI-19523

### 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)


Saleor has Staff-Authenticated Error Message Information Disclosure Vulnerability via Python Exceptions

[Severity: MEDIUM]

### Impact
Some internal Python exceptions are not handled properly and thus are returned in API as error messages. Some messages might contain sensitive information like user email address in staff-authenticated requests.

This issue has been patched in versions 3.1.48, 3.7.59, 3.8.30, 3.9.27, 3.10.14 and 3.11.12.

### Workarounds
None

### For more information
If you have any questions or comments about this advisory:
* Open a discussion at https://github.com/saleor/saleor/discussions
* Email us at [hello@saleor.io](mailto:hello@saleor.io)


RestEasy Reactive implementation of Quarkus allows Creation of Temporary File With Insecure Permissions

[Severity: LOW]

In RestEasy Reactive implementation of Quarkus the insecure `File.createTempFile()` is used in the `FileBodyHandler` class which creates temp files with insecure permissions that could be read by a local user.


Pterodactyl Wings contains UNIX Symbolic Link (Symlink) Following resulting in deletion of files and directories on the host system

[Severity: CRITICAL]

### Impact

This vulnerability impacts anyone running the affected versions of Wings.  The vulnerability can be used to delete files and directories recursively on the host system.  This vulnerability can be combined with [`GHSA-p8r3-83r8-jwj5`](https://github.com/pterodactyl/wings/security/advisories/GHSA-p8r3-83r8-jwj5) to overwrite files on the host system.

In order to use this exploit, an attacker must have an existing "server" allocated and controlled by Wings.  Information on how the exploitation of this vulnerability works will be released on February 24th, 2023 in North America.

### Patches

This vulnerability has been resolved in version `v1.11.4` of Wings, and has been back-ported to the 1.7 release series in `v1.7.4`.

Anyone running `v1.11.x` should upgrade to `v1.11.4` and anyone running `v1.7.x` should upgrade to `v1.7.4`.

### Workarounds

None at this time.


Withdrawn: Fortra GoAnywhere MFT Deserialization of Untrusted Data vulnerability affects metasploit-framework

[Severity: HIGH]

## Withdrawn
This advisory has been withdrawn because it was incorrectly associated with the metasploit-framework package, which is not affected by this CVE, and the actual vulnerable component does not fit within our supported ecosystems. This link is maintained to preserve external references.

## Original Description

Fortra (formerly, HelpSystems) GoAnywhere MFT suffers from a pre-authentication command injection vulnerability in the License Response Servlet due to deserializing an arbitrary attacker-controlled object.


Jenkins GitHub Pull Request Builder Plugin missing permission check allows enumerating credentials IDs

[Severity: MEDIUM]

Jenkins GitHub Pull Request Builder Plugin 1.42.2 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.


Exposure of system-scoped Kubernetes credentials in Jenkins Kubernetes Credentials Provider Plugin

[Severity: MEDIUM]

Jenkins Kubernetes Credentials Provider Plugin 1.208.v128ee9800c04 and earlier does not set the appropriate context for Kubernetes credentials lookup, allowing attackers with Item/Configure permission to access and potentially capture Kubernetes credentials they are not entitled to.


Any Flarum user including unactivated can reply in public discussions whose first post was permanently deleted

[Severity: LOW]

If the first post of a discussion is permanently deleted but the discussion stays visible, any actor who can view the discussion is able to create a new reply via the REST API, no matter the reply permission or lock status.

This includes users that don't have a validated email.

Guests cannot successfully create a reply because the API will fail with a 500 error when the user ID 0 is inserted into the database. This should also be fixed to return the expected 401/403 status.

This happens because when the first post of a discussion is permanently deleted, the `first_post_id` attribute of the discussion becomes `null` which causes access control to be skipped for all new replies.

Flarum automatically makes discussions with zero comments invisible so an additional condition for this vulnerability is that the discussion must have at least one approved reply so that `discussions.comment_count` is still above zero after the post deletion.

### Impact
This can open the discussion to uncontrolled spam or just unintentional replies if users still had their tab open before the vulnerable discussion was locked and then post a reply when they shouldn't be able to.

In combination with the email notification settings, this could also be used as a way to send unsolicited emails.

Versions between `v1.3.0` and `v1.6.3` are impacted.

### Patches
The vulnerability has been fixed and published as flarum/core v1.6.3. All communities running Flarum should upgrade as soon as possible to v1.6.3 using:

```
composer update --prefer-dist --no-dev -a -W
```
You can then confirm you run the latest version using:

```
composer show flarum/core
```

### Workarounds
If you don't delete the first posts you are not affected. A workaround can be to delete the discussion itself, or amend the database to manually set a `first_post_id`.

### For more information
For any questions or comments on this vulnerability please visit https://discuss.flarum.org/

For support questions create a discussion at https://discuss.flarum.org/t/support.

A reminder that if you ever become aware of a security issue in Flarum, please report it to us privately by emailing [security@flarum.org](mailto:security@flarum.org), and we will address it promptly.


bzip2 allows attackers to cause a denial of service via a large file that triggers an integer overflow

[Severity: HIGH]

The bzip2 crate before 0.4.4 for Rust allow attackers to cause a denial of service via a large file that triggers an integer overflow in `mem.rs`. NOTE: this is unrelated to the https://crates.io/crates/bzip2-rs product.


AWS S3 Crypto SDK sends an unencrypted hash of the plaintext alongside the ciphertext as a metadata field

[Severity: MEDIUM]

The AWS S3 Crypto SDK sends an unencrypted hash of the plaintext alongside the ciphertext as a metadata field. This hash can be used to brute force the plaintext, if the hash is readable to the attacker. AWS now blocks this metadata field, but older SDK versions still send it.


jsonwebtoken's insecure implementation of key retrieval function could lead to Forgeable Public/Private Tokens from RSA to HMAC

[Severity: MEDIUM]

# Overview

Versions `<=8.5.1` of `jsonwebtoken` library can be misconfigured so that passing a poorly implemented key retrieval function (referring to the `secretOrPublicKey` argument from the [readme link](https://github.com/auth0/node-jsonwebtoken#jwtverifytoken-secretorpublickey-options-callback)) will result in incorrect verification of tokens. There is a possibility of using a different algorithm and key combination in verification  than the one that was used to sign the tokens. Specifically, tokens signed with an asymmetric public key could be verified with a symmetric HS256 algorithm. This can lead to successful validation of forged tokens.

# Am I affected?

You will be affected if your application is supporting usage of both symmetric key and asymmetric key in jwt.verify() implementation with the same key retrieval function.

# How do I fix it?

Update to version 9.0.0.

# Will the fix impact my users?

There is no impact for end users


jsonwebtoken vulnerable to signature validation bypass due to insecure default algorithm in jwt.verify()

[Severity: MEDIUM]

# Overview

In versions <=8.5.1 of jsonwebtoken library, lack of algorithm definition and a falsy secret or key in the `jwt.verify()` function can lead to signature validation bypass due to defaulting to the `none` algorithm for signature verification.

# Am I affected?
You will be affected if all the following are true in the `jwt.verify()` function:
- a token with no signature is received
- no algorithms are specified
- a falsy (e.g. null, false, undefined) secret or key is passed

# How do I fix it?

Update to version 9.0.0 which removes the default support for the none algorithm in the `jwt.verify()` method.

# Will the fix impact my users?

There will be no impact, if you update to version 9.0.0 and you don’t need to allow for the `none` algorithm. If you need 'none' algorithm, you have to explicitly specify that in `jwt.verify()` options.


Smoothie vulnerable to Cross-site Scripting when tooltipLabel or strokeStyle are controlled by users

[Severity: MEDIUM]

The package smoothie from 1.31.0 and before 1.36.1 are vulnerable to Cross-site Scripting (XSS) due to improper user input sanitization in strokeStyle and tooltipLabel properties. Exploiting this vulnerability is possible when the user can control these properties.


TYPO3 CMS vulnerable to Sensitive Information Disclosure via YAML Placeholder Expressions in Site Configuration

[Severity: MEDIUM]

> ### CVSS: `CVSS:3.1/AV:N/AC:L/PR:H/UI:R/S:U/C:H/I:L/A:L/E:F/RL:O/RC:C` (5.3)

### Problem
Due to the lack of handling user-submitted [YAML placeholder expressions](https://docs.typo3.org/m/typo3/reference-coreapi/main/en-us/Configuration/Yaml/YamlApi.html#custom-placeholder-processing) in the site configuration backend module, attackers could expose sensitive internal information, such as system configuration or HTTP request messages of other website visitors.

A valid backend user account having administrator privileges is needed to exploit this vulnerability.

### Solution
Update to TYPO3 versions 9.5.38 ELTS, 10.4.33, 11.5.20, 12.1.1 that fix the problem described above.

### Credits
Thanks to TYPO3 core & security team member Oliver Hader who reported and fixed the issue.

### References
* [TYPO3-CORE-SA-2022-016](https://typo3.org/security/advisory/typo3-core-sa-2022-016)


Yauaa vulnerable to ArrayIndexOutOfBoundsException triggered by a crafted Sec-Ch-Ua-Full-Version-List

[Severity: HIGH]

### Impact
Applications using the Client Hints analysis feature introduced with 7.0.0 can crash because the Yauaa library throws an ArrayIndexOutOfBoundsException. Applications that do not use this feature are not affected.

### Patches
Upgrade to 7.9.0

### Workarounds
Catch and discard any exceptions from Yauaa.


Cap'n Proto and its Rust implementation vulnerable to out-of-bounds read due to logic error handling list-of-list

[Severity: MEDIUM]

The Cap'n Proto library and capnp Rust package are vulnerable to out-of-bounds read due to logic error handling list-of-list. If a message consumer expects data of type "list of pointers", and if the consumer performs certain specific actions on such data, then a message producer can cause the consumer to read out-of-bounds memory. This could trigger a process crash in the consumer, or in some cases could allow exfiltration of private in-memory data.

Impact
======

- Remotely segfault a peer by sending it a malicious message, if the victim performs certain actions on a list-of-pointer type.
- Possible exfiltration of memory, if the victim performs additional certain actions on a list-of-pointer type.
- To be vulnerable, an application must perform a specific sequence of actions, described below. At present, **we are not aware of any vulnerable application**, but we advise updating regardless.

Fixed in
========

Unfortunately, the bug is present in inlined code, therefore the fix will require rebuilding dependent applications.

C++ fix:

- git commit [25d34c67863fd960af34fc4f82a7ca3362ee74b9][0]
- release 0.11 (future)
- release 0.10.3:
  - Unix: https://capnproto.org/capnproto-c++-0.10.3.tar.gz
  - Windows: https://capnproto.org/capnproto-c++-win32-0.10.3.zip
- release 0.9.2:
  - Unix: https://capnproto.org/capnproto-c++-0.9.2.tar.gz
  - Windows: https://capnproto.org/capnproto-c++-win32-0.9.2.zip
- release 0.8.1:
  - Unix: https://capnproto.org/capnproto-c++-0.8.1.tar.gz
  - Windows: https://capnproto.org/capnproto-c++-win32-0.8.1.zip
- release 0.7.1:
  - Unix: https://capnproto.org/capnproto-c++-0.7.1.tar.gz
  - Windows: https://capnproto.org/capnproto-c++-win32-0.7.1.zip
- release 0.5.4:
  - Unix: https://capnproto.org/capnproto-c++-0.5.4.tar.gz
  - Windows: https://capnproto.org/capnproto-c++-win32-0.5.4.zip

Rust fix:

- `capnp` crate version `0.15.2`, `0.14.11`, or `0.13.7`

[0]: https://github.com/capnproto/capnproto/commit/25d34c67863fd960af34fc4f82a7ca3362ee74b9

Details
=======

A specially-crafted pointer could escape bounds checking by exploiting inconsistent handling of pointers when a list-of-structs is downgraded to a list-of-pointers.

For an in-depth explanation of how this bug works, see [David Renshaw's blog post](https://dwrensha.github.io/capnproto-rust/2022/11/30/out_of_bounds_memory_access_bug.html). This details below focus only on determining whether an application is vulnerable.

In order to be vulnerable, an application must have certain properties.

First, the application must accept messages with a schema in which a field has list-of-pointer type. This includes `List(Text)`, `List(Data)`, `List(List(T))`, or `List(C)` where `C` is an interface type. In the following discussion, we will assume this field is named `foo`.

Second, the application must accept a message of this schema from a malicious source, where the attacker can maliciously encode the pointer representing the field `foo`.

Third, the application must call `getFoo()` to obtain a `List<T>::Reader` for the field, and then use it in one of the following two ways:

1. Pass it as the parameter to another message's `setFoo()`, thus copying the field into a new message. Note that copying the parent struct as a whole will *not* trigger the bug; the bug only occurs if the specific field `foo` is get/set on its own.

2. Convert it into `AnyList::Reader`, and then attempt to access it through that. This is much less likely; very few apps use the `AnyList` API.

The dynamic API equivalents of these actions (`capnp/dynamic.h`) are also affected.

If the application does these steps, the attacker may be able to cause the Cap'n Proto implementation to read beyond the end of the message. This could induce a segmentation fault. Or, worse, data that happened to be in memory immediately after the message might be returned as if it were part of the message. In the latter case, if the application then forwards that data back to the attacker or sends it to another third party, this could result in exfiltration of secrets.

Any exfiltration of data would have the following limitations:

* The attacker could exfiltrate no more than 512 KiB of memory immediately following the message buffer.
  * The attacker chooses in advance how far past the end of the message to read.
  * The attacker's message itself must be larger than the exfiltrated data. Note that a sufficiently large message buffer will likely be allocated using mmap() in which case the attack will likely segfault.
* The attack can only work if the 8 bytes immediately following the exfiltrated data contains a valid in-bounds Cap'n Proto pointer. The easiest way to achieve this is if the pointer is null, i.e. 8 bytes of zero.
  * The attacker must specify exactly how much data to exfiltrate, so must guess exactly where such a valid pointer will exist.
  * If the exfiltrated data is not followed by a valid pointer, the attack will throw an exception. If an application has chosen to ignore exceptions (e.g. by compiling with `-fno-exceptions` and not registering an alternative exception callback) then the attack may be able to proceed anyway.


crewjam/saml vulnerable to signature bypass via multiple Assertion elements due to improper authentication

[Severity: CRITICAL]

### Impact

The crewjam/saml go library is vulnerable to an authentication bypass when processing SAML responses containing multiple Assertion elements.

### Patches

This issue has been corrected in version 0.4.9.

### Credit

This issue was reported by Felix Wilhelm from Google Project Zero.


Exposure of Private Personal Information to an Unauthorized Actor in org.xwiki.platform:xwiki-platform-rest-server

[Severity: MEDIUM]

### Impact
The `modifications` rest endpoint does not filter out entries according to the user's rights. Therefore, information hidden from unauthorized users are exposed though the `modifications` rest endpoint (e.g., comments, page names...).

### Patches
Users should upgrade to XWiki 14.6+, 14.4.3+,  or13.10.8+. Older versions have not been patched.

### Workarounds
No known workaround.

### References

- Patch: https://github.com/xwiki/xwiki-platform/commit/38dc1aa1a4435f24d58f5b8e4566cbcb0971f8ff
- Jira issue: https://jira.xwiki.org/browse/XWIKI-19997

### 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)


Exposure of Sensitive Information to an Unauthorized Actor in org.xwiki.platform:xwiki-platform-livetable-ui

[Severity: MEDIUM]

### Impact

User without the right to view documents can deduce their existence by repeated Livetable queries.

#### Reproduction steps

1. Restrict "view" access to `Sandbox.TestPage3` by setting an explicit view right for admins
1. As a user who is not an admin, open `<server>/bin/get/XWiki/LiveTableResults?outputSyntax=plain&classname=&collist=doc.title%2Cdoc.location%2Cdoc.content&doc.title=Sandbo&doc.location=Sandbox.TestPage3&doc.content=dummy&limit=0` where `<server>` is the URL of your XWiki installation.

#### Expect Result:

No results are displayed as the user doesn't have view rights on Sandbox.TestPage3.

##### Actual Result:

The result

```json
{
  "reqNo": null,
  "matchingtags": {},
  "tags": [],
  "totalrows": 1,
  "returnedrows": 0,
  "offset": 1,
  "rows": [
    {
      "doc_viewable": false,
      "doc_fullName": "obfuscated"
    }
  ]
}
```

is displayed.

This reveals that a document `Sandbox.TestPage3` exists (we explicitly searched for this name) which has a title containing `"Sandbo"` and a content containing `"dummy"`. By starting with a single letter and then iteratively extending the match, the full content of the title/content or XObject properties can be discovered. Several tests can be combined in a single request to use binary search to narrow down the actual match from a list of possible characters/words. If the used alphabet is known and smaller than 128 distinct characters, it is possible to discover one character with 7 requests. Alternatively, frequencies of words and word pairs (2-gram frequencies) can be used to first guess whole words and only resort to guessing individual characters if none of the predicted words match, allowing a much faster recovery of the textual content. As it also depends on the content how easy the attack is and how much recovered content would be a "successful" attack, it is hard to quantify how many requests are necessary.

### Patches

The issue has been patched in XWiki 14.6RC1, 13.10.8, and 14.4.3, the response is not properly cleaned up of obfuscated entries.

### Workarounds

The [patch](https://github.com/xwiki/xwiki-platform/commit/1450b6e3c69ac7df25e5a2571186d1f43402facd#diff-5a739e5865b1f1ad9d79b724791be51b0095a0170cc078911c940478b13b949a) for the document `XWiki.LiveTableResultsMacros` can be manually applied or a XAR archive of a patched version can be [imported](https://www.xwiki.org/xwiki/bin/view/Documentation/UserGuide/Features/Imports#HImportingXWikipages), on versions >= 12.10.11, >= 13.9-rc-1, and >= 13.4.4.

### References

- https://github.com/xwiki/xwiki-platform/commit/1450b6e3c69ac7df25e5a2571186d1f43402facd#diff-5a739e5865b1f1ad9d79b724791be51b0095a0170cc078911c940478b13b949a
- https://jira.xwiki.org/browse/XWIKI-19999

### 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)


Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection') in org.xwiki.platform:xwiki-platform-menu-ui

[Severity: CRITICAL]

### Impact
Any user with view rights on commonly accessible documents including the menu macro can execute arbitrary Groovy, Python or Velocity code in XWiki leading to full access to the XWiki installation due to improper escaping of the macro content and parameters of the menu macro.

The issue can be demonstrated by opening `<server>/xwiki/bin/view/Main?sheet=CKEditor.HTMLConverter&language=en&sourceSyntax=xwiki%2F2.1&stripHTMLEnvelope=true&fromHTML=false&toHTML=true&text=%7B%7Bmenu%7D%7D%7B%7Bcache+id%3D%22menuMacro%22%7D%7D%7B%7Bgroovy%7D%7Dprintln%28%22Hello+from+Groovy%21%22%29%7B%7B%2Fgroovy%7D%7D%7B%7B%2Fcache%7D%7D%7B%7B%2Fmenu%7D%7D` where `<server>` is the URL of the XWiki installation. If this displays "Hello from Groovy!", the installation is vulnerable.

### Patches
The problem has been patched in XWiki 14.6RC1, 13.10.8 and 14.4.3.

### Workarounds
The [patch](https://github.com/xwiki/xwiki-platform/commit/2fc20891e6c6b0ca05ee07e315e7f435e8919f8d) for the document `Menu.MenuMacro` can be manually applied or a XAR archive of a patched version can be [imported](https://www.xwiki.org/xwiki/bin/view/Documentation/UserGuide/Features/Imports#HImportingXWikipages). The menu macro was basically unchanged since XWiki 11.6 so on XWiki 11.6 or later the [patch for version of 13.10.8](https://github.com/xwiki/xwiki-platform/commit/59ccca24a8465a19f40c51d65fcc2c09c1edea16) can most likely be applied, on XWiki version 14.0 and later the versions in XWiki 14.6 and 14.4.3 should be appropriate.

### References
* https://github.com/xwiki/xwiki-platform/commit/2fc20891e6c6b0ca05ee07e315e7f435e8919f8d
* https://jira.xwiki.org/browse/XWIKI-19857

### 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)