ghsa

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

Spring Security 6.4.0 - 6.4.3 may not correctly locate method security annotations on parameterized types or methods. This may cause an authorization bypass.  You are not affected if you are not using @EnableMethodSecurity, or you do not have method security annotations on parameterized types or methods, or all method security annotations are attached to target methods

### Summary A security check that gets called after GraphQl resolvers is always replaced by another one as there's no break in this clause: https://github.com/api-platform/core/pull/6444/files#diff-09e3c2cfe12a2ce65bd6c983c7ca6bfcf783f852b8d0554bb938e8ebf5e5fa65R56 https://github.com/soyuka/core/blob/7e2e8f9ff322ac5f6eb5f65baf432bffdca0fd51/src/Symfony/Security/State/AccessCheckerProvider.php#L49-L57 ### PoC Create a graphql endpoint with a security after resolver. ### Impact As this fallsback to `security`, the impact is there only when there's only a security after resolver and none inside security. The test at https://github.com/api-platform/core/pull/6444 is probably broken.

Affected versions of this crate didn't provide sufficient lifetime constraints to conversion functions from `alloc::sync::Arc` and `alloc::rc::Rc`, which made it possible to create projections of these reference counted pointers. Unlike the original reference counted pointers, these projections could outlive original data's lifetimes. This projected pointer could cause the original `Arc`'s or `Rc`'s `Drop::drop` to get called at a point where the original data was no longer valid, leading to a potential use after free. The affected functions were - `pared::prc::Prc::from_rc` - `pared::prc::Prc::project` - `pared::prc::Prc::try_from_rc` - `pared::sync::Parc::from_arc` - `pared::sync::Parc::project` - `pared::sync::Parc::try_from_arc` This flaw was fixed in [108f540ea8acb6073751a1aa386085c1cdc4fd1e](https://github.com/radekvit/pared/commit/108f540ea8acb6073751a1aa386085c1cdc4fd1e) by requiring that the type stored in the `Arc`s and `Rc`s passed to these functions contain `T: 'static`.

### Summary The [AWS Cloud Development Kit (CDK)](https://aws.amazon.com/cdk/) is an open-source framework for defining cloud infrastructure using code. Users use it to create their own applications, which are converted to AWS CloudFormation templates during deployment to a user's AWS account. AWS CDK contains pre-built components called "constructs," which are higher-level abstractions providing defaults and best practices. This approach enables developers to use familiar programming languages to define complex cloud infrastructure more efficiently than writing raw CloudFormation templates. The [AWS CodePipeline](https://aws.amazon.com/codepipeline/) construct deploys CodePipeline, a managed service that orchestrates software release processes through a series of stages, each comprising one or more actions executed by CodePipeline. To perform these actions, CodePipeline assumes IAM roles with permissions necessary for each step, allowing it to interact with AWS services and resource...