ghsa

Craft CMS through 4.4.9 is vulnerable to HTML Injection.

Cross Site Scripting vulnerability in khodakhah NodCMS v.3.0 allows an attacker with administrative privileges to execute arbitrary code and gain access to sensitive information via a crafted script to the address parameter.

Cross Site Scripting vulnerability in YiiCMS v.1.2.0 and prior allows a remote attacker to execute arbitrary code via the news function. A fix is available at commit 4a9d68564eb78d9f64e3f5dd77186a154093615b.

File Upload vulnerability in liufee CMS v.2.0.7.1 allows a remote attacker to execute arbitrary code via the image suffix function.

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 `queryTableDictItemsByCode` 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 `queryFilterTableDictInfo` in method `org.jeecg.modules.api.controller.SystemApiController`.