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.

5548 vulnerabilities reference this CWE, most recent first.

GHSA-PPVX-RWH9-7RJ7

Vulnerability from github – Published: 2026-04-08 00:04 – Updated: 2026-06-08 19:09
VLAI
Summary
pyload-ng: Authorization Bypass for SSL Certificate/Key Configuration Due to Option Name Mismatch in pyload-ng
Details

Summary

The ADMIN_ONLY_CORE_OPTIONS authorization set in set_config_value() uses incorrect option names ssl_cert and ssl_key, while the actual configuration option names are ssl_certfile and ssl_keyfile. This name mismatch causes the admin-only check to always evaluate to False, allowing any user with SETTINGS permission to overwrite the SSL certificate and key file paths. Additionally, the ssl_certchain option was never added to the admin-only set at all.

Details

The vulnerability is in src/pyload/core/api/__init__.py. The ADMIN_ONLY_CORE_OPTIONS set is defined at lines 237-248:

ADMIN_ONLY_CORE_OPTIONS = {
    ("general", "storage_folder"),
    ("log", "syslog_host"),
    ("log", "syslog_port"),
    ("proxy", "password"),
    ("proxy", "username"),
    ("reconnect", "script"),
    ("webui", "host"),
    ("webui", "ssl_cert"),      # BUG: should be "ssl_certfile"
    ("webui", "ssl_key"),       # BUG: should be "ssl_keyfile"
    ("webui", "use_ssl"),
}
# NOTE: ("webui", "ssl_certchain") is entirely missing

The actual config option names are defined in src/pyload/core/config/default.cfg:39-41:

file ssl_certfile : "SSL Certificate" = ssl.crt
file ssl_keyfile : "SSL Key" = ssl.key
file ssl_certchain : "CA's intermediate certificate bundle (optional)" =

The authorization check at line 267 compares the incoming (category, option) tuple against this set:

if (category, option) in ADMIN_ONLY_CORE_OPTIONS and not is_admin:
    self.pyload.log.error(...)
    return

When a request arrives with option=ssl_certfile, the check evaluates ("webui", "ssl_certfile") in ADMIN_ONLY_CORE_OPTIONS which is False because the set contains ("webui", "ssl_cert"), not ("webui", "ssl_certfile"). The admin-only guard is bypassed and config.set() at line 271 proceeds to write the attacker-supplied value.

The value is cast as a file type in parser.py:300-305, which resolves it via os.path.realpath() but performs no further validation:

elif typ in ("file", "folder"):
    return (
        ""
        if value in (None, "")
        else os.path.realpath(os.path.expanduser(os.fsdecode(value)))
    )

On server restart with SSL enabled, the webserver loads the attacker-controlled paths (webserver_thread.py:22-23,51-52):

self.certfile = self.pyload.config.get("webui", "ssl_certfile")
self.keyfile = self.pyload.config.get("webui", "ssl_keyfile")
# ...
self.server.ssl_adapter = BuiltinSSLAdapter(
    self.certfile, self.keyfile, self.certchain
)

PoC

Prerequisites: A pyLoad instance with SSL enabled and a non-admin user account that has SETTINGS permission.

Step 1: Authenticate as the non-admin user to get a session cookie:

curl -c cookies.txt -X POST 'http://localhost:8000/login' \
  -d 'username=settingsuser&password=password123'

Step 2: Set the SSL certificate to an attacker-controlled file path:

curl -b cookies.txt -X POST 'http://localhost:8000/json/save_config' \
  -H 'Content-Type: application/json' \
  -d '{"category": "core", "config": {"webui|ssl_certfile": "/tmp/attacker.crt"}}'

Expected response: true (config saved successfully)

Step 3: Set the SSL key to an attacker-controlled file path:

curl -b cookies.txt -X POST 'http://localhost:8000/json/save_config' \
  -H 'Content-Type: application/json' \
  -d '{"category": "core", "config": {"webui|ssl_keyfile": "/tmp/attacker.key"}}'

Expected response: true (config saved successfully)

Step 4: Set the SSL certificate chain (never protected):

curl -b cookies.txt -X POST 'http://localhost:8000/json/save_config' \
  -H 'Content-Type: application/json' \
  -d '{"category": "core", "config": {"webui|ssl_certchain": "/tmp/attacker-chain.crt"}}'

Expected response: true (config saved successfully)

Step 5: After the server restarts, it will load the attacker's certificate and key for all HTTPS connections.

Impact

A non-admin user with SETTINGS permission can replace the SSL certificate and key used by the pyLoad HTTPS server. When the server restarts (or is restarted by an admin), it will serve HTTPS using the attacker's certificate/key pair. This enables:

  • Man-in-the-Middle attacks: The attacker, possessing the private key for the now-active certificate, can intercept and decrypt all HTTPS traffic to the pyLoad instance, including admin credentials and session tokens.
  • Credential theft: All users (including admins) connecting over HTTPS will have their credentials exposed to the attacker.
  • Configuration tampering: With intercepted admin credentials, the attacker can escalate to full admin access.

The attack requires SSL to already be enabled by an admin (the use_ssl option is correctly protected), the attacker to place certificate/key files on the filesystem (potentially achievable via pyLoad's download functionality), and a server restart.

Recommended Fix

Fix the option names in ADMIN_ONLY_CORE_OPTIONS and add the missing ssl_certchain option in src/pyload/core/api/__init__.py:

ADMIN_ONLY_CORE_OPTIONS = {
    ("general", "storage_folder"),
    ("log", "syslog_host"),
    ("log", "syslog_port"),
    ("proxy", "password"),
    ("proxy", "username"),
    ("reconnect", "script"),
    ("webui", "host"),
    ("webui", "ssl_certfile"),    # Fixed: was "ssl_cert"
    ("webui", "ssl_keyfile"),     # Fixed: was "ssl_key"
    ("webui", "ssl_certchain"),   # Added: was missing entirely
    ("webui", "use_ssl"),
}
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": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "pyload-ng"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.5.0b3.dev97"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-35586"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-08T00:04:34Z",
    "nvd_published_at": "2026-04-07T17:16:34Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nThe `ADMIN_ONLY_CORE_OPTIONS` authorization set in `set_config_value()` uses incorrect option names `ssl_cert` and `ssl_key`, while the actual configuration option names are `ssl_certfile` and `ssl_keyfile`. This name mismatch causes the admin-only check to always evaluate to False, allowing any user with SETTINGS permission to overwrite the SSL certificate and key file paths. Additionally, the `ssl_certchain` option was never added to the admin-only set at all.\n\n## Details\n\nThe vulnerability is in `src/pyload/core/api/__init__.py`. The `ADMIN_ONLY_CORE_OPTIONS` set is defined at lines 237-248:\n\n```python\nADMIN_ONLY_CORE_OPTIONS = {\n    (\"general\", \"storage_folder\"),\n    (\"log\", \"syslog_host\"),\n    (\"log\", \"syslog_port\"),\n    (\"proxy\", \"password\"),\n    (\"proxy\", \"username\"),\n    (\"reconnect\", \"script\"),\n    (\"webui\", \"host\"),\n    (\"webui\", \"ssl_cert\"),      # BUG: should be \"ssl_certfile\"\n    (\"webui\", \"ssl_key\"),       # BUG: should be \"ssl_keyfile\"\n    (\"webui\", \"use_ssl\"),\n}\n# NOTE: (\"webui\", \"ssl_certchain\") is entirely missing\n```\n\nThe actual config option names are defined in `src/pyload/core/config/default.cfg:39-41`:\n\n```\nfile ssl_certfile : \"SSL Certificate\" = ssl.crt\nfile ssl_keyfile : \"SSL Key\" = ssl.key\nfile ssl_certchain : \"CA\u0027s intermediate certificate bundle (optional)\" =\n```\n\nThe authorization check at line 267 compares the incoming `(category, option)` tuple against this set:\n\n```python\nif (category, option) in ADMIN_ONLY_CORE_OPTIONS and not is_admin:\n    self.pyload.log.error(...)\n    return\n```\n\nWhen a request arrives with `option=ssl_certfile`, the check evaluates `(\"webui\", \"ssl_certfile\") in ADMIN_ONLY_CORE_OPTIONS` which is **False** because the set contains `(\"webui\", \"ssl_cert\")`, not `(\"webui\", \"ssl_certfile\")`. The admin-only guard is bypassed and `config.set()` at line 271 proceeds to write the attacker-supplied value.\n\nThe value is cast as a `file` type in `parser.py:300-305`, which resolves it via `os.path.realpath()` but performs no further validation:\n\n```python\nelif typ in (\"file\", \"folder\"):\n    return (\n        \"\"\n        if value in (None, \"\")\n        else os.path.realpath(os.path.expanduser(os.fsdecode(value)))\n    )\n```\n\nOn server restart with SSL enabled, the webserver loads the attacker-controlled paths (`webserver_thread.py:22-23,51-52`):\n\n```python\nself.certfile = self.pyload.config.get(\"webui\", \"ssl_certfile\")\nself.keyfile = self.pyload.config.get(\"webui\", \"ssl_keyfile\")\n# ...\nself.server.ssl_adapter = BuiltinSSLAdapter(\n    self.certfile, self.keyfile, self.certchain\n)\n```\n\n## PoC\n\nPrerequisites: A pyLoad instance with SSL enabled and a non-admin user account that has SETTINGS permission.\n\n**Step 1:** Authenticate as the non-admin user to get a session cookie:\n```bash\ncurl -c cookies.txt -X POST \u0027http://localhost:8000/login\u0027 \\\n  -d \u0027username=settingsuser\u0026password=password123\u0027\n```\n\n**Step 2:** Set the SSL certificate to an attacker-controlled file path:\n```bash\ncurl -b cookies.txt -X POST \u0027http://localhost:8000/json/save_config\u0027 \\\n  -H \u0027Content-Type: application/json\u0027 \\\n  -d \u0027{\"category\": \"core\", \"config\": {\"webui|ssl_certfile\": \"/tmp/attacker.crt\"}}\u0027\n```\nExpected response: `true` (config saved successfully)\n\n**Step 3:** Set the SSL key to an attacker-controlled file path:\n```bash\ncurl -b cookies.txt -X POST \u0027http://localhost:8000/json/save_config\u0027 \\\n  -H \u0027Content-Type: application/json\u0027 \\\n  -d \u0027{\"category\": \"core\", \"config\": {\"webui|ssl_keyfile\": \"/tmp/attacker.key\"}}\u0027\n```\nExpected response: `true` (config saved successfully)\n\n**Step 4:** Set the SSL certificate chain (never protected):\n```bash\ncurl -b cookies.txt -X POST \u0027http://localhost:8000/json/save_config\u0027 \\\n  -H \u0027Content-Type: application/json\u0027 \\\n  -d \u0027{\"category\": \"core\", \"config\": {\"webui|ssl_certchain\": \"/tmp/attacker-chain.crt\"}}\u0027\n```\nExpected response: `true` (config saved successfully)\n\n**Step 5:** After the server restarts, it will load the attacker\u0027s certificate and key for all HTTPS connections.\n\n## Impact\n\nA non-admin user with SETTINGS permission can replace the SSL certificate and key used by the pyLoad HTTPS server. When the server restarts (or is restarted by an admin), it will serve HTTPS using the attacker\u0027s certificate/key pair. This enables:\n\n- **Man-in-the-Middle attacks:** The attacker, possessing the private key for the now-active certificate, can intercept and decrypt all HTTPS traffic to the pyLoad instance, including admin credentials and session tokens.\n- **Credential theft:** All users (including admins) connecting over HTTPS will have their credentials exposed to the attacker.\n- **Configuration tampering:** With intercepted admin credentials, the attacker can escalate to full admin access.\n\nThe attack requires SSL to already be enabled by an admin (the `use_ssl` option is correctly protected), the attacker to place certificate/key files on the filesystem (potentially achievable via pyLoad\u0027s download functionality), and a server restart.\n\n## Recommended Fix\n\nFix the option names in `ADMIN_ONLY_CORE_OPTIONS` and add the missing `ssl_certchain` option in `src/pyload/core/api/__init__.py`:\n\n```python\nADMIN_ONLY_CORE_OPTIONS = {\n    (\"general\", \"storage_folder\"),\n    (\"log\", \"syslog_host\"),\n    (\"log\", \"syslog_port\"),\n    (\"proxy\", \"password\"),\n    (\"proxy\", \"username\"),\n    (\"reconnect\", \"script\"),\n    (\"webui\", \"host\"),\n    (\"webui\", \"ssl_certfile\"),    # Fixed: was \"ssl_cert\"\n    (\"webui\", \"ssl_keyfile\"),     # Fixed: was \"ssl_key\"\n    (\"webui\", \"ssl_certchain\"),   # Added: was missing entirely\n    (\"webui\", \"use_ssl\"),\n}\n```",
  "id": "GHSA-ppvx-rwh9-7rj7",
  "modified": "2026-06-08T19:09:03Z",
  "published": "2026-04-08T00:04:34Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/pyload/pyload/security/advisories/GHSA-ppvx-rwh9-7rj7"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-35586"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/pyload/pyload"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/pyload-ng/PYSEC-2026-123.yaml"
    }
  ],
  "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"
    }
  ],
  "summary": "pyload-ng: Authorization Bypass for SSL Certificate/Key Configuration Due to Option Name Mismatch in pyload-ng"
}

GHSA-PPXJ-47MH-CMJ8

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

Insufficient Access Control in the firmware for Intel(R) E810 Ethernet Controllers before version 1.4.1.13 may allow a privileged user to potentially enable denial of service via local access.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2020-24497"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-02-17T14:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Insufficient Access Control in the firmware for Intel(R) E810 Ethernet Controllers before version 1.4.1.13 may allow a privileged user to potentially enable denial of service via local access.",
  "id": "GHSA-ppxj-47mh-cmj8",
  "modified": "2022-05-24T17:42:29Z",
  "published": "2022-05-24T17:42:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-24497"
    },
    {
      "type": "WEB",
      "url": "https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00456.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-PQ68-R59W-PQ6C

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

The Bluetooth Low Energy Secure Manager Protocol (SMP) implementation in Texas Instruments SimpleLink SIMPLELINK-CC2640R2-SDK through 2.2.3 allows the Diffie-Hellman check during the Secure Connection pairing to be skipped if the Link Layer encryption setup is performed earlier. An attacker in radio range can achieve arbitrary read/write access to protected GATT service data, cause a denial of service, or possibly control a device's function by establishing an encrypted session with an unauthenticated Long Term Key (LTK).

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2020-13593"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-08-31T15:15:00Z",
    "severity": "MODERATE"
  },
  "details": "The Bluetooth Low Energy Secure Manager Protocol (SMP) implementation in Texas Instruments SimpleLink SIMPLELINK-CC2640R2-SDK through 2.2.3 allows the Diffie-Hellman check during the Secure Connection pairing to be skipped if the Link Layer encryption setup is performed earlier. An attacker in radio range can achieve arbitrary read/write access to protected GATT service data, cause a denial of service, or possibly control a device\u0027s function by establishing an encrypted session with an unauthenticated Long Term Key (LTK).",
  "id": "GHSA-pq68-r59w-pq6c",
  "modified": "2022-05-24T17:26:58Z",
  "published": "2022-05-24T17:26:58Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-13593"
    },
    {
      "type": "WEB",
      "url": "https://asset-group.github.io/cves.html"
    },
    {
      "type": "WEB",
      "url": "https://asset-group.github.io/disclosures/sweyntooth"
    },
    {
      "type": "WEB",
      "url": "http://www.ti.com/tool/BLE-STACK"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-PQ86-J2C2-47F6

Vulnerability from github – Published: 2026-05-11 19:39 – Updated: 2026-06-09 10:23
VLAI
Summary
MantisBT: Authorization Bypass in Bugnote Editing via Issue Update API
Details

The mc_issue_update() function in MantisBT allows users having update_bug_threshold access (UPDATER, with default settings) to edit, change view state, and modify time tracking on bugnotes belonging to other users — bypassing the default DEVELOPER (level 55) threshold required by the dedicated mc_issue_note_update() function.

Impact

  1. UPDATER can edit notes by DEVELOPER/MANAGER/ADMIN — bypassing the DEVELOPER threshold
  2. UPDATER can change private notes to public — exposing confidential internal discussion
  3. UPDATER can change public notes to private — hiding information from reporters/viewers

Patches

  • 6e58fae4f22efdc3987f903c8ba2611de17a9435

Workarounds

None

Credits

Thanks to the following security researchers for independently discovering and responsibly reporting the issue. - Vishal Shukla - Tristan Madani (@TristanInSec) from Talence Security

This advisory's contents was largely copied from Tristan's well-written report.

Severity
5.3 (Medium)
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.28.1"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "mantisbt/mantisbt"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.28.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-42070"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-11T19:39:31Z",
    "nvd_published_at": "2026-05-28T21:16:29Z",
    "severity": "MODERATE"
  },
  "details": "The mc_issue_update() function in MantisBT allows users having *update_bug_threshold* access (UPDATER, with default settings) to edit, change view state, and modify time tracking on bugnotes belonging to other users \u2014 bypassing the default DEVELOPER (level 55) threshold required by the dedicated mc_issue_note_update() function.\n\n### Impact\n1. UPDATER can edit notes by DEVELOPER/MANAGER/ADMIN \u2014 bypassing the DEVELOPER threshold\n2. UPDATER can change private notes to public \u2014 exposing confidential internal discussion\n3. UPDATER can change public notes to private \u2014 hiding information from reporters/viewers\n\n### Patches\n- 6e58fae4f22efdc3987f903c8ba2611de17a9435\n\n### Workarounds\nNone\n\n### Credits\nThanks to the following security researchers for independently discovering and responsibly reporting the issue.\n- Vishal Shukla \n- Tristan Madani (@TristanInSec) from Talence Security \n\nThis advisory\u0027s contents was largely copied from Tristan\u0027s well-written report.",
  "id": "GHSA-pq86-j2c2-47f6",
  "modified": "2026-06-09T10:23:43Z",
  "published": "2026-05-11T19:39:31Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/mantisbt/mantisbt/security/advisories/GHSA-pq86-j2c2-47f6"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42070"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mantisbt/mantisbt/commit/6e58fae4f22efdc3987f903c8ba2611de17a9435"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/mantisbt/mantisbt"
    },
    {
      "type": "WEB",
      "url": "https://mantisbt.org/bugs/view.php?id=37089"
    },
    {
      "type": "WEB",
      "url": "https://mantisbt.org/bugs/view.php?id=37093"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "MantisBT: Authorization Bypass in Bugnote Editing via Issue Update API"
}

GHSA-PQP2-X3GP-9G37

Vulnerability from github – Published: 2026-04-07 15:30 – Updated: 2026-04-07 15:30
VLAI
Details

An issue that allowed MCP agents to access certificate information from outside of their authorized organization scope has been resolved. This is an instance of CWE-863: Incorrect Authorization, and has an estimated CVSS score of CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:L/I:N/A:N (3.0 Low). This issue was fixed in version 4.0.260203.0 of the runZero Platform.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-5379"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-07T15:17:47Z",
    "severity": "LOW"
  },
  "details": "An issue that allowed MCP agents to access certificate information from outside of their authorized organization scope has been resolved. This is an instance of CWE-863: Incorrect Authorization, and has an estimated CVSS score of CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:L/I:N/A:N (3.0 Low). This issue was fixed in version 4.0.260203.0 of the runZero Platform.",
  "id": "GHSA-pqp2-x3gp-9g37",
  "modified": "2026-04-07T15:30:52Z",
  "published": "2026-04-07T15:30:52Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-5379"
    },
    {
      "type": "WEB",
      "url": "https://help.runzero.com/docs/release-notes/#402602030"
    },
    {
      "type": "WEB",
      "url": "https://www.runzero.com/advisories/runzero-platform-mcp-cert-infoleak-cve-2026-5379"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-PQPW-CVM4-8MV9

Vulnerability from github – Published: 2026-07-09 20:54 – Updated: 2026-07-09 20:54
VLAI
Summary
Avo: Direct attachment upload endpoint lacks upload authorization and bypasses field-level upload policy
Details

Summary

Avo's direct attachment upload endpoint lacks server-side upload authorization and bypasses the documented field-level upload policy methods such as upload_{FIELD_ID}?.

An authenticated Avo user who can reach the Avo attachment upload endpoint can replace or add attachment content, including binary content, filename, and content-type metadata, on a resolved record even when both update? and upload_<field>? policies deny the operation.

This primarily affects multi-role Avo Pro/Advanced-style deployments where non-administrator or restricted operator users can reach Avo and per-record or per-field operations are expected to be enforced by policies.

Details

Avo exposes a direct attachment upload endpoint:

POST /<avo-root>/avo_api/resources/:resource_name/:id/attachments/

The vulnerable code path is Avo::AttachmentsController#create:

  • app/controllers/avo/attachments_controller.rb:9-24

Current behavior:

def create
  blob = ActiveStorage::Blob.create_and_upload! io: params[:file].to_io, filename: params[:filename]
  association_name = BaseResource.valid_attachment_name(@record, params[:attachment_key])

  if association_name
    @record.send(association_name).attach blob
  elsif params[:key].blank?
    raise ActionController::BadRequest.new(...)
  end

  render json: {
    url: main_app.url_for(blob),
    href: main_app.url_for(blob)
  }
end

This endpoint creates an ActiveStorage::Blob before validating the requested attachment association and before any upload authorization could be enforced. If attachment_key resolves to an association, the blob is attached to the target record. If the request uses the key-based/Trix path, the endpoint can still persist the blob and return url/href even when no attachment association is resolved on the target record.

The controller never calls:

  • @resource.authorization.authorize_action("upload_<field>?", record: @record, ...)
  • @resource.authorization.authorize_action("update?", record: @record, ...)

This is inconsistent with the rest of Avo's file authorization implementation. The field-level file authorization concern defines upload authorization as:

  • lib/avo/fields/concerns/file_authorization.rb:11-12
  • lib/avo/fields/concerns/file_authorization.rb:25-27
def can_upload_file?
  authorize_file_action(:upload)
end

def authorize_file_action(action)
  authorize_action("#{action}_#{id}?", record: record, raise_exception: false)
end

That upload policy is used by UI components to decide whether to render upload controls, but the server-side upload endpoint does not enforce the same policy. A user can therefore bypass the policy by directly POSTing to the endpoint.

By contrast, attachment deletion does call attachment-specific authorization:

  • app/controllers/avo/attachments_controller.rb:27-65
def destroy
  if authorized_to :delete
    ...
  end
end

def authorized_to(action)
  @resource.authorization.authorize_action("#{action}_#{params[:attachment_name]}?", record: @record, raise_exception: false)
end

The asymmetry is:

  • destroy: calls delete_<attachment_name>?
  • create: does not call upload_<attachment_key>? or update?

The field-level upload authorization intent is also documented by Avo:

  • Issue #1624 requested the "Ability to police each file upload/download/delete". https://github.com/avo-hq/avo/issues/1624
  • PR #1625 introduced upload_cover_photo? as an example upload policy method. https://github.com/avo-hq/avo/pull/1625
  • PR #1667 clarified the policy semantics: "From now on, only field level authorization will be considered. If it is defined and returns true, the action will be granted; otherwise, it will not." https://github.com/avo-hq/avo/pull/1667
  • The current Avo authorization documentation lists upload_{FIELD_ID}? as the policy method controlling whether a user can upload an attachment, stating: "Controls whether the user can upload the attachment." https://docs.avohq.io/4.0/authorization.html
  • The same documentation says the same upload_file? policy method will be used to "authorize the file upload" in action file fields. https://docs.avohq.io/4.0/authorization.html

Affected versions observed:

  • PoC-confirmed: Avo 3.31.2, commit 46aa6b3bc9e3283110c39e58cfec8bb95adc1897
  • Same vulnerable code path by source inspection: origin/main HEAD as of 2026-05-29, 9e23ddc88f2b1e762e4a5ec35a6f86370ac16c73
  • Same vulnerable code path by source inspection: Avo v4.0.0.beta.26, 6d339595a27f8779cb99b4aa38ddc97cb702b30f
  • Same vulnerable code path by source inspection: origin/4-dev at version 4.0.0.beta.40, 7ab9794f8b044b11b9677cdc57547d99cf96c3f3

Suggested affected range for the GitHub Security Advisory form:

>= 2.28.0

Rationale:

  • The direct attachment upload endpoint exists without upload authorization from commit ab5f5970e2aa76e6ca0a95bf04f510ba7ed5e858 (feature: trix attachments, 2021-04-24), first included in tag v1.4.0.
  • The documented field-level upload policy bypass is confirmed from commit 667049ceeda838394214489693d088708d9da77d (feature: field level file authorization, 2023-03-12), first included in tag v2.28.0.
  • PR #1667 later clarified the field-level-only grant/deny semantics in commit 31b6ef94f8cc4c340a2a75eec36c838cda933ce7, first included in tag v2.30.1.

From a narrow missing-authorization perspective, the issue exists from v1.4.0; the >= 2.28.0 range is a conservative submission range anchored to the documented field-level upload policy boundary.

Fixed version: to be determined by maintainers.

PoC

A local request spec was used to reproduce the issue. The PoC adds pundit to the test group and replaces Avo::Services::AuthorizationService with a test double. The test double records every authorize_action invocation and, when invoked, delegates the decision to a PostPolicy resolved via Pundit.policy!.

The policy setup is:

  • PostPolicy#update? returns false
  • PostPolicy#upload_attachments? returns false
  • PostPolicy#upload_cover_photo? returns false
  • PostPolicy#method_missing returns true for all other policy methods ending in ?, simulating a user with general read access but explicit update/upload denial
  • the replacement authorization service records all authorize_action calls

The open-source repository does not include Avo Pro's authorization client. The critical observation is independent of which client is plugged in: the vulnerable endpoint never invokes authorize_action at all, so the call list remains empty.

The PoC user has roles: {admin: true}, which is required only to pass the dummy app's coarse route-level guard:

authenticate :user, ->(user) { user.is_admin? }

The vulnerability under test is one layer below that guard: the fine-grained record/field authorization that Avo Pro/Pundit deployments would normally enforce. The dummy route gate is not part of Avo's upload policy decision. In a deployment where non-admin operators reach Avo through a different authentication rule, AttachmentsController#create would still skip authorize_action for the upload.

Policy scoping is orthogonal to this finding. Even if apply_policy filtered the record set during lookup, AttachmentsController#create would still not authorize the upload action itself for records that survive the scope.

The spec demonstrates:

  1. Normal record update is denied by policy and does not persist changes.
  2. Direct upload with attachment_key=cover_photo succeeds even though PostPolicy#upload_cover_photo? returns false, replacing the existing has_one_attached cover_photo blob.
  3. Direct upload with attachment_key=attachments succeeds even though PostPolicy#upload_attachments? returns false, adding to a has_many_attached association.
  4. Direct upload with params[:key] and no attachment association succeeds, creates an ActiveStorage::Blob, and returns url/href without attaching the blob to the record.
  5. The direct upload requests do not invoke the replacement authorization service at all.

The full request-spec patch can be provided in this advisory thread if useful.

Verification environment:

  • Ruby 3.3.1
  • Avo 3.31.2
  • Commit 46aa6b3bc9e3283110c39e58cfec8bb95adc1897

Impact

This is a missing server-side authorization vulnerability in Avo's direct attachment upload endpoint.

The primary affected deployments are Avo Pro/Advanced-style multi-role deployments where non-administrator or restricted operator users can reach Avo, and per-record/per-field operations are expected to be enforced by policies.

In such deployments, an authenticated Avo user can add or replace attachment content on a resolved record even when the host application policy denies both:

  • record update, for example update?
  • field-level upload, for example upload_cover_photo? or upload_attachments?

For has_one_attached fields, the demonstrated impact is replacement of a protected attachment field with attacker-controlled content. The attacker controls the uploaded binary content, filename, and content-type metadata for the reachable field.

For key-based/Trix upload flows, the endpoint can persist a blob and return a URL even when no attachment association is resolved. This means the endpoint should not be left as an unauthenticated blob creation and URL return path for authenticated Avo users.

In admin-only deployments following the Avo Community pattern, practical exposure is much lower because the only users who can reach the endpoint are already trusted to perform record updates through the normal CRUD path.

Suggested fix direction:

  • validate the requested attachment_key before any blob is stored
  • perform upload authorization before ActiveStorage::Blob.create_and_upload!
  • derive the policy method from the validated association name rather than raw request input
  • apply an equivalent authorization decision to supported params[:key] / Trix upload flows before blob creation or URL return
  • return a JSON-compatible 403 Forbidden response when upload authorization is denied

The default Avo::Services::AuthorizationService#authorize_action returns true in lib/avo/services/authorization_service.rb:34-35, so applications without a custom authorization client should not see a behavior change from adding an authorization call. Deployments with custom/Pro authorization clients that explicitly deny upload would gain enforcement at this endpoint.

No official Avo-level workaround was confirmed in this review. Until a fix is available, applications can reduce exposure by ensuring only fully trusted administrators can access Avo routes.

Applications needing an immediate mitigation may override or monkey-patch Avo::AttachmentsController#create to authorize uploads before blob creation. Any mitigation should be tested against the application's Avo authorization client and upload UI, because the endpoint is used by Trix/file upload flows. If a mitigation falls back to update? for key-based/Trix uploads, that is a conservative behavior change for applications that currently allow read-only operators to use those uploads; those deployments should replace the fallback with an explicit rich-text upload policy.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "avo"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.28.0"
            },
            {
              "fixed": "3.32.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-53769"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-09T20:54:10Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nAvo\u0027s direct attachment upload endpoint lacks server-side upload authorization and bypasses the documented field-level upload policy methods such as `upload_{FIELD_ID}?`.\n\nAn authenticated Avo user who can reach the Avo attachment upload endpoint can replace or add attachment content, including binary content, filename, and content-type metadata, on a resolved record even when both `update?` and `upload_\u003cfield\u003e?` policies deny the operation.\n\nThis primarily affects multi-role Avo Pro/Advanced-style deployments where non-administrator or restricted operator users can reach Avo and per-record or per-field operations are expected to be enforced by policies.\n\n### Details\n\nAvo exposes a direct attachment upload endpoint:\n\n```text\nPOST /\u003cavo-root\u003e/avo_api/resources/:resource_name/:id/attachments/\n```\n\nThe vulnerable code path is `Avo::AttachmentsController#create`:\n\n- `app/controllers/avo/attachments_controller.rb:9-24`\n\nCurrent behavior:\n\n```ruby\ndef create\n  blob = ActiveStorage::Blob.create_and_upload! io: params[:file].to_io, filename: params[:filename]\n  association_name = BaseResource.valid_attachment_name(@record, params[:attachment_key])\n\n  if association_name\n    @record.send(association_name).attach blob\n  elsif params[:key].blank?\n    raise ActionController::BadRequest.new(...)\n  end\n\n  render json: {\n    url: main_app.url_for(blob),\n    href: main_app.url_for(blob)\n  }\nend\n```\n\nThis endpoint creates an `ActiveStorage::Blob` before validating the requested attachment association and before any upload authorization could be enforced. If `attachment_key` resolves to an association, the blob is attached to the target record. If the request uses the key-based/Trix path, the endpoint can still persist the blob and return `url`/`href` even when no attachment association is resolved on the target record.\n\nThe controller never calls:\n\n- `@resource.authorization.authorize_action(\"upload_\u003cfield\u003e?\", record: @record, ...)`\n- `@resource.authorization.authorize_action(\"update?\", record: @record, ...)`\n\nThis is inconsistent with the rest of Avo\u0027s file authorization implementation. The field-level file authorization concern defines upload authorization as:\n\n- `lib/avo/fields/concerns/file_authorization.rb:11-12`\n- `lib/avo/fields/concerns/file_authorization.rb:25-27`\n\n```ruby\ndef can_upload_file?\n  authorize_file_action(:upload)\nend\n\ndef authorize_file_action(action)\n  authorize_action(\"#{action}_#{id}?\", record: record, raise_exception: false)\nend\n```\n\nThat upload policy is used by UI components to decide whether to render upload controls, but the server-side upload endpoint does not enforce the same policy. A user can therefore bypass the policy by directly POSTing to the endpoint.\n\nBy contrast, attachment deletion does call attachment-specific authorization:\n\n- `app/controllers/avo/attachments_controller.rb:27-65`\n\n```ruby\ndef destroy\n  if authorized_to :delete\n    ...\n  end\nend\n\ndef authorized_to(action)\n  @resource.authorization.authorize_action(\"#{action}_#{params[:attachment_name]}?\", record: @record, raise_exception: false)\nend\n```\n\nThe asymmetry is:\n\n- `destroy`: calls `delete_\u003cattachment_name\u003e?`\n- `create`: does not call `upload_\u003cattachment_key\u003e?` or `update?`\n\nThe field-level upload authorization intent is also documented by Avo:\n\n- Issue #1624 requested the \"Ability to police each file upload/download/delete\".\n  https://github.com/avo-hq/avo/issues/1624\n- PR #1625 introduced `upload_cover_photo?` as an example upload policy method.\n  https://github.com/avo-hq/avo/pull/1625\n- PR #1667 clarified the policy semantics: \"From now on, only field level\n  authorization will be considered. If it is defined and returns true, the\n  action will be granted; otherwise, it will not.\"\n  https://github.com/avo-hq/avo/pull/1667\n- The current Avo authorization documentation lists `upload_{FIELD_ID}?` as the\n  policy method controlling whether a user can upload an attachment, stating:\n  \"Controls whether the user can upload the attachment.\"\n  https://docs.avohq.io/4.0/authorization.html\n- The same documentation says the same `upload_file?` policy method will be used\n  to \"authorize the file upload\" in action file fields.\n  https://docs.avohq.io/4.0/authorization.html\n\nAffected versions observed:\n\n- PoC-confirmed: Avo `3.31.2`, commit\n  `46aa6b3bc9e3283110c39e58cfec8bb95adc1897`\n- Same vulnerable code path by source inspection: `origin/main` HEAD as of\n  2026-05-29,\n  `9e23ddc88f2b1e762e4a5ec35a6f86370ac16c73`\n- Same vulnerable code path by source inspection: Avo `v4.0.0.beta.26`,\n  `6d339595a27f8779cb99b4aa38ddc97cb702b30f`\n- Same vulnerable code path by source inspection: `origin/4-dev` at version\n  `4.0.0.beta.40`,\n  `7ab9794f8b044b11b9677cdc57547d99cf96c3f3`\n\nSuggested affected range for the GitHub Security Advisory form:\n\n```text\n\u003e= 2.28.0\n```\n\nRationale:\n\n- The direct attachment upload endpoint exists without upload authorization from\n  commit `ab5f5970e2aa76e6ca0a95bf04f510ba7ed5e858` (`feature: trix\n  attachments`, 2021-04-24), first included in tag `v1.4.0`.\n- The documented field-level upload policy bypass is confirmed from commit\n  `667049ceeda838394214489693d088708d9da77d` (`feature: field level file\n  authorization`, 2023-03-12), first included in tag `v2.28.0`.\n- PR #1667 later clarified the field-level-only grant/deny semantics in commit\n  `31b6ef94f8cc4c340a2a75eec36c838cda933ce7`, first included in tag\n  `v2.30.1`.\n\nFrom a narrow missing-authorization perspective, the issue exists from\n`v1.4.0`; the `\u003e= 2.28.0` range is a conservative submission range anchored to\nthe documented field-level upload policy boundary.\n\nFixed version: to be determined by maintainers.\n\n### PoC\n\nA local request spec was used to reproduce the issue. The PoC adds `pundit` to\nthe test group and replaces\n`Avo::Services::AuthorizationService` with a test double. The test double\nrecords every `authorize_action` invocation and, when invoked, delegates the\ndecision to a `PostPolicy` resolved via `Pundit.policy!`.\n\nThe policy setup is:\n\n- `PostPolicy#update?` returns `false`\n- `PostPolicy#upload_attachments?` returns `false`\n- `PostPolicy#upload_cover_photo?` returns `false`\n- `PostPolicy#method_missing` returns `true` for all other policy methods ending\n  in `?`, simulating a user with general read access but explicit update/upload\n  denial\n- the replacement authorization service records all `authorize_action` calls\n\nThe open-source repository does not include Avo Pro\u0027s authorization client. The\ncritical observation is independent of which client is plugged in: the vulnerable\nendpoint never invokes `authorize_action` at all, so the call list remains empty.\n\nThe PoC user has `roles: {admin: true}`, which is required only to pass the\ndummy app\u0027s coarse route-level guard:\n\n```ruby\nauthenticate :user, -\u003e(user) { user.is_admin? }\n```\n\nThe vulnerability under test is one layer below that guard: the fine-grained\nrecord/field authorization that Avo Pro/Pundit deployments would normally\nenforce. The dummy route gate is not part of Avo\u0027s upload policy decision. In a\ndeployment where non-admin operators reach Avo through a different\nauthentication rule, `AttachmentsController#create` would still skip\n`authorize_action` for the upload.\n\nPolicy scoping is orthogonal to this finding. Even if `apply_policy` filtered\nthe record set during lookup, `AttachmentsController#create` would still not\nauthorize the upload action itself for records that survive the scope.\n\nThe spec demonstrates:\n\n1. Normal record update is denied by policy and does not persist changes.\n2. Direct upload with `attachment_key=cover_photo` succeeds even though\n   `PostPolicy#upload_cover_photo?` returns `false`, replacing the existing\n   `has_one_attached` `cover_photo` blob.\n3. Direct upload with `attachment_key=attachments` succeeds even though\n   `PostPolicy#upload_attachments?` returns `false`, adding to a\n   `has_many_attached` association.\n4. Direct upload with `params[:key]` and no attachment association succeeds,\n   creates an `ActiveStorage::Blob`, and returns `url`/`href` without attaching\n   the blob to the record.\n5. The direct upload requests do not invoke the replacement authorization\n   service at all.\n\nThe full request-spec patch can be provided in this advisory thread if useful.\n\nVerification environment:\n\n- Ruby `3.3.1`\n- Avo `3.31.2`\n- Commit `46aa6b3bc9e3283110c39e58cfec8bb95adc1897`\n\n### Impact\n\nThis is a missing server-side authorization vulnerability in Avo\u0027s direct\nattachment upload endpoint.\n\nThe primary affected deployments are Avo Pro/Advanced-style multi-role\ndeployments where non-administrator or restricted operator users can reach Avo,\nand per-record/per-field operations are expected to be enforced by policies.\n\nIn such deployments, an authenticated Avo user can add or replace attachment\ncontent on a resolved record even when the host application policy denies both:\n\n- record update, for example `update?`\n- field-level upload, for example `upload_cover_photo?` or\n  `upload_attachments?`\n\nFor `has_one_attached` fields, the demonstrated impact is replacement of a\nprotected attachment field with attacker-controlled content. The attacker\ncontrols the uploaded binary content, filename, and content-type metadata for\nthe reachable field.\n\nFor key-based/Trix upload flows, the endpoint can persist a blob and return a\nURL even when no attachment association is resolved. This means the endpoint\nshould not be left as an unauthenticated blob creation and URL return path for\nauthenticated Avo users.\n\nIn admin-only deployments following the Avo Community pattern, practical\nexposure is much lower because the only users who can reach the endpoint are\nalready trusted to perform record updates through the normal CRUD path.\n\nSuggested fix direction:\n\n- validate the requested `attachment_key` before any blob is stored\n- perform upload authorization before `ActiveStorage::Blob.create_and_upload!`\n- derive the policy method from the validated association name rather than raw\n  request input\n- apply an equivalent authorization decision to supported `params[:key]` / Trix\n  upload flows before blob creation or URL return\n- return a JSON-compatible `403 Forbidden` response when upload authorization is\n  denied\n\nThe default `Avo::Services::AuthorizationService#authorize_action` returns\n`true` in `lib/avo/services/authorization_service.rb:34-35`, so applications\nwithout a custom authorization client should not see a behavior change from\nadding an authorization call. Deployments with custom/Pro authorization clients\nthat explicitly deny upload would gain enforcement at this endpoint.\n\nNo official Avo-level workaround was confirmed in this review. Until a fix is\navailable, applications can reduce exposure by ensuring only fully trusted\nadministrators can access Avo routes.\n\nApplications needing an immediate mitigation may override or monkey-patch\n`Avo::AttachmentsController#create` to authorize uploads before blob creation.\nAny mitigation should be tested against the application\u0027s Avo authorization\nclient and upload UI, because the endpoint is used by Trix/file upload flows.\nIf a mitigation falls back to `update?` for key-based/Trix uploads, that is a\nconservative behavior change for applications that currently allow read-only\noperators to use those uploads; those deployments should replace the fallback\nwith an explicit rich-text upload policy.",
  "id": "GHSA-pqpw-cvm4-8mv9",
  "modified": "2026-07-09T20:54:10Z",
  "published": "2026-07-09T20:54:10Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/avo-hq/avo/security/advisories/GHSA-pqpw-cvm4-8mv9"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/avo-hq/avo"
    },
    {
      "type": "WEB",
      "url": "https://github.com/avo-hq/avo/releases/tag/v3.32.0"
    }
  ],
  "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"
    }
  ],
  "summary": "Avo: Direct attachment upload endpoint lacks upload authorization and bypasses field-level upload policy"
}

GHSA-PQR3-XMR4-GR42

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

Improper access control in the Intel(R) Data Center Manager software before version 4.1 may allow an unauthenticated user to potentially enable escalation of privilege via adjacent access.

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

{
  "affected": [],
  "aliases": [
    "CVE-2022-23182"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-08-18T20:15:00Z",
    "severity": "HIGH"
  },
  "details": "Improper access control in the Intel(R) Data Center Manager software before version 4.1 may allow an unauthenticated user to potentially enable escalation of privilege via adjacent access.",
  "id": "GHSA-pqr3-xmr4-gr42",
  "modified": "2022-08-20T00:00:38Z",
  "published": "2022-08-19T00:00:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-23182"
    },
    {
      "type": "WEB",
      "url": "https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00662.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-PQWR-PHVV-V49F

Vulnerability from github – Published: 2025-03-20 12:32 – Updated: 2025-03-21 17:29
VLAI
Summary
Open WebUI Allows Admin Deletion via API Endpoint
Details

In open-webui/open-webui version v0.3.8, there is an improper privilege management vulnerability. The application allows an attacker, acting as an admin, to delete other administrators via the API endpoint http://0.0.0.0:8080/api/v1/users/{uuid_administrator}. This action is restricted by the user interface but can be performed through direct API calls.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "open-webui"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "0.3.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-7039"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-269",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-03-21T17:29:56Z",
    "nvd_published_at": "2025-03-20T10:15:35Z",
    "severity": "HIGH"
  },
  "details": "In open-webui/open-webui version v0.3.8, there is an improper privilege management vulnerability. The application allows an attacker, acting as an admin, to delete other administrators via the API endpoint `http://0.0.0.0:8080/api/v1/users/{uuid_administrator}`. This action is restricted by the user interface but can be performed through direct API calls.",
  "id": "GHSA-pqwr-phvv-v49f",
  "modified": "2025-03-21T17:29:56Z",
  "published": "2025-03-20T12:32:45Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-7039"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/open-webui/open-webui"
    },
    {
      "type": "WEB",
      "url": "https://huntr.com/bounties/27fc8a5a-546e-4cf2-8edb-df42e36518fc"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Open WebUI Allows Admin Deletion via API Endpoint"
}

GHSA-PR32-4GHW-RWCV

Vulnerability from github – Published: 2026-03-11 18:30 – Updated: 2026-05-13 18:30
VLAI
Details

Incorrect resolving of namespaces in composite databases in Neo4j Enterprise edition prior to versions 2026.02 and 5.26.22 can lead to the following scenario:  an admin that intends to give a user an access to a remote database constituent "namespace.name" will inadvertently grant access to any local database or remote alias called "name". If such database or alias doesn't exist when the command is run, the privileges will apply if it's created in the future.

Severity
7.2 (High)
CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H
2.0 (Low)
CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:A/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/AU:N/R:U/V:D/RE:M/U:Green
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-1497"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-11T16:16:22Z",
    "severity": "LOW"
  },
  "details": "Incorrect resolving of namespaces in composite databases in Neo4j Enterprise edition prior to versions 2026.02 and 5.26.22 can lead to the following scenario:\u00a0\nan admin that intends to give a user an access to a remote database constituent \"namespace.name\" will inadvertently grant access to any local database or remote alias called \"name\". If such database or alias doesn\u0027t exist when the command is run, the privileges will apply if it\u0027s created in the future.",
  "id": "GHSA-pr32-4ghw-rwcv",
  "modified": "2026-05-13T18:30:31Z",
  "published": "2026-03-11T18:30:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-1497"
    },
    {
      "type": "WEB",
      "url": "https://neo4j.com/security/CVE-2026-1497"
    }
  ],
  "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:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:A/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:N/R:U/V:D/RE:M/U:Green",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-PR8C-FV23-2J59

Vulnerability from github – Published: 2025-02-01 00:31 – Updated: 2025-02-03 18:30
VLAI
Details

macrozheng mall-tiny 1.0.1 is vulnerable to Incorrect Access Control via the logout function. After a user logs out, their token is still available and fetches information in the logged-in state.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-57433"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-284",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-01-31T22:15:12Z",
    "severity": "HIGH"
  },
  "details": "macrozheng mall-tiny 1.0.1 is vulnerable to Incorrect Access Control via the logout function. After a user logs out, their token is still available and fetches information in the logged-in state.",
  "id": "GHSA-pr8c-fv23-2j59",
  "modified": "2025-02-03T18:30:40Z",
  "published": "2025-02-01T00:31:02Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57433"
    },
    {
      "type": "WEB",
      "url": "https://github.com/peccc/restful_vul/blob/main/mall_tiny_logout_failed/mall_tiny_logout_failed.md"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/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