#kubernetes

Security is an ongoing engineering discipline, it's not just a reaction to a crisis. For example, if you were responsible for a large suspension bridge, you would know that cracks don’t appear overnight. They start as small stress fractures, invisible to the untrained eye. If ignored, these weaknesses eventually lead to structural failures. That’s why regular maintenance, checking for early signs of wear, reinforcing weak points, and applying protective coating is crucial.Security vulnerabilities in IT are often presented like bridge failures that make news headlines. These issues require

Version 1.15.1 might feel like a run-of-the-mill new release of cert-manager Operator for Red Hat OpenShift but actually it features more than a few notable enhancements to improve the security posture of your OpenShift clusters. This exciting release improves the overall security posture of your OpenShift clusters, and expands upon your ability to protect your cluster networking communications with TLS certificates managed by cert-manager. The release of Red Hat OpenShift 4.18 emphasises zero trust architecture, and introduces as Technology Preview, the powerful istio-csr agent via cert-manag

About Remote Code Execution – Kubernetes (CVE-2025-1974) vulnerability. An unauthenticated attacker with access to the pod network can achieve arbitrary code execution in the context of the ingress-nginx controller. This can lead to disclosure of Secrets accessible to the controller. In the default installation, the controller can access all Secrets cluster-wide. 🔹 On March 24, […]

A security issue was discovered in Kubernetes where under certain conditions, an unauthenticated attacker with access to the pod network can achieve arbitrary code execution in the context of the ingress-nginx controller. This can lead to 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 attacker-provided data are included in a filename by the ingress-nginx Admission Controller feature, resulting in directory traversal within the container. This could result in denial of service, or when combined with other vulnerabilities, limited disclosure of Secret objects from the cluster.

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.)

### 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...

A set of five critical security shortcomings have been disclosed in the Ingress NGINX Controller for Kubernetes that could result in unauthenticated remote code execution, putting over 6,500 clusters at immediate risk by exposing the component to the public internet. The vulnerabilities (CVE-2025-24513, CVE-2025-24514, CVE-2025-1097, CVE-2025-1098, and CVE-2025-1974 ), assigned a CVSS score of