Source
ghsa
If you are using the `eks.Cluster` or `eks.FargateCluster` construct we need you to take action. Other users are not affected and can stop reading. ### Impact The AWS Cloud Development Kit (CDK) allows for the definition of Amazon Elastic Container Service for Kubernetes (EKS) clusters. `eks.Cluster` and `eks.FargateCluster` constructs create two roles that have an overly permissive trust policy. The first, referred to as the _CreationRole_, is used by lambda handlers to create the cluster and deploy Kubernetes resources (e.g `KubernetesManifest`, `HelmChart`, ...) onto it. Users with CDK version higher or equal to [1.62.0](https://github.com/aws/aws-cdk/releases/tag/v1.62.0) (including v2 users) will be affected. The second, referred to as the _default MastersRole_, is provisioned only if the `mastersRole` property isn't provided and has permissions to execute `kubectl` commands on the cluster. Users with CDK version higher or equal to [1.57.0](https://github.com/aws/aws-cdk/...
Jenkins Team Concert Plugin 2.4.1 and earlier does not perform permission checks in methods implementing form validation. This allows attackers with Overall/Read permission to check for the existence of an attacker-specified file path on the Jenkins controller file system. Team Concert Plugin 2.4.2 requires Overall/Administer permission for the affected form validation methods.
### Impact When the `verifyMultiProof`, `verifyMultiProofCalldata`, `processMultiProof`, or `processMultiProofCalldata` functions are in use, it is possible to construct merkle trees that allow forging a valid multiproof for an arbitrary set of leaves. A contract may be vulnerable if it uses multiproofs for verification and the merkle tree that is processed includes a node with value 0 at depth 1 (just under the root). This could happen inadvertently for balanced trees with 3 leaves or less, if the leaves are not hashed. This could happen deliberately if a malicious tree builder includes such a node in the tree. A contract is not vulnerable if it uses single-leaf proving (`verify`, `verifyCalldata`, `processProof`, or `processProofCalldata`), or if it uses multiproofs with a known tree that has hashed leaves. Standard merkle trees produced or validated with the [@openzeppelin/merkle-tree](https://github.com/OpenZeppelin/merkle-tree) library are safe. ### Patches The problem has be...
In Apache Airflow, some potentially sensitive values were being shown to the user in certain situations. This vulnerability is mitigated by the fact configuration is not shown in the UI by default (only if `[webserver] expose_config` is set to `non-sensitive-only`), and not all uncensored values are actually sentitive. This issue affects Apache Airflow: from 2.5.0 before 2.6.2. Users are recommended to update to version 2.6.2 or later.
JeecgBoot up to v 3.5.1 was discovered to contain a SQL injection vulnerability via the component `queryFilterTableDictInfo` in method `org.jeecg.modules.api.controller.SystemApiController`.
JeecgBoot up to v 3.5.1 was discovered to contain a SQL injection vulnerability via the component `queryTableDictItemsByCode` in method `org.jeecg.modules.api.controller.SystemApiController`.
### Duplicate Advisory This advisory has been withdrawn because it is a duplicate of GHSA-wm5g-p99q-66g4. This link is maintained to preserve external references. ### Original Description _joinPath in elFinderVolumeLocalFileSystem.class.php in elFinder before 2.1.62 allows path traversal in the PHP LocalVolumeDriver connector.
Solon before 2.3.3 allows Deserialization of Untrusted Data.
Whaleal IceFrog v1.1.8 component Aviator Template Engine is vulnerable to deserialization of untrusted data. The application deserializes untrusted data without sufficiently verifying that the resulting data will be valid.
### Context Content Security Policies (CSP) are a defense-in-depth strategy against XSS attacks. Improper application of CSP isn't itself a vulnerability, but it does fail to prevent XSS in the event that there is a viable attack vector for an XSS attack. ### Impact There aren't any XSS attack vectors via the Apollo Server landing pages _known to Apollo_, so to our knowledge there is no impact. However, if there are existing XSS vectors that haven't been reported and patched, then all users of Apollo Server's landing pages have a vulnerability which won't be prevented by the current CSP implemented by the landing pages. ### Patches The issue is patched in the latest version of Apollo Server, v4.7.4. ### Workarounds The landing page can be disabled completely until the patch can be upgraded to. https://www.apollographql.com/docs/apollo-server/api/plugin/landing-pages/#disabling-the-landing-page ### References https://content-security-policy.com/nonce/