Default status is the baseline for the product, each version can override it (e.g. patched versions marked unaffected).
| Vendor | Product | Default status | Versions | ||||||
|---|---|---|---|---|---|---|---|---|---|
| n/a | n/a | affected |
|
No data.
No data available yet.
| Source | ID | Title |
|---|---|---|
EUVD |
EUVD-2024-52994 | A validation integrity issue was discovered in Fort through 1.6.4 before 2.0.0. RPKI manifests are listings of relevant files that clients are supposed to verify. Assuming everything else is correct, the most recent version of a manifest should be prioritized over other versions, to prevent replays, accidental or otherwise. Manifests contain the manifestNumber and thisUpdate fields, which can be used to gauge the relevance of a given manifest, when compared to other manifests. The former is a serial-like sequential number, and the latter is the date on which the manifest was created. However, the product does not compare the up-to-dateness of the most recently fetched manifest against the cached manifest. As such, it's prone to a rollback to a previous version if it's served a valid outdated manifest. This leads to outdated route origin validation. |
No CVSS v4.0
No CVSS v3.0
No CVSS v2
This CVE is not in the KEV list.
Exploit prediction score: < 1% (0.210% probability within 30 days)
| Link | Providers |
|---|---|
| https://nicmx.github.io/FORT-validator/CVE.html |
|
| Type | Values Removed | Values Added |
|---|---|---|
| Metrics |
epss
|
epss
|
| Type | Values Removed | Values Added |
|---|---|---|
| First Time appeared |
Nicmx
Nicmx fort-validator |
|
| CPEs | cpe:2.3:a:nicmx:fort-validator:*:*:*:*:*:*:*:* | |
| Vendors & Products |
Nicmx
Nicmx fort-validator |
| Type | Values Removed | Values Added |
|---|---|---|
| Weaknesses | CWE-346 | |
| Metrics |
cvssV3_1
|
| Type | Values Removed | Values Added |
|---|---|---|
| Description | A validation integrity issue was discovered in Fort through 1.6.4 before 2.0.0. RPKI manifests are listings of relevant files that clients are supposed to verify. Assuming everything else is correct, the most recent version of a manifest should be prioritized over other versions, to prevent replays, accidental or otherwise. Manifests contain the manifestNumber and thisUpdate fields, which can be used to gauge the relevance of a given manifest, when compared to other manifests. The former is a serial-like sequential number, and the latter is the date on which the manifest was created. However, the product does not compare the up-to-dateness of the most recently fetched manifest against the cached manifest. As such, it's prone to a rollback to a previous version if it's served a valid outdated manifest. This leads to outdated route origin validation. | |
| References |
|