apollographql federation bis 1.52.0/2.8.4 Denial of Service
| CVSS Meta Temp Score | Aktueller Exploitpreis (≈) | CTI Interest Score |
|---|---|---|
| 7.4 | $0-$5k | 0.00 |
Zusammenfassung
Es wurde eine Schwachstelle in apollographql federation bis 1.52.0/2.8.4 gefunden. Sie wurde als kritisch eingestuft. Es betrifft eine unbekannte Funktion. Durch Manipulation mit unbekannten Daten kann eine Denial of Service-Schwachstelle ausgenutzt werden. Diese Verwundbarkeit ist als CVE-2024-43414 gelistet. Der Angriff kann remote ausgeführt werden. Es existiert kein Exploit. Ein Upgrade der betroffenen Komponente wird empfohlen.
Details
Eine Schwachstelle wurde in apollographql federation bis 1.52.0/2.8.4 ausgemacht. Sie wurde als kritisch eingestuft. Dies betrifft eine unbekannte Verarbeitung. Dank der Manipulation mit einer unbekannten Eingabe kann eine Denial of Service-Schwachstelle ausgenutzt werden. Klassifiziert wurde die Schwachstelle durch CWE als CWE-674. Auswirkungen hat dies auf die Verfügbarkeit. Die Zusammenfassung von CVE lautet:
Apollo Federation is an architecture for declaratively composing APIs into a unified graph. Each team can own their slice of the graph independently, empowering them to deliver autonomously and incrementally. Instances of @apollo/query-planner >=2.0.0 and =2.0.0 and < 2.8.5 and Apollo Router <1.52.1 are also impacted through their use of @apollo/query-panner. If @apollo/query-planner is asked to plan a sufficiently complex query, it may loop infinitely and never complete. This results in unbounded memory consumption and either a crash or out-of-memory (OOM) termination. This issue can be triggered if you have at least one non-@key field that can be resolved by multiple subgraphs. To identify these shared fields, the schema for each subgraph must be reviewed. The mechanism to identify shared fields varies based on the version of Federation your subgraphs are using. You can check if your subgraphs are using Federation 1 or Federation 2 by reviewing their schemas. Federation 2 subgraph schemas will contain a @link directive referencing the version of Federation being used while Federation 1 subgraphs will not. For example, in a Federation 2 subgraph, you will find a line like @link(url: "https://specs.apollo.dev/federation/v2.0"). If a similar @link directive is not present in your subgraph schema, it is using Federation 1. Note that a supergraph can contain a mix of Federation 1 and Federation 2 subgraphs. This issue results from the Apollo query planner attempting to use a Number exceeding Javascript’s Number.MAX_VALUE in some cases. In Javascript, Number.MAX_VALUE is (2^1024 - 2^971). When the query planner receives an inbound graphql request, it breaks the query into pieces and for each piece, generates a list of potential execution steps to solve the piece. These candidates represent the steps that the query planner will take to satisfy the pieces of the larger query. As part of normal operations, the query planner requires and calculates the number of possible query plans for the total query. That is, it needs the product of the number of query plan candidates for each piece of the query. Under normal circumstances, after generating all query plan candidates and calculating the number of all permutations, the query planner moves on to stack rank candidates and prune less-than-optimal options. In particularly complex queries, especially those where fields can be solved through multiple subgraphs, this can cause the number of all query plan permutations to balloon. In worst-case scenarios, this can end up being a number larger than Number.MAX_VALUE. In Javascript, if Number.MAX_VALUE is exceeded, Javascript represents the value as “infinity”. If the count of candidates is evaluated as infinity, the component of the query planner responsible for pruning less-than-optimal query plans does not actually prune candidates, causing the query planner to evaluate many orders of magnitude more query plan candidates than necessary. This issue has been addressed in @apollo/query-planner v2.8.5, @apollo/gateway v2.8.5, and Apollo Router v1.52.1. Users are advised to upgrade. This issue can be avoided by ensuring there are no fields resolvable from multiple subgraphs. If all subgraphs are using Federation 2, you can confirm that you are not impacted by ensuring that none of your subgraph schemas use the @shareable directive. If you are using Federation 1 subgraphs, you will need to validate that there are no fields resolvable by multiple subgraphs.Bereitgestellt wird das Advisory unter github.com. Die Verwundbarkeit wird seit dem 12.08.2024 mit der eindeutigen Identifikation CVE-2024-43414 gehandelt. Sie ist leicht auszunutzen. Umgesetzt werden kann der Angriff über das Netzwerk. Das Ausnutzen erfordert keine spezifische Authentisierung. Technische Details oder ein Exploit zur Schwachstelle sind nicht verfügbar. Als Angriffstechnik weist das MITRE ATT&CK Projekt die ID T1499 aus.
Ein Aktualisieren auf die Version 1.52.1 oder 2.8.5 vermag dieses Problem zu lösen.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Produkt
Hersteller
Name
Version
- 1.0
- 1.1
- 1.2
- 1.3
- 1.4
- 1.5
- 1.6
- 1.7
- 1.8
- 1.9
- 1.10
- 1.11
- 1.12
- 1.13
- 1.14
- 1.15
- 1.16
- 1.17
- 1.18
- 1.19
- 1.20
- 1.21
- 1.22
- 1.23
- 1.24
- 1.25
- 1.26
- 1.27
- 1.28
- 1.29
- 1.30
- 1.31
- 1.32
- 1.33
- 1.34
- 1.35
- 1.36
- 1.37
- 1.38
- 1.39
- 1.40
- 1.41
- 1.42
- 1.43
- 1.44
- 1.45
- 1.46
- 1.47
- 1.48
- 1.49
- 1.50
- 1.51
- 1.52.0
- 2.8.0
- 2.8.1
- 2.8.2
- 2.8.3
- 2.8.4
Webseite
CPE 2.3
CPE 2.2
CVSSv4
VulDB Vector: 🔍VulDB Zuverlässigkeit: 🔍
CVSSv3
VulDB Meta Base Score: 7.5VulDB Meta Temp Score: 7.4
VulDB Base Score: 7.5
VulDB Temp Score: 7.2
VulDB Vector: 🔍
VulDB Zuverlässigkeit: 🔍
NVD Base Score: 7.5
NVD Vector: 🔍
CNA Base Score: 7.5
CNA Vector (GitHub_M): 🔍
CVSSv2
| AV | AC | Au | C | I | A |
|---|---|---|---|---|---|
| 💳 | 💳 | 💳 | 💳 | 💳 | 💳 |
| 💳 | 💳 | 💳 | 💳 | 💳 | 💳 |
| 💳 | 💳 | 💳 | 💳 | 💳 | 💳 |
| Vektor | Komplexität | Authentisierung | Vertraulichkeit | Integrität | Verfügbarkeit |
|---|---|---|---|---|---|
| freischalten | freischalten | freischalten | freischalten | freischalten | freischalten |
| freischalten | freischalten | freischalten | freischalten | freischalten | freischalten |
| freischalten | freischalten | freischalten | freischalten | freischalten | freischalten |
VulDB Base Score: 🔍
VulDB Temp Score: 🔍
VulDB Zuverlässigkeit: 🔍
Exploiting
Klasse: Denial of ServiceCWE: CWE-674 / CWE-404
CAPEC: 🔍
ATT&CK: 🔍
Physisch: Nein
Lokal: Nein
Remote: Ja
Verfügbarkeit: 🔍
Status: Nicht definiert
EPSS Score: 🔍
EPSS Percentile: 🔍
Preisentwicklung: 🔍
Aktuelle Preisschätzung: 🔍
| 0-Day | freischalten | freischalten | freischalten | freischalten |
|---|---|---|---|---|
| Heute | freischalten | freischalten | freischalten | freischalten |
Threat Intelligence
Interesse: 🔍Aktive Akteure: 🔍
Aktive APT Gruppen: 🔍
Gegenmassnahmen
Empfehlung: UpgradeStatus: 🔍
0-Day Time: 🔍
Upgrade: federation 1.52.1/2.8.5
Timeline
12.08.2024 🔍27.08.2024 🔍
27.08.2024 🔍
13.09.2024 🔍
Quellen
Produkt: github.comAdvisory: GHSA-fmj9-77q8-g6c4
Status: Bestätigt
CVE: CVE-2024-43414 (🔍)
GCVE (CVE): GCVE-0-2024-43414
GCVE (VulDB): GCVE-100-275957
Eintrag
Erstellt: 27.08.2024 20:59Aktualisierung: 13.09.2024 08:13
Anpassungen: 27.08.2024 20:59 (63), 28.08.2024 15:53 (1), 13.09.2024 08:13 (10)
Komplett: 🔍
Cache ID: 216::103
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Bisher keine Kommentare. Sprachen: de + en.
Bitte loggen Sie sich ein, um kommentieren zu können.