Common Weakness Enumeration

CWE-269

Discouraged

Improper Privilege Management

Abstraction: Class · Status: Draft

The product does not properly assign, modify, track, or check privileges for an actor, creating an unintended sphere of control for that actor.

6487 vulnerabilities reference this CWE, most recent first.

GHSA-V39C-4QQW-8546

Vulnerability from github – Published: 2022-05-24 17:38 – Updated: 2024-10-08 18:33

Details

Microsoft SharePoint Elevation of Privilege Vulnerability This CVE ID is unique from CVE-2021-1712.

Severity

8.0 (High)


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

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2021-1719"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-269"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-01-12T20:15:00Z",
    "severity": "HIGH"
  },
  "details": "Microsoft SharePoint Elevation of Privilege Vulnerability This CVE ID is unique from CVE-2021-1712.",
  "id": "GHSA-v39c-4qqw-8546",
  "modified": "2024-10-08T18:33:03Z",
  "published": "2022-05-24T17:38:51Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-1719"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-1719"
    },
    {
      "type": "WEB",
      "url": "https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2021-1719"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-V39M-97P8-GQG7

Vulnerability from github – Published: 2026-06-04 19:28 – Updated: 2026-06-04 19:28

Summary

Shopware: Privilege escalation: non-admin user with user:create ACL can create admin accounts

Details

UserController::upsertUser() writes user data in SYSTEM_SCOPE and does not filter the admin field. A non-admin API user with user:create or user:update ACL permission can set admin: true on new or existing users, escalating to full admin access.

The Problem

In src/Core/Framework/Api/Controller/UserController.php, line 210-234:

public function upsertUser(?string $userId, Request $request, Context $context, ResponseFactoryInterface $factory): Response
{
    $data = $request->request->all(); // raw request data, no field filtering
    // ...
    $events = $context->scope(Context::SYSTEM_SCOPE, fn (Context $context) =>
        $this->userRepository->upsert([$data], $context)
    );
}

SYSTEM_SCOPE bypasses AclWriteValidator entirely (line 52 of AclWriteValidator::preValidate() returns early for SYSTEM_SCOPE). The admin boolean field is accepted without restriction.

Compare with IntegrationController::upsertIntegration() in the same codebase, which correctly checks:

if ((!$source instanceof AdminApiSource)
    || (!$source->isAdmin()
    && isset($data['admin']))
) {
    throw new PermissionDeniedException();
}

UserController is missing this exact check.

Impact

Any API user with the low-privilege user:create permission can create accounts with full admin access, or with user:update can promote any existing user to admin. This is a direct privilege escalation.

Suggested Fix

Add the same isAdmin() check from IntegrationController:

$source = $context->getSource();
if ((!$source instanceof AdminApiSource) || (!$source->isAdmin() && isset($data['admin']))) {
    throw new PermissionDeniedException();
}

Best regards, Keyvan Hardani

Severity

6.5 (Medium)


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

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "shopware/platform"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.7.0.0"
            },
            {
              "fixed": "6.7.10.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "shopware/platform"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.6.10.18"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "shopware/core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.7.0.0"
            },
            {
              "fixed": "6.7.10.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "shopware/core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.6.10.18"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-48010"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-269"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-04T19:28:29Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "`UserController::upsertUser()` writes user data in `SYSTEM_SCOPE` and does not filter the `admin` field. A non-admin API user with `user:create` or `user:update` ACL permission can set `admin: true` on new or existing users, escalating to full admin access.\n\n## The Problem\n\nIn `src/Core/Framework/Api/Controller/UserController.php`, line 210-234:\n\n```php\npublic function upsertUser(?string $userId, Request $request, Context $context, ResponseFactoryInterface $factory): Response\n{\n    $data = $request-\u003erequest-\u003eall(); // raw request data, no field filtering\n    // ...\n    $events = $context-\u003escope(Context::SYSTEM_SCOPE, fn (Context $context) =\u003e\n        $this-\u003euserRepository-\u003eupsert([$data], $context)\n    );\n}\n```\n\n`SYSTEM_SCOPE` bypasses `AclWriteValidator` entirely (line 52 of `AclWriteValidator::preValidate()` returns early for `SYSTEM_SCOPE`). The `admin` boolean field is accepted without restriction.\n\nCompare with `IntegrationController::upsertIntegration()` in the same codebase, which correctly checks:\n\n```php\nif ((!$source instanceof AdminApiSource)\n    || (!$source-\u003eisAdmin()\n    \u0026\u0026 isset($data[\u0027admin\u0027]))\n) {\n    throw new PermissionDeniedException();\n}\n```\n\n`UserController` is missing this exact check.\n\n## Impact\n\nAny API user with the low-privilege `user:create` permission can create accounts with full admin access, or with `user:update` can promote any existing user to admin. This is a direct privilege escalation.\n\n## Suggested Fix\n\nAdd the same `isAdmin()` check from `IntegrationController`:\n\n```php\n$source = $context-\u003egetSource();\nif ((!$source instanceof AdminApiSource) || (!$source-\u003eisAdmin() \u0026\u0026 isset($data[\u0027admin\u0027]))) {\n    throw new PermissionDeniedException();\n}\n```\n\nBest regards,\nKeyvan Hardani",
  "id": "GHSA-v39m-97p8-gqg7",
  "modified": "2026-06-04T19:28:29Z",
  "published": "2026-06-04T19:28:29Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/shopware/shopware/security/advisories/GHSA-v39m-97p8-gqg7"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/shopware/shopware"
    },
    {
      "type": "WEB",
      "url": "https://github.com/shopware/shopware/releases/tag/v6.6.10.18"
    },
    {
      "type": "WEB",
      "url": "https://github.com/shopware/shopware/releases/tag/v6.7.10.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Shopware: Privilege escalation: non-admin user with user:create ACL can create admin accounts"
}

GHSA-V3CH-W844-FCPJ

Vulnerability from github – Published: 2023-01-11 00:30 – Updated: 2023-01-11 00:30

Details

Azure Service Fabric Container Elevation of Privilege Vulnerability.

Severity

7.0 (High)


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

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2023-21531"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-269"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-01-10T22:15:00Z",
    "severity": "HIGH"
  },
  "details": "Azure Service Fabric Container Elevation of Privilege Vulnerability.",
  "id": "GHSA-v3ch-w844-fcpj",
  "modified": "2023-01-11T00:30:48Z",
  "published": "2023-01-11T00:30:48Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-21531"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2023-21531"
    },
    {
      "type": "WEB",
      "url": "https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2023-21531"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-V3FV-W877-65RM

Vulnerability from github – Published: 2022-05-24 17:10 – Updated: 2022-05-24 17:10

Details

A remote code execution vulnerability exists in Microsoft Windows that could allow remote code execution if a .LNK file is processed.An attacker who successfully exploited this vulnerability could gain the same user rights as the local user, aka 'LNK Remote Code Execution Vulnerability'.

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2020-0684"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-269"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-03-12T16:15:00Z",
    "severity": "MODERATE"
  },
  "details": "A remote code execution vulnerability exists in Microsoft Windows that could allow remote code execution if a .LNK file is processed.An attacker who successfully exploited this vulnerability could gain the same user rights as the local user, aka \u0027LNK Remote Code Execution Vulnerability\u0027.",
  "id": "GHSA-v3fv-w877-65rm",
  "modified": "2022-05-24T17:10:53Z",
  "published": "2022-05-24T17:10:53Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-0684"
    },
    {
      "type": "WEB",
      "url": "https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-0684"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-V3GF-Q256-843H

Vulnerability from github – Published: 2022-05-24 17:30 – Updated: 2023-12-31 21:30

Details

An elevation of privilege vulnerability exists in the way Azure Functions validate access keys.An unauthenticated attacker who successfully exploited this vulnerability could invoke an HTTP Function without proper authorization.This security update addresses the vulnerability by correctly validating access keys used to access HTTP Functions., aka 'Azure Functions Elevation of Privilege Vulnerability'.

Severity

5.3 (Medium)


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

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2020-16904"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-269",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-10-16T23:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "An elevation of privilege vulnerability exists in the way Azure Functions validate access keys.An unauthenticated attacker who successfully exploited this vulnerability could invoke an HTTP Function without proper authorization.This security update addresses the vulnerability by correctly validating access keys used to access HTTP Functions., aka \u0027Azure Functions Elevation of Privilege Vulnerability\u0027.",
  "id": "GHSA-v3gf-q256-843h",
  "modified": "2023-12-31T21:30:22Z",
  "published": "2022-05-24T17:30:56Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-16904"
    },
    {
      "type": "WEB",
      "url": "https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-16904"
    }
  ],
  "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"
    }
  ]
}

GHSA-V3H3-3683-PQF4

Vulnerability from github – Published: 2026-07-22 00:32 – Updated: 2026-07-22 00:32

Details

Vulnerability in the Oracle Agile Product Lifecycle Management for Process product of Oracle Supply Chain (component: Product Quality Management). The supported version that is affected is 6.2.4. Easily exploitable vulnerability allows low privileged attacker with network access via HTTP to compromise Oracle Agile Product Lifecycle Management for Process. Successful attacks of this vulnerability can result in takeover of Oracle Agile Product Lifecycle Management for Process. CVSS 3.1 Base Score 8.8 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H).

Severity

8.8 (High)


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

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-61179"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-269"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-21T22:18:49Z",
    "severity": "HIGH"
  },
  "details": "Vulnerability in the Oracle Agile Product Lifecycle Management for Process product of Oracle Supply Chain (component: Product Quality Management).   The supported version that is affected is 6.2.4. Easily exploitable vulnerability allows low privileged attacker with network access via HTTP to compromise Oracle Agile Product Lifecycle Management for Process.  Successful attacks of this vulnerability can result in takeover of Oracle Agile Product Lifecycle Management for Process. CVSS 3.1 Base Score 8.8 (Confidentiality, Integrity and Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H).",
  "id": "GHSA-v3h3-3683-pqf4",
  "modified": "2026-07-22T00:32:21Z",
  "published": "2026-07-22T00:32:21Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-61179"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpujul2026.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-V3JW-H6RW-7CWR

Vulnerability from github – Published: 2025-07-30 00:32 – Updated: 2025-11-03 21:34

Details

This issue was addressed through improved state management. This issue is fixed in macOS Sequoia 15.3, macOS Ventura 13.7.7, macOS Sonoma 14.7.7. An app may be able to execute arbitrary code out of its sandbox or with certain elevated privileges.

Severity

9.8 (Critical)


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

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2025-24119"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-269"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-07-30T00:15:29Z",
    "severity": "CRITICAL"
  },
  "details": "This issue was addressed through improved state management. This issue is fixed in macOS Sequoia 15.3, macOS Ventura 13.7.7, macOS Sonoma 14.7.7. An app may be able to execute arbitrary code out of its sandbox or with certain elevated privileges.",
  "id": "GHSA-v3jw-h6rw-7cwr",
  "modified": "2025-11-03T21:34:11Z",
  "published": "2025-07-30T00:32:19Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-24119"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/122068"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/124150"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/124151"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2025/Jul/33"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2025/Jul/34"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-V3M4-V33X-7JHP

Vulnerability from github – Published: 2025-05-08 21:32 – Updated: 2025-05-08 21:32

Details

On Arista CloudVision systems (virtual or physical on-premise deployments), Zero Touch Provisioning can be used to gain admin privileges on the CloudVision system, with more permissions than necessary, which can be used to query or manipulate system state for devices under management. Note that CloudVision as-a-Service is not affected.

Severity

10.0 (Critical)


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

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2025-0505"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-269"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-05-08T19:16:01Z",
    "severity": "CRITICAL"
  },
  "details": "On Arista CloudVision systems (virtual or physical on-premise deployments), Zero Touch Provisioning can be used to gain admin privileges on the CloudVision system, with more permissions than necessary, which can be used to query or manipulate system state for devices under management. Note that CloudVision as-a-Service is not affected.",
  "id": "GHSA-v3m4-v33x-7jhp",
  "modified": "2025-05-08T21:32:56Z",
  "published": "2025-05-08T21:32:56Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-0505"
    },
    {
      "type": "WEB",
      "url": "https://www.arista.com/en/support/advisories-notices/security-advisory/21315-security-advisory-0115"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-V3P6-34MC-HJ7V

Vulnerability from github – Published: 2026-10-09 20:40 – Updated: 2026-10-09 20:40

Summary

Vikunja: Scoped API token can mint unrestricted OAuth session credentials

Details

Summary

A scoped API token can bypass its declared permissions by using the OAuth authorization flow to mint normal session credentials.

A token limited to:

{"oauth":["authorize"]}

can call /api/v1/oauth/authorize, receive an OAuth authorization code, exchange it at /api/v1/oauth/token, and obtain a normal bearer JWT plus refresh token. The resulting credentials are not restricted by the original API-token permissions.

Affected Component

Scoped API tokens
OAuth authorization flow
POST /api/v1/oauth/authorize
POST /api/v1/oauth/token

Impact

A narrowly scoped API token with only oauth.authorize can be converted into normal session credentials for the same user.

This bypasses the intended API-token permission boundary. An attacker who obtains or is delegated such a limited token can mint a normal JWT and refresh token, then access routes outside the original token scope.

Runtime validation showed that the original scoped token could not access GET /api/v1/user, but the minted OAuth access token could access:

GET /api/v1/user
GET /api/v1/projects

No cross-user access, privilege escalation to admin, or access to another account was validated.

Technical Details

The issue is caused by an authentication-context mismatch between scoped API-token authentication and OAuth authorization-code issuance.

The vulnerable chain is:

A scoped API token authenticates the request and sets the current user context.
/api/v1/oauth/authorize accepts that API-token-authenticated user as a valid OAuth resource owner.
The OAuth authorization endpoint issues an authorization code.
/api/v1/oauth/token exchanges that code for a normal bearer JWT and refresh token.
The resulting credentials are not bound to the original API-token permissions.

Relevant code paths:

pkg/routes/routes.go
registers /api/v1/oauth/authorize in an authenticated API route group that also accepts scoped API tokens
pkg/models/api_routes.go
exposes non-CRUD subroutes as API-token permissions
exposes the OAuth authorization endpoint under the oauth permission group
pkg/routes/api_tokens.go
stores api_token and api_user in the request context during API-token authentication
pkg/user/user.go
treats api_user as an authenticated current user
pkg/modules/auth/oauth2server/authorize.go
uses the current user and issues an OAuth authorization code
pkg/modules/auth/oauth2server/token.go
exchanges the authorization code for a normal JWT and refresh token

Steps to Reproduce

1. Create a scoped API token

Create an API token with only the following permission:

{"oauth":["authorize"]}

Observed response:

201 Created

The returned token had only the oauth.authorize permission.

2. Negative control: direct access with scoped token fails

Request:

GET /api/v1/user
Authorization: Bearer <scoped-api-token>

Observed response:

401 Unauthorized

Response body:

{"code":11,"message":"missing, malformed, expired or otherwise invalid token provided"}

This confirms that the scoped token cannot directly access the normal user route.

3. Obtain an OAuth authorization code with the scoped token

Request:

POST /api/v1/oauth/authorize
Authorization: Bearer <scoped-api-token>
Content-Type: application/json

Body:

{
  "response_type": "code",
  "client_id": "vikunja",
  "redirect_uri": "vikunja-flutter://callback",
  "code_challenge": "<pkce-s256-challenge>",
  "code_challenge_method": "S256"
}

Observed response:

200 OK

Response body:

{
  "code": "<redacted>",
  "redirect_uri": "vikunja-flutter://callback",
  "state": ""
}

The scoped API token successfully obtained an OAuth authorization code.

4. Exchange the authorization code for session credentials

Request:

POST /api/v1/oauth/token
Content-Type: application/json

Body:

{
  "grant_type": "authorization_code",
  "code": "<redacted>",
  "client_id": "vikunja",
  "redirect_uri": "vikunja-flutter://callback",
  "code_verifier": "<original-pkce-verifier>"
}

Observed response:

200 OK

Response body:

{
  "access_token": "<redacted>",
  "token_type": "bearer",
  "expires_in": 600,
  "refresh_token": "<redacted>"
}

The authorization code was exchanged for a normal access token and refresh token.

5. Use the minted access token on normal routes

Request:

GET /api/v1/user
Authorization: Bearer <minted-oauth-access-token>

Observed response:

200 OK

Additional scope check:

GET /api/v1/projects
Authorization: Bearer <minted-oauth-access-token>

Observed response:

200 OK

The minted OAuth access token could access normal non-OAuth routes that the original scoped API token could not access.

Expected Behavior

A scoped API token should not be able to obtain credentials with broader permissions than its declared scope.

/api/v1/oauth/authorize should require a normal user session or another authentication context suitable for OAuth authorization-code issuance. API-token-authenticated requests should not be accepted for minting OAuth authorization codes.

Actual Behavior

A token scoped only to oauth.authorize can obtain an OAuth authorization code and exchange it for a normal JWT plus refresh token.

The minted credentials are not restricted by the original API-token permissions.

Severity

8.1 (High)


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

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "code.vikunja.io/api"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.3.0"
            },
            {
              "fixed": "2.4.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "2.3.0"
      ]
    }
  ],
  "aliases": [
    "CVE-2026-57458"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-269"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-09T20:40:28Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Summary\n\nA scoped API token can bypass its declared permissions by using the OAuth authorization flow to mint normal session credentials.\n\nA token limited to:\n\n```json\n{\"oauth\":[\"authorize\"]}\n```\n\ncan call `/api/v1/oauth/authorize`, receive an OAuth authorization code, exchange it at `/api/v1/oauth/token`, and obtain a normal bearer JWT plus refresh token. The resulting credentials are not restricted by the original API-token permissions.\n\n## Affected Component\n\n* Scoped API tokens\n* OAuth authorization flow\n* `POST /api/v1/oauth/authorize`\n* `POST /api/v1/oauth/token`\n\n## Impact\n\nA narrowly scoped API token with only `oauth.authorize` can be converted into normal session credentials for the same user.\n\nThis bypasses the intended API-token permission boundary. An attacker who obtains or is delegated such a limited token can mint a normal JWT and refresh token, then access routes outside the original token scope.\n\nRuntime validation showed that the original scoped token could not access `GET /api/v1/user`, but the minted OAuth access token could access:\n\n* `GET /api/v1/user`\n* `GET /api/v1/projects`\n\nNo cross-user access, privilege escalation to admin, or access to another account was validated.\n\n## Technical Details\n\nThe issue is caused by an authentication-context mismatch between scoped API-token authentication and OAuth authorization-code issuance.\n\nThe vulnerable chain is:\n\n1. A scoped API token authenticates the request and sets the current user context.\n2. `/api/v1/oauth/authorize` accepts that API-token-authenticated user as a valid OAuth resource owner.\n3. The OAuth authorization endpoint issues an authorization code.\n4. `/api/v1/oauth/token` exchanges that code for a normal bearer JWT and refresh token.\n5. The resulting credentials are not bound to the original API-token permissions.\n\nRelevant code paths:\n\n* `pkg/routes/routes.go`\n\n  * registers `/api/v1/oauth/authorize` in an authenticated API route group that also accepts scoped API tokens\n\n* `pkg/models/api_routes.go`\n\n  * exposes non-CRUD subroutes as API-token permissions\n  * exposes the OAuth authorization endpoint under the `oauth` permission group\n\n* `pkg/routes/api_tokens.go`\n\n  * stores `api_token` and `api_user` in the request context during API-token authentication\n\n* `pkg/user/user.go`\n\n  * treats `api_user` as an authenticated current user\n\n* `pkg/modules/auth/oauth2server/authorize.go`\n\n  * uses the current user and issues an OAuth authorization code\n\n* `pkg/modules/auth/oauth2server/token.go`\n\n  * exchanges the authorization code for a normal JWT and refresh token\n\n## Steps to Reproduce\n\n### 1. Create a scoped API token\n\nCreate an API token with only the following permission:\n\n```json\n{\"oauth\":[\"authorize\"]}\n```\n\nObserved response:\n\n```http\n201 Created\n```\n\nThe returned token had only the `oauth.authorize` permission.\n\n### 2. Negative control: direct access with scoped token fails\n\nRequest:\n\n```http\nGET /api/v1/user\nAuthorization: Bearer \u003cscoped-api-token\u003e\n```\n\nObserved response:\n\n```http\n401 Unauthorized\n```\n\nResponse body:\n\n```json\n{\"code\":11,\"message\":\"missing, malformed, expired or otherwise invalid token provided\"}\n```\n\nThis confirms that the scoped token cannot directly access the normal user route.\n\n### 3. Obtain an OAuth authorization code with the scoped token\n\nRequest:\n\n```http\nPOST /api/v1/oauth/authorize\nAuthorization: Bearer \u003cscoped-api-token\u003e\nContent-Type: application/json\n```\n\nBody:\n\n```json\n{\n  \"response_type\": \"code\",\n  \"client_id\": \"vikunja\",\n  \"redirect_uri\": \"vikunja-flutter://callback\",\n  \"code_challenge\": \"\u003cpkce-s256-challenge\u003e\",\n  \"code_challenge_method\": \"S256\"\n}\n```\n\nObserved response:\n\n```http\n200 OK\n```\n\nResponse body:\n\n```json\n{\n  \"code\": \"\u003credacted\u003e\",\n  \"redirect_uri\": \"vikunja-flutter://callback\",\n  \"state\": \"\"\n}\n```\n\nThe scoped API token successfully obtained an OAuth authorization code.\n\n### 4. Exchange the authorization code for session credentials\n\nRequest:\n\n```http\nPOST /api/v1/oauth/token\nContent-Type: application/json\n```\n\nBody:\n\n```json\n{\n  \"grant_type\": \"authorization_code\",\n  \"code\": \"\u003credacted\u003e\",\n  \"client_id\": \"vikunja\",\n  \"redirect_uri\": \"vikunja-flutter://callback\",\n  \"code_verifier\": \"\u003coriginal-pkce-verifier\u003e\"\n}\n```\n\nObserved response:\n\n```http\n200 OK\n```\n\nResponse body:\n\n```json\n{\n  \"access_token\": \"\u003credacted\u003e\",\n  \"token_type\": \"bearer\",\n  \"expires_in\": 600,\n  \"refresh_token\": \"\u003credacted\u003e\"\n}\n```\n\nThe authorization code was exchanged for a normal access token and refresh token.\n\n### 5. Use the minted access token on normal routes\n\nRequest:\n\n```http\nGET /api/v1/user\nAuthorization: Bearer \u003cminted-oauth-access-token\u003e\n```\n\nObserved response:\n\n```http\n200 OK\n```\n\nAdditional scope check:\n\n```http\nGET /api/v1/projects\nAuthorization: Bearer \u003cminted-oauth-access-token\u003e\n```\n\nObserved response:\n\n```http\n200 OK\n```\n\nThe minted OAuth access token could access normal non-OAuth routes that the original scoped API token could not access.\n\n## Expected Behavior\n\nA scoped API token should not be able to obtain credentials with broader permissions than its declared scope.\n\n`/api/v1/oauth/authorize` should require a normal user session or another authentication context suitable for OAuth authorization-code issuance. API-token-authenticated requests should not be accepted for minting OAuth authorization codes.\n\n## Actual Behavior\n\nA token scoped only to `oauth.authorize` can obtain an OAuth authorization code and exchange it for a normal JWT plus refresh token.\n\nThe minted credentials are not restricted by the original API-token permissions.",
  "id": "GHSA-v3p6-34mc-hj7v",
  "modified": "2026-10-09T20:40:28Z",
  "published": "2026-10-09T20:40:28Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/go-vikunja/vikunja/security/advisories/GHSA-v3p6-34mc-hj7v"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-vikunja/vikunja/commit/4ae2e093014881052ed8f8ecd8bcb9adf83dd276"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/go-vikunja/vikunja"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-vikunja/vikunja/releases/tag/v2.4.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Vikunja: Scoped API token can mint unrestricted OAuth session credentials"
}

GHSA-V3Q2-56H4-5753

Vulnerability from github – Published: 2022-05-24 17:46 – Updated: 2022-05-24 17:46

Details

A logic issue was addressed with improved state management. This issue is fixed in macOS Big Sur 11.2, Security Update 2021-001 Catalina, Security Update 2021-001 Mojave, macOS Big Sur 11.1, Security Update 2020-001 Catalina, Security Update 2020-007 Mojave. A malicious application may be able to elevate privileges.

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2020-27938"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-269"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-04-02T18:15:00Z",
    "severity": "HIGH"
  },
  "details": "A logic issue was addressed with improved state management. This issue is fixed in macOS Big Sur 11.2, Security Update 2021-001 Catalina, Security Update 2021-001 Mojave, macOS Big Sur 11.1, Security Update 2020-001 Catalina, Security Update 2020-007 Mojave. A malicious application may be able to elevate privileges.",
  "id": "GHSA-v3q2-56h4-5753",
  "modified": "2022-05-24T17:46:10Z",
  "published": "2022-05-24T17:46:10Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-27938"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/HT212011"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/HT212147"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

Mitigation MIT-1

Architecture and Design Operation

Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software.

Mitigation MIT-48

Architecture and Design

Strategy: Separation of Privilege

Follow the principle of least privilege when assigning access rights to entities in a software system.

Mitigation MIT-49

Architecture and Design

Strategy: Separation of Privilege

Consider following the principle of separation of privilege. Require multiple conditions to be met before permitting access to a system resource.

CAPEC-122: Privilege Abuse

An adversary is able to exploit features of the target that should be reserved for privileged users or administrators but are exposed to use by lower or non-privileged accounts. Access to sensitive information and functionality must be controlled to ensure that only authorized users are able to access these resources.

CAPEC-233: Privilege Escalation

An adversary exploits a weakness enabling them to elevate their privilege and perform an action that they are not supposed to be authorized to perform.

CAPEC-58: Restful Privilege Elevation

An adversary identifies a Rest HTTP (Get, Put, Delete) style permission method allowing them to perform various malicious actions upon server data due to lack of access control mechanisms implemented within the application service accepting HTTP messages.

← Back to the CWE list