Approved changes feed: RSS · Atom
cpe:2.3:a:studiocms:studiocms:*:*:*:*:*:*:*:*part: a version: * update: *
| Vendor | Studiocms (5c339485-1db9-5486-8d32-4cfcbde5d554) |
|---|---|
| Product | Studiocms (9b69707a-9082-529c-a852-128683a3a135) |
| Edition | * |
| Language | * |
| Software edition | * |
| Target software | * |
| Target hardware | * |
| Other | * |
Notes
Imported from gcve-enriched-dumps CVE data
PURL mappings
| PURL | Source | Last updated |
|---|---|---|
pkg:github/withstudiocms/studiocms |
purl2cpe | 2026-07-28 16:41:08.490893 |
pkg:npm/studiocms |
purl2cpe | 2026-07-28 16:41:08.490895 |
Vulnerability references
| Identifier | cpeApplicability | Submitted | db.gcve.eu details | Rationale |
|---|---|---|---|---|
CVE:CVE-2026-32638 |
vulnerable | 2026-06-08 07:57:17.783421 |
StudioCMS REST getUsers Exposes Owner Account Records to Admin Tokens
LOW (2.7)
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.
Published: 2026-03-18T20:41:14.034Z
Updated: 2026-03-19T15:01:00.396Z |
Imported from gcve-enriched-dumps CVE data |
CVE:CVE-2026-32106 |
vulnerable | 2026-06-08 07:57:16.683736 |
StudioCMS: REST API Missing Rank Check Allows Admin to Create Peer Admin Accounts
MEDIUM (4.7)
StudioCMS is a server-side-rendered, Astro native, headless content management system. Prior to 0.4.3, the REST API createUser endpoint uses string-based rank checks that only block creating owner accounts, while the Dashboard API uses indexOf-based rank comparison that prevents creating users at or above your own rank. This inconsistency allows an admin to create additional admin accounts via the REST API, enabling privilege proliferation and persistence. This vulnerability is fixed in 0.4.3.
Published: 2026-03-11T20:09:12.095Z
Updated: 2026-03-12T19:48:33.042Z |
Imported from gcve-enriched-dumps CVE data |
CVE:CVE-2026-32104 |
vulnerable | 2026-06-08 07:57:16.680939 |
StudioCMS: IDOR in User Notification Preferences Allows Any Authenticated User to Modify Any User's Settings
MEDIUM (5.4)
StudioCMS is a server-side-rendered, Astro native, headless content management system. Prior to 0.4.3, the updateUserNotifications endpoint accepts a user ID from the request payload and uses it to update that user's notification preferences. It checks that the caller is logged in but never verifies that the caller owns the target account (id !== userData.user.id). Any authenticated visitor can modify notification preferences for any user, including disabling admin notifications to suppress detection of malicious activity. This vulnerability is fixed in 0.4.3.
Published: 2026-03-11T20:09:44.879Z
Updated: 2026-03-12T19:48:05.180Z |
Imported from gcve-enriched-dumps CVE data |
CVE:CVE-2026-32103 |
vulnerable | 2026-06-08 07:57:16.680490 |
StudioCMS: IDOR — Admin-to-Owner Account Takeover via Password Reset Link Generation
MEDIUM (6.8)
StudioCMS is a server-side-rendered, Astro native, headless content management system. Prior to 0.4.3, the POST /studiocms_api/dashboard/create-reset-link endpoint allows any authenticated user with admin privileges to generate a password reset token for any other user, including the owner account. The handler verifies that the caller is an admin but does not enforce role hierarchy, nor does it validate that the target userId matches the caller's identity. Combined with the POST /studiocms_api/dashboard/reset-password endpoint, this allows a complete account takeover of the highest-privileged account in the system. This vulnerability is fixed in 0.4.3.
Published: 2026-03-11T20:06:58.276Z
Updated: 2026-03-12T19:48:56.254Z |
Imported from gcve-enriched-dumps CVE data |
CVE:CVE-2026-32101 |
vulnerable | 2026-06-08 07:57:16.679556 |
StudioCMS S3 Storage Manager Authorization Bypass via Missing `await` on Async Auth Check
HIGH (7.6)
StudioCMS is a server-side-rendered, Astro native, headless content management system. Prior to 0.3.1, the S3 storage manager's isAuthorized() function is declared async (returns Promise<boolean>) but is called without await in both the POST and PUT handlers. Since a Promise object is always truthy in JavaScript, !isAuthorized(type) always evaluates to false, completely bypassing the authorization check. Any authenticated user with the lowest visitor role can upload, delete, rename, and list all files in the S3 bucket. This vulnerability is fixed in 0.3.1.
Published: 2026-03-11T20:03:05.319Z
Updated: 2026-03-12T19:51:19.210Z |
Imported from gcve-enriched-dumps CVE data |
CVE:CVE-2026-30945 |
vulnerable | 2026-06-08 07:57:14.580325 | db.gcve.eu details were skipped to keep the page responsive. | Imported from gcve-enriched-dumps CVE data |
CVE:CVE-2026-30944 |
vulnerable | 2026-06-08 07:57:14.579804 | db.gcve.eu details were skipped to keep the page responsive. | Imported from gcve-enriched-dumps CVE data |
CVE:CVE-2026-24134 |
vulnerable | 2026-06-08 07:51:17.187806 | db.gcve.eu details were skipped to keep the page responsive. | Imported from gcve-enriched-dumps CVE data |
Contribute
You can submit an edit proposal for this CPE entry or suggest a related product/vendor addition using the action button above.
Inspect record JSON
Open this panel to browse, search, copy or download the JSON record.