GHSA-M77F-652Q-WWP4

Vulnerability from github – Published: 2022-09-15 03:25 – Updated: 2022-09-19 19:22
VLAI
Summary
axum-core has no default limit put on request bodies
Details

<bytes::Bytes as axum_core::extract::FromRequest>::from_request would not, by default, set a limit for the size of the request body. That meant if a malicious peer would send a very large (or infinite) body your server might run out of memory and crash.

This also applies to these extractors which used Bytes::from_request internally: - axum::extract::Form - axum::extract::Json - String

The fix is also in axum-core 0.3.0.rc.2 but 0.3.0.rc.1 is vulnerable.

Because axum depends on axum-core it is vulnerable as well. The vulnerable versions of axum are <= 0.5.15 and 0.6.0.rc.1. axum >= 0.5.16 and >= 0.6.0.rc.2 does have the fix and are not vulnerable.

The patched versions will set a 2 MB limit by default.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "axum-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.2.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "axum-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.3.0-rc.1"
            },
            {
              "fixed": "0.3.0-rc.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "0.3.0-rc.1"
      ]
    }
  ],
  "aliases": [
    "CVE-2022-3212"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-770"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-09-15T03:25:15Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "`\u003cbytes::Bytes as axum_core::extract::FromRequest\u003e::from_request` would not, by default, set a limit for the size of the request body. That meant if a malicious peer would send a very large (or infinite) body your server might run out of memory and crash.\n\nThis also applies to these extractors which used `Bytes::from_request` internally:\n- `axum::extract::Form`\n- `axum::extract::Json`\n- `String`\n\nThe fix is also in `axum-core` `0.3.0.rc.2` but `0.3.0.rc.1` _is_ vulnerable.\n\nBecause `axum` depends on `axum-core` it is vulnerable as well. The vulnerable versions of `axum` are `\u003c= 0.5.15` and `0.6.0.rc.1`. `axum` `\u003e= 0.5.16` and `\u003e= 0.6.0.rc.2` does have the fix and are not vulnerable.\n\nThe patched versions will set a 2 MB limit by default.\n",
  "id": "GHSA-m77f-652q-wwp4",
  "modified": "2022-09-19T19:22:47Z",
  "published": "2022-09-15T03:25:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-3212"
    },
    {
      "type": "WEB",
      "url": "https://github.com/tokio-rs/axum/pull/1346"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/tokio-rs/axum"
    },
    {
      "type": "WEB",
      "url": "https://rustsec.org/advisories/RUSTSEC-2022-0055.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "axum-core has no default limit put on request bodies"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.



Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.