Common Weakness Enumeration

CWE-862

Allowed-with-Review

Missing Authorization

Abstraction: Class · Status: Incomplete

The product does not perform an authorization check when an actor attempts to access a resource or perform an action.

14892 vulnerabilities reference this CWE, most recent first.

GHSA-F5R8-7H4F-JR9X

Vulnerability from github – Published: 2022-05-24 17:35 – Updated: 2023-08-23 17:55
VLAI
Summary
Moodle incorrect access control
Details

A vulnerability was found in Moodle where users with "Log in as" capability in a course context (typically, course managers) may gain access to some site administration capabilities by "logging in as" a System manager. This affects 3.9 to 3.9.1, 3.8 to 3.8.4, 3.7 to 3.7.7, 3.5 to 3.5.13 and earlier unsupported versions. This is fixed in 3.9.2, 3.8.5, 3.7.8 and 3.5.14.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.9.1"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "moodle/moodle"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.9"
            },
            {
              "fixed": "3.9.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.8.4"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "moodle/moodle"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.8"
            },
            {
              "fixed": "3.8.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.7.7"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "moodle/moodle"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.7"
            },
            {
              "fixed": "3.7.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.5.13"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "moodle/moodle"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.5"
            },
            {
              "fixed": "3.5.14"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2020-25629"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-284",
      "CWE-862"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-07-13T22:41:47Z",
    "nvd_published_at": "2020-12-08T01:15:00Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability was found in Moodle where users with \"Log in as\" capability in a course context (typically, course managers) may gain access to some site administration capabilities by \"logging in as\" a System manager. This affects 3.9 to 3.9.1, 3.8 to 3.8.4, 3.7 to 3.7.7, 3.5 to 3.5.13 and earlier unsupported versions. This is fixed in 3.9.2, 3.8.5, 3.7.8 and 3.5.14.",
  "id": "GHSA-f5r8-7h4f-jr9x",
  "modified": "2023-08-23T17:55:15Z",
  "published": "2022-05-24T17:35:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-25629"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/moodle/moodle"
    },
    {
      "type": "WEB",
      "url": "https://moodle.org/mod/forum/discuss.php?d=410841"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Moodle incorrect access control"
}

GHSA-F5VM-7V68-F9FF

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

Insufficient authentication security controls in the browser-based authentication components in Amazon Athena ODBC driver before 2.1.0.0 might allow a threat actor to intercept or hijack authentication sessions due to insufficient protections in the browser-based authentication flows.

To remediate this issue, users should upgrade to version 2.1.0.0.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-35561"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-03T21:17:12Z",
    "severity": "CRITICAL"
  },
  "details": "Insufficient authentication security controls in the browser-based authentication components in Amazon Athena ODBC driver before 2.1.0.0 might allow a threat actor to intercept or hijack authentication sessions due to insufficient protections in the browser-based authentication flows.\n\nTo remediate this issue, users should upgrade to version 2.1.0.0.",
  "id": "GHSA-f5vm-7v68-f9ff",
  "modified": "2026-04-03T21:31:43Z",
  "published": "2026-04-03T21:31:43Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-35561"
    },
    {
      "type": "WEB",
      "url": "https://aws.amazon.com/security/security-bulletins/2026-013-aws"
    },
    {
      "type": "WEB",
      "url": "https://docs.aws.amazon.com/athena/latest/ug/odbc-v2-driver-release-notes.html"
    },
    {
      "type": "WEB",
      "url": "https://downloads.athena.us-east-1.amazonaws.com/drivers/ODBC/v2.1.0.0/Linux/AmazonAthenaODBC-2.1.0.0.rpm"
    },
    {
      "type": "WEB",
      "url": "https://downloads.athena.us-east-1.amazonaws.com/drivers/ODBC/v2.1.0.0/Mac/Intel/AmazonAthenaODBC-2.1.0.0_x86.pkg"
    },
    {
      "type": "WEB",
      "url": "https://downloads.athena.us-east-1.amazonaws.com/drivers/ODBC/v2.1.0.0/Mac/arm/AmazonAthenaODBC-2.1.0.0_arm.pkg"
    },
    {
      "type": "WEB",
      "url": "https://downloads.athena.us-east-1.amazonaws.com/drivers/ODBC/v2.1.0.0/Windows/AmazonAthenaODBC-2.1.0.0.msi"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/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-F637-W7P2-M7FX

Vulnerability from github – Published: 2026-06-24 17:41 – Updated: 2026-06-24 17:41
VLAI
Summary
OliveTin: ValidateArgumentType API Endpoint's Missing Authentication Allows Action and Argument Enumeration
Details

Summary

The ValidateArgumentType RPC endpoint in service/internal/api/api.go does not perform any authentication or authorization checks. Unlike all other data-returning API endpoints, it does not call auth.UserFromApiCall or checkDashboardAccess. When AuthRequireGuestsToLogin is enabled (the security-conscious configuration), this endpoint remains accessible to unauthenticated users and can be used as an oracle to enumerate valid action binding IDs and their argument configurations.

Details

Root Cause

The ValidateArgumentType handler at service/internal/api/api.go:726 has no authentication check:

func (api *oliveTinAPI) ValidateArgumentType(ctx ctx.Context, req *connect.Request[apiv1.ValidateArgumentTypeRequest]) (*connect.Response[apiv1.ValidateArgumentTypeResponse], error) {
    if api.argumentNotFoundForValidation(req.Msg) {
        return nil, connect.NewError(connect.CodeNotFound, fmt.Errorf("action or argument not found for binding ID %s", req.Msg.BindingId))
    }

    err := api.validateArgumentTypeInternal(req.Msg)
    desc := ""
    if err != nil {
        desc = err.Error()
    }

    return connect.NewResponse(&apiv1.ValidateArgumentTypeResponse{
        Valid:       err == nil,
        Description: desc,
    }), nil
}

Compare this with adjacent endpoints that DO have auth checks:

// WhoAmI - has auth check
func (api *oliveTinAPI) WhoAmI(ctx ctx.Context, req *connect.Request[apiv1.WhoAmIRequest]) ... {
    user := auth.UserFromApiCall(ctx, req, api.cfg)
    if err := api.checkDashboardAccess(user); err != nil {
        return nil, err
    }
    ...
}

// GetDashboard - has auth check
func (api *oliveTinAPI) GetDashboard(ctx ctx.Context, req *connect.Request[apiv1.GetDashboardRequest]) ... {
    user := auth.UserFromApiCall(ctx, req, api.cfg)
    if err := api.checkDashboardAccess(user); err != nil {
        return nil, err
    }
    ...
}

Oracle Behavior

The endpoint provides different responses based on whether the binding and argument exist:

  • Valid binding + valid argument: Returns {valid: true/false, description: "..."} (200 OK)

  • Valid binding + invalid argument: Returns CodeNotFound error

  • Invalid binding: Returns CodeNotFound error

While the error messages for the last two cases are identical, an attacker who knows a valid binding ID (or can guess one from action title SHA256) can enumerate argument names by observing which ones return 200 OK vs CodeNotFound.

Binding ID Predictability

Binding IDs are SHA256 hashes of action titles (see service/internal/executor/executor_actions.go). Since action titles are typically short, human-readable strings (e.g., "Ping", "Restart Service", "Deploy"), an attacker can precompute hashes of likely titles and test them against this endpoint.

Scope

This finding is only meaningful when AuthRequireGuestsToLogin: true is configured. In the default configuration where guests have full dashboard access, the action information is already visible through the dashboard API. When AuthRequireGuestsToLogin is true, checkDashboardAccess blocks guest access to other endpoints but NOT to ValidateArgumentType.

PoC

Prerequisites

  • OliveTin instance with AuthRequireGuestsToLogin: true configured

Step 1: Verify other endpoints require auth

Confirm that regular endpoints reject unauthenticated requests:

curl -s -X POST http://localhost:1337/api/GetDashboard \
  -H "Content-Type: application/json" \
  -d "{}"
# Returns: CodePermissionDenied - "guests are not allowed to access the dashboard"

Step 2: Enumerate binding IDs via ValidateArgumentType

Test candidate binding IDs (SHA256 of guessed action titles):

# Test if an action titled "Ping" exists
BINDING_ID=$(echo -n "Ping" | sha256sum | cut -d" " -f1)
curl -s -X POST http://localhost:1337/api/ValidateArgumentType \
  -H "Content-Type: application/json" \
  -d "{\"bindingId\":\"$BINDING_ID\",\"argumentName\":\"test\",\"value\":\"x\",\"type\":\"ascii\"}"
# If action exists: returns CodeNotFound (argument "test" not found for this binding)
# If action does not exist: returns CodeNotFound (same message, but confirms the oracle)

Step 3: Enumerate argument names for a known binding

Once a valid binding ID is known, brute-force argument names:

# Test if argument "target" exists for the Ping action
curl -s -X POST http://localhost:1337/api/ValidateArgumentType \
  -H "Content-Type: application/json" \
  -d "{\"bindingId\":\"$BINDING_ID\",\"argumentName\":\"target\",\"value\":\"test\",\"type\":\"ascii\"}"
# If argument exists: returns {valid: true/false} (200 OK) -- CONFIRMED
# If argument does not exist: returns CodeNotFound error

Impact

  1. Information Disclosure: Unauthenticated users can enumerate which actions exist (by testing binding IDs) and which arguments each action accepts (by testing argument names). This reveals the server configuration to unauthorized parties.

  2. Reconnaissance for Further Attacks: The enumerated information (action names, argument names, argument types) provides valuable reconnaissance for more targeted attacks such as the ot_ prefix argument injection (see advisory 001) or social engineering.

  3. Limited Scope: This is only exploitable when AuthRequireGuestsToLogin: true is configured. In the default configuration, guests already have full access to the dashboard which exposes the same information.

Recommended Fix

Add authentication and dashboard access checks to the ValidateArgumentType handler, consistent with all other data-returning endpoints:

func (api *oliveTinAPI) ValidateArgumentType(ctx ctx.Context, req *connect.Request[apiv1.ValidateArgumentTypeRequest]) (*connect.Response[apiv1.ValidateArgumentTypeResponse], error) {
    // Add auth check consistent with other endpoints
    user := auth.UserFromApiCall(ctx, req, api.cfg)
    if err := api.checkDashboardAccess(user); err != nil {
        return nil, err
    }

    if api.argumentNotFoundForValidation(req.Msg) {
        return nil, connect.NewError(connect.CodeNotFound, fmt.Errorf("action or argument not found for binding ID %s", req.Msg.BindingId))
    }

    err := api.validateArgumentTypeInternal(req.Msg)
    desc := ""
    if err != nil {
        desc = err.Error()
    }

    return connect.NewResponse(&apiv1.ValidateArgumentTypeResponse{
        Valid:       err == nil,
        Description: desc,
    }), nil
}
Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/OliveTin/OliveTin"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.0.0-20260521230847-a3865704c854"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-48709"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-24T17:41:01Z",
    "nvd_published_at": "2026-06-15T21:17:15Z",
    "severity": "LOW"
  },
  "details": "## Summary\n\nThe `ValidateArgumentType` RPC endpoint in `service/internal/api/api.go` does not perform any authentication or authorization checks. Unlike all other data-returning API endpoints, it does not call `auth.UserFromApiCall` or `checkDashboardAccess`. When `AuthRequireGuestsToLogin` is enabled (the security-conscious configuration), this endpoint remains accessible to unauthenticated users and can be used as an oracle to enumerate valid action binding IDs and their argument configurations.\n\n## Details\n\n### Root Cause\n\nThe `ValidateArgumentType` handler at `service/internal/api/api.go:726` has no authentication check:\n\n```go\nfunc (api *oliveTinAPI) ValidateArgumentType(ctx ctx.Context, req *connect.Request[apiv1.ValidateArgumentTypeRequest]) (*connect.Response[apiv1.ValidateArgumentTypeResponse], error) {\n    if api.argumentNotFoundForValidation(req.Msg) {\n        return nil, connect.NewError(connect.CodeNotFound, fmt.Errorf(\"action or argument not found for binding ID %s\", req.Msg.BindingId))\n    }\n\n    err := api.validateArgumentTypeInternal(req.Msg)\n    desc := \"\"\n    if err != nil {\n        desc = err.Error()\n    }\n\n    return connect.NewResponse(\u0026apiv1.ValidateArgumentTypeResponse{\n        Valid:       err == nil,\n        Description: desc,\n    }), nil\n}\n```\n\nCompare this with adjacent endpoints that DO have auth checks:\n\n```go\n// WhoAmI - has auth check\nfunc (api *oliveTinAPI) WhoAmI(ctx ctx.Context, req *connect.Request[apiv1.WhoAmIRequest]) ... {\n    user := auth.UserFromApiCall(ctx, req, api.cfg)\n    if err := api.checkDashboardAccess(user); err != nil {\n        return nil, err\n    }\n    ...\n}\n\n// GetDashboard - has auth check\nfunc (api *oliveTinAPI) GetDashboard(ctx ctx.Context, req *connect.Request[apiv1.GetDashboardRequest]) ... {\n    user := auth.UserFromApiCall(ctx, req, api.cfg)\n    if err := api.checkDashboardAccess(user); err != nil {\n        return nil, err\n    }\n    ...\n}\n```\n\n### Oracle Behavior\n\nThe endpoint provides different responses based on whether the binding and argument exist:\n\n- **Valid binding + valid argument**: Returns `{valid: true/false, description: \"...\"}` (200 OK)\n\n- **Valid binding + invalid argument**: Returns `CodeNotFound` error\n\n- **Invalid binding**: Returns `CodeNotFound` error\n\nWhile the error messages for the last two cases are identical, an attacker who knows a valid binding ID (or can guess one from action title SHA256) can enumerate argument names by observing which ones return 200 OK vs CodeNotFound.\n\n\n\n\n\n\n\n\n\n### Binding ID Predictability\n\nBinding IDs are SHA256 hashes of action titles (see `service/internal/executor/executor_actions.go`). Since action titles are typically short, human-readable strings (e.g., \"Ping\", \"Restart Service\", \"Deploy\"), an attacker can precompute hashes of likely titles and test them against this endpoint.\n\n### Scope\nThis finding is only meaningful when `AuthRequireGuestsToLogin: true` is configured. In the default configuration where guests have full dashboard access, the action information is already visible through the dashboard API.\nWhen `AuthRequireGuestsToLogin` is true, `checkDashboardAccess` blocks guest access to other endpoints but NOT to `ValidateArgumentType`.\n\n## PoC\n\n### Prerequisites\n\n- OliveTin instance with `AuthRequireGuestsToLogin: true` configured\n\n### Step 1: Verify other endpoints require auth\n\nConfirm that regular endpoints reject unauthenticated requests:\n\n```bash\ncurl -s -X POST http://localhost:1337/api/GetDashboard \\\n  -H \"Content-Type: application/json\" \\\n  -d \"{}\"\n# Returns: CodePermissionDenied - \"guests are not allowed to access the dashboard\"\n```\n\n### Step 2: Enumerate binding IDs via ValidateArgumentType\n\nTest candidate binding IDs (SHA256 of guessed action titles):\n\n```bash\n# Test if an action titled \"Ping\" exists\nBINDING_ID=$(echo -n \"Ping\" | sha256sum | cut -d\" \" -f1)\ncurl -s -X POST http://localhost:1337/api/ValidateArgumentType \\\n  -H \"Content-Type: application/json\" \\\n  -d \"{\\\"bindingId\\\":\\\"$BINDING_ID\\\",\\\"argumentName\\\":\\\"test\\\",\\\"value\\\":\\\"x\\\",\\\"type\\\":\\\"ascii\\\"}\"\n# If action exists: returns CodeNotFound (argument \"test\" not found for this binding)\n# If action does not exist: returns CodeNotFound (same message, but confirms the oracle)\n```\n\n### Step 3: Enumerate argument names for a known binding\n\nOnce a valid binding ID is known, brute-force argument names:\n\n```bash\n# Test if argument \"target\" exists for the Ping action\ncurl -s -X POST http://localhost:1337/api/ValidateArgumentType \\\n  -H \"Content-Type: application/json\" \\\n  -d \"{\\\"bindingId\\\":\\\"$BINDING_ID\\\",\\\"argumentName\\\":\\\"target\\\",\\\"value\\\":\\\"test\\\",\\\"type\\\":\\\"ascii\\\"}\"\n# If argument exists: returns {valid: true/false} (200 OK) -- CONFIRMED\n# If argument does not exist: returns CodeNotFound error\n```\n\n## Impact\n\n1. **Information Disclosure**: Unauthenticated users can enumerate which actions exist (by testing binding IDs) and which arguments each action accepts (by testing argument names). This reveals the server configuration to unauthorized parties.\n\n2. **Reconnaissance for Further Attacks**: The enumerated information (action names, argument names, argument types) provides valuable reconnaissance for more targeted attacks such as the `ot_` prefix argument injection (see advisory 001) or social engineering.\n\n3. **Limited Scope**: This is only exploitable when `AuthRequireGuestsToLogin: true` is configured. In the default configuration, guests already have full access to the dashboard which exposes the same information.\n\n## Recommended Fix\n\nAdd authentication and dashboard access checks to the `ValidateArgumentType` handler, consistent with all other data-returning endpoints:\n\n```go\nfunc (api *oliveTinAPI) ValidateArgumentType(ctx ctx.Context, req *connect.Request[apiv1.ValidateArgumentTypeRequest]) (*connect.Response[apiv1.ValidateArgumentTypeResponse], error) {\n    // Add auth check consistent with other endpoints\n    user := auth.UserFromApiCall(ctx, req, api.cfg)\n    if err := api.checkDashboardAccess(user); err != nil {\n        return nil, err\n    }\n\n    if api.argumentNotFoundForValidation(req.Msg) {\n        return nil, connect.NewError(connect.CodeNotFound, fmt.Errorf(\"action or argument not found for binding ID %s\", req.Msg.BindingId))\n    }\n\n    err := api.validateArgumentTypeInternal(req.Msg)\n    desc := \"\"\n    if err != nil {\n        desc = err.Error()\n    }\n\n    return connect.NewResponse(\u0026apiv1.ValidateArgumentTypeResponse{\n        Valid:       err == nil,\n        Description: desc,\n    }), nil\n}\n```",
  "id": "GHSA-f637-w7p2-m7fx",
  "modified": "2026-06-24T17:41:01Z",
  "published": "2026-06-24T17:41:01Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/OliveTin/OliveTin/security/advisories/GHSA-f637-w7p2-m7fx"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-48709"
    },
    {
      "type": "WEB",
      "url": "https://github.com/OliveTin/OliveTin/commit/a3865704c854061452a4ab5f6d95de3312698ccd"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/OliveTin/OliveTin"
    },
    {
      "type": "WEB",
      "url": "https://github.com/OliveTin/OliveTin/releases/tag/3000.13.0"
    }
  ],
  "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"
    }
  ],
  "summary": "OliveTin: ValidateArgumentType API Endpoint\u0027s Missing Authentication Allows Action and Argument Enumeration"
}

GHSA-F647-638R-HXRW

Vulnerability from github – Published: 2026-02-19 18:31 – Updated: 2026-02-20 18:31
VLAI
Details

Missing Authorization vulnerability in PublishPress PublishPress Authors publishpress-authors allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects PublishPress Authors: from n/a through <= 4.10.1.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-25330"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-02-19T09:16:17Z",
    "severity": "MODERATE"
  },
  "details": "Missing Authorization vulnerability in PublishPress PublishPress Authors publishpress-authors allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects PublishPress Authors: from n/a through \u003c= 4.10.1.",
  "id": "GHSA-f647-638r-hxrw",
  "modified": "2026-02-20T18:31:27Z",
  "published": "2026-02-19T18:31:52Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-25330"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/Wordpress/Plugin/publishpress-authors/vulnerability/wordpress-publishpress-authors-plugin-4-10-1-broken-access-control-vulnerability?_s_id=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-F64C-Q58Q-9942

Vulnerability from github – Published: 2026-07-01 09:30 – Updated: 2026-07-01 09:30
VLAI
Details

The Motors – Car Dealership & Classified Listings Plugin plugin for WordPress is vulnerable to authorization bypass in all versions up to, and including, 1.4.111. This is due to the plugin not properly verifying that a user is authorized to perform an action. This makes it possible for authenticated attackers, with subscriber-level access and above, to mark or unmark any other user's car listing as sold by replaying a valid nonce harvested from their own listing against an arbitrary victim post ID, triggering a site-wide 'Sold' badge on the victim's listing and silently stripping its special_car featured post meta as a side effect. Exploitation requires the attacker to hold an active listing of their own (obtainable by a Subscriber via the plugin's add-listing form) in order to harvest a valid nonce for the 'stm_mark_as_sold_car' action, which can then be replayed against any other listing's post ID.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-12435"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-01T08:16:21Z",
    "severity": "MODERATE"
  },
  "details": "The Motors \u2013 Car Dealership \u0026 Classified Listings Plugin plugin for WordPress is vulnerable to authorization bypass in all versions up to, and including, 1.4.111. This is due to the plugin not properly verifying that a user is authorized to perform an action. This makes it possible for authenticated attackers, with subscriber-level access and above, to mark or unmark any other user\u0027s car listing as sold by replaying a valid nonce harvested from their own listing against an arbitrary victim post ID, triggering a site-wide \u0027Sold\u0027 badge on the victim\u0027s listing and silently stripping its special_car featured post meta as a side effect. Exploitation requires the attacker to hold an active listing of their own (obtainable by a Subscriber via the plugin\u0027s add-listing form) in order to harvest a valid nonce for the \u0027stm_mark_as_sold_car\u0027 action, which can then be replayed against any other listing\u0027s post ID.",
  "id": "GHSA-f64c-q58q-9942",
  "modified": "2026-07-01T09:30:25Z",
  "published": "2026-07-01T09:30:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-12435"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/motors-car-dealership-classified-listings/tags/1.4.108/includes/vehicle_functions.php#L2400"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/motors-car-dealership-classified-listings/tags/1.4.108/includes/vehicle_functions.php#L2402"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/motors-car-dealership-classified-listings/tags/1.4.108/templates/listing-cars/listing-list-owner-actions.php#L74"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/motors-car-dealership-classified-listings/tags/1.4.110/includes/vehicle_functions.php#L2400"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/motors-car-dealership-classified-listings/tags/1.4.110/includes/vehicle_functions.php#L2402"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/motors-car-dealership-classified-listings/tags/1.4.110/templates/listing-cars/listing-list-owner-actions.php#L74"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/changeset?sfp_email=\u0026sfph_mail=\u0026reponame=\u0026old=3577332%40motors-car-dealership-classified-listings\u0026new=3577332%40motors-car-dealership-classified-listings\u0026sfp_email=\u0026sfph_mail="
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/5238c344-d685-4eab-822c-d3c1050cc982?source=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-F653-W82J-53XF

Vulnerability from github – Published: 2025-04-04 15:31 – Updated: 2026-04-01 18:34
VLAI
Details

Missing Authorization vulnerability in shiptrack Booking Calendar and Notification allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Booking Calendar and Notification: from n/a through 4.0.3.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-31381"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-04-04T14:15:22Z",
    "severity": "MODERATE"
  },
  "details": "Missing Authorization vulnerability in shiptrack Booking Calendar and Notification allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Booking Calendar and Notification: from n/a through 4.0.3.",
  "id": "GHSA-f653-w82j-53xf",
  "modified": "2026-04-01T18:34:28Z",
  "published": "2025-04-04T15:31:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-31381"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/wordpress/plugin/booking-calendar-and-notification/vulnerability/wordpress-booking-calendar-and-notification-plugin-4-0-3-broken-authentication-vulnerability?_s_id=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-F655-743R-35CR

Vulnerability from github – Published: 2024-06-09 09:30 – Updated: 2024-06-09 09:30
VLAI
Details

Missing Authorization vulnerability in Mr.Ebabi New Order Notification for Woocommerce.This issue affects New Order Notification for Woocommerce: from n/a through 2.0.2.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-31098"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-06-09T09:15:11Z",
    "severity": "HIGH"
  },
  "details": "Missing Authorization vulnerability in Mr.Ebabi New Order Notification for Woocommerce.This issue affects New Order Notification for Woocommerce: from n/a through 2.0.2.",
  "id": "GHSA-f655-743r-35cr",
  "modified": "2024-06-09T09:30:34Z",
  "published": "2024-06-09T09:30:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-31098"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/vulnerability/new-order-notification-for-woocommerce/wordpress-new-order-notification-for-woocommerce-plugin-2-0-2-broken-access-control-vulnerability?_s_id=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-F65Q-PVV3-2XQ6

Vulnerability from github – Published: 2024-11-01 15:31 – Updated: 2024-11-01 15:31
VLAI
Details

Missing Authorization vulnerability in Packlink Shipping S.L. Packlink PRO shipping module allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Packlink PRO shipping module: from n/a through 3.4.6.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-38740"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-11-01T15:15:33Z",
    "severity": "MODERATE"
  },
  "details": "Missing Authorization vulnerability in Packlink Shipping S.L. Packlink PRO shipping module allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Packlink PRO shipping module: from n/a through 3.4.6.",
  "id": "GHSA-f65q-pvv3-2xq6",
  "modified": "2024-11-01T15:31:58Z",
  "published": "2024-11-01T15:31:58Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38740"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/vulnerability/packlink-pro-shipping/wordpress-packlink-pro-shipping-module-plugin-3-4-8-broken-access-control-vulnerability?_s_id=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-F65R-H4G3-3H9H

Vulnerability from github – Published: 2026-06-26 20:34 – Updated: 2026-06-26 20:34
VLAI
Summary
Backpropagate: backprop ui --auth and backprop ui --share do not enforce authentication
Details

Summary

In backpropagate >= 1.1.0, the optional Reflex web UI (pip install backpropagate[ui], launched via backprop ui) exposes a training control plane: dataset upload, model load, training start/stop, multi-run orchestration, GGUF export, and HuggingFace Hub push.

The CLI accepts two operator-facing flags intended as security controls:

  • --auth user:pass — documented as "require HTTP Basic authentication on every request to the UI."
  • --share — documented as "expose the UI on a public address; requires --auth."

When --auth user:pass is passed, the CLI prints Auth: enabled (user: <username>) to confirm to the operator that authentication is active, then exports BACKPROPAGATE_UI_AUTH=user:pass to the subprocess that launches the Reflex backend.

The Reflex backend (backpropagate/ui_app/**) never reads BACKPROPAGATE_UI_AUTH. No authentication middleware is registered. No request-level guard runs. No WebSocket upgrade guard runs. Any client that reaches the bound port — local or remote, depending on whether --share is used — has full UI access.

An inline comment at backpropagate/cli.py:1217-1218 in the v1.1.0 source documents the gap: "For Phase 1 the variable is exported but Reflex doesn't read it yet." This comment was internal-facing; the user-facing documentation (README, CHANGELOG, SHIP_GATE) advertised the contract as enforced.

This advisory is filed primarily because the runtime contradicted an operator-facing security claim. Code-only bugs of comparable shape (auth check missing entirely from a path) would already warrant disclosure; the additional false-promise dimension raises the severity.

Impact

An attacker who reaches the bound port can:

  • Read uploaded datasets rendered in the UI preview, including content of any JSONL/CSV/TXT file the legitimate operator has uploaded for fine-tuning.
  • Trigger arbitrary training runs against any base model the operator has installed locally or that can be downloaded from HuggingFace.
  • Trigger HuggingFace Hub pushes to repositories named via the UI input (subject to the operator's local HF token's scope — typically all repos owned by the operator).
  • Cause disk-fill DoS via the rx.upload endpoint (no size cap, no extension filter, no per-session count cap in v1.1.0 / v1.1.1).
  • Read model paths (source_model_path, dataset_path, model, uploaded_path) which are user-supplied and bypass the safe_path() helper that lives in backpropagate/ui_security.py (path validation is dead code on the Reflex surface in v1.1.0 / v1.1.1).

The combination of unauthenticated training control, HF push target spoofing, and path-input traversal makes the affected endpoint suitable for both data exfiltration (reading uploaded training data) and supply-chain attacks (pushing tampered model weights to the operator's HF account).

The local-only default (no --share) reduces exposure to a host-local attacker. The --share flag is documented as a "public URL" feature; operators who used --share --auth user:pass had no warning that the auth half was inert.

Patches

Fixed in v1.2.0 (released 2026-05-23). The patch implements real ASGI middleware via rx.App(api_transformer=basic_auth_transformer) that gates HTTP routes AND the /_event WebSocket upgrade. Four modes (no_auth_local_only / token_auto / explicit_creds / production), HMAC-signed cookie validated PRE-websocket.accept(), Host + Origin allowlists. The middleware ships alongside a 4-layer defense in depth at the cli.py / ui_app/app.py / rxconfig.py / env-strip surfaces so direct python -m reflex run invocations (bypassing the CLI guard) also enforce authentication.

Upgrade with:

  • pip: pip install --upgrade backpropagate
  • npm: npm install -g @mcptoolshop/backpropagate@latest

Full release notes: https://github.com/mcp-tool-shop-org/backpropagate/blob/main/CHANGELOG.md#120---2026-05-23

Workarounds

If users cannot upgrade immediately:

  1. Do not pass --auth or --share to backprop ui. Run the UI with no flags (backprop ui); it will bind to localhost and accept any client that can reach 127.0.0.1.
  2. For remote access, use SSH port-forwarding instead of --share: # On the client: ssh -L 7860:localhost:7860 <training-host> # On the server: backprop ui # no --share # Then open http://localhost:7860 in your local browser. SSH provides the authentication layer the Reflex UI did not.
  3. Audit existing deployments. If any host running backpropagate >= 1.1.0 has previously been launched with --share, treat any uploaded training data, model paths, or HF push targets visible in that UI session as potentially exposed. Re-issue HF tokens that have been in use during such sessions.

Binary distribution gap. Standalone binaries (Windows .exe / macOS .app via PyInstaller) failed to build for v1.2.0 and will land in a follow-up patch release. In the interim, users who relied on the v1.1.x binary distribution should install the patched version via pip install backpropagate==1.2.0 to receive the auth-bypass fix. The v1.2.0 PyPI package and @mcptoolshop/backpropagate@1.2.0 npm package both carry the patched code.

Credit

Discovered by the dogfood-swarm Stage A audit on 2026-05-22 (finding ID FRONTEND-A-001, classified CRITICAL). The audit also surfaced contradicting documentation in CHANGELOG / SHIP_GATE / README; those were corrected in v1.2.0 alongside the runtime fix.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "backpropagate"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.1.0"
            },
            {
              "fixed": "1.2.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@mcptoolshop/backpropagate"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.1.0"
            },
            {
              "fixed": "1.2.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-48797"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1295",
      "CWE-358",
      "CWE-862"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-26T20:34:29Z",
    "nvd_published_at": "2026-06-17T13:20:43Z",
    "severity": "CRITICAL"
  },
  "details": "## Summary\n\nIn `backpropagate \u003e= 1.1.0`, the optional Reflex web UI (`pip install backpropagate[ui]`, launched via `backprop ui`) exposes a training control plane: dataset upload, model load, training start/stop, multi-run orchestration, GGUF export, and HuggingFace Hub push.\n\nThe CLI accepts two operator-facing flags intended as security controls:\n\n- `--auth user:pass` \u2014 documented as \"require HTTP Basic authentication on every request to the UI.\"\n- `--share` \u2014 documented as \"expose the UI on a public address; requires `--auth`.\"\n\nWhen `--auth user:pass` is passed, the CLI prints `Auth: enabled (user: \u003cusername\u003e)` to confirm to the operator that authentication is active, then exports `BACKPROPAGATE_UI_AUTH=user:pass` to the subprocess that launches the Reflex backend.\n\n**The Reflex backend (`backpropagate/ui_app/**`) never reads `BACKPROPAGATE_UI_AUTH`.** No authentication middleware is registered. No request-level guard runs. No WebSocket upgrade guard runs. Any client that reaches the bound port \u2014 local or remote, depending on whether `--share` is used \u2014 has full UI access.\n\nAn inline comment at `backpropagate/cli.py:1217-1218` in the v1.1.0 source documents the gap: *\"For Phase 1 the variable is exported but Reflex doesn\u0027t read it yet.\"* This comment was internal-facing; the user-facing documentation (README, CHANGELOG, SHIP_GATE) advertised the contract as enforced.\n\nThis advisory is filed primarily because the runtime contradicted an operator-facing security claim. Code-only bugs of comparable shape (auth check missing entirely from a path) would already warrant disclosure; the additional false-promise dimension raises the severity.\n\n## Impact\n\nAn attacker who reaches the bound port can:\n\n- **Read uploaded datasets** rendered in the UI preview, including content of any JSONL/CSV/TXT file the legitimate operator has uploaded for fine-tuning.\n- **Trigger arbitrary training runs** against any base model the operator has installed locally or that can be downloaded from HuggingFace.\n- **Trigger HuggingFace Hub pushes** to repositories named via the UI input (subject to the operator\u0027s local HF token\u0027s scope \u2014 typically all repos owned by the operator).\n- **Cause disk-fill DoS** via the `rx.upload` endpoint (no size cap, no extension filter, no per-session count cap in v1.1.0 / v1.1.1).\n- **Read model paths** (`source_model_path`, `dataset_path`, `model`, `uploaded_path`) which are user-supplied and bypass the `safe_path()` helper that lives in `backpropagate/ui_security.py` (path validation is dead code on the Reflex surface in v1.1.0 / v1.1.1).\n\nThe combination of unauthenticated training control, HF push target spoofing, and path-input traversal makes the affected endpoint suitable for both data exfiltration (reading uploaded training data) and supply-chain attacks (pushing tampered model weights to the operator\u0027s HF account).\n\nThe local-only default (no `--share`) reduces exposure to a host-local attacker. The `--share` flag is documented as a \"public URL\" feature; operators who used `--share --auth user:pass` had no warning that the auth half was inert.\n\n## Patches\n\nFixed in **v1.2.0** (released 2026-05-23). The patch implements real ASGI middleware via `rx.App(api_transformer=basic_auth_transformer)` that gates HTTP routes AND the `/_event` WebSocket upgrade. Four modes (`no_auth_local_only` / `token_auto` / `explicit_creds` / `production`), HMAC-signed cookie validated PRE-`websocket.accept()`, Host + Origin allowlists. The middleware ships alongside a 4-layer defense in depth at the cli.py / ui_app/app.py / rxconfig.py / env-strip surfaces so direct `python -m reflex run` invocations (bypassing the CLI guard) also enforce authentication.\n\nUpgrade with:\n\n- pip: `pip install --upgrade backpropagate`\n- npm: `npm install -g @mcptoolshop/backpropagate@latest`\n\nFull release notes: https://github.com/mcp-tool-shop-org/backpropagate/blob/main/CHANGELOG.md#120---2026-05-23\n\n## Workarounds\n\nIf users cannot upgrade immediately:\n\n1. **Do not pass `--auth` or `--share` to `backprop ui`.** Run the UI with no flags (`backprop ui`); it will bind to `localhost` and accept any client that can reach `127.0.0.1`.\n2. **For remote access, use SSH port-forwarding** instead of `--share`:\n   ```\n   # On the client:\n   ssh -L 7860:localhost:7860 \u003ctraining-host\u003e\n   # On the server:\n   backprop ui            # no --share\n   # Then open http://localhost:7860 in your local browser.\n   ```\n   SSH provides the authentication layer the Reflex UI did not.\n3. **Audit existing deployments.** If any host running `backpropagate \u003e= 1.1.0` has previously been launched with `--share`, treat any uploaded training data, model paths, or HF push targets visible in that UI session as potentially exposed. Re-issue HF tokens that have been in use during such sessions.\n\n**Binary distribution gap.** Standalone binaries (Windows .exe / macOS .app via PyInstaller) failed to build for v1.2.0 and will land in a follow-up patch release. In the interim, users who relied on the v1.1.x binary distribution should install the patched version via `pip install backpropagate==1.2.0` to receive the auth-bypass fix. The v1.2.0 PyPI package and `@mcptoolshop/backpropagate@1.2.0` npm package both carry the patched code.\n\n## Credit\n\nDiscovered by the dogfood-swarm Stage A audit on 2026-05-22 (finding ID `FRONTEND-A-001`, classified CRITICAL). The audit also surfaced contradicting documentation in CHANGELOG / SHIP_GATE / README; those were corrected in v1.2.0 alongside the runtime fix.",
  "id": "GHSA-f65r-h4g3-3h9h",
  "modified": "2026-06-26T20:34:29Z",
  "published": "2026-06-26T20:34:29Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/mcp-tool-shop-org/backpropagate/security/advisories/GHSA-f65r-h4g3-3h9h"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-48797"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/mcp-tool-shop-org/backpropagate"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mcp-tool-shop-org/backpropagate/releases/tag/v1.2.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Backpropagate: backprop ui --auth and backprop ui --share do not enforce authentication"
}

GHSA-F696-867G-2759

Vulnerability from github – Published: 2025-09-03 15:30 – Updated: 2025-11-05 20:43
VLAI
Summary
Jenkins OpenTelemetry Plugin missing permission check allows capturing credentials
Details

A missing permission check in Jenkins OpenTelemetry Plugin 3.1543.v8446b_92b_cd64 and earlier allows attackers with Overall/Read permission to connect to an attacker-specified URL using attacker-specified credentials IDs obtained through another method, capturing credentials stored in Jenkins.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "io.jenkins.plugins:opentelemetry"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.1543.1545.vf5a"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-58460"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-09-03T22:23:42Z",
    "nvd_published_at": "2025-09-03T15:15:39Z",
    "severity": "MODERATE"
  },
  "details": "A missing permission check in Jenkins OpenTelemetry Plugin 3.1543.v8446b_92b_cd64 and earlier allows attackers with Overall/Read permission to connect to an attacker-specified URL using attacker-specified credentials IDs obtained through another method, capturing credentials stored in Jenkins.",
  "id": "GHSA-f696-867g-2759",
  "modified": "2025-11-05T20:43:47Z",
  "published": "2025-09-03T15:30:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-58460"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jenkinsci/opentelemetry-plugin/commit/f5a4ec123769096ad9a4930ede56588b0fee40f3"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/jenkinsci/opentelemetry-plugin"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jenkinsci/opentelemetry-plugin/releases/tag/3.1543.1545.vf5a_4ec123769"
    },
    {
      "type": "WEB",
      "url": "https://www.jenkins.io/security/advisory/2025-09-03/#SECURITY-3602"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2025/09/03/4"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Jenkins OpenTelemetry Plugin missing permission check allows capturing credentials"
}

Mitigation
Architecture and Design
  • Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries.
  • Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
Mitigation
Architecture and Design

Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].

Mitigation MIT-4.4
Architecture and Design

Strategy: Libraries or Frameworks

  • Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
  • For example, consider using authorization frameworks such as the JAAS Authorization Framework [REF-233] and the OWASP ESAPI Access Control feature [REF-45].
Mitigation
Architecture and Design
  • For web applications, make sure that the access control mechanism is enforced correctly at the server side on every page. Users should not be able to access any unauthorized functionality or information by simply requesting direct access to that page.
  • One way to do this is to ensure that all pages containing sensitive information are not cached, and that all such pages restrict access to requests that are accompanied by an active and authenticated session token associated with a user who has the required permissions to access that page.
Mitigation
System Configuration Installation

Use the access control capabilities of your operating system and server environment and define your access control lists accordingly. Use a "default deny" policy when defining these ACLs.

CAPEC-665: Exploitation of Thunderbolt Protection Flaws

An adversary leverages a firmware weakness within the Thunderbolt protocol, on a computing device to manipulate Thunderbolt controller firmware in order to exploit vulnerabilities in the implementation of authorization and verification schemes within Thunderbolt protection mechanisms. Upon gaining physical access to a target device, the adversary conducts high-level firmware manipulation of the victim Thunderbolt controller SPI (Serial Peripheral Interface) flash, through the use of a SPI Programing device and an external Thunderbolt device, typically as the target device is booting up. If successful, this allows the adversary to modify memory, subvert authentication mechanisms, spoof identities and content, and extract data and memory from the target device. Currently 7 major vulnerabilities exist within Thunderbolt protocol with 9 attack vectors as noted in the Execution Flow.