Security
Headlines
HeadlinesLatestCVEs

Source

ghsa

GHSA-h95w-p3x6-wwj6: Froxlor vulnerable to Code Injection

Froxlor prior to version 0.10.39 is vulnerable to Code Injection.

ghsa
#git
GHSA-m7gv-v8xx-v47w: XWiki OIDC Authenticator vulnerable to bypassing OpenID login by providing a custom provider

### Impact Even if a wiki has an OpenID provider configured through its xwiki.properties, it is possible to provide a third party provider by providing its details through request parameters. One can then bypass the XWiki authentication altogether by specifying its own provider through the oidc.endpoint.* request parameters (or by using an XWiki-based OpenID provider with oidc.xwikiprovider. With the same approach, one could also provide a specific group mapping through oidc.groups.mapping that would make his user automatically part of the XWikiAdminGroup ### Patches Patched in 1.29.1. ### Workarounds There is no workaround, an upgrade of the authenticator is required. ### References https://jira.xwiki.org/browse/OIDC-118 ### For more information If you have any questions or comments about this advisory: * Open an issue in Jira XWiki * Email us at our security mailing list

GHSA-p5g9-rjcf-95vj: fastest-json-copy vulnerable to Prototype Pollution

fastest-json-copy version 1.0.1 allows an external attacker to edit or add new properties to an object. This is possible because the application does not correctly validate the incoming JSON keys, thus allowing the `__proto__` property to be edited.

GHSA-653v-rqx9-j85p: deep-object-diff vulnerable to Prototype Pollution

deep-object-diff version 1.1.0 allows an external attacker to edit or add new properties to an object. This is possible because the application does not properly validate incoming JSON keys, thus allowing the `__proto__` property to be edited.

GHSA-ff9j-pwxg-q5p2: deep-parse-json vulnerable to Prototype Pollution

deep-parse-json version 1.0.2 allows an external attacker to edit or add new properties to an object. This is possible because the application does not correctly validate the incoming JSON keys, thus allowing the `__proto__` property to be edited.

GHSA-qqhf-xfhw-7884: Markdownify has Files or Directories Accessible to External Parties

Markdownify version 1.4.1 allows an external attacker to remotely obtain arbitrary local files on any client that attempts to view a malicious markdown file through Markdownify. This is possible because the application does not have a CSP policy (or at least not strict enough) and/or does not properly validate the contents of markdown files before rendering them.

GHSA-xgqr-5wqw-9fpv: Apache UIMA Path Traversal vulnerability

A relative path traversal vulnerability in a FileUtil class used by the PEAR management component of Apache UIMA allows an attacker to create files outside the designated target directory using carefully crafted ZIP entry names. This issue affects Apache UIMA Apache UIMA version 3.3.0 and prior versions. Note that PEAR files should never be installed into an UIMA installation from untrusted sources because PEAR archives are executable plugins that will be able to perform any actions with the same privileges as the host Java Virtual Machine.

GHSA-236j-rfx5-wq38: OpenCart allows users on admin page to obtain database information or read server files through SQL injection

OpenCart 3.0.3.7 allows users to obtain database information or read server files through SQL injection in the background.

GHSA-fjhh-67wv-7gr4: Reflected Cross site scripting (XSS) in kairosdb

KairosDB through 1.2.2 has XSS in view.html because of showErrorMessage in js/graph.js, as demonstrated by view.html?q= with a '"sampling":{"value":"<script>' substring.

GHSA-25mx-2mxm-6343: @keystone-6/core's NODE_ENV defaults to development with esbuild

### Impact `@keystone-6/core@3.0.0 || 3.0.1` users that use `NODE_ENV` in their own code (**not dependencies**) to trigger security-sensitive functionality in a production build are vulnerable to `NODE_ENV` being inlined to `"development"` for user code. If your dependencies use `NODE_ENV` to trigger particular behaviours (optimisations, security or otherwise), they should still respect your environment's configured `NODE_ENV` variable and thereby be unaffected. If you do not use `NODE_ENV` in your own code to trigger security-sensitive functionality, **you are not impacted** by this vulnerability. An example of code that would be affected, might be the following: ```typescript if (process.env.NODE_ENV !== 'production') { // this code would unintentionally run in your production builds } ``` ### Technical Description The problem comes from esbuild defaulting `NODE_ENV` to `"development"` when a platform configuration is undefined. You can read about why [`esbuild` has that behavi...