Vulnerability-Lookup

CVE-2026-32638 (GCVE-0-2026-32638)

Vulnerability from cvelistv5 – Published: 2026-03-18 20:41 – Updated: 2026-03-19 15:01

Title

StudioCMS REST getUsers Exposes Owner Account Records to Admin Tokens

Summary

StudioCMS is a server-side-rendered, Astro native, headless content management system. Prior to 0.4.4, the REST API `getUsers` endpoint in StudioCMS uses the attacker-controlled `rank` query parameter to decide whether owner accounts should be filtered from the result set. As a result, an admin token can request `rank=owner` and receive owner account records, including IDs, usernames, display names, and email addresses, even though the adjacent `getUser` endpoint correctly blocks admins from viewing owner users. This is an authorization inconsistency inside the same user-management surface. Version 0.4.4 fixes the issue.

Severity

2.7 (Low)


                        
                          CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:N

SSVC

Exploitation: poc Automatable: no Technical Impact: partial

CISA Coordinator · CISA-ADP (v2.0.3)

Decision recorded 2026-03-19 15:00 UTC

CWE

CWE-639 - Authorization Bypass Through User-Controlled Key

Assigner

GitHub_M CNA under the mitre root

CNA scorecard C 72/100 over 7868 records in the last 180 days details

References

3 references

URL	Tags
https://github.com/withstudiocms/studiocms/securi…	x_refsource_CONFIRM
https://github.com/withstudiocms/studiocms/commit…	x_refsource_MISC
https://github.com/withstudiocms/studiocms/releas…	x_refsource_MISC

Impacted products

1 product

Vendor	Product	Version	CPE status
withstudiocms	studiocms	Affected: < 0.4.4	guessed

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-32638",
                "options": [
                  {
                    "Exploitation": "poc"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-03-19T15:00:04.391194Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-03-19T15:01:00.396Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "studiocms",
          "vendor": "withstudiocms",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 0.4.4"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "StudioCMS is a server-side-rendered, Astro native, headless content management system. Prior to 0.4.4, the REST API `getUsers` endpoint in StudioCMS uses the attacker-controlled `rank` query parameter to decide whether owner accounts should be filtered from the result set. As a result, an admin token can request `rank=owner` and receive owner account records, including IDs, usernames, display names, and email addresses, even though the adjacent `getUser` endpoint correctly blocks admins from viewing owner users. This is an authorization inconsistency inside the same user-management surface. Version 0.4.4 fixes the issue."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "NETWORK",
            "availabilityImpact": "NONE",
            "baseScore": 2.7,
            "baseSeverity": "LOW",
            "confidentialityImpact": "LOW",
            "integrityImpact": "NONE",
            "privilegesRequired": "HIGH",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:N",
            "version": "3.1"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-639",
              "description": "CWE-639: Authorization Bypass Through User-Controlled Key",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-03-18T20:41:14.034Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/withstudiocms/studiocms/security/advisories/GHSA-xvf4-ch4q-2m24",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/withstudiocms/studiocms/security/advisories/GHSA-xvf4-ch4q-2m24"
        },
        {
          "name": "https://github.com/withstudiocms/studiocms/commit/aebe8bcb3618bb07c6753e3f5c982c1fe6adea64",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/withstudiocms/studiocms/commit/aebe8bcb3618bb07c6753e3f5c982c1fe6adea64"
        },
        {
          "name": "https://github.com/withstudiocms/studiocms/releases/tag/studiocms@0.4.4",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/withstudiocms/studiocms/releases/tag/studiocms@0.4.4"
        }
      ],
      "source": {
        "advisory": "GHSA-xvf4-ch4q-2m24",
        "discovery": "UNKNOWN"
      },
      "title": "StudioCMS REST getUsers Exposes Owner Account Records to Admin Tokens"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2026-32638",
    "datePublished": "2026-03-18T20:41:14.034Z",
    "dateReserved": "2026-03-12T15:29:36.560Z",
    "dateUpdated": "2026-03-19T15:01:00.396Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "epss": {
      "cve": "CVE-2026-32638",
      "date": "2026-11-15",
      "epss": "0.00422",
      "percentile": "0.37058"
    },
    "nvd": {
      "cve": {
        "affected": [
          {
            "affectedData": [
              {
                "product": "studiocms",
                "vendor": "withstudiocms",
                "versions": [
                  {
                    "status": "affected",
                    "version": "\u003c 0.4.4"
                  }
                ]
              }
            ],
            "source": "security-advisories@github.com"
          }
        ],
        "configurations": [
          {
            "nodes": [
              {
                "cpeMatch": [
                  {
                    "criteria": "cpe:2.3:a:studiocms:studiocms:*:*:*:*:*:*:*:*",
                    "matchCriteriaId": "EF77B4D2-70E1-4F62-AE18-5726017098A2",
                    "versionEndExcluding": "0.4.4",
                    "vulnerable": true
                  }
                ],
                "negate": false,
                "operator": "OR"
              }
            ]
          }
        ],
        "cveTags": [],
        "descriptions": [
          {
            "lang": "en",
            "value": "StudioCMS is a server-side-rendered, Astro native, headless content management system. Prior to 0.4.4, the REST API `getUsers` endpoint in StudioCMS uses the attacker-controlled `rank` query parameter to decide whether owner accounts should be filtered from the result set. As a result, an admin token can request `rank=owner` and receive owner account records, including IDs, usernames, display names, and email addresses, even though the adjacent `getUser` endpoint correctly blocks admins from viewing owner users. This is an authorization inconsistency inside the same user-management surface. Version 0.4.4 fixes the issue."
          },
          {
            "lang": "es",
            "value": "StudioCMS es un sistema de gesti\u00f3n de contenido sin cabeza, nativo de Astro y renderizado en el lado del servidor. Antes de la versi\u00f3n 0.4.4, el endpoint `getUsers` de la API REST en StudioCMS utiliza el par\u00e1metro de consulta `rank` controlado por el atacante para decidir si las cuentas de propietario deben filtrarse del conjunto de resultados. Como resultado, un token de administrador puede solicitar `rank=owner` y recibir registros de cuentas de propietario, incluyendo IDs, nombres de usuario, nombres para mostrar y direcciones de correo electr\u00f3nico, a pesar de que el endpoint adyacente `getUser` bloquea correctamente a los administradores para que no vean a los usuarios propietarios. Esto es una inconsistencia de autorizaci\u00f3n dentro de la misma superficie de gesti\u00f3n de usuarios. La versi\u00f3n 0.4.4 soluciona el problema."
          }
        ],
        "id": "CVE-2026-32638",
        "lastModified": "2026-06-17T10:36:08.737",
        "metrics": {
          "cvssMetricV31": [
            {
              "cvssData": {
                "attackComplexity": "LOW",
                "attackVector": "NETWORK",
                "availabilityImpact": "NONE",
                "baseScore": 2.7,
                "baseSeverity": "LOW",
                "confidentialityImpact": "LOW",
                "integrityImpact": "NONE",
                "privilegesRequired": "HIGH",
                "scope": "UNCHANGED",
                "userInteraction": "NONE",
                "vectorString": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:N",
                "version": "3.1"
              },
              "exploitabilityScore": 1.2,
              "impactScore": 1.4,
              "source": "security-advisories@github.com",
              "type": "Secondary"
            }
          ],
          "ssvcV203": [
            {
              "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
              "ssvcData": {
                "id": "CVE-2026-32638",
                "options": [
                  {
                    "exploitation": "poc"
                  },
                  {
                    "automatable": "no"
                  },
                  {
                    "technicalImpact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-03-19T15:00:04.391194Z",
                "version": "2.0.3"
              }
            }
          ]
        },
        "published": "2026-03-18T21:16:26.770",
        "references": [
          {
            "source": "security-advisories@github.com",
            "tags": [
              "Patch"
            ],
            "url": "https://github.com/withstudiocms/studiocms/commit/aebe8bcb3618bb07c6753e3f5c982c1fe6adea64"
          },
          {
            "source": "security-advisories@github.com",
            "tags": [
              "Product",
              "Release Notes"
            ],
            "url": "https://github.com/withstudiocms/studiocms/releases/tag/studiocms@0.4.4"
          },
          {
            "source": "security-advisories@github.com",
            "tags": [
              "Exploit",
              "Mitigation",
              "Vendor Advisory"
            ],
            "url": "https://github.com/withstudiocms/studiocms/security/advisories/GHSA-xvf4-ch4q-2m24"
          }
        ],
        "sourceIdentifier": "security-advisories@github.com",
        "vulnStatus": "Analyzed",
        "weaknesses": [
          {
            "description": [
              {
                "lang": "en",
                "value": "CWE-639"
              }
            ],
            "source": "security-advisories@github.com",
            "type": "Secondary"
          }
        ]
      }
    },
    "redhat_vex": {
      "current_release_date": "2026-03-27T07:40:38+00:00",
      "cve": "CVE-2026-32638",
      "id": "CVE-2026-32638",
      "initial_release_date": "2026-01-01T00:00:00+00:00",
      "product_status:known_not_affected": "1",
      "source": "Red Hat CSAF VEX",
      "status": "final",
      "title": "StudioCMS REST getUsers Exposes Owner Account Records to Admin Tokens",
      "url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-32638.json",
      "version": "3"
    },
    "vulnrichment": {
      "containers": {
        "adp": [
          {
            "metrics": [
              {
                "other": {
                  "content": {
                    "id": "CVE-2026-32638",
                    "options": [
                      {
                        "Exploitation": "poc"
                      },
                      {
                        "Automatable": "no"
                      },
                      {
                        "Technical Impact": "partial"
                      }
                    ],
                    "role": "CISA Coordinator",
                    "timestamp": "2026-03-19T15:00:04.391194Z",
                    "version": "2.0.3"
                  },
                  "type": "ssvc"
                }
              }
            ],
            "providerMetadata": {
              "dateUpdated": "2026-03-19T15:00:55.453Z",
              "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
              "shortName": "CISA-ADP"
            },
            "title": "CISA ADP Vulnrichment"
          }
        ],
        "cna": {
          "affected": [
            {
              "product": "studiocms",
              "vendor": "withstudiocms",
              "versions": [
                {
                  "status": "affected",
                  "version": "\u003c 0.4.4"
                }
              ]
            }
          ],
          "descriptions": [
            {
              "lang": "en",
              "value": "StudioCMS is a server-side-rendered, Astro native, headless content management system. Prior to 0.4.4, the REST API `getUsers` endpoint in StudioCMS uses the attacker-controlled `rank` query parameter to decide whether owner accounts should be filtered from the result set. As a result, an admin token can request `rank=owner` and receive owner account records, including IDs, usernames, display names, and email addresses, even though the adjacent `getUser` endpoint correctly blocks admins from viewing owner users. This is an authorization inconsistency inside the same user-management surface. Version 0.4.4 fixes the issue."
            }
          ],
          "metrics": [
            {
              "cvssV3_1": {
                "attackComplexity": "LOW",
                "attackVector": "NETWORK",
                "availabilityImpact": "NONE",
                "baseScore": 2.7,
                "baseSeverity": "LOW",
                "confidentialityImpact": "LOW",
                "integrityImpact": "NONE",
                "privilegesRequired": "HIGH",
                "scope": "UNCHANGED",
                "userInteraction": "NONE",
                "vectorString": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:N",
                "version": "3.1"
              }
            }
          ],
          "problemTypes": [
            {
              "descriptions": [
                {
                  "cweId": "CWE-639",
                  "description": "CWE-639: Authorization Bypass Through User-Controlled Key",
                  "lang": "en",
                  "type": "CWE"
                }
              ]
            }
          ],
          "providerMetadata": {
            "dateUpdated": "2026-03-18T20:41:14.034Z",
            "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
            "shortName": "GitHub_M"
          },
          "references": [
            {
              "name": "https://github.com/withstudiocms/studiocms/security/advisories/GHSA-xvf4-ch4q-2m24",
              "tags": [
                "x_refsource_CONFIRM"
              ],
              "url": "https://github.com/withstudiocms/studiocms/security/advisories/GHSA-xvf4-ch4q-2m24"
            },
            {
              "name": "https://github.com/withstudiocms/studiocms/commit/aebe8bcb3618bb07c6753e3f5c982c1fe6adea64",
              "tags": [
                "x_refsource_MISC"
              ],
              "url": "https://github.com/withstudiocms/studiocms/commit/aebe8bcb3618bb07c6753e3f5c982c1fe6adea64"
            },
            {
              "name": "https://github.com/withstudiocms/studiocms/releases/tag/studiocms@0.4.4",
              "tags": [
                "x_refsource_MISC"
              ],
              "url": "https://github.com/withstudiocms/studiocms/releases/tag/studiocms@0.4.4"
            }
          ],
          "source": {
            "advisory": "GHSA-xvf4-ch4q-2m24",
            "discovery": "UNKNOWN"
          },
          "title": "StudioCMS REST getUsers Exposes Owner Account Records to Admin Tokens"
        }
      },
      "cveMetadata": {
        "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "assignerShortName": "GitHub_M",
        "cveId": "CVE-2026-32638",
        "datePublished": "2026-03-18T20:41:14.034Z",
        "dateReserved": "2026-03-12T15:29:36.560Z",
        "dateUpdated": "2026-03-19T15:01:00.396Z",
        "state": "PUBLISHED"
      },
      "dataType": "CVE_RECORD",
      "dataVersion": "5.2"
    }
  }
}

CNVD-2026-18148

Vulnerability from cnvd - Published: 2026-04-22

Title

StudioCMS信息泄露漏洞

Description

StudioCMS是StudioCMS开源的一个内容管理系统。 StudioCMS存在信息泄露漏洞，该漏洞源于REST API getUsers端点使用攻击者控制的rank查询参数，攻击者可利用该漏洞导致管理员令牌获取所有者账户记录，造成授权不一致。

Severity

低

Patch Name

StudioCMS信息泄露漏洞的补丁

Patch Description

StudioCMS是StudioCMS开源的一个内容管理系统。 StudioCMS存在信息泄露漏洞，该漏洞源于REST API getUsers端点使用攻击者控制的rank查询参数，攻击者可利用该漏洞导致管理员令牌获取所有者账户记录，造成授权不一致。目前，供应商发布了安全公告及相关补丁信息，修复了此漏洞。

Formal description

目前厂商已发布升级补丁以修复漏洞，补丁获取链接： https://studiocms.dev/

Reference

https://nvd.nist.gov/vuln/detail/CVE-2026-32638

Impacted products

Name
StudioCMS StudioCMS <0.4.4

Show details on source website

JSON

To clipboard

{
  "cves": {
    "cve": {
      "cveNumber": "CVE-2026-32638",
      "cveUrl": "https://nvd.nist.gov/vuln/detail/CVE-2026-32638"
    }
  },
  "description": "StudioCMS\u662fStudioCMS\u5f00\u6e90\u7684\u4e00\u4e2a\u5185\u5bb9\u7ba1\u7406\u7cfb\u7edf\u3002\n\nStudioCMS\u5b58\u5728\u4fe1\u606f\u6cc4\u9732\u6f0f\u6d1e\uff0c\u8be5\u6f0f\u6d1e\u6e90\u4e8eREST API getUsers\u7aef\u70b9\u4f7f\u7528\u653b\u51fb\u8005\u63a7\u5236\u7684rank\u67e5\u8be2\u53c2\u6570\uff0c\u653b\u51fb\u8005\u53ef\u5229\u7528\u8be5\u6f0f\u6d1e\u5bfc\u81f4\u7ba1\u7406\u5458\u4ee4\u724c\u83b7\u53d6\u6240\u6709\u8005\u8d26\u6237\u8bb0\u5f55\uff0c\u9020\u6210\u6388\u6743\u4e0d\u4e00\u81f4\u3002",
  "formalWay": "\u76ee\u524d\u5382\u5546\u5df2\u53d1\u5e03\u5347\u7ea7\u8865\u4e01\u4ee5\u4fee\u590d\u6f0f\u6d1e\uff0c\u8865\u4e01\u83b7\u53d6\u94fe\u63a5\uff1a\r\nhttps://studiocms.dev/",
  "isEvent": "\u901a\u7528\u8f6f\u786c\u4ef6\u6f0f\u6d1e",
  "number": "CNVD-2026-18148",
  "openTime": "2026-04-22",
  "patchDescription": "StudioCMS\u662fStudioCMS\u5f00\u6e90\u7684\u4e00\u4e2a\u5185\u5bb9\u7ba1\u7406\u7cfb\u7edf\u3002\r\n\r\nStudioCMS\u5b58\u5728\u4fe1\u606f\u6cc4\u9732\u6f0f\u6d1e\uff0c\u8be5\u6f0f\u6d1e\u6e90\u4e8eREST API getUsers\u7aef\u70b9\u4f7f\u7528\u653b\u51fb\u8005\u63a7\u5236\u7684rank\u67e5\u8be2\u53c2\u6570\uff0c\u653b\u51fb\u8005\u53ef\u5229\u7528\u8be5\u6f0f\u6d1e\u5bfc\u81f4\u7ba1\u7406\u5458\u4ee4\u724c\u83b7\u53d6\u6240\u6709\u8005\u8d26\u6237\u8bb0\u5f55\uff0c\u9020\u6210\u6388\u6743\u4e0d\u4e00\u81f4\u3002\u76ee\u524d\uff0c\u4f9b\u5e94\u5546\u53d1\u5e03\u4e86\u5b89\u5168\u516c\u544a\u53ca\u76f8\u5173\u8865\u4e01\u4fe1\u606f\uff0c\u4fee\u590d\u4e86\u6b64\u6f0f\u6d1e\u3002",
  "patchName": "StudioCMS\u4fe1\u606f\u6cc4\u9732\u6f0f\u6d1e\u7684\u8865\u4e01",
  "products": {
    "product": "StudioCMS StudioCMS \u003c0.4.4"
  },
  "referenceLink": "https://nvd.nist.gov/vuln/detail/CVE-2026-32638",
  "serverity": "\u4f4e",
  "submitTime": "2026-03-20",
  "title": "StudioCMS\u4fe1\u606f\u6cc4\u9732\u6f0f\u6d1e"
}

FKIE_CVE-2026-32638

Vulnerability from fkie_nvd - Published: 2026-03-18 21:16 - Updated: 2026-06-17 10:36

Severity

2.7 (Low) - CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:N

Summary

References

URL	Tags
security-advisories@github.com	https://github.com/withstudiocms/studiocms/commit/aebe8bcb3618bb07c6753e3f5c982c1fe6adea64	Patch
security-advisories@github.com	https://github.com/withstudiocms/studiocms/releases/tag/studiocms@0.4.4	Product, Release Notes
security-advisories@github.com	https://github.com/withstudiocms/studiocms/security/advisories/GHSA-xvf4-ch4q-2m24	Exploit, Mitigation, Vendor Advisory

Impacted products

	Vendor	Product	Version
	studiocms	studiocms	*

JSON

To clipboard

{
  "affected": [
    {
      "affectedData": [
        {
          "product": "studiocms",
          "vendor": "withstudiocms",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 0.4.4"
            }
          ]
        }
      ],
      "source": "security-advisories@github.com"
    }
  ],
  "configurations": [
    {
      "nodes": [
        {
          "cpeMatch": [
            {
              "criteria": "cpe:2.3:a:studiocms:studiocms:*:*:*:*:*:*:*:*",
              "matchCriteriaId": "EF77B4D2-70E1-4F62-AE18-5726017098A2",
              "versionEndExcluding": "0.4.4",
              "vulnerable": true
            }
          ],
          "negate": false,
          "operator": "OR"
        }
      ]
    }
  ],
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "StudioCMS is a server-side-rendered, Astro native, headless content management system. Prior to 0.4.4, the REST API `getUsers` endpoint in StudioCMS uses the attacker-controlled `rank` query parameter to decide whether owner accounts should be filtered from the result set. As a result, an admin token can request `rank=owner` and receive owner account records, including IDs, usernames, display names, and email addresses, even though the adjacent `getUser` endpoint correctly blocks admins from viewing owner users. This is an authorization inconsistency inside the same user-management surface. Version 0.4.4 fixes the issue."
    },
    {
      "lang": "es",
      "value": "StudioCMS es un sistema de gesti\u00f3n de contenido sin cabeza, nativo de Astro y renderizado en el lado del servidor. Antes de la versi\u00f3n 0.4.4, el endpoint `getUsers` de la API REST en StudioCMS utiliza el par\u00e1metro de consulta `rank` controlado por el atacante para decidir si las cuentas de propietario deben filtrarse del conjunto de resultados. Como resultado, un token de administrador puede solicitar `rank=owner` y recibir registros de cuentas de propietario, incluyendo IDs, nombres de usuario, nombres para mostrar y direcciones de correo electr\u00f3nico, a pesar de que el endpoint adyacente `getUser` bloquea correctamente a los administradores para que no vean a los usuarios propietarios. Esto es una inconsistencia de autorizaci\u00f3n dentro de la misma superficie de gesti\u00f3n de usuarios. La versi\u00f3n 0.4.4 soluciona el problema."
    }
  ],
  "id": "CVE-2026-32638",
  "lastModified": "2026-06-17T10:36:08.737",
  "metrics": {
    "cvssMetricV31": [
      {
        "cvssData": {
          "attackComplexity": "LOW",
          "attackVector": "NETWORK",
          "availabilityImpact": "NONE",
          "baseScore": 2.7,
          "baseSeverity": "LOW",
          "confidentialityImpact": "LOW",
          "integrityImpact": "NONE",
          "privilegesRequired": "HIGH",
          "scope": "UNCHANGED",
          "userInteraction": "NONE",
          "vectorString": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:N",
          "version": "3.1"
        },
        "exploitabilityScore": 1.2,
        "impactScore": 1.4,
        "source": "security-advisories@github.com",
        "type": "Secondary"
      }
    ],
    "ssvcV203": [
      {
        "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
        "ssvcData": {
          "id": "CVE-2026-32638",
          "options": [
            {
              "exploitation": "poc"
            },
            {
              "automatable": "no"
            },
            {
              "technicalImpact": "partial"
            }
          ],
          "role": "CISA Coordinator",
          "timestamp": "2026-03-19T15:00:04.391194Z",
          "version": "2.0.3"
        }
      }
    ]
  },
  "published": "2026-03-18T21:16:26.770",
  "references": [
    {
      "source": "security-advisories@github.com",
      "tags": [
        "Patch"
      ],
      "url": "https://github.com/withstudiocms/studiocms/commit/aebe8bcb3618bb07c6753e3f5c982c1fe6adea64"
    },
    {
      "source": "security-advisories@github.com",
      "tags": [
        "Product",
        "Release Notes"
      ],
      "url": "https://github.com/withstudiocms/studiocms/releases/tag/studiocms@0.4.4"
    },
    {
      "source": "security-advisories@github.com",
      "tags": [
        "Exploit",
        "Mitigation",
        "Vendor Advisory"
      ],
      "url": "https://github.com/withstudiocms/studiocms/security/advisories/GHSA-xvf4-ch4q-2m24"
    }
  ],
  "sourceIdentifier": "security-advisories@github.com",
  "vulnStatus": "Analyzed",
  "weaknesses": [
    {
      "description": [
        {
          "lang": "en",
          "value": "CWE-639"
        }
      ],
      "source": "security-advisories@github.com",
      "type": "Secondary"
    }
  ]
}

GHSA-XVF4-CH4Q-2M24

Vulnerability from github – Published: 2026-03-16 16:37 – Updated: 2026-03-18 21:51

Summary

StudioCMS REST getUsers Exposes Owner Account Records to Admin Tokens

Details

Summary

The REST API getUsers endpoint in StudioCMS uses the attacker-controlled rank query parameter to decide whether owner accounts should be filtered from the result set. As a result, an admin token can request rank=owner and receive owner account records, including IDs, usernames, display names, and email addresses, even though the adjacent getUser endpoint correctly blocks admins from viewing owner users. This is an authorization inconsistency inside the same user-management surface.

Details

Vulnerable Code Path

File: D:/bugcrowd/studiocms/repo/packages/studiocms/frontend/pages/studiocms_api/_handlers/rest-api/v1/secure.ts, lines 1605-1647

.handle(
    'getUsers',
    Effect.fn(
        function* ({ urlParams: { name, rank, username } }) {
            if (!restAPIEnabled) {
                return yield* new RestAPIError({ error: 'Endpoint not found' });
            }
            const [sdk, user] = yield* Effect.all([SDKCore, CurrentRestAPIUser]);

            if (user.rank !== 'owner' && user.rank !== 'admin') {
                return yield* new RestAPIError({ error: 'Unauthorized' });
            }

            const allUsers = yield* sdk.GET.users.all();
            let data = allUsers.map(...);

            if (rank !== 'owner') {
                data = data.filter((user) => user.rank !== 'owner');
            }

            if (rank) {
                data = data.filter((user) => user.rank === rank);
            }

            return data;
        },

The rank variable in if (rank !== 'owner') is the request query parameter, not the caller's privilege level. An admin can therefore pass rank=owner, skip the owner-filtering branch, and then have the second if (rank) branch return only owner accounts.

Adjacent Endpoint Shows Intended Security Boundary

File: D:/bugcrowd/studiocms/repo/packages/studiocms/frontend/pages/studiocms_api/_handlers/rest-api/v1/secure.ts, lines 1650-1710

const existingUserRankIndex = availablePermissionRanks.indexOf(existingUserRank);
const loggedInUserRankIndex = availablePermissionRanks.indexOf(user.rank);

if (loggedInUserRankIndex <= existingUserRankIndex) {
    return yield* new RestAPIError({
        error: 'Unauthorized to view user with higher rank',
    });
}

getUser correctly blocks an admin from viewing an owner record. getUsers bypasses that boundary for bulk enumeration.

Sensitive Fields Returned

The getUsers response includes:

id
email
name
username
rank
timestamps and profile URL/avatar fields when present

This is enough to enumerate all owner accounts and target them for phishing, social engineering, or follow-on attacks against out-of-band workflows.

PoC

HTTP PoC

Use any admin-level REST API token:

curl -X GET 'http://localhost:4321/studiocms_api/rest/v1/secure/users?rank=owner' \
  -H 'Authorization: Bearer <admin-api-token>'

Expected behavior: - owner records should be excluded for admin callers, consistent with getUser

Actual behavior: - the response contains owner user objects, including email addresses and user IDs

Local Validation of the Exact Handler Logic

I validated the filtering logic locally with the same conditions used by getUsers and getUser.

Observed output:

{
  "admin_getUsers_rank_owner": [
    {
      "email": "owner@example.test",
      "id": "owner-1",
      "name": "Site Owner",
      "rank": "owner",
      "username": "owner1"
    }
  ],
  "admin_getUser_owner": "Unauthorized to view user with higher rank"
}

This demonstrates the authorization mismatch clearly: - bulk listing with rank=owner exposes owner records - direct access to a single owner record is denied

Impact

Owner Account Enumeration: Admin tokens can recover owner user IDs, usernames, display names, and email addresses.
Authorization Boundary Bypass: The REST collection endpoint bypasses the stricter per-record rank check already implemented by getUser.
Chaining Value: Exposed owner contact data can support phishing, account-targeting, and admin-to-owner pivot attempts in deployments that treat owner identities as higher-trust principals.

Recommended Fix

Apply rank filtering based on the caller's role, not on the request query parameter, and reuse the same privilege rule as getUser.

Example fix:

const loggedInUserRankIndex = availablePermissionRanks.indexOf(user.rank);

data = data.filter((candidate) => {
    const candidateRankIndex = availablePermissionRanks.indexOf(candidate.rank);
    return loggedInUserRankIndex > candidateRankIndex;
});

if (rank) {
    data = data.filter((candidate) => candidate.rank === rank);
}

At minimum, replace:

if (rank !== 'owner') {
    data = data.filter((user) => user.rank !== 'owner');
}

with a check tied to user.rank rather than the query parameter.

Severity

2.7 (Low)


                  
                    CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.4.3"
      },
      "package": {
        "ecosystem": "npm",
        "name": "studiocms"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.4.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-32638"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-16T16:37:42Z",
    "nvd_published_at": "2026-03-18T21:16:26Z",
    "severity": "LOW"
  },
  "details": "## Summary\n\nThe REST API `getUsers` endpoint in StudioCMS uses the attacker-controlled `rank` query parameter to decide whether owner accounts should be filtered from the result set. As a result, an admin token can request `rank=owner` and receive owner account records, including IDs, usernames, display names, and email addresses, even though the adjacent `getUser` endpoint correctly blocks admins from viewing owner users. This is an authorization inconsistency inside the same user-management surface.\n\n## Details\n\n### Vulnerable Code Path\n\nFile: `D:/bugcrowd/studiocms/repo/packages/studiocms/frontend/pages/studiocms_api/_handlers/rest-api/v1/secure.ts`, lines 1605-1647\n\n```ts\n.handle(\n    \u0027getUsers\u0027,\n    Effect.fn(\n        function* ({ urlParams: { name, rank, username } }) {\n            if (!restAPIEnabled) {\n                return yield* new RestAPIError({ error: \u0027Endpoint not found\u0027 });\n            }\n            const [sdk, user] = yield* Effect.all([SDKCore, CurrentRestAPIUser]);\n\n            if (user.rank !== \u0027owner\u0027 \u0026\u0026 user.rank !== \u0027admin\u0027) {\n                return yield* new RestAPIError({ error: \u0027Unauthorized\u0027 });\n            }\n\n            const allUsers = yield* sdk.GET.users.all();\n            let data = allUsers.map(...);\n\n            if (rank !== \u0027owner\u0027) {\n                data = data.filter((user) =\u003e user.rank !== \u0027owner\u0027);\n            }\n\n            if (rank) {\n                data = data.filter((user) =\u003e user.rank === rank);\n            }\n\n            return data;\n        },\n```\n\nThe `rank` variable in `if (rank !== \u0027owner\u0027)` is the request query parameter, not the caller\u0027s privilege level. An admin can therefore pass `rank=owner`, skip the owner-filtering branch, and then have the second `if (rank)` branch return only owner accounts.\n\n### Adjacent Endpoint Shows Intended Security Boundary\n\nFile: `D:/bugcrowd/studiocms/repo/packages/studiocms/frontend/pages/studiocms_api/_handlers/rest-api/v1/secure.ts`, lines 1650-1710\n\n```ts\nconst existingUserRankIndex = availablePermissionRanks.indexOf(existingUserRank);\nconst loggedInUserRankIndex = availablePermissionRanks.indexOf(user.rank);\n\nif (loggedInUserRankIndex \u003c= existingUserRankIndex) {\n    return yield* new RestAPIError({\n        error: \u0027Unauthorized to view user with higher rank\u0027,\n    });\n}\n```\n\n`getUser` correctly blocks an admin from viewing an owner record. `getUsers` bypasses that boundary for bulk enumeration.\n\n### Sensitive Fields Returned\n\nThe `getUsers` response includes:\n\n- `id`\n- `email`\n- `name`\n- `username`\n- `rank`\n- timestamps and profile URL/avatar fields when present\n\nThis is enough to enumerate all owner accounts and target them for phishing, social engineering, or follow-on attacks against out-of-band workflows.\n\n## PoC\n\n### HTTP PoC\n\nUse any admin-level REST API token:\n\n```bash\ncurl -X GET \u0027http://localhost:4321/studiocms_api/rest/v1/secure/users?rank=owner\u0027 \\\n  -H \u0027Authorization: Bearer \u003cadmin-api-token\u003e\u0027\n```\n\nExpected behavior:\n- owner records should be excluded for admin callers, consistent with `getUser`\n\nActual behavior:\n- the response contains owner user objects, including email addresses and user IDs\n\n### Local Validation of the Exact Handler Logic\n\nI validated the filtering logic locally with the same conditions used by `getUsers` and `getUser`.\n\nObserved output:\n\n```json\n{\n  \"admin_getUsers_rank_owner\": [\n    {\n      \"email\": \"owner@example.test\",\n      \"id\": \"owner-1\",\n      \"name\": \"Site Owner\",\n      \"rank\": \"owner\",\n      \"username\": \"owner1\"\n    }\n  ],\n  \"admin_getUser_owner\": \"Unauthorized to view user with higher rank\"\n}\n```\n\nThis demonstrates the authorization mismatch clearly:\n- bulk listing with `rank=owner` exposes owner records\n- direct access to a single owner record is denied\n\n## Impact\n\n- **Owner Account Enumeration:** Admin tokens can recover owner user IDs, usernames, display names, and email addresses.\n- **Authorization Boundary Bypass:** The REST collection endpoint bypasses the stricter per-record rank check already implemented by `getUser`.\n- **Chaining Value:** Exposed owner contact data can support phishing, account-targeting, and admin-to-owner pivot attempts in deployments that treat owner identities as higher-trust principals.\n\n## Recommended Fix\n\nApply rank filtering based on the caller\u0027s role, not on the request query parameter, and reuse the same privilege rule as `getUser`.\n\nExample fix:\n\n```ts\nconst loggedInUserRankIndex = availablePermissionRanks.indexOf(user.rank);\n\ndata = data.filter((candidate) =\u003e {\n    const candidateRankIndex = availablePermissionRanks.indexOf(candidate.rank);\n    return loggedInUserRankIndex \u003e candidateRankIndex;\n});\n\nif (rank) {\n    data = data.filter((candidate) =\u003e candidate.rank === rank);\n}\n```\n\nAt minimum, replace:\n\n```ts\nif (rank !== \u0027owner\u0027) {\n    data = data.filter((user) =\u003e user.rank !== \u0027owner\u0027);\n}\n```\n\nwith a check tied to `user.rank` rather than the query parameter.",
  "id": "GHSA-xvf4-ch4q-2m24",
  "modified": "2026-03-18T21:51:20Z",
  "published": "2026-03-16T16:37:42Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/withstudiocms/studiocms/security/advisories/GHSA-xvf4-ch4q-2m24"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32638"
    },
    {
      "type": "WEB",
      "url": "https://github.com/withstudiocms/studiocms/commit/aebe8bcb3618bb07c6753e3f5c982c1fe6adea64"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/withstudiocms/studiocms"
    },
    {
      "type": "WEB",
      "url": "https://github.com/withstudiocms/studiocms/releases/tag/studiocms@0.4.4"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "StudioCMS REST getUsers Exposes Owner Account Records to Admin Tokens"
}

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.

Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

Order JSON

How durations are calculated

Following the VTEM framework (Black Hat USA 2015), time to patch starts when the vendor or a coordinator was informed, total time to patch at discovery, and disclosure to patch at public disclosure; vendor response time runs from the report to its acknowledgement. Time to exploit and time unpatched start at the earliest discovery or report, falling back to public disclosure. Unpatched time ends at the first recorded patch, or the calculation time when no patch is recorded. Exploitation to patch shows the interval between those two events; a published proof of concept is a public exploit, not exploitation.

Each result shows its source dates. A negative interval means the end event came first; when date-only inputs leave the order open, the result says so. Date-only inputs are approximate. The earliest evidence wins: KEV report dates and sightings are labelled as such. Records describing another vulnerability are listed but never calculated from, and a PoC alone does not establish exploitation. Missing patch evidence does not prove that no patch exists. Filters below change the event list only.

Publication & reservation Sightings KEV catalogs Other timestamps

Loading timeline…

The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base model, served locally by ML-Gateway. They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.

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.

Action not permitted

CVE-2026-32638 (GCVE-0-2026-32638)

CNVD-2026-18148

FKIE_CVE-2026-32638

GHSA-XVF4-CH4Q-2M24

Summary

Details

Vulnerable Code Path

Adjacent Endpoint Shows Intended Security Boundary

Sensitive Fields Returned

PoC

HTTP PoC

Local Validation of the Exact Handler Logic

Impact

Recommended Fix

Tags

Sightings

Nomenclature

Vulnerability timeline

Related by attack behaviour