ghsa

Grafana is an open-source platform for monitoring and observability. The Grafana Alerting VictorOps integration was not properly protected and could be exposed to users with Viewer permission. Fixed in versions 11.5.0, 11.4.1, 11.3.3, 11.2.6, 11.1.11, 11.0.11 and 10.4.15

A flaw was found in the Wildfly Server Role Based Access Control (RBAC) provider. When authorization to control management operations is secured using the Role Based Access Control provider, a user without the required privileges can suspend or resume the server. A user with a Monitor or Auditor role is supposed to have only read access permissions and should not be able to suspend the server. The vulnerability is caused by the Suspend and Resume handlers not performing authorization checks to validate whether the current user has the required permissions to proceed with the action. ### Impact Standalone server (Domain mode is not affected) with use access control enabled with RBAC provider can be suspended or resumed by unauthorized users. When a server is suspended, the server will stop receiving user requests. The resume handle does the opposite; it will cause a suspended server to start accepting user requests. ### Patches Fixed in [WildFly Core 27.0.1.Final](https://github.com/w...

### Summary While rebuilding [PMD Designer](https://github.com/pmd/pmd-designer) for Reproducible Builds and digging into issues, I found out that passphrase for `gpg.keyname=0xD0BF1D737C9A1C22` is included in jar published to Maven Central. ### Details See https://github.com/jvm-repo-rebuild/reproducible-central/blob/master/content/net/sourceforge/pmd/pmd-designer/README.md I removed 2 lines from https://github.com/jvm-repo-rebuild/reproducible-central/blob/master/content/net/sourceforge/pmd/pmd-designer/pmd-designer-7.0.0.diffoscope but real content is: ``` ├── net/sourceforge/pmd/util/fxdesigner/designer.properties │ @@ -1,14 +1,12 @@ │ #Properties │ checkstyle.plugin.version=3.3.1 │ checkstyle.version=10.14.0 │ -gpg.keyname=0xD0BF1D737C9A1C22 │ -gpg.passphrase=evicx0nuPfvSVhVyeXpw │ jar.plugin.version=3.3.0 │ -java.version=11.0.22 │ +java.version=11.0.25 │ javadoc.plugin.version=3.6.3 │ jflex-output=/home/runner/work/pmd-designer/pmd-designer/target/generated-sources/jflex...

### Impact Lookup tables, whose length is not divisible by `26 = floor(num_routed_wires / 3)` always include the `0 -> 0` input-output pair. Thus a malicious prover can always prove that `f(0) = 0` for any lookup table f (unless its length happens to be divisible by 26). The cause of problem is that the `LookupTableGate`-s are [padded with zeros](https://github.com/0xPolygonZero/plonky2/blob/main/plonky2/src/plonk/prover.rs#L97). The fix is done by padding with an existing table pair, similarly to `LookupGate`. A workaround from the user side is to extend the table (by repeating some entries) so that its length becomes divisible by 26. Fortunately, the seemingly most common use case, namely, hash functions with table-based sbox-es, are not vulnerable: * both Monolith's and Tip5/Tip4's s-box tables already map 0 to 0; * more generally, forcing several (0,0) pairs inside such a hash function appears to be a too strong restriction to find an otherwise valid trace. A malicious prover...

### Impact A vulnerability was discovered in Argo CD that exposed secret values in error messages and the diff view when an invalid Kubernetes Secret resource was synced from a repository. The vulnerability assumes the user has write access to the repository and can exploit it, either intentionally or unintentionally, by committing an invalid Secret to repository and triggering a Sync. Once exploited, any user with read access to Argo CD can view the exposed secret data. ### Patches A patch for this vulnerability is available in the following Argo CD versions: - v2.13.4 - v2.12.10 - v2.11.13 ### Workarounds There is no workaround other than upgrading. ### References Fixed with commit https://github.com/argoproj/argo-cd/commit/6f5537bdf15ddbaa0f27a1a678632ff0743e4107 & https://github.com/argoproj/gitops-engine/commit/7e21b91e9d0f64104c8a661f3f390c5e6d73ddca

### Impact By design, AdmissionPolicy and AdmissionPolicyGroup can evaluate only namespaced resources. The resources to be evaluated are determined by the rules provided by the user when defining the policy. There might be Kubernetes namespaced resources that should not be validated by AdmissionPolicy and by the AdmissionPolicyGroup policies because of their sensitive nature. For example, PolicyReport are namespaced resources that contain the list of non compliant objects found inside of a namespace. See [this section](https://docs.kubewarden.io/explanations/audit-scanner/policy-reports) of Kubewarden’s documentation for more details about PolicyReport resources. An attacker can use either an AdmissionPolicy or an AdmissionPolicyGroup to prevent the creation and update of PolicyReport objects to hide non-compliant resources. Moreover, the same attacker might use a mutating AdmissionPolicy to alter the contents of the PolicyReport created inside of the namespace. ### Patches Starting...

### Impact The [policy group feature](https://docs.kubewarden.io/explanations/policy-groups), added to by the 1.17.0 release, introduced two new types of CRD: ClusterAdmissionPolicyGroup and AdmissionPolicyGroup. The former is cluster wide, while the latter is namespaced. By being namespaced, the AdmissionPolicyGroup has a well constrained impact on cluster resources. Hence, it’s considered safe to allow non-admin users to create and manage these resources in the namespaces they own. Kubewarden policies can be allowed to query the Kubernetes API at evaluation time; these types of policies are called “[context aware](https://docs.kubewarden.io/reference/spec/context-aware-policies)“. Context aware policies can perform list and get operations against a Kubernetes cluster. The queries are done using the ServiceAccount of the Policy Server instance that hosts the policy. That means that access to the cluster is determined by the RBAC rules that apply to that ServiceAccount. The Admission...

### Impact A vulnerable node can be forced to shutdown/crash using a specially crafted message. More in-depth details will be released at a later time. ### Patches A fix has been included in geth version 1.14.13 and onwards. ### Workarounds Unfortunately, no workaround is available. ### Credits This issue was originally reported to Polygon Security by David Matosse (@iam-ned).

### Impact A vulnerability was discovered in Argo CD that exposed secret values in error messages and the diff view when an invalid Kubernetes Secret resource was synced from a repository. The vulnerability assumes the user has write access to the repository and can exploit it, either intentionally or unintentionally, by committing an invalid Secret to repository and triggering a Sync. Once exploited, any user with read access to Argo CD can view the exposed secret data. ### Patches A patch for this vulnerability is available in the following Argo CD versions: - v2.13.4 - v2.12.10 - v2.11.13 ### Workarounds There is no workaround other than upgrading. ### References Fixed with commit https://github.com/argoproj/argo-cd/commit/6f5537bdf15ddbaa0f27a1a678632ff0743e4107 & https://github.com/argoproj/gitops-engine/commit/7e21b91e9d0f64104c8a661f3f390c5e6d73ddca

### Impact We recently underwent Penetration Testing of OpenMRS by a third-party company. **Vulnerabilities were found, and fixes have been made and released.** We've released security updates that include critical fixes, and so, we strongly recommend upgrading affected modules. **This notice applies to _all_ OpenMRS instances.** The testers used the OpenMRS v3 Reference Application (O3 RefApp); however, their findings highlighted modules commonly used in older OpenMRS applications, including the O2 RefApp. ## Vulnerability Details - The issues uncovered included broken access control (e.g. inappropriate admin access), phishing vulnerability, and stored XSS (e.g. vulnerable passwords). - No vulnerabilities were found in the O3 frontend esm modules. - The Letter of Attestation from the penetration test is [available here](https://drive.google.com/file/d/1sBm4-FzLA8hSoM9wYknBfgEttBHyLvoU/view?usp=sharing) for your reference. - After the fixes were applied, the OpenMRS O3 RefApp met ...