GHSA-xch9-h8qw-85c7
Vulnerability from github
Published
2025-10-02 21:15
Modified
2025-10-02 21:15
Summary
Canonical LXD Project Existence Determination Through Error Handling in Image Get Function
Details

Impact

The LXD /1.0/images endpoint is implemented as an AllowUntrusted API that requires no authentication, making it accessible to users without accounts. This API allows determining project existence through differences in HTTP status codes when accessed with the project parameter.

https://github.com/canonical/lxd/blob/43d5189564d27f6161b430ed258c8b56603c2759/lxd/images.go#L63-L69

This configuration allows access without authentication:

https://github.com/canonical/lxd/blob/43d5189564d27f6161b430ed258c8b56603c2759/lxd/daemon.go#L924-L926

This API returns a 404 error when accessing existing projects and a 403 error when accessing non-existent projects, allowing confirmation of project existence through this difference.

The problematic implementation is shown below.

First, in the error handling implementation of the imagesGet function below, project existence is checked within the projectutils.ImageProject function, and the err returned by the ImageProject function is directly returned to the user.

https://github.com/canonical/lxd/blob/43d5189564d27f6161b430ed258c8b56603c2759/lxd/i mages.go#L1781-L1788

When the project doesn't exist, the error is 404 (http.StatusNotFound), which is returned to the user:

https://github.com/canonical/lxd/blob/43d5189564d27f6161b430ed258c8b56603c2759/lxd/db/cluster/projects.mapper.go#L237-L239

On the other hand, when the project exists but the user lacks viewing permissions, the imagesGet function returns 403 (response.Forbidden):

https://github.com/canonical/lxd/blob/43d5189564d27f6161b430ed258c8b56603c2759/lxd/images.go#L1796-L1799

Reproduction Steps

  1. Send the following request without authentication to a non-existent project:

curl -k "https://lxd-host:8443/1.0/images?project=XXX-project"

Response:

json {"type":"error","status":"","status_code":0,"operation":"","error_code":404,"error":"fetch project: Project not found","metadata":null}

  1. Send a request without authentication to an existing project (if a public project exists, it will be included in the response):

curl -k "https://lxd-host:8443/1.0/images?project=exist-project"

Reponse:

{"type":"error","status":"","status_code":0,"operation":"","error_code":403,"error":"Untrusted callers may only access public images in the default project","metadata":null}

Risk

The attack requires only network access to the LXD API endpoint, with no authentication needed.

The attack allows confirming the existence of projects within the LXD system by exploiting differences in HTTP status codes. This could potentially increase the exploitability of othervulnerabilities.

Additionally, since project IDs often use meaningful names set by users, this could lead to leakage of unpublished product information. However, resource information within projects cannot be obtained, limiting the impact to existence confirmation only.

Countermeasures

It is recommended to modify the error handling in the imagesGet function to return consistent responses regardless of project existence. Specifically, when an error occurs during project existence verification, the implementation should be changed to always return a 403 (Untrusted callers may only access public images in the default project) error to unauthenticated users.

This ensures that the same error response is returned for both existing and non-existing projects, preventing determination of project existence.

Patches

| LXD Series | Status | | ------------- | ------------- | | 6 | Fixed in LXD 6.5 | | 5.21 | Fixed in LXD 5.21.4 | | 5.0 | Ignored - Not critical | | 4.0 | Ignored - EOL and not critical |

References

Reported by GMO Flatt Security Inc.

Show details on source website


{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/canonical/lxd"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.0"
            },
            {
              "fixed": "5.21.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/canonical/lxd"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.0"
            },
            {
              "fixed": "6.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/canonical/lxd"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.0.0-20200331193331-03aab09f5b5c"
            },
            {
              "fixed": "0.0.0-20250827065555-0494f5d47e41"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-54291"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-209"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-10-02T21:15:46Z",
    "nvd_published_at": "2025-10-02T10:15:39Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\nThe LXD /1.0/images endpoint is implemented as an AllowUntrusted API that requires no authentication, making it accessible to users without accounts. This API allows determining project existence through differences in HTTP status codes when accessed with the project parameter.\n\n\nhttps://github.com/canonical/lxd/blob/43d5189564d27f6161b430ed258c8b56603c2759/lxd/images.go#L63-L69\n\nThis configuration allows access without authentication:\n\nhttps://github.com/canonical/lxd/blob/43d5189564d27f6161b430ed258c8b56603c2759/lxd/daemon.go#L924-L926\n\nThis API returns a 404 error when accessing existing projects and a 403 error when accessing non-existent projects, allowing confirmation of project existence through this difference.\n\nThe problematic implementation is shown below.\n\nFirst, in the error handling implementation of the imagesGet function below, project existence is checked within the `projectutils.ImageProject` function, and the err returned by the `ImageProject` function is directly returned to the user.\n\n\nhttps://github.com/canonical/lxd/blob/43d5189564d27f6161b430ed258c8b56603c2759/lxd/i mages.go#L1781-L1788\n\nWhen the project doesn\u0027t exist, the error is 404 (http.StatusNotFound), which is\nreturned to the user:\n\nhttps://github.com/canonical/lxd/blob/43d5189564d27f6161b430ed258c8b56603c2759/lxd/db/cluster/projects.mapper.go#L237-L239\n\nOn the other hand, when the project exists but the user lacks viewing permissions, the imagesGet function returns 403 (response.Forbidden):\n\nhttps://github.com/canonical/lxd/blob/43d5189564d27f6161b430ed258c8b56603c2759/lxd/images.go#L1796-L1799\n\n### Reproduction Steps\n1. Send the following request without authentication to a non-existent project:\n\n```\ncurl -k \"https://lxd-host:8443/1.0/images?project=XXX-project\"\n```\n\nResponse:\n\n```json\n{\"type\":\"error\",\"status\":\"\",\"status_code\":0,\"operation\":\"\",\"error_code\":404,\"error\":\"fetch project: Project not found\",\"metadata\":null}\n```\n\n2. Send a request without authentication to an existing project (if a public project exists, it will be included in the response):\n\n```\ncurl -k \"https://lxd-host:8443/1.0/images?project=exist-project\"\n```\n\nReponse:\n\n```\n{\"type\":\"error\",\"status\":\"\",\"status_code\":0,\"operation\":\"\",\"error_code\":403,\"error\":\"Untrusted callers may only access public images in the default project\",\"metadata\":null}\n```\n\n### Risk\nThe attack requires only network access to the LXD API endpoint, with no authentication needed.\n\nThe attack allows confirming the existence of projects within the LXD system by exploiting differences in HTTP status codes. \nThis could potentially increase the exploitability of othervulnerabilities.\n\nAdditionally, since project IDs often use meaningful names set by users, this could lead to leakage of unpublished product information. However, resource information within projects cannot be obtained, limiting the impact to existence confirmation only.\n\n### Countermeasures\nIt is recommended to modify the error handling in the imagesGet function to return consistent responses regardless of project existence. Specifically, when an error occurs during project existence verification, the implementation should be changed to always return a 403 (Untrusted callers may only access public images in the default project) error to unauthenticated users.\n\nThis ensures that the same error response is returned for both existing and non-existing\nprojects, preventing determination of project existence.\n\n### Patches\n\n| LXD Series  | Status |\n| ------------- | ------------- |\n| 6 | Fixed in LXD 6.5  |\n| 5.21 | Fixed in LXD 5.21.4  |\n| 5.0 | Ignored - Not critical |\n| 4.0  | Ignored - EOL and not critical |\n\n### References\nReported by GMO Flatt Security Inc.",
  "id": "GHSA-xch9-h8qw-85c7",
  "modified": "2025-10-02T21:15:46Z",
  "published": "2025-10-02T21:15:46Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/canonical/lxd/security/advisories/GHSA-xch9-h8qw-85c7"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-54291"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/canonical/lxd"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Canonical LXD Project Existence Determination Through Error Handling in Image Get Function"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
  • Patched: This vulnerability was successfully patched by the user reporting the sighting.
  • Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
  • Not confirmed: The user expresses doubt about the veracity of the vulnerability.
  • Not patched: This vulnerability was not successfully patched by the user reporting the sighting.


Loading…