ghsa

### Impact When credentials are provided while creating an OnboardingTask they may be visible via the Job Results view under the Additional Data tab as args for the Celery Task execution. This only applies to OnboardingTasks that are created with credentials specified while on v2.0.0-2.0.2 of Nautobot Device Onboarding. This advisory does not apply earlier version or when using NAPALM_USERNAME & NAPALM_PASSWORD from nautobot_config.py ### Patches v3.0.0 ### Workarounds None ### Recommendations * Delete all Job Results for any onboarding task to remove clear text credentials from database entries that were run while on v2.0.X * Upgrade to v3.0.0 * Rotate any exposed credential

### Summary A web UI user can store files anywhere on the pyLoad server and gain command execution by abusing scripts. ### Details When a user creates a new package, a subdirectory is created within the /downloads folder to store files. This new directory name is derived from the package name, except a filter is applied to make sure it can't traverse directories and stays within /downloads. src/pyload/core/api/__init__.py::add_package::L432 ```python folder = ( folder.replace("http://", "") .replace("https://", "") .replace(":", "") .replace("/", "_") .replace("\\", "_") ) ``` So if a package were created with the name ```"../"``` the application would instead create the folder ```"/downloads/.._/"``` However, when editing packages there is no prevention in place and a user can just pick any arbitrary directory in the filesystem. src/pyload/webui/app/blueprints/json_blueprint.py::edit_package::L195 ```python id = int(flask.request.form["pack...

### Impact An attacker could modify the locators.ini locator file with python code that without proper validation it's executed and it could lead to rce. The vulnerability is in the function def __locator__(self, locator_name: str) in page.py. The vulnerable code that load and execute directly from the file without validation it's: ```python return eval(self._bot.locator(self._page_name, locator_name)) ``` ### Patches In order to mitigate this issue it's important to upgrade to fastbots version 0.1.5 or above. ### References [Merge that fix also this issue](https://github.com/ubertidavide/fastbots/pull/3#issue-2003080806)

The go-jose package is subject to a "billion hashes attack" causing denial-of-service when decrypting JWE inputs. This occurs when an attacker can provide a PBES2 encrypted JWE blob with a very large p2c value that, when decrypted, produces a denial-of-service.

### Impact Using the model/workflow management API, there is a chance of uploading potentially harmful archives that contain files that are extracted to any location on the filesystem that is within the process permissions. Leveraging this issue could aid third-party actors in hiding harmful code in open-source/public models, which can be downloaded from the internet, and take advantage of machines running Torchserve. ### Patches The ZipSlip issue in TorchServe has been fixed by validating the paths of files contained within a zip archive before extracting them: https://github.com/pytorch/serve/pull/2634 TorchServe release 0.9.0 includes fixes to address the ZipSlip vulnerability: https://github.com/pytorch/serve/releases/tag/v0.9.0 ### References https://github.com/pytorch/serve/pull/2634 https://github.com/pytorch/serve/releases/tag/v0.9.0 ### Credit We would like to thank Oligo Security for responsibly disclosing this issue. If you have any questions or comments about this advi...

### Impact `next-auth` applications prior to version **4.24.5** that rely on the default [Middleware authorization](https://next-auth.js.org/configuration/nextjs#middleware) are affected. A bad actor could create an empty/mock user, by getting hold of a NextAuth.js-issued JWT from an interrupted OAuth sign-in flow (state, PKCE or nonce). Manually overriding the `next-auth.session-token` cookie value with this non-related JWT would let the user simulate a logged in user, albeit having no user information associated with it. (The only property on this user is an opaque randomly generated string). This vulnerability does **not** give access to other users' data, neither to resources that require proper authorization via scopes or other means. The created mock user has no information associated with it (ie. no name, email, access_token, etc.) This vulnerability can be exploited by bad actors to peek at logged in user states (e.g. dashboard layout). _Note: Regardless of the vulnerabil...

### Impact Users are able to bypass the field level security. This means fields that they where not allowed to populate could be populated anyway even in the event that they tried to populate something that they don't have access to. ### Patches This issue has been patched in 1.3.4 ### Workarounds None

### Impact A CSRF vulnerability in the query on XWiki tool allows executing arbitrary database queries on the database of the XWiki installation. Among other things, this allows modifying and deleting all data of the wiki. This could be both used to damage the wiki and to create an account with elevated privileges for the attacker, thus impacting the confidentiality, integrity and availability of the whole XWiki instance. A possible attack vector are comments on the wiki, by embedding an image with wiki syntax like `[[image:path:/xwiki/bin/view/Admin/QueryOnXWiki?query=DELETE%20FROM%20xwikidoc]]`, all documents would be deleted from the database when an admin user views this comment. ### Patches This has been patched in Admin Tools Application 4.5.1 by adding form token checks. ### Workarounds The [patch](https://github.com/xwiki-contrib/application-admintools/commit/45298b4fbcafba6914537dcdd798a1e1385f9e46) can also be applied manually to the affected pages. Alternatively, if the qu...

### Impact A cross site request forgery vulnerability in the admin tool for executing shell commands on the server allows an attacker to execute arbitrary shell commands by tricking an admin into loading the URL with the shell command. A very simple possibility for an attack are comments. When the attacker can leave a comment on any page in the wiki it is sufficient to include an image with an URL like `/xwiki/bin/view/Admin/RunShellCommand?command=touch%20/tmp/attacked` in the comment. When an admin views the comment, the file `/tmp/attacked` will be created on the server. The output of the command is also vulnerable to XWiki syntax injection which offers a simple way to execute Groovy in the context of the XWiki installation and thus an even easier way to compromise the integrity and confidentiality of the whole XWiki installation. ### Patches This has been patched by adding a form token check in version 4.5.1 of the admin tools. ### Workarounds The [patch](https://github.com/xwik...

### Impact The Solr-based search suggestion provider that also duplicates as generic JavaScript API for search results in XWiki exposes the content of all documents of all wikis to anybody who has access to it, by default it is public. This exposes all information stored in the wiki (but not some protected information like password hashes). While there is a right check normally, the right check can be circumvented by explicitly requesting fields from Solr that don't include the data for the right check. This can be reproduced by opening `<xwiki-server>/xwiki/bin/get/XWiki/SuggestSolrService?outputSyntax=plain&media=json&nb=1000&query=q%3D*%3A*%0Aq.op%3DAND%0Afq%3Dtype%3ADOCUMENT%0Afl%3Dtitle_%2C+reference%2C+links%2C+doccontentraw_%2C+objcontent__&input=+` where `<xwiki-server>` is the URL of the XWiki installation. If this displays any results, the wiki is vulnerable. ### Patches This has been fixed in XWiki 15.6RC1, 15.5.1 and 14.10.15 by not listing documents whose rights cannot be...