Common Weakness Enumeration

CWE-863

Allowed-with-Review

Incorrect Authorization

Abstraction: Class · Status: Incomplete

The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check.

5550 vulnerabilities reference this CWE, most recent first.

GHSA-QRVC-X2CW-MGCP

Vulnerability from github – Published: 2021-12-14 00:01 – Updated: 2021-12-17 00:01
VLAI
Details

The Page/Post Content Shortcode WordPress plugin through 1.0 does not have proper authorisation in place, allowing users with a role as low as contributor to access draft/private/password protected/trashed posts/pages they should not be allowed to, including posts created by other users such as admins and editors.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-24819"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-12-13T11:15:00Z",
    "severity": "MODERATE"
  },
  "details": "The Page/Post Content Shortcode WordPress plugin through 1.0 does not have proper authorisation in place, allowing users with a role as low as contributor to access draft/private/password protected/trashed posts/pages they should not be allowed to, including posts created by other users such as admins and editors.",
  "id": "GHSA-qrvc-x2cw-mgcp",
  "modified": "2021-12-17T00:01:04Z",
  "published": "2021-12-14T00:01:03Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-24819"
    },
    {
      "type": "WEB",
      "url": "https://wpscan.com/vulnerability/c97b218c-b430-4301-884f-f64d0dd08f07"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-QRWJ-VH9X-GW5V

Vulnerability from github – Published: 2026-07-06 21:52 – Updated: 2026-07-06 21:52
VLAI
Summary
Coder's workspace agent API insecure redirect handling allowed cross-agent file read and write
Details

Summary

agentConn.apiClient() used the default redirect behavior of http.Client while its custom transport dialed the host from the request URL as long as the port was the workspace agent HTTP API port (4). Agent tailnet IPs are deterministic from agent UUIDs, so a malicious workspace agent could return a redirect to another agent's tailnet IP and cause the control-plane client to send the follow-up workspace agent API request to the victim agent instead of the intended agent.

Redirects that preserve the method and body, such as HTTP 307 and 308, allow replay of write and process-start requests. HTTP 301, 302 and 303 redirects only convert POST requests to GET requests, so they are sufficient to demonstrate redirected reads but not write or command-execution primitives.

Impact

An authenticated user with a running workspace and control of a modified workspace agent can redirect workspace agent API requests made to their agent toward another online workspace agent reachable on the tailnet. If the attacker knows the victim agent UUID, they can derive the victim's tailnet IP and target the victim's file APIs to read or write files as the victim workspace user.

In affected versions that expose the workspace agent process API, the same primitive can be chained to command execution as the victim workspace user by writing a payload through the redirected file API and then redirecting a process-start request to execute it. This crosses workspace and tenant boundaries.

Patches

The fix disables automatic redirect following for workspace agent API clients and pins all workspace agent API dials to the intended agent's deterministic tailnet address. Requests whose URL host does not match the intended agent are rejected instead of being dialed.

The fix was backported to all supported release lines:

Release line Patched version
2.34 v2.34.4
2.33 v2.33.10
2.32 v2.32.9
2.29 (ESR) v2.29.19

Workarounds

None. Upgrading is required.

Resources

  • Fix: #26600
Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/coder/coder/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.34.0"
            },
            {
              "fixed": "2.34.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/coder/coder/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.33.0"
            },
            {
              "fixed": "2.33.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/coder/coder/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.30.0"
            },
            {
              "fixed": "2.32.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/coder/coder/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.27.0"
            },
            {
              "fixed": "2.29.19"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-863",
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-06T21:52:31Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\n\n`agentConn.apiClient()` used the default redirect behavior of `http.Client` while its custom transport dialed the host from the request URL as long as the port was the workspace agent HTTP API port (`4`). Agent tailnet IPs are deterministic from agent UUIDs, so a malicious workspace agent could return a redirect to another agent\u0027s tailnet IP and cause the control-plane client to send the follow-up workspace agent API request to the victim agent instead of the intended agent.\n\nRedirects that preserve the method and body, such as HTTP 307 and 308, allow replay of write and process-start requests. HTTP 301, 302 and 303 redirects only convert POST requests to GET requests, so they are sufficient to demonstrate redirected reads but not write or command-execution primitives.\n\n### Impact\n\nAn authenticated user with a running workspace and control of a modified workspace agent can redirect workspace agent API requests made to their agent toward another online workspace agent reachable on the tailnet. If the attacker knows the victim agent UUID, they can derive the victim\u0027s tailnet IP and target the victim\u0027s file APIs to read or write files as the victim workspace user.\n\nIn affected versions that expose the workspace agent process API, the same primitive can be chained to command execution as the victim workspace user by writing a payload through the redirected file API and then redirecting a process-start request to execute it. This crosses workspace and tenant boundaries.\n\n### Patches\n\nThe fix disables automatic redirect following for workspace agent API clients and pins all workspace agent API dials to the intended agent\u0027s deterministic tailnet address. Requests whose URL host does not match the intended agent are rejected instead of being dialed.\n\nThe fix was backported to all supported release lines:\n\n| Release line | Patched version |\n|---|---|\n| 2.34 | [v2.34.4](https://github.com/coder/coder/releases/tag/v2.34.4) |\n| 2.33 | [v2.33.10](https://github.com/coder/coder/releases/tag/v2.33.10) |\n| 2.32 | [v2.32.9](https://github.com/coder/coder/releases/tag/v2.32.9) |\n| 2.29 (ESR) | [v2.29.19](https://github.com/coder/coder/releases/tag/v2.29.19) |\n\n### Workarounds\n\nNone. Upgrading is required.\n\n### Resources\n- Fix: #26600",
  "id": "GHSA-qrwj-vh9x-gw5v",
  "modified": "2026-07-06T21:52:31Z",
  "published": "2026-07-06T21:52:31Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/coder/coder/security/advisories/GHSA-qrwj-vh9x-gw5v"
    },
    {
      "type": "WEB",
      "url": "https://github.com/coder/coder/pull/26600"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/coder/coder"
    }
  ],
  "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:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Coder\u0027s workspace agent API insecure redirect handling allowed cross-agent file read and write"
}

GHSA-QV2Q-FRHR-PHX3

Vulnerability from github – Published: 2022-05-24 19:19 – Updated: 2022-07-13 00:01
VLAI
Details

An incorrect access control vulnerability exists in Sourcecodester Engineers Online Portal in PHP in nia_munoz_monitoring_system/admin/uploads. An attacker can leverage this vulnerability in order to bypass access controls and access all the files uploaded to the web server without the need of authentication or authorization.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-42671"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-11-05T13:15:00Z",
    "severity": "HIGH"
  },
  "details": "An incorrect access control vulnerability exists in Sourcecodester Engineers Online Portal in PHP in nia_munoz_monitoring_system/admin/uploads. An attacker can leverage this vulnerability in order to bypass access controls and access all the files uploaded to the web server without the need of authentication or authorization.",
  "id": "GHSA-qv2q-frhr-phx3",
  "modified": "2022-07-13T00:01:43Z",
  "published": "2022-05-24T19:19:50Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-42671"
    },
    {
      "type": "WEB",
      "url": "https://github.com/TheHackingRabbi/CVE-2021-42671"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nu11secur1ty/CVE-mitre/tree/main/CVE-2021-42671"
    },
    {
      "type": "WEB",
      "url": "https://www.sourcecodester.com/php/13115/engineers-online-portal-php.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-QV87-C5CQ-X7XF

Vulnerability from github – Published: 2022-07-13 00:01 – Updated: 2022-07-17 00:00
VLAI
Details

Improper authorization vulnerability in Knoxguard prior to SMR Jul-2022 Release 1 allows local attacker to disable keyguard and bypass Knoxguard lock by factory reset.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-33702"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-285",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-07-12T14:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Improper authorization vulnerability in Knoxguard prior to SMR Jul-2022 Release 1 allows local attacker to disable keyguard and bypass Knoxguard lock by factory reset.",
  "id": "GHSA-qv87-c5cq-x7xf",
  "modified": "2022-07-17T00:00:46Z",
  "published": "2022-07-13T00:01:54Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-33702"
    },
    {
      "type": "WEB",
      "url": "https://security.samsungmobile.com/securityUpdate.smsb?year=2022\u0026month=7"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-QV92-PXWH-47QF

Vulnerability from github – Published: 2025-07-30 00:32 – Updated: 2025-11-03 21:34
VLAI
Details

The issue was addressed with additional permissions checks. This issue is fixed in iPadOS 17.7.9, watchOS 11.6, visionOS 2.6, iOS 18.6 and iPadOS 18.6, macOS Sequoia 15.6, tvOS 18.6. An app may be able to access user-sensitive data.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-43230"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-07-30T00:15:35Z",
    "severity": "MODERATE"
  },
  "details": "The issue was addressed with additional permissions checks. This issue is fixed in iPadOS 17.7.9, watchOS 11.6, visionOS 2.6, iOS 18.6 and iPadOS 18.6, macOS Sequoia 15.6, tvOS 18.6. An app may be able to access user-sensitive data.",
  "id": "GHSA-qv92-pxwh-47qf",
  "modified": "2025-11-03T21:34:15Z",
  "published": "2025-07-30T00:32:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-43230"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/124147"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/124148"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/124149"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/124153"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/124154"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/124155"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2025/Jul/30"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2025/Jul/31"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2025/Jul/32"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2025/Jul/35"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2025/Jul/37"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-QV9C-RWMQ-RGM5

Vulnerability from github – Published: 2025-07-03 12:34 – Updated: 2025-07-03 12:34
VLAI
Details

Incorrect Authorization vulnerability in OpenText™ GroupWise allows Exploiting Incorrectly Configured Access Control Security Levels.

The vulnerability could allow unauthorized access to calendar items marked private.

This issue affects GroupWise versions 7 through 17.5, 23.4, 24.1, 24.2, 24.3, 24.4.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-0885"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-07-03T10:15:36Z",
    "severity": "LOW"
  },
  "details": "Incorrect Authorization vulnerability in OpenText\u2122 GroupWise allows Exploiting Incorrectly Configured Access Control Security Levels.\n\nThe vulnerability could allow unauthorized access to calendar items marked private.\n\nThis issue affects GroupWise versions 7 through 17.5, 23.4, 24.1, 24.2, 24.3, 24.4.",
  "id": "GHSA-qv9c-rwmq-rgm5",
  "modified": "2025-07-03T12:34:56Z",
  "published": "2025-07-03T12:34:56Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-0885"
    },
    {
      "type": "WEB",
      "url": "https://portal.microfocus.com/s/article/KM000041560?language=en_US"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:P/PR:H/UI:N/VC:L/VI:N/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:P/AU:Y/R:A/V:D/RE:L/U:Green",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-QVHF-3567-PC4V

Vulnerability from github – Published: 2022-05-24 17:10 – Updated: 2025-06-19 14:41
VLAI
Summary
Sandbox bypass vulnerability in Script Security Plugin
Details

Sandbox protection in Script Security Plugin 1.70 and earlier can be circumvented through: - Crafted constructor calls and bodies (due to an incomplete fix of SECURITY-582) - Crafted method calls on objects that implement GroovyInterceptable

This allows attackers able to specify and run sandboxed scripts to execute arbitrary code in the context of the Jenkins controller JVM.

Script Security Plugin 1.71 has additional restrictions and sanity checks to ensure that super constructors cannot be constructed without being intercepted by the sandbox. In addition, it also intercepts method calls on objects that implement GroovyInterceptable as calls to GroovyObject#invokeMethod(String, Object), which is on the list of dangerous signatures and should not be approved for use in the sandbox.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.70"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.jenkins-ci.plugins:script-security"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.71"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2020-2135"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-693",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-01-05T20:11:47Z",
    "nvd_published_at": "2020-03-09T16:15:00Z",
    "severity": "HIGH"
  },
  "details": "Sandbox protection in Script Security Plugin 1.70 and earlier can be circumvented through:\n- Crafted constructor calls and bodies (due to an incomplete fix of [SECURITY-582](https://www.jenkins.io/security/advisory/2017-08-07/#super-constructor-calls))\n- Crafted method calls on objects that implement `GroovyInterceptable`\n\nThis allows attackers able to specify and run sandboxed scripts to execute arbitrary code in the context of the Jenkins controller JVM.\n\nScript Security Plugin 1.71 has additional restrictions and sanity checks to ensure that super constructors cannot be constructed without being intercepted by the sandbox. In addition, it also intercepts method calls on objects that implement `GroovyInterceptable` as calls to `GroovyObject#invokeMethod(String, Object)`, which is on the list of dangerous signatures and should not be approved for use in the sandbox.",
  "id": "GHSA-qvhf-3567-pc4v",
  "modified": "2025-06-19T14:41:34Z",
  "published": "2022-05-24T17:10:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-2135"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jenkinsci/script-security-plugin/commit/5b1969e0bdf5cde04a165b847144756b28495788"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/jenkinsci/script-security-plugin"
    },
    {
      "type": "WEB",
      "url": "https://jenkins.io/security/advisory/2020-03-09/#SECURITY-1754"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2020/03/09/1"
    }
  ],
  "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": "Sandbox bypass vulnerability in Script Security Plugin"
}

GHSA-QVJ8-GWPM-4X49

Vulnerability from github – Published: 2026-06-22 09:30 – Updated: 2026-06-23 21:30
VLAI
Details

Authorization handling for component configuration verification requests in Apache NiFi 1.15.0 through 2.9.0 allows clients with read access to submit proposed configuration properties. The proposed properties override current configuration, enabling users with read access to invoke predefined verification methods with alternative settings. Apache NiFi installations that do not implement different levels of authorization for viewing and modifying component configuration are not subject to this vulnerability. Upgrading to Apache NiFi 2.10.0 is the recommended mitigation, requiring write access to submit configuration verification requests.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-44911"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-22T08:17:05Z",
    "severity": "LOW"
  },
  "details": "Authorization handling for component configuration verification requests in Apache NiFi 1.15.0 through 2.9.0 allows clients with read access to submit proposed configuration properties. The proposed properties override current configuration, enabling users with read access to invoke predefined verification methods with alternative settings. Apache NiFi installations that do not implement different levels of authorization for viewing and modifying component configuration are not subject to this vulnerability. Upgrading to Apache NiFi 2.10.0 is the recommended mitigation, requiring write access to submit configuration verification requests.",
  "id": "GHSA-qvj8-gwpm-4x49",
  "modified": "2026-06-23T21:30:27Z",
  "published": "2026-06-22T09:30:45Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44911"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/wrj3t4k2bwd2cztyp078f5kj3722qfzy"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2026/06/20/4"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:L/VI:L/VA:L/SC:L/SI:L/SA:L/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:Y/R:U/V:C/RE:L/U:Amber",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-QVM2-GFGR-C2H6

Vulnerability from github – Published: 2022-05-24 19:04 – Updated: 2022-07-13 00:01
VLAI
Details

Insufficient policy enforcement in Content Security Policy in Google Chrome prior to 91.0.4472.77 allowed a remote attacker to bypass content security policy via a crafted HTML page.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-30531"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-06-07T20:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Insufficient policy enforcement in Content Security Policy in Google Chrome prior to 91.0.4472.77 allowed a remote attacker to bypass content security policy via a crafted HTML page.",
  "id": "GHSA-qvm2-gfgr-c2h6",
  "modified": "2022-07-13T00:01:22Z",
  "published": "2022-05-24T19:04:11Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-30531"
    },
    {
      "type": "WEB",
      "url": "https://chromereleases.googleblog.com/2021/05/stable-channel-update-for-desktop_25.html"
    },
    {
      "type": "WEB",
      "url": "https://crbug.com/1115628"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/ETMZL6IHCTCTREEL434BQ4THQ7EOHJ43"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/PAT6EOXVQFE6JFMFQF4IKAOUQSHMHL54"
    },
    {
      "type": "WEB",
      "url": "https://security.gentoo.org/glsa/202107-06"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-QVP4-RPMR-XWRR

Vulnerability from github – Published: 2021-06-23 18:00 – Updated: 2021-06-22 20:50
VLAI
Summary
Possible bypass of token claim validation when OAuth2 Introspection caching is enabled
Details

Impact

When you make a request to an endpoint that requires the scope foo using an access token granted with that foo scope, introspection will be valid and that token will be cached. The problem comes when a second requests to an endpoint that requires the scope bar is made before the cache has expired. Whether the token is granted or not to the bar scope, introspection will be valid.

Patches

A patch will be released with v0.38.12-beta.1.

Workarounds

Per default, caching is disabled for the oauth2_introspection authenticator. When caching is disabled, this vulnerability does not exist.

Trace

The cache is checked in func (a *AuthenticatorOAuth2Introspection) Authenticate(...). From tokenFromCache() it seems that it only validates the token expiration date, but ignores whether the token has or not the proper scopes.

Post-Mortem

The vulnerability was introduced in PR #424. During review, we failed to require appropriate test coverage by the submitter which is the primary reason that the vulnerability passed the review process.

To avoid this from happening again we enabled codecov with a strict policy on the Ory Oathkeeper repository: Without an increase in code coverage the PR can not be merged.

To address this issue and any regressions we have added a test suite ensuring that the cache behaviour is correct in the different scenarios:

  • Scope strategy is none, cache is enabled, and requested_scope is not empty -> cache will not be used;
  • Scope strategy is none, cache is enabled, and requested_scope is empty -> cache will be used;
  • Scope strategy is not none, cache is enabled, and requested_scope is not empty -> cache will be used;

as well as validating if iss, aud, exp, token_use, and scope are validated.

Additionally, we added CodeQL scanning to the CI.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.38.11-beta.1"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/ory/oathkeeper"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.38.0-beta.2"
            },
            {
              "fixed": "0.38.12-beta.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-06-22T20:50:44Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Impact\n\nWhen you make a request to an endpoint that requires the scope `foo` using an access token granted with that `foo` scope, introspection will be valid and that token will be cached. The problem comes when a second requests to an endpoint that requires the scope `bar` is made before the cache has expired. Whether the token is granted or not to the `bar` scope, introspection will be valid.\n\n### Patches\n\nA patch will be released with `v0.38.12-beta.1`.\n\n### Workarounds\n\nPer default, caching is disabled for the `oauth2_introspection` authenticator. When caching is disabled, this vulnerability does not exist.\n\n### Trace\n\nThe cache is checked in [`func (a *AuthenticatorOAuth2Introspection) Authenticate(...)`](https://github.com/ory/oathkeeper/blob/6a31df1c3779425e05db1c2a381166b087cb29a4/pipeline/authn/authenticator_oauth2_introspection.go#L152). From [`tokenFromCache()`](https://github.com/ory/oathkeeper/blob/6a31df1c3779425e05db1c2a381166b087cb29a4/pipeline/authn/authenticator_oauth2_introspection.go#L97) it seems that it only validates the token expiration date, but ignores whether the token has or not the proper scopes.\n\n### Post-Mortem\n\nThe vulnerability was introduced in PR #424. During review, we failed to require appropriate test coverage by the submitter which is the primary reason that the vulnerability passed the review process.\n\nTo avoid this from happening again we enabled codecov with a strict policy on the Ory Oathkeeper repository: Without an increase in code coverage the PR can not be merged.\n\nTo address this issue and any regressions we have added a test suite ensuring that the cache behaviour is correct in the different scenarios:\n\n- Scope strategy is `none`, cache is enabled, and `requested_scope` is not empty -\u003e cache will not be used;\n- Scope strategy is `none`, cache is enabled, and `requested_scope` is empty -\u003e cache will be used;\n- Scope strategy is not `none`, cache is enabled, and `requested_scope` is not empty -\u003e cache will be used;\n\nas well as validating if `iss`, `aud`, `exp`, `token_use`, and scope are validated.\n\nAdditionally, we added [CodeQL scanning](https://github.com/ory/oathkeeper/commit/64ac7562669287d391cd72dfd43c5d71ff9f89a1) to the CI.",
  "id": "GHSA-qvp4-rpmr-xwrr",
  "modified": "2021-06-22T20:50:44Z",
  "published": "2021-06-23T18:00:20Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/ory/oathkeeper/security/advisories/GHSA-qvp4-rpmr-xwrr"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Possible bypass of token claim validation when OAuth2 Introspection caching is enabled"
}

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.

No CAPEC attack patterns related to this CWE.