Common Weakness Enumeration

CWE-863

Allowed-with-Review

Incorrect Authorization

Abstraction: Class · Status: Incomplete

API response cwe.mitre.org

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.

5548 vulnerabilities reference this CWE, most recent first.

GHSA-376R-8QWC-R5QG

Vulnerability from github – Published: 2022-05-24 16:56 – Updated: 2024-04-04 01:55
VLAI
Details

On NXP Kinetis KV1x, Kinetis KV3x, and Kinetis K8x devices, Flash Access Controls (FAC) (a software IP protection method for execute-only access) can be defeated by observing CPU registers and the effect of code/instruction execution.

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

{
  "affected": [],
  "aliases": [
    "CVE-2019-14237"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-09-12T18:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "On NXP Kinetis KV1x, Kinetis KV3x, and Kinetis K8x devices, Flash Access Controls (FAC) (a software IP protection method for execute-only access) can be defeated by observing CPU registers and the effect of code/instruction execution.",
  "id": "GHSA-376r-8qwc-r5qg",
  "modified": "2024-04-04T01:55:38Z",
  "published": "2022-05-24T16:56:02Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-14237"
    },
    {
      "type": "WEB",
      "url": "https://www.usenix.org/system/files/woot19-paper_schink.pdf"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-3775-99MW-8RP4

Vulnerability from github – Published: 2026-05-04 20:11 – Updated: 2026-05-13 13:39
VLAI
Summary
Argo has incomplete fix for CVE-2026-31892: hostNetwork, securityContext, serviceAccountName bypass templateReferencing Strict/Secure
Details

The fix for CVE-2026-31892 (commit 534f4ff) blocks podSpecPatch when templateReferencing: Strict is active, but doesn't restrict other WorkflowSpec fields that flow through the same merge path and get applied to pods. A user can set hostNetwork: true, override serviceAccountName, or change securityContext on their Workflow while referencing a hardened template -- these survive JoinWorkflowSpec and get applied at pod creation.

The check in setExecWorkflow gates on HasPodSpecPatch() only:

if woc.controller.Config.WorkflowRestrictions.MustUseReference() && woc.wf.Spec.HasPodSpecPatch() {

Everything else passes through. createWorkflowPod reads hostNetwork, securityContext, serviceAccountName, tolerations, and automountServiceAccountToken from the merged spec and applies them directly to the pod.

JoinWorkflowSpec constructs the merge target from the user's spec and applies the template as a patch -- user fields take priority. When the template doesn't explicitly set a field like hostNetwork (most won't -- false is the zero value and gets omitted), the user's true survives. For fields like securityContext and serviceAccountName, the template-level value takes precedence IF the template explicitly sets it. The bypass applies when the template relies on defaults.

Both Strict and Secure modes are affected. Secure stores the merged spec on first submission, so user overrides get baked into the stored spec and subsequent MustNotChangeSpec comparisons pass.

Steps to reproduce

Tested on v4.0.2 (the CVE-2026-31892 patched version) on kind v0.27.0 / K8s v1.35.0.

# enable strict mode
kubectl patch configmap workflow-controller-configmap -n argo --type merge \
  -p '{"data":{"workflowRestrictions":"templateReferencing: Strict\n"}}'
kubectl rollout restart deployment workflow-controller -n argo

A template that lists network interfaces:

cat <<'EOF' | kubectl apply -n argo -f -
apiVersion: argoproj.io/v1alpha1
kind: WorkflowTemplate
metadata:
  name: netcheck
spec:
  entrypoint: check
  templates:
  - name: check
    container:
      image: alpine:latest
      command: ["/bin/sh", "-c"]
      args: ["ip addr show | grep -E '^[0-9]+:' | cut -d: -f2"]
EOF

Submit a workflow with hostNetwork: true:

cat <<'EOF' | kubectl create -n argo -f -
apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: bypass-
spec:
  workflowTemplateRef:
    name: netcheck
  hostNetwork: true
EOF

Pod gets host networking:

$ kubectl get pod -n argo -l workflows.argoproj.io/workflow=bypass-bmg9b -o jsonpath='{.items[0].spec.hostNetwork}'
true

Container without the override sees eth0@if20. With the override, the pod sees the host's full network namespace -- all veth interfaces for other containers on the node.

podSpecPatch IS correctly blocked on the same cluster:

$ kubectl get workflow patched-check-jd272 -n argo -o jsonpath='{.status.message}'
podSpecPatch is not permitted when using workflowTemplateRef with templateReferencing restriction

serviceAccountName override also works -- a workflow with serviceAccountName: argo-server creates a pod running under the argo-server SA instead of the namespace default:

$ kubectl get pod -n argo -l workflows.argoproj.io/workflow=bypass-sa-slmjs -o jsonpath='{.items[0].spec.serviceAccountName}'
argo-server

Tested in Secure mode as well -- same result. Pod created with hostNetwork: true before the workflow errors on an unrelated permission issue.

Impact

A user with create Workflow permission can bypass templateReferencing: Strict to get host network access, switch service accounts, override pod security context, add tolerations to schedule on control-plane nodes, or enable SA token mounting. This defeats the stated purpose of the feature.

The practical impact depends on what Kubernetes-level controls are in place. Clusters with PodSecurity admission or OPA/Gatekeeper would independently block some of these (like hostNetwork). Clusters that rely on Argo's Strict mode as the primary enforcement layer are fully exposed.

Fix direction

The check in setExecWorkflow should cover all WorkflowSpec fields that influence pod security posture, not just podSpecPatch. The affected fields that I confirmed in createWorkflowPod: hostNetwork, securityContext, serviceAccountName, automountServiceAccountToken, tolerations, dnsPolicy, schedulerName, hostAliases, volumes.

An alternative approach: when MustUseReference() is true, strip all user-set WorkflowSpec fields except a known-safe allowlist (entrypoint, arguments, labels, annotations) before merging. This avoids a growing denylist as new fields get added.

Affected versions

All versions supporting templateReferencing, including v4.0.2 and v3.7.11 which patched CVE-2026-31892.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/argoproj/argo-workflows/v3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.7.14"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/argoproj/argo-workflows/v4"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.0.0"
            },
            {
              "fixed": "4.0.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-42296"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-04T20:11:38Z",
    "nvd_published_at": "2026-05-09T04:16:25Z",
    "severity": "HIGH"
  },
  "details": "The fix for CVE-2026-31892 (commit 534f4ff) blocks `podSpecPatch` when `templateReferencing: Strict` is active, but doesn\u0027t restrict other WorkflowSpec fields that flow through the same merge path and get applied to pods. A user can set `hostNetwork: true`, override `serviceAccountName`, or change `securityContext` on their Workflow while referencing a hardened template -- these survive `JoinWorkflowSpec` and get applied at pod creation.\n\nThe check in `setExecWorkflow` gates on `HasPodSpecPatch()` only:\n\n```go\nif woc.controller.Config.WorkflowRestrictions.MustUseReference() \u0026\u0026 woc.wf.Spec.HasPodSpecPatch() {\n```\n\nEverything else passes through. `createWorkflowPod` reads `hostNetwork`, `securityContext`, `serviceAccountName`, `tolerations`, and `automountServiceAccountToken` from the merged spec and applies them directly to the pod.\n\n`JoinWorkflowSpec` constructs the merge target from the user\u0027s spec and applies the template as a patch -- user fields take priority. When the template doesn\u0027t explicitly set a field like `hostNetwork` (most won\u0027t -- `false` is the zero value and gets omitted), the user\u0027s `true` survives. For fields like `securityContext` and `serviceAccountName`, the template-level value takes precedence IF the template explicitly sets it. The bypass applies when the template relies on defaults.\n\nBoth `Strict` and `Secure` modes are affected. `Secure` stores the merged spec on first submission, so user overrides get baked into the stored spec and subsequent `MustNotChangeSpec` comparisons pass.\n\n## Steps to reproduce\n\nTested on v4.0.2 (the CVE-2026-31892 patched version) on kind v0.27.0 / K8s v1.35.0.\n\n```bash\n# enable strict mode\nkubectl patch configmap workflow-controller-configmap -n argo --type merge \\\n  -p \u0027{\"data\":{\"workflowRestrictions\":\"templateReferencing: Strict\\n\"}}\u0027\nkubectl rollout restart deployment workflow-controller -n argo\n```\n\nA template that lists network interfaces:\n\n```bash\ncat \u003c\u003c\u0027EOF\u0027 | kubectl apply -n argo -f -\napiVersion: argoproj.io/v1alpha1\nkind: WorkflowTemplate\nmetadata:\n  name: netcheck\nspec:\n  entrypoint: check\n  templates:\n  - name: check\n    container:\n      image: alpine:latest\n      command: [\"/bin/sh\", \"-c\"]\n      args: [\"ip addr show | grep -E \u0027^[0-9]+:\u0027 | cut -d: -f2\"]\nEOF\n```\n\nSubmit a workflow with `hostNetwork: true`:\n\n```bash\ncat \u003c\u003c\u0027EOF\u0027 | kubectl create -n argo -f -\napiVersion: argoproj.io/v1alpha1\nkind: Workflow\nmetadata:\n  generateName: bypass-\nspec:\n  workflowTemplateRef:\n    name: netcheck\n  hostNetwork: true\nEOF\n```\n\nPod gets host networking:\n\n```\n$ kubectl get pod -n argo -l workflows.argoproj.io/workflow=bypass-bmg9b -o jsonpath=\u0027{.items[0].spec.hostNetwork}\u0027\ntrue\n```\n\nContainer without the override sees `eth0@if20`. With the override, the pod sees the host\u0027s full network namespace -- all veth interfaces for other containers on the node.\n\n`podSpecPatch` IS correctly blocked on the same cluster:\n\n```\n$ kubectl get workflow patched-check-jd272 -n argo -o jsonpath=\u0027{.status.message}\u0027\npodSpecPatch is not permitted when using workflowTemplateRef with templateReferencing restriction\n```\n\n`serviceAccountName` override also works -- a workflow with `serviceAccountName: argo-server` creates a pod running under the `argo-server` SA instead of the namespace default:\n\n```\n$ kubectl get pod -n argo -l workflows.argoproj.io/workflow=bypass-sa-slmjs -o jsonpath=\u0027{.items[0].spec.serviceAccountName}\u0027\nargo-server\n```\n\nTested in Secure mode as well -- same result. Pod created with `hostNetwork: true` before the workflow errors on an unrelated permission issue.\n\n## Impact\n\nA user with `create Workflow` permission can bypass `templateReferencing: Strict` to get host network access, switch service accounts, override pod security context, add tolerations to schedule on control-plane nodes, or enable SA token mounting. This defeats the stated purpose of the feature.\n\nThe practical impact depends on what Kubernetes-level controls are in place. Clusters with PodSecurity admission or OPA/Gatekeeper would independently block some of these (like `hostNetwork`). Clusters that rely on Argo\u0027s Strict mode as the primary enforcement layer are fully exposed.\n\n## Fix direction\n\nThe check in `setExecWorkflow` should cover all WorkflowSpec fields that influence pod security posture, not just `podSpecPatch`. The affected fields that I confirmed in `createWorkflowPod`: `hostNetwork`, `securityContext`, `serviceAccountName`, `automountServiceAccountToken`, `tolerations`, `dnsPolicy`, `schedulerName`, `hostAliases`, `volumes`.\n\nAn alternative approach: when `MustUseReference()` is true, strip all user-set WorkflowSpec fields except a known-safe allowlist (entrypoint, arguments, labels, annotations) before merging. This avoids a growing denylist as new fields get added.\n\n## Affected versions\n\nAll versions supporting `templateReferencing`, including v4.0.2 and v3.7.11 which patched CVE-2026-31892.",
  "id": "GHSA-3775-99mw-8rp4",
  "modified": "2026-05-13T13:39:21Z",
  "published": "2026-05-04T20:11:38Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/argoproj/argo-workflows/security/advisories/GHSA-3775-99mw-8rp4"
    },
    {
      "type": "WEB",
      "url": "https://github.com/argoproj/argo-workflows/security/advisories/GHSA-3wf5-g532-rcrr"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42296"
    },
    {
      "type": "WEB",
      "url": "https://github.com/argoproj/argo-workflows/commit/2727f3f701677d467dfb5e053c57237cbc752c3c"
    },
    {
      "type": "WEB",
      "url": "https://github.com/argoproj/argo-workflows/commit/534f4ff1cbd86908e8ff76d97d553ad5a49a950d"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/argoproj/argo-workflows"
    },
    {
      "type": "WEB",
      "url": "https://github.com/argoproj/argo-workflows/releases/tag/v3.7.14"
    },
    {
      "type": "WEB",
      "url": "https://github.com/argoproj/argo-workflows/releases/tag/v4.0.5"
    }
  ],
  "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"
    }
  ],
  "summary": "Argo has incomplete fix for CVE-2026-31892: hostNetwork, securityContext, serviceAccountName bypass templateReferencing Strict/Secure"
}

GHSA-37F6-M354-672C

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

The UsersWP WordPress plugin before 1.2.3.1 is missing access controls when updating a user avatar, and does not make sure file names for user avatars are unique, allowing a logged in user to overwrite another users avatar.

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

{
  "affected": [],
  "aliases": [
    "CVE-2022-0442"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-03-07T09:15:00Z",
    "severity": "MODERATE"
  },
  "details": "The UsersWP WordPress plugin before 1.2.3.1 is missing access controls when updating a user avatar, and does not make sure file names for user avatars are unique, allowing a logged in user to overwrite another users avatar.",
  "id": "GHSA-37f6-m354-672c",
  "modified": "2022-03-17T00:02:55Z",
  "published": "2022-03-08T00:00:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-0442"
    },
    {
      "type": "WEB",
      "url": "https://wpscan.com/vulnerability/9cf0822a-c9d6-4ebc-b905-95b143d1a692"
    }
  ],
  "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-37JG-QM7M-782R

Vulnerability from github – Published: 2022-05-24 19:17 – Updated: 2023-07-18 15:30
VLAI
Details

Tad Honor viewing book list function is vulnerable to authorization bypass, thus remote attackers can use special parameters to delete articles arbitrarily without logging in.

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

{
  "affected": [],
  "aliases": [
    "CVE-2021-41564"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-285",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-10-08T16:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Tad Honor viewing book list function is vulnerable to authorization bypass, thus remote attackers can use special parameters to delete articles arbitrarily without logging in.",
  "id": "GHSA-37jg-qm7m-782r",
  "modified": "2023-07-18T15:30:33Z",
  "published": "2022-05-24T19:17:04Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-41564"
    },
    {
      "type": "WEB",
      "url": "https://www.twcert.org.tw/tw/cp-132-5168-52304-1.html"
    }
  ],
  "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-37WJ-C2WJ-XRJH

Vulnerability from github – Published: 2022-05-24 17:15 – Updated: 2022-07-11 00:00
VLAI
Details

An issue was discovered in Sonatype Nexus Repository Manager in versions 3.21.1 and 3.22.0. It is possible for a user with appropriate privileges to create, modify, and execute scripting tasks without use of the UI or API. NOTE: in 3.22.0, scripting is disabled by default (making this not exploitable).

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

{
  "affected": [],
  "aliases": [
    "CVE-2020-11753"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-04-20T19:15:00Z",
    "severity": "MODERATE"
  },
  "details": "An issue was discovered in Sonatype Nexus Repository Manager in versions 3.21.1 and 3.22.0. It is possible for a user with appropriate privileges to create, modify, and execute scripting tasks without use of the UI or API. NOTE: in 3.22.0, scripting is disabled by default (making this not exploitable).",
  "id": "GHSA-37wj-c2wj-xrjh",
  "modified": "2022-07-11T00:00:25Z",
  "published": "2022-05-24T17:15:49Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-11753"
    },
    {
      "type": "WEB",
      "url": "https://cwe.mitre.org/data/definitions/284.html"
    },
    {
      "type": "WEB",
      "url": "https://support.sonatype.com/hc/en-us/articles/360046233714"
    }
  ],
  "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"
    }
  ]
}

GHSA-37XJ-PFM3-JG48

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

Vulnerability in the PeopleSoft Enterprise CS Student Records product of Oracle PeopleSoft (component: Class Search). The supported version that is affected is 9.2. Easily exploitable vulnerability allows low privileged attacker with network access via HTTP to compromise PeopleSoft Enterprise CS Student Records. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in PeopleSoft Enterprise CS Student Records, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of PeopleSoft Enterprise CS Student Records accessible data as well as unauthorized read access to a subset of PeopleSoft Enterprise CS Student Records accessible data. CVSS 3.1 Base Score 5.4 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N).

Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:L
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-35553"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-10-20T11:16:00Z",
    "severity": "MODERATE"
  },
  "details": "Vulnerability in the PeopleSoft Enterprise CS Student Records product of Oracle PeopleSoft (component: Class Search). The supported version that is affected is 9.2. Easily exploitable vulnerability allows low privileged attacker with network access via HTTP to compromise PeopleSoft Enterprise CS Student Records. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in PeopleSoft Enterprise CS Student Records, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of PeopleSoft Enterprise CS Student Records accessible data as well as unauthorized read access to a subset of PeopleSoft Enterprise CS Student Records accessible data. CVSS 3.1 Base Score 5.4 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N).",
  "id": "GHSA-37xj-pfm3-jg48",
  "modified": "2022-07-13T00:01:28Z",
  "published": "2022-05-24T19:18:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-35553"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpuoct2021.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-384C-GG34-G96H

Vulnerability from github – Published: 2022-05-01 17:42 – Updated: 2022-07-06 19:51
VLAI
Summary
Incorrect Authorization in Getahead Direct Web Remoting
Details

Getahead Direct Web Remoting (DWR) before 1.1.4 allows attackers to obtain unauthorized access to public methods via a crafted request that bypasses the include/exclude checks.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.directwebremoting:dwr"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.1.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2007-0184"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-07-06T19:51:48Z",
    "nvd_published_at": "2007-01-12T05:04:00Z",
    "severity": "HIGH"
  },
  "details": "Getahead Direct Web Remoting (DWR) before 1.1.4 allows attackers to obtain unauthorized access to public methods via a crafted request that bypasses the include/exclude checks.",
  "id": "GHSA-384c-gg34-g96h",
  "modified": "2022-07-06T19:51:48Z",
  "published": "2022-05-01T17:42:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2007-0184"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/31377"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2009-02/msg00002.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Incorrect Authorization in Getahead Direct Web Remoting"
}

GHSA-384W-5V3F-Q499

Vulnerability from github – Published: 2020-12-01 20:25 – Updated: 2024-10-01 21:19
VLAI
Summary
Base class whitelist configuration ignored in OAuthenticator
Details

Impact

What goes wrong?

The deprecated (in jupyterhub 1.2) configuration Authenticator.whitelist, which should be transparently mapped to Authenticator.allowed_users with a warning, is instead ignored by OAuthenticator classes, resulting in the same behavior as if this configuration has not been set. If this is the only mechanism of authorization restriction (i.e. no group or team restrictions in configuration) then all authenticated users will be allowed. Provider-based restrictions, including deprecated values such as GitHubOAuthenticator.org_whitelist are not affected.

Who is impacted?

All users of OAuthenticator 0.12.0 and 0.12.1 with JupyterHub 1.2 (JupyterHub Helm chart 0.10.0-0.10.5) who use the admin.whitelist.users configuration in the jupyterhub helm chart or the c.Authenticator.whitelist configuration directly. Users of other deprecated configuration, e.g. c.GitHubOAuthenticator.team_whitelist are not affected.

If you see a log line like this and expect a specific list of allowed usernames:

[I 2020-11-27 16:51:54.528 JupyterHub app:1717] Not using allowed_users. Any authenticated user will be allowed.

you are likely affected.

Patches

  • Replacing deprecated c.Authenticator.whitelist = ... with c.Authenticator.allowed_users = ... avoids the issue.
  • Update oauthenticator to 0.12.2
  • Update jupyterhub helm chart to 0.10.6

If any users have been authorized during this time who should not have been, they must be deleted via the API or admin interface, per the documentation.

Workarounds

Replacing c.Authenticator.whitelist = ... with c.Authenticator.allowed_users = ... avoids the issue.

In the jupyterhub helm chart prior to 0.10.6, this can be done via hub.extraConfig:

auth:
  allowedUsers:
  - user1
  - user2

hub:
  extraConfig:
    allowedUsers: |
        # set new field not exposed in helm chart < 0.10.6
        set_config_if_not_none(c.Authenticator, "allowed_users", "auth.allowedUsers")

For more information

If you have any questions or comments about this advisory:

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "oauthenticator"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.12.0"
            },
            {
              "fixed": "0.12.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2020-26250"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2020-12-01T20:24:40Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Impact\n\n__What goes wrong?__\n\nThe deprecated (in jupyterhub 1.2) configuration `Authenticator.whitelist`, which should be transparently mapped to `Authenticator.allowed_users` with a warning, is instead ignored by OAuthenticator classes, resulting in the same behavior as if this configuration has not been set. If this is the only mechanism of authorization restriction (i.e. no group or team restrictions in configuration) then all authenticated users will be allowed. Provider-based restrictions, including deprecated values such as `GitHubOAuthenticator.org_whitelist` are **not** affected.\n\n__Who is impacted?__\n\nAll users of OAuthenticator 0.12.0 and 0.12.1 with JupyterHub 1.2 (JupyterHub Helm chart 0.10.0-0.10.5) who use the `admin.whitelist.users` configuration in the jupyterhub helm chart or the `c.Authenticator.whitelist` configuration directly. Users of other deprecated configuration, e.g. `c.GitHubOAuthenticator.team_whitelist` are **not** affected.\n\nIf you see a log line like this and expect a specific list of allowed usernames:\n\n```\n[I 2020-11-27 16:51:54.528 JupyterHub app:1717] Not using allowed_users. Any authenticated user will be allowed.\n```\n\nyou are likely affected.\n\n### Patches\n\n- Replacing deprecated `c.Authenticator.whitelist = ...` with `c.Authenticator.allowed_users = ...` avoids the issue.\n- Update oauthenticator to 0.12.2\n- Update jupyterhub helm chart to 0.10.6\n\nIf any users have been authorized during this time who should not have been, they must be deleted via the API or admin interface, [per the documentation](https://jupyterhub.readthedocs.io/en/1.2.2/getting-started/authenticators-users-basics.html#add-or-remove-users-from-the-hub).\n\n### Workarounds\n\nReplacing `c.Authenticator.whitelist = ...` with `c.Authenticator.allowed_users = ...` avoids the issue.\n\nIn the jupyterhub helm chart prior to 0.10.6, this can be done via `hub.extraConfig`:\n\n```yaml\nauth:\n  allowedUsers:\n  - user1\n  - user2\n\nhub:\n  extraConfig:\n    allowedUsers: |\n        # set new field not exposed in helm chart \u003c 0.10.6\n        set_config_if_not_none(c.Authenticator, \"allowed_users\", \"auth.allowedUsers\")\n```\n\n\n### For more information\n\nIf you have any questions or comments about this advisory:\n\n* Open a thread [on the Jupyter forum](http://discourse.jupyter.org)\n* Email us at [security@ipython.org](mailto:security@ipython.org)",
  "id": "GHSA-384w-5v3f-q499",
  "modified": "2024-10-01T21:19:38Z",
  "published": "2020-12-01T20:25:00Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/jupyterhub/oauthenticator/security/advisories/GHSA-384w-5v3f-q499"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-26250"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jupyterhub/oauthenticator/commit/a4aac191c16cf6281f3d346615aefa75702b02d7"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/jupyterhub/oauthenticator"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jupyterhub/oauthenticator/blob/master/docs/source/changelog.md#0122---2020-11-30"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/oauthenticator/PYSEC-2020-68.yaml"
    },
    {
      "type": "WEB",
      "url": "https://jupyterhub.readthedocs.io/en/1.2.2/getting-started/authenticators-users-basics.html#add-or-remove-users-from-the-hub"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:H/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Base class whitelist configuration ignored in OAuthenticator"
}

GHSA-3856-CJCH-9CV8

Vulnerability from github – Published: 2023-10-27 21:30 – Updated: 2024-04-04 08:57
VLAI
Details

In resetSettingsLocked of SettingsProvider.java, there is a possible lockscreen bypass due to a permissions bypass. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.

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

{
  "affected": [],
  "aliases": [
    "CVE-2023-40117"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-10-27T21:15:08Z",
    "severity": "HIGH"
  },
  "details": "In resetSettingsLocked of SettingsProvider.java, there is a possible lockscreen bypass due to a permissions bypass. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.",
  "id": "GHSA-3856-cjch-9cv8",
  "modified": "2024-04-04T08:57:37Z",
  "published": "2023-10-27T21:30:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-40117"
    },
    {
      "type": "WEB",
      "url": "https://android.googlesource.com/platform/frameworks/base/+/ff86ff28cf82124f8e65833a2dd8c319aea08945"
    },
    {
      "type": "WEB",
      "url": "https://android.googlesource.com/platform/packages/apps/Settings/+/11815817de2f2d70fe842b108356a1bc75d44ffb"
    },
    {
      "type": "WEB",
      "url": "https://source.android.com/security/bulletin/2023-10-01"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-3857-XM38-JMQ2

Vulnerability from github – Published: 2022-05-14 03:57 – Updated: 2022-11-02 00:41
VLAI
Summary
Incorrect Authorization in Jenkins Core
Details

Jenkins before 2.3 and LTS before 1.651.2 allow remote authenticated users with multiple accounts to cause a denial of service (unable to login) by editing the "full name."

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.jenkins-ci.main:jenkins-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2016-3722"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-11-02T00:41:06Z",
    "nvd_published_at": "2016-05-17T14:08:00Z",
    "severity": "MODERATE"
  },
  "details": "Jenkins before 2.3 and LTS before 1.651.2 allow remote authenticated users with multiple accounts to cause a denial of service (unable to login) by editing the \"full name.\"",
  "id": "GHSA-3857-xm38-jmq2",
  "modified": "2022-11-02T00:41:06Z",
  "published": "2022-05-14T03:57:44Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2016-3722"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2016:1206"
    },
    {
      "type": "WEB",
      "url": "https://wiki.jenkins-ci.org/display/SECURITY/Jenkins+Security+Advisory+2016-05-11"
    },
    {
      "type": "WEB",
      "url": "https://www.cloudbees.com/jenkins-security-advisory-2016-05-11"
    },
    {
      "type": "WEB",
      "url": "http://rhn.redhat.com/errata/RHSA-2016-1773.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Incorrect Authorization in Jenkins Core"
}
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.

← Back to the CWE list