Source
ghsa
An issue was discovered in Juju that resulted in the leak of the sensitive context ID, which allows a local unprivileged attacker to access other sensitive data or relation accessible to the local charm. A potential exploit where a user can run a bash loop attempting to execute hook tools. If running while another hook is executing, we log an error with the context ID, making it possible for the user to then use that ID in a following call successfully. This means an unprivileged user can access anything available via a hook tool such as config, relation data and secrets.
### Impact This ClusterRole has `*` verbs of `*` resources. If a malicious user can access the worker node which has kubean's deployment, he/she can abuse these excessive permissions to do whatever he/she likes to the whole cluster, resulting in a cluster-level privilege escalation. ### Patches `>=v0.18.0` ### References Reporting by @younaman(Nanzi Yang) https://github.com/kubean-io/kubean/issues/1326
### Impact A malicious registry could return a different digest for a pinned manifest without detection. ### Patches This has been fixed in the v0.7.1 release. ### Workarounds After running a `regclient.ManifestGet`, the returned digest can be compared to the requested digest.
### Impact Some of the recent development by Icinga is, under certain circumstances, susceptible to cross site request forgery. (CSRF) Affected products: * Icinga Web (>=2.12.0) * Icinga DB Web (>=1.0.0) * Icinga Notifications Web (>=0.1.0) * Icinga Web JIRA Integration (>=1.3.0) All affected products, in any version, will be unaffected by this once `icinga-php-library` is upgraded. ### Patches Version 0.10.1 will include a fix for this. It will be published as part of the `icinga-php-library` v0.14.1 release.
Insufficient Session Expiration vulnerability in Apache Airflow Providers FAB. This issue affects Apache Airflow Providers FAB: 1.2.1 (when used with Apache Airflow 2.9.3) and FAB 1.2.0 for all Airflow versions. The FAB provider prevented the user from logging out. * FAB provider 1.2.1 only affected Airflow 2.9.3 (earlier and later versions of Airflow are not affected) * FAB provider 1.2.0 affected all versions of Airflow. Users who run Apache Airflow 2.9.3 are recommended to upgrade to Apache Airflow Providers FAB version 1.2.2 which fixes the issue. Users who run Any Apache Airflow version and have FAB provider 1.2.0 are recommended to upgrade to Apache Airflow Providers FAB version 1.2.2 which fixes the issue. Also upgrading Apache Airflow to latest version available is recommended. Note: Early version of Airflow reference container images of Airflow 2.9.3 and constraint files contained FAB provider 1.2.1 version, but this is fixed in updated versions of the images. Users...
A Server-Side Request Forgery (SSRF) affects Rocket.Chat's Twilio webhook endpoint before version 6.10.1.
APM server logs contain document body from a partially failed bulk index request. For example, in case of unavailable_shards_exception for a specific document, since the ES response line contains the document body, and that APM server logs the ES response line on error, the document is effectively logged.
An incomplete fix for CVE-2023-1625 was found in openstack-heat. Sensitive information may possibly be disclosed through the OpenStack stack abandon command with the hidden feature set to True and the CVE-2023-1625 fix applied.
A flaw was found in Podman. This issue may allow an attacker to create a specially crafted container that, when configured to share the same IPC with at least one other container, can create a large number of IPC resources in /dev/shm. The malicious container will continue to exhaust resources until it is out-of-memory (OOM) killed. While the malicious container's cgroup will be removed, the IPC resources it created are not. Those resources are tied to the IPC namespace that will not be removed until all containers using it are stopped, and one non-malicious container is holding the namespace open. The malicious container is restarted, either automatically or by attacker control, repeating the process and increasing the amount of memory consumed. With a container configured to restart always, such as `podman run --restart=always`, this can result in a memory-based denial of service of the system.
### Summary Reposilite v3.5.10 is affected by an Arbitrary File Upload vulnerability via path traversal in expanding of Javadoc archives. ### Details Reposilite provides support for JavaDocs files, which are archives that contain documentation for artifacts. Specifically, [JavadocEndpoints.kt](https://github.com/dzikoysk/reposilite/blob/68b73f19dc9811ccf10936430cf17f7b0e622bd6/reposilite-backend/src/main/kotlin/com/reposilite/javadocs/infrastructure/JavadocEndpoints.kt#L28) controller allows to expand the javadoc archive into the server's file system and return its content. The problem is in the way how the archives are expanded, specifically how the new filename is created: [JavadocContainerService.kt#L127-L136](https://github.com/dzikoysk/reposilite/blob/68b73f19dc9811ccf10936430cf17f7b0e622bd6/reposilite-backend/src/main/kotlin/com/reposilite/javadocs/JavadocContainerService.kt#L127-L136) ```kotlin jarFile.entries().asSequence().forEach { file -> if (file.isDirectory) { ...