Security
Headlines
HeadlinesLatestCVEs

Source

ghsa

GHSA-c6c3-h4f7-3962: apollo-portal has potential unauthorized access issue

### Impact A vulnerability exists in the synchronization configuration feature that allows users to craft specific requests to bypass permission checks. This exploit enables them to modify a namespace without the necessary permissions. ### Patches The issue was addressed with an input parameter check in #5192, which was released in version [2.3.0](https://github.com/apolloconfig/apollo/releases/tag/v2.3.0). ### Workarounds To mitigate the issue without upgrading, follow the recommended practices to prevent Apollo from being exposed to the internet. ### Credits The vulnerability was reported and reproduced by [Lakeswang](https://github.com/Lakes-bitgetsec). ### References For any questions or comments regarding this advisory: * Open an issue in [issue](https://github.com/apolloconfig/apollo/issues) * Email us at [[email protected]](mailto:[email protected])

ghsa
#vulnerability#google#git#java#auth#maven
GHSA-vhr5-g3pm-49fm: matrix-js-sdk will freeze when a user sets a room with itself as a its predecessor

### Impact A malicious homeserver can craft a room or room structure such that the predecessors form a cycle. The matrix-js-sdk's `getRoomUpgradeHistory` function will infinitely recurse in this case, causing the code to hang. This method is public but also called by the 'leaveRoomChain()' method, so leaving a room will also trigger the bug. Even if the CVSS score would be 4.1 ([AV:N/AC:L/PR:L/UI:R/S:C/C:N/I:N/A:L](https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:N/AC:L/PR:L/UI:R/S:C/C:N/I:N/A:L&version=3.1)) we classify this as High severity issue. ### Patches This was patched in matrix-js-sdk 34.3.1. ### Workarounds Sanity check rooms before passing them to the matrix-js-sdk or avoid calling either `getRoomUpgradeHistory` or `leaveRoomChain`. ### References N/A.

GHSA-mq69-4j5w-3qwp: Capsule tenant owner with "patch namespace" permission can hijack system namespaces

# Attack Vector Then, let me briefly explain the reasons for the errors mentioned above: 1. The 'kubectl edit' command was used to patch the namespace, but this operation requires both 'get' and 'patch' permissions, hence the error. One should use methods like 'curl' to directly send a PATCH request; 2. The webhook does not intercept patch operations on 'kube-system' because 'kube-system' does not have an ownerReference. # Below are my detailed reproduction steps 1. Create a test cluster `kind create cluster --image=kindest/node:v1.24.15 --name=k8s` 2. Install the capsule `helm install capsule projectcapsule/capsule -n capsule-system --create-namespace` 3. Create a tenant ``` kubectl create -f - << EOF apiVersion: capsule.clastix.io/v1beta2 kind: Tenant metadata: name: tenant1 spec: owners: - name: alice kind: User EOF ``` 4. Create user alice ``` ./create-user.sh alice tenant1 capsule.clastix.io export KUBECONFIG=alice-tenant1.kubeconfig ``` 5. Patch kube-system (The first ...

GHSA-hrww-x3fq-xcvh: Umbraco CMS Improper Access Control vulnerability

### Impact As an authenticated user one can access a few unintended endpoints

GHSA-hh8p-374f-qgr5: Grafana plugin data sources vulnerable to access control bypass

Access control for plugin data sources protected by the ReqActions json field of the plugin.json is bypassed if the user or service account is granted associated access to any other data source, as the ReqActions check was not scoped to each specific datasource. The account must have prior query access to the impacted datasource.

GHSA-77gj-crhp-3gvx: Umbraco CMS vulnerable to Generation of Error Message Containing Sensitive Information

### Impact Some endpoints in the Management API can return stack trace information, even when Umbraco is not in debug mode.

GHSA-2fm6-mv57-p2qh: Apache Dolphinscheduler Code Injection vulnerability

Exposure of Remote Code Execution in Apache Dolphinscheduler. This issue affects Apache DolphinScheduler: before 3.2.2. We recommend users to upgrade Apache DolphinScheduler to version 3.2.2, which fixes the issue.

GHSA-9cmq-m9j5-mvww: Spring Framework vulnerable to Denial of Service

In Spring Framework versions 5.3.0 - 5.3.38 and older unsupported versions, it is possible for a user to provide a specially crafted Spring Expression Language (SpEL) expression that may cause a denial of service (DoS) condition. Older, unsupported versions are also affected. Specifically, an application is vulnerable when the following is true: * The application evaluates user-supplied SpEL expressions.

GHSA-hmqf-wpq9-jq83: Spring Security Missing Authorization vulnerability

Missing Authorization When Using @AuthorizeReturnObject in Spring Security 6.3.0 and 6.3.1 allows attacker to render security annotations inaffective.

GHSA-f963-4cq8-2gw7: In XWiki Platform, payloads stored in content is executed when a user with script/programming right edit them

### Impact A user without script/programming right can trick a user with elevated rights to edit a content with a malicious payload using a WYSIWYG editor. The user with elevated rights is not warned beforehand that they are going to edit possibly dangerous content. The payload is executed at edit time. ### Patches This vulnerability has been patched in XWiki 15.10RC1. ### Workarounds No workaround. It is advised to upgrade to XWiki 15.10+. ### References * https://jira.xwiki.org/browse/XWIKI-20331 * https://jira.xwiki.org/browse/XWIKI-21311 * https://jira.xwiki.org/browse/XWIKI-21481 * https://jira.xwiki.org/browse/XWIKI-21482 * https://jira.xwiki.org/browse/XWIKI-21483 * https://jira.xwiki.org/browse/XWIKI-21484 * https://jira.xwiki.org/browse/XWIKI-21485 * https://jira.xwiki.org/browse/XWIKI-21486 * https://jira.xwiki.org/browse/XWIKI-21487 * https://jira.xwiki.org/browse/XWIKI-21488 * https://jira.xwiki.org/browse/XWIKI-21489 * https://jira.xwiki.org/browse/XWIKI-21490 ### ...