Overview 4 matches · 0 in Waratek scope · 0 protected · 0 exploited · 0 CISA KEV · 0 public PoC · 0 EPSS ≥ 0.5
4matches
0in Waratek scope0.0%
0protected0.0%
0exploited0.0%
0CISA KEV0.0%
0public PoC0.0%
0EPSS ≥ 0.50.0%
Protected by Waratek
0
0.0%
Rule in development
0
0.0%
Mitigation candidate
0
0.0%
No exploit published
0
0.0%
Outside Waratek scope
0
0.0%
Not applicable
4
100.0%
Withdrawn CVE
0
0.0%
blocked by ARMR today
0
0.0%
partly blocked
0
0.0%
not blocked
4
100.0%
not established
0
0.0%
unrecorded
0
0.0%
Exploited
0
0.0%
Working exploit published
0
0.0%
Proof of concept only
0
0.0%
Forecast only
0
0.0%
No public exploit
4
100.0%
| CVE | Severity | Published▾ | Status | Exploitation | Description |
|---|---|---|---|---|---|
| CVE-2023-38495 | Critical | 2023-07-27 | Not applicable | No public exploit | Crossplane is a framework for building cloud native control planes without needing to write code. In versions prior to 1.11.5, 1.12.3, and 1.13.0, Crossplane's image backend does not validate the byte contents of Crossplane packages. As such, Crossplane does not detect if an attacker has tampered with a Package. The problem has been fixed in 1.11.5, 1.12.3 and 1.13.0. As a workaround, only use images from trusted sources and keep Package editing/creating privileges to administrators only. |
| CVE-2023-37900 | Low | 2023-07-27 | Not applicable | No public exploit | Crossplane is a framework for building cloud native control planes without needing to write code. In versions prior to 1.11.5, 1.12.3, and 1.13.0, a high-privileged user could create a Package referencing an arbitrarily large image containing that Crossplane would then parse, possibly resulting in exhausting all the available memory and therefore in the container being OOMKilled. The impact is limited due to the high privileges required to be able to create the Package and the eventually consistency nature of controller. This issue is fixed in versions 1.11.5, 1.12.3, and 1.13.0. |
| CVE-2021-27099 | Medium | 2021-03-05 | Not applicable | No public exploit | In SPIRE before versions 0.8.5, 0.9.4, 0.10.2, 0.11.3 and 0.12.1, the "aws_iid" Node Attestor improperly normalizes the path provided through the agent ID templating feature, which may allow the issuance of an arbitrary SPIFFE ID within the same trust domain, if the attacker controls the value of an EC2 tag prior to attestation, and the attestor is configured for agent ID templating where the tag value is the last element in the path. This issue has been fixed in SPIRE versions 0.11.3 and 0.12.1 |
| CVE-2021-27098 | High | 2021-03-05 | Not applicable | No public exploit | In SPIRE 0.8.1 through 0.8.4 and before versions 0.9.4, 0.10.2, 0.11.3 and 0.12.1, specially crafted requests to the FetchX509SVID RPC of SPIRE Server’s Legacy Node API can result in the possible issuance of an X.509 certificate with a URI SAN for a SPIFFE ID that the agent is not authorized to distribute. Proper controls are in place to require that the caller presents a valid agent certificate that is already authorized to issue at least one SPIFFE ID, and the requested SPIFFE ID belongs to the same trust domain, prior to being able to trigger this vulnerability. This issue has been fixed in SPIRE versions 0.8.5, 0.9.4, 0.10.2, 0.11.3 and 0.12.1. |