Security
Headlines
HeadlinesLatestCVEs

Source

ghsa

GHSA-3x8x-79m2-3w2w: jackson-databind possible Denial of Service if using JDK serialization to serialize JsonNode

jackson-databind 2.10.x through 2.12.x before 2.12.6 and 2.13.x before 2.13.1 allows attackers to cause a denial of service (2 GB transient heap usage per read) in uncommon situations involving JsonNode JDK serialization.

ghsa
#dos#js#git#java
GHSA-pmhg-cmjc-3875: Ansible Semaphore mishandles authentication

api/auth.go in Ansible Semaphore before 2.8.89 mishandles authentication.

GHSA-47pj-q2vm-46xc: Collection.js vulnerable to Prototype Pollution

Versions of the package collection.js before 6.8.1 are vulnerable to Prototype Pollution via the `extend` function in `Collection.js/dist/node/iterators/extend.js`.

GHSA-gq6w-q6wh-jggc: PHAR deserialization allowing remote code execution

## Description snappy is vulnerable to PHAR deserialization due to a lack of checking on the protocol before passing it into the `file_exists()` function. If an attacker can upload files of any type to the server he can pass in the phar:// protocol to unserialize the uploaded file and instantiate arbitrary PHP objects. This can lead to remote code execution especially when snappy is used with frameworks with documented POP chains like Laravel/Symfony vulnerable developer code. If user can control the output file from the `generateFromHtml()` function, it will invoke deserialization. ## Proof of Concept Install Snappy via composer require `knplabs/knp-snappy`. After that, under snappy directory, create an `index.php` file with this vulnerable code. ```php <?php // index.php // include autoloader require __DIR__ . '/vendor/autoload.php'; // reference the snappy namespace use Knp\Snappy\Pdf; // vulnerable object class VulnerableClass { public $fileName; public $callback; ...

GHSA-r5x6-w42p-jhpp: Cilium eBPF filters may be temporarily removed during agent restart

### Impact When Cilium is started, there is a short period when Cilium eBPF programs are not attached to the host. During this period, the host does not implement any of Cilium's featureset. This can cause disruption to newly established connections during this period due to the lack of Load Balancing, or can cause Network Policy bypass due to the lack of Network Policy enforcement during the window. This vulnerability impacts any Cilium-managed endpoints on the node (such as Kubernetes Pods), as well as the host network namespace (including Host Firewall). ### Patches This vulnerability is fixed by https://github.com/cilium/cilium/pull/24336, included in Cilium 1.13.1 or later. Cilium releases 1.12.x, 1.11.x and earlier are not affected. ### Workarounds There are no known workarounds. ### Acknowledgements The Cilium community has worked together with members of Isovalent to prepare these mitigations. Special thanks to Louis DeLosSantos and Timo Beckers for investigating and fix...

GHSA-8fg8-jh2h-f2hc: Potential network policy bypass when routing IPv6 traffic

## Impact Under specific conditions, Cilium may misattribute the source IP address of traffic to a cluster, identifying external traffic as coming from the host on which Cilium is running. As a consequence, network policies for that cluster might be bypassed, depending on the specific network policies enabled. Only IPv6 traffic is impacted by this vulnerability. This issue only manifests when: * Cilium is routing IPv6 traffic, and * Kube-proxy is used for service handling, and * NodePorts are used to route traffic to pods. IPv6 is disabled by default. Cilium's kube-proxy replacement feature is not affected by this vulnerability. ## Patches The problem has been fixed and is available on versions >=1.11.15, >=1.12.8, >=1.13.1 ## Workarounds Disable IPv6 routing (IPv6 is disabled by default). ## Acknowledgements The Cilium community has worked together with members of Isovalent to prepare these mitigations. Special thanks to Yusuke Suzuki for both highlighting and fixing the issu...

GHSA-4hc4-pgfx-3mrx: cilium-agent container can access the host via `hostPath` mount

### Impact An attacker with access to a Cilium agent pod can write to `/opt/cni/bin` due to a `hostPath` mount of that directory in the agent pod. By replacing the CNI binary with their own malicious binary and waiting for the creation of a new pod on the node, the attacker can gain access to the underlying node. ### Patches The issue has been fixed and is available on versions >=1.11.15, >=1.12.8, >=1.13.1. ### Workarounds [Kubernetes RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) should be used to deny users and service accounts `exec` access to Cilium agent pods. In cases where a user requires `exec` access to Cilium agent pods, but should not have access to the underlying node, no workaround is possible. ### References * [PR containing resolution](https://github.com/cilium/cilium/pull/24075) ### Acknowledgements The Cilium community has worked together with members of Isovalent and Form3 to prepare these mitigations. Special thanks to Anastasios Kou...

GHSA-xc9p-r5qj-8xm9: Improper quoting of columns when calling methods "getByUuid" & "exists" on UUID Model

### Impact The quoting is not done properly in UUID DAO model, so there's the theoretical possibility to inject custom SQL if the developer is using this methods with input data and not doing proper input validation in advance and so relies on the auto-quoting being done by the DAO class. ### Patches Update to version 10.5.19 or apply this patch manually https://github.com/pimcore/pimcore/commit/08e7ba56ae983c3c67ec563b6989b16ef8f35275.patch ### Workarounds Apply https://github.com/pimcore/pimcore/commit/08e7ba56ae983c3c67ec563b6989b16ef8f35275.patch manually. ### References #14633

GHSA-x5j3-mq9g-8jc8: Cross-site Scripting (XSS) in UrlSlug Data type

### Impact An attacker can use XSS to send a malicious script to an unsuspecting user. ### Patches Update to version 10.5.19 or apply this patch manually https://github.com/pimcore/pimcore/pull/14669.patch ### Workarounds Apply https://github.com/pimcore/pimcore/pull/14669.patch manually. ### References https://huntr.dev/bounties/fa77d780-9b23-404b-8c44-12108881d11a

GHSA-vq59-5x26-h639: Authorization Bypass Through User-Controlled Key play-with-docker

Impact Give that CORS configuration was not correct, an attacker could use [play-with-docker.com](http://play-with-docker.com/) as an example, set origin header in http request as [evil-play-with-docker.com](http://evil-play-with-docker.com/), it will be echo in response header, which successfully bypass the CORS policy and retrieves basic user information. Patches It has been fixed in lastest version, Please upgrade to latest version Workarounds No, users have to upgrade version.