Source
ghsa
### Impact By either creating a new or editing an existing document with an icon set, an attacker can inject XWiki syntax and Velocity code that is executed with programming rights and thus allows remote code execution. There are different attack vectors, the simplest is the Velocity code in the icon set's HTML or XWiki syntax definition. The [icon picker](https://extensions.xwiki.org/xwiki/bin/view/Extension/Icon%20Theme%20Application#HIconPicker) can be used to trigger the rendering of any icon set. The XWiki syntax variant of the icon set is also used without any escaping in some documents, allowing to inject XWiki syntax including script macros into a document that might have programming right, for this the currently used icon theme needs to be edited. Further, the HTML output of the icon set is output as JSON in the icon picker and this JSON is interpreted as XWiki syntax, allowing again the injection of script macros into a document with programming right and thus allowing remote...
### Impact The HTML sanitizer that is included in XWiki since version 14.6RC1 allowed form and input HTML tags. In the context of XWiki, this allows an attacker without script right to either create forms that can be used for phishing attacks or also in the context of a sheet, the attacker could add an input like `{{html}}<input type="hidden" name="content" value="{{groovy}}println("Hello from Groovy!")" />{{/html}}` that would allow remote code execution when it is submitted by an admin (the sheet is rendered as part of the edit form). The attacker would need to ensure that the edit form looks plausible, though, which can be non-trivial as without script right the attacker cannot display the regular content of the document. ### Patches This has been patched in XWiki 14.10.6 and 15.2RC1 by removing the central form-related tags from the list of allowed tags. ### Workarounds An admin can manually disallow the tags by adding `form, input, select, textarea, button` to the con...
### 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
### Effect Any user with edit rights can edit all pages in the `CKEditor' space. This makes it possible to perform a variety of harmful actions, such as - removing technical documents, leading to loss of service - Editing the javascript configuration of CKEditor, leading to persistent XSS ### Patches This issue has been patched in XWiki 14.10.6 and XWiki 15.1. This issue has been patched on the CKEditor Integration extension 1.64.9 for XWiki version older than 14.6RC1. ### Workarounds The issue can be fixed manually by restricting the `edit` and `delete` rights to a trusted user or group (e.g. the `XWiki.XWikiAdminGroup` group), implicitly disabling those rights for all other users. See https://github.com/xwiki/xwiki-platform/commit/9d9d86179457cb8dc48b4491510537878800be4f ### References - https://jira.xwiki.org/browse/XWIKI-20590 - https://jira.xwiki.org/browse/CKEDITOR-508 - https://github.com/xwiki/xwiki-platform/commit/9d9d86179457cb8dc48b4491510537878800be4f ### For more info...
### Summary There is a permission flaw in the Sealos billing system, which allows users to control the recharge resource account. sealos. io/v1/Payment, resulting in the ability to recharge any amount of 1 RMB. ### Details The reason is that sealos is in arrears. Egg pain, we can't create a terminal anymore. Let's charge for it: Then it was discovered that the charging interface had returned all resource information. Unfortunately, based on previous vulnerability experience, the namespace of this custom resource is still under the current user's control and may have permission to correct it. ### PoC disable by publish ### Impact + sealos public cloud user + CWE-287 Improper Authentication
### Impact Users with capabilities to upload media (editors and above) are succeptible to SSRF (Server-Side Request Forgery) when executing the `createMediaItem` Mutation. Authenticated users making GraphQL requests that execute the `createMediaItem` could pass executable paths in the mutations `filePath` argument that could give them unwarranted access to the server. It's recommended to update to WPGraphQL v1.14.6 or newer. If you're unable to do so, below is a snippet you can add to your functions.php (or similar) that filters the `createMediaItem` mutation's resolver. ### Patches - [v1.14.6](https://github.com/wp-graphql/wp-graphql/releases/tag/v1.14.6) - https://github.com/wp-graphql/wp-graphql/pull/2840 ### Workarounds If you're unable to upgrade to v1.14.6 or higher, you should be able to use the following snippet in your functions.php to override the vulnerable resolver. This snippet has been tested as far back as WPGraphQL v0.15 ```php add_filter( 'graphql_pre_resolv...
### Impact An attacker who uses this vulnerability can craft a PDF which leads to an infinite loop if `__parse_content_stream` is executed. This infinite loop blocks the current process and can utilize a single core of the CPU by 100%. It does not affect memory usage. That is, for example, the case if the user extracted text from such a PDF. Example Code and a PDF that causes the issue: ```python from pypdf import PdfReader # https://objects.githubusercontent.com/github-production-repository-file-5c1aeb/3119517/11367871?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIWNJYAX4CSVEH53A%2F20230627%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20230627T201018Z&X-Amz-Expires=300&X-Amz-Signature=d71c8fd9181c4875f0c04d563b6d32f1d4da6e7b2e6be2f14479ce4ecdc9c8b2&X-Amz-SignedHeaders=host&actor_id=1658117&key_id=0&repo_id=3119517&response-content-disposition=attachment%3Bfilename%3DMiFO_LFO_FEIS_NOA_Published.3.pdf&response-content-type=application%2Fpdf reader = PdfReader("MiFO_LFO_FEIS_NO...
When a Keycloak server is configured to support mTLS authentication for OAuth/OpenID clients, it does not properly verify the client certificate chain. A client that possesses a proper certificate can authorize itself as any other client and therefore access data that belongs to other clients.
AssertionConsumerServiceURL is a Java implementation for SAML Service Providers (org.keycloak.protocol.saml). Affected versions of this package are vulnerable to Cross-site Scripting (XSS). AssertionConsumerServiceURL allows XSS when sending a crafted SAML XML request.
A flaw was found in keycloak-core. This flaw considers the scenario when using X509 Client Certificate Authenticatior with the option "Revalidate Client Certificate". A user may be able to choose, if directly connect to keycloak (not passing via reverse proxy) a specific certificate. If there's a configuration error in KC_SPI_TRUSTSTORE_FILE_FILE the authenticator allows even with the "Cannot validate client certificate trust: Truststore not available" message as there's no certificate to trust against.