ghsa

A security issue was discovered in [ingress-nginx](https://github.com/kubernetes/ingress-nginx) where the `auth-tls-match-cn` Ingress annotation can be used to inject configuration into nginx. This can lead to arbitrary code execution in the context of the ingress-nginx controller, and disclosure of Secrets accessible to the controller. (Note that in the default installation, the controller can access all Secrets cluster-wide.)

A security issue was discovered in [ingress-nginx](https://github.com/kubernetes/ingress-nginx) where the `mirror-target` and `mirror-host` Ingress annotations can be used to inject arbitrary configuration into nginx. This can lead to arbitrary code execution in the context of the ingress-nginx controller, and disclosure of Secrets accessible to the controller. (Note that in the default installation, the controller can access all Secrets cluster-wide.)

A security issue was discovered in [ingress-nginx](https://github.com/kubernetes/ingress-nginx) where the `auth-url` Ingress annotation can be used to inject configuration into nginx. This can lead to arbitrary code execution in the context of the ingress-nginx controller, and disclosure of Secrets accessible to the controller. (Note that in the default installation, the controller can access all Secrets cluster-wide.)

An issue in the Shiro-based RBAC (Role-based Access Control) mechanism of OpenDaylight Service Function Chaining (SFC) Subproject SFC Sodium-SR4 and below allows attackers to execute privileged operations via a crafted request.

Insecure Shiro cookie configurations in OpenDaylight Service Function Chaining (SFC) Subproject SFC Sodium-SR4 and below allow attackers to access sensitive information via a man-in-the-middle attack.

Use of incorrectly resolved name or reference in OpenDaylight Service Function Chaining (SFC) Subproject SFC Sodium-SR4 and below allows attackers to cause a Denial of Service (DoS).

Prior to version 0.10.3, the built-in clients of the `web-push` crate eagerly allocated memory based on the `Content-Length` header returned by the Web Push endpoint. Malicious Web Push endpoints could return a large `Content-Length` without ever having to send as much data, leading to denial of service by memory exhaustion. Services providing Web Push notifications typically allow the user to register an arbitrary endpoint, so the endpoint should not be trusted. The fixed version 0.10.3 now limits the amount of memory it will allocate for each response, limits the amount of data it will read from the endpoint, and returns an error if the endpoint sends too much data. As before, it is recommended that services add a timeout for each request to Web Push endpoints.

### Impact [Node based network policies](https://docs.cilium.io/en/stable/security/policy/language/#node-based) (`fromNodes` and `toNodes`) will incorrectly permit traffic to/from non-node endpoints that share the labels specified in `fromNodes` and `toNodes` sections of network policies. Node based network policy is disabled by default in Cilium. ### Patches This issue was fixed by https://github.com/cilium/cilium/pull/36657. This issue affects: - Cilium v1.16 between v1.16.0 and v1.16.7 inclusive - Cilium v1.17 between v1.17.0 and v1.17.1 inclusive This issue is fixed in: - Cilium v1.16.8 - Cilium v1.17.2 ### Workarounds Users can work around this issue by ensuring that the labels used in `fromNodes` and `toNodes` fields are used exclusively by nodes and not by other endpoints. ### Acknowledgements The Cilium community has worked together with members of Isovalent to prepare these mitigations. Special thanks to @oblazek for reporting and fixing this issue. ### For more i...

### Summary Kyverno ignores subjectRegExp and IssuerRegExp while verifying artifact's sign with keyless mode. It allows the attacker to deploy kubernetes resources with the artifacts that were signed by unexpected certificate. ### Details Kyverno checks only subject and issuer fields when verifying an artifact's signature: https://github.com/Mohdcode/kyverno/blob/373f942ea9fa8b63140d0eb0e101b9a5f71033f3/pkg/cosign/cosign.go#L537. While there are subjectRegExp and issuerRegExp fields that can also be used for the defining expected subject and issue values. If the last ones are used then their values are not taken in count and there is no actually restriction for the certificate that was used for the image sign. ### PoC For the successful exploitation attacker needs: - Private key of any certificate in the certificate chain that trusted by cosign. It can be certificate that signed by company's self-signed Root CA if they are using their own PKI. - Access to container registry to push...

### Impact For Cilium users who: - Use Gateway API for Ingress for some services **AND** - Use [LB-IPAM](https://docs.cilium.io/en/stable/network/lb-ipam/) or BGP for LB Service implementation **AND** - Use network policies to block egress traffic from workloads in a namespace to workloads in other namespaces Egress traffic from workloads covered by such network policies to LoadBalancers configured by `Gateway` resources will incorrectly be allowed. LoadBalancer resources not deployed via a Gateway API configuration are not affected by this issue. ### Patches This issue was fixed by https://github.com/cilium/proxy/pull/1172. This issue affects: - Cilium v1.15 between v1.15.0 and v1.15.14 inclusive - Cilium v1.16 between v1.16.0 and v1.16.7 inclusive - Cilium v1.17 between v1.17.0 and v1.17.1 inclusive This issue is fixed in: - Cilium v1.15.15 - Cilium v1.16.8 - Cilium v1.17.2 ### Workarounds A Clusterwide Cilium Network Policy can be used to work around this issue for users ...