Vulnerability-Lookup

GHSA-XHGX-QJR6-8FF6

Vulnerability from github – Published: 2022-04-12 00:00 – Updated: 2026-07-05 03:30

Details

An Access Control vulnerability exists in KevinLAB Inc Building Energy Management System 4ST BEMS 1.0.0 due to an undocumented backdoor account. A malicious user can log in using the backdor account with admin highest privileges and obtain system control.

Severity

7.2 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2021-37292"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-04-11T19:15:00Z",
    "severity": "HIGH"
  },
  "details": "An Access Control vulnerability exists in KevinLAB Inc Building Energy Management System 4ST BEMS 1.0.0 due to an undocumented backdoor account. A malicious user can log in using the backdor account with admin highest privileges and obtain system control.",
  "id": "GHSA-xhgx-qjr6-8ff6",
  "modified": "2026-07-05T03:30:47Z",
  "published": "2022-04-12T00:00:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-37292"
    },
    {
      "type": "WEB",
      "url": "https://www.zeroscience.mk/en/vulnerabilities"
    },
    {
      "type": "WEB",
      "url": "http://www.kevinlab.com"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-XHJW-95FP-8VGQ

Vulnerability from github – Published: 2026-04-24 20:12 – Updated: 2026-05-06 21:24

Summary

Traefik Kubernetes CRD allows unauthorized cross-namespace middleware binding

Details

Summary

There is a vulnerability in Traefik's Kubernetes CRD provider cross-namespace isolation enforcement.

When providers.kubernetesCRD.allowCrossNamespace=false, Traefik correctly rejects direct cross-namespace middleware references from IngressRoute objects, but fails to apply the same restriction to middleware references nested inside a Chain middleware's spec.chain.middlewares[]. An actor with permission to create or update Traefik CRDs in their own namespace can exploit this to cause Traefik to resolve and apply middleware objects from another namespace, bypassing the documented isolation boundary.

Patches

https://github.com/traefik/traefik/releases/tag/v2.11.43
https://github.com/traefik/traefik/releases/tag/v3.6.14
https://github.com/traefik/traefik/releases/tag/v3.7.0-rc.2

For more information

If there are any questions or comments about this advisory, please open an issue.

Original Description ### Summary When `providers.kubernetesCRD.allowCrossNamespace=false`, Traefik still allows a namespace-local `Middleware` of type `Chain` to reference middleware objects from another namespace via `spec.chain.middlewares[].namespace`. This bypasses the documented cross-namespace restriction and allows an actor with permission to create or update Traefik CRDs in namespace A to bind middleware defined in namespace B to routes in namespace A. ### Details Traefik documents `allowCrossNamespace` as the control that governs whether `IngressRoute` objects may reference resources in other namespaces. Direct middleware references from `IngressRoute.routes[].middlewares[]` are validated in `pkg/provider/kubernetes/crd/kubernetes_http.go` by `makeMiddlewareKeys(...)`, which rejects cross-namespace references when `allowCrossNamespace` is disabled. However, nested middleware references inside `Middleware.spec.chain.middlewares[]` follow a different code path. `createChainMiddleware(...)` in `pkg/provider/kubernetes/crd/kubernetes.go` does not receive or enforce `allowCrossNamespace`; it resolves `mi.Namespace` (or defaults to the current namespace) and appends `makeID(ns, mi.Name)` unconditionally. At runtime, `pkg/server/middleware/middlewares.go` qualifies and builds `config.Chain.Middlewares`, so the cross-namespace middleware is actually loaded and used. This was verified on the current `master` at commit `786f7192e11878dfaa634f8263bf79bb730a71cb`. This appears related to earlier cross-namespace hardening work, but the surviving issue is a distinct nested `Chain` middleware code path rather than the already-guarded direct reference path. ### Expected behavior When `providers.kubernetesCRD.allowCrossNamespace=false`, any middleware reference that resolves to an object in another namespace should be rejected, whether referenced directly from an `IngressRoute` or indirectly through a local `Chain` middleware. ### Actual behavior A namespace-local `Chain` middleware can reference `spec.chain.middlewares[].namespace` in another namespace, and Traefik resolves and applies that middleware even when cross-namespace references are disabled. ### Attacker prerequisites The attacker must have permission to create or update Traefik CRDs in a namespace they control, but does not need permission to modify resources in the target namespace. ### PoC 1. Run Traefik with the Kubernetes CRD provider and set `allowCrossNamespace: false`. 2. Create two namespaces, for example `default` and `cross-ns`. 3. Apply a middleware in `cross-ns`:

apiVersion: traefik.io/v1alpha1
kind: Middleware
metadata:
  name: victim-strip
  namespace: cross-ns
spec:
  stripPrefix:
    prefixes:
      - /secret

4. Apply a chain middleware in `default` that references the middleware above:

apiVersion: traefik.io/v1alpha1
kind: Middleware
metadata:
  name: mychain
  namespace: default
spec:
  chain:
    middlewares:
      - name: victim-strip
        namespace: cross-ns

5. Apply an `IngressRoute` in `default` that references only the local `mychain` middleware:

apiVersion: traefik.io/v1alpha1
kind: IngressRoute
metadata:
  name: demo
  namespace: default
spec:
  entryPoints:
    - web
  routes:
    - match: Host(`example.test`) && PathPrefix(`/demo`)
      kind: Rule
      middlewares:
        - name: mychain
      services:
        - name: whoami
          port: 80

6. Observe that Traefik accepts the configuration and resolves the resulting chain to the middleware from `cross-ns` even though `allowCrossNamespace` is disabled. 7. As a control, replace the local chain reference in the `IngressRoute` with a direct cross-namespace middleware reference. That direct reference is rejected when `allowCrossNamespace=false`, which indicates the bypass is specific to nested `Chain` middleware resolution. ### Impact This is an authorization / trust-boundary bypass in Traefik's Kubernetes CRD provider. Clusters that rely on providers.kubernetesCRD.allowCrossNamespace=false for namespace isolation are affected. An actor who is allowed to create or update Traefik CRDs in their own namespace can still cause Traefik to apply middleware from another namespace by referencing it indirectly through a local Chain middleware. The practical impact depends on which middleware objects exist in the other namespace, but this can allow unauthorized reuse of security-sensitive or policy-bearing middleware across namespace boundaries. Examples include request modification, header manipulation, authentication or forward-auth related behavior, and other traffic-handling policies that were intended to remain namespace-scoped. Testers have not verified unauthenticated remote compromise, code execution, or universal cross-tenant data exposure. The core issue is that a documented isolation control can be bypassed through the nested Chain middleware reference path.

Severity

6.4 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N

4.8 (Medium)


                  
                    CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/traefik/traefik/v3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.7.0-ea.1"
            },
            {
              "fixed": "3.7.0-rc.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/traefik/traefik/v3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.0.0-beta1"
            },
            {
              "fixed": "3.6.14"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/traefik/traefik/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.11.43"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/traefik/traefik"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "1.7.34"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-41174"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-653",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-24T20:12:10Z",
    "nvd_published_at": "2026-04-30T21:16:33Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nThere is a vulnerability in Traefik\u0027s Kubernetes CRD provider cross-namespace isolation enforcement.\n\nWhen `providers.kubernetesCRD.allowCrossNamespace=false`, Traefik correctly rejects direct cross-namespace middleware references from `IngressRoute` objects, but fails to apply the same restriction to middleware references nested inside a `Chain` middleware\u0027s `spec.chain.middlewares[]`. An actor with permission to create or update Traefik CRDs in their own namespace can exploit this to cause Traefik to resolve and apply middleware objects from another namespace, bypassing the documented isolation boundary.\n\n## Patches\n\n- https://github.com/traefik/traefik/releases/tag/v2.11.43\n- https://github.com/traefik/traefik/releases/tag/v3.6.14\n- https://github.com/traefik/traefik/releases/tag/v3.7.0-rc.2\n\n## For more information\n\nIf there are any questions or comments about this advisory, please [open an issue](https://github.com/traefik/traefik/issues).\n\n\u003cdetails\u003e\n\u003csummary\u003eOriginal Description\u003c/summary\u003e\n\n### Summary\nWhen `providers.kubernetesCRD.allowCrossNamespace=false`, Traefik still allows a namespace-local `Middleware` of type `Chain` to reference middleware objects from another namespace via `spec.chain.middlewares[].namespace`.\n\nThis bypasses the documented cross-namespace restriction and allows an actor with permission to create or update Traefik CRDs in namespace A to bind middleware defined in namespace B to routes in namespace A.\n\n### Details\nTraefik documents `allowCrossNamespace` as the control that governs whether `IngressRoute` objects may reference resources in other namespaces.\n\nDirect middleware references from `IngressRoute.routes[].middlewares[]` are validated in `pkg/provider/kubernetes/crd/kubernetes_http.go` by `makeMiddlewareKeys(...)`, which rejects cross-namespace references when `allowCrossNamespace` is disabled.\n\nHowever, nested middleware references inside `Middleware.spec.chain.middlewares[]` follow a different code path. `createChainMiddleware(...)` in `pkg/provider/kubernetes/crd/kubernetes.go` does not receive or enforce `allowCrossNamespace`; it resolves `mi.Namespace` (or defaults to the current namespace) and appends `makeID(ns, mi.Name)` unconditionally.\n\nAt runtime, `pkg/server/middleware/middlewares.go` qualifies and builds `config.Chain.Middlewares`, so the cross-namespace middleware is actually loaded and used.\n\nThis was verified on the current `master` at commit `786f7192e11878dfaa634f8263bf79bb730a71cb`.\n\nThis appears related to earlier cross-namespace hardening work, but the surviving issue is a distinct nested `Chain` middleware code path rather than the already-guarded direct reference path.\n\n### Expected behavior\nWhen `providers.kubernetesCRD.allowCrossNamespace=false`, any middleware reference that resolves to an object in another namespace should be rejected, whether referenced directly from an `IngressRoute` or indirectly through a local `Chain` middleware.\n\n### Actual behavior\nA namespace-local `Chain` middleware can reference `spec.chain.middlewares[].namespace` in another namespace, and Traefik resolves and applies that middleware even when cross-namespace references are disabled.\n\n### Attacker prerequisites\nThe attacker must have permission to create or update Traefik CRDs in a namespace they control, but does not need permission to modify resources in the target namespace.\n\n### PoC\n1. Run Traefik with the Kubernetes CRD provider and set `allowCrossNamespace: false`.\n\n2. Create two namespaces, for example `default` and `cross-ns`.\n\n3. Apply a middleware in `cross-ns`:\n\n```yaml\napiVersion: traefik.io/v1alpha1\nkind: Middleware\nmetadata:\n  name: victim-strip\n  namespace: cross-ns\nspec:\n  stripPrefix:\n    prefixes:\n      - /secret\n```\n\n4. Apply a chain middleware in `default` that references the middleware above:\n\n```yaml\napiVersion: traefik.io/v1alpha1\nkind: Middleware\nmetadata:\n  name: mychain\n  namespace: default\nspec:\n  chain:\n    middlewares:\n      - name: victim-strip\n        namespace: cross-ns\n```\n\n5. Apply an `IngressRoute` in `default` that references only the local `mychain` middleware:\n\n```yaml\napiVersion: traefik.io/v1alpha1\nkind: IngressRoute\nmetadata:\n  name: demo\n  namespace: default\nspec:\n  entryPoints:\n    - web\n  routes:\n    - match: Host(`example.test`) \u0026\u0026 PathPrefix(`/demo`)\n      kind: Rule\n      middlewares:\n        - name: mychain\n      services:\n        - name: whoami\n          port: 80\n```\n\n6. Observe that Traefik accepts the configuration and resolves the resulting chain to the middleware from `cross-ns` even though `allowCrossNamespace` is disabled.\n\n7. As a control, replace the local chain reference in the `IngressRoute` with a direct cross-namespace middleware reference. That direct reference is rejected when `allowCrossNamespace=false`, which indicates the bypass is specific to nested `Chain` middleware resolution.\n\n### Impact\n\nThis is an authorization / trust-boundary bypass in Traefik\u0027s Kubernetes CRD provider.\n\nClusters that rely on providers.kubernetesCRD.allowCrossNamespace=false for namespace isolation are affected. An actor who is allowed to create or update Traefik CRDs in their own namespace can still cause Traefik to apply middleware from another namespace by referencing it indirectly through a local Chain middleware.\n\nThe practical impact depends on which middleware objects exist in the other namespace, but this can allow unauthorized reuse of security-sensitive or policy-bearing middleware across namespace boundaries. Examples include request modification, header manipulation, authentication or forward-auth related behavior, and other traffic-handling policies that were intended to remain namespace-scoped.\n\nTesters have not verified unauthenticated remote compromise, code execution, or universal cross-tenant data exposure. The core issue is that a documented isolation control can be bypassed through the nested Chain middleware reference path.\n\n\u003c/details\u003e",
  "id": "GHSA-xhjw-95fp-8vgq",
  "modified": "2026-05-06T21:24:47Z",
  "published": "2026-04-24T20:12:10Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/traefik/traefik/security/advisories/GHSA-xhjw-95fp-8vgq"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41174"
    },
    {
      "type": "WEB",
      "url": "https://github.com/traefik/traefik/commit/df00d82fc7f12e07199551832b54de6d0e55414d"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/traefik/traefik"
    },
    {
      "type": "WEB",
      "url": "https://github.com/traefik/traefik/releases/tag/v2.11.43"
    },
    {
      "type": "WEB",
      "url": "https://github.com/traefik/traefik/releases/tag/v3.6.14"
    },
    {
      "type": "WEB",
      "url": "https://github.com/traefik/traefik/releases/tag/v3.7.0-rc.2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Traefik Kubernetes CRD allows unauthorized cross-namespace middleware binding"
}

GHSA-XHMM-6XR8-JX92

Vulnerability from github – Published: 2025-08-28 15:30 – Updated: 2025-08-28 15:30

Details

The Block Bad Bots and Stop Bad Bots Crawlers and Spiders and Anti Spam Protection plugin for WordPress is vulnerable to unauthorized access of data due to an insufficient capability check on the 'stopbadbots_check_wordpress_logged_in_cookie' function in all versions up to, and including, 11.58. This makes it possible for unauthenticated attackers to bypass blocklists, rate limits, and other plugin functionality.

Severity

6.5 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:L

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2025-9376"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-08-28T12:15:39Z",
    "severity": "MODERATE"
  },
  "details": "The Block Bad Bots and Stop Bad Bots Crawlers and Spiders and Anti Spam Protection plugin for WordPress is vulnerable to unauthorized access of data due to an insufficient capability check on the \u0027stopbadbots_check_wordpress_logged_in_cookie\u0027 function in all versions up to, and including, 11.58. This makes it possible for unauthenticated attackers to bypass blocklists, rate limits, and other plugin functionality.",
  "id": "GHSA-xhmm-6xr8-jx92",
  "modified": "2025-08-28T15:30:40Z",
  "published": "2025-08-28T15:30:40Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-9376"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/stopbadbots/trunk/stopbadbots.php#L1958"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/changeset/3350927"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/changeset/3351023"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/8d6b0d86-3cb4-4723-b677-141c604f00cc?source=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-XHQ5-45PM-2GJR

Vulnerability from github – Published: 2026-03-26 21:34 – Updated: 2026-04-18 00:56

Summary

OpenClaw: Nextcloud Talk room allowlist matched colliding room names instead of stable room tokens

Details

Summary

Nextcloud Talk room authorization matched on collidable room names instead of the stable room token, allowing policy confusion across similarly named rooms.

Affected Packages / Versions

Package: openclaw (npm)
Affected: < 2026.3.22
Fixed: >= 2026.3.22
Latest released tag checked: v2026.3.23-2 (630f1479c44f78484dfa21bb407cbe6f171dac87)
Latest published npm version checked: 2026.3.23-2

Fix Commit(s)

a47722de7e3c9cbda8d5512747ca7e3bb8f6ee66

Release Status

The fix shipped in v2026.3.22 and remains present in v2026.3.23 and v2026.3.23-2.

Code-Level Confirmation

extensions/nextcloud-talk/src/inbound.ts now resolves allowlist policy from roomToken-backed room identity.
extensions/nextcloud-talk/src/policy.ts now keys room authorization on stable room tokens instead of display names.

OpenClaw thanks @zpbrent for reporting.

Severity

4.2 (Medium)


                  
                    CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N

2.3 (Low)


                  
                    CVSS:4.0/AV:N/AC:H/AT:N/PR:L/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.3.22"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-35624"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639",
      "CWE-807",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-26T21:34:18Z",
    "nvd_published_at": null,
    "severity": "LOW"
  },
  "details": "## Summary\nNextcloud Talk room authorization matched on collidable room names instead of the stable room token, allowing policy confusion across similarly named rooms.\n\n## Affected Packages / Versions\n- Package: `openclaw` (npm)\n- Affected: \u003c 2026.3.22\n- Fixed: \u003e= 2026.3.22\n- Latest released tag checked: `v2026.3.23-2` (`630f1479c44f78484dfa21bb407cbe6f171dac87`)\n- Latest published npm version checked: `2026.3.23-2`\n\n## Fix Commit(s)\n- `a47722de7e3c9cbda8d5512747ca7e3bb8f6ee66`\n\n## Release Status\nThe fix shipped in `v2026.3.22` and remains present in `v2026.3.23` and `v2026.3.23-2`.\n\n## Code-Level Confirmation\n- extensions/nextcloud-talk/src/inbound.ts now resolves allowlist policy from roomToken-backed room identity.\n- extensions/nextcloud-talk/src/policy.ts now keys room authorization on stable room tokens instead of display names.\n\nOpenClaw thanks @zpbrent for reporting.",
  "id": "GHSA-xhq5-45pm-2gjr",
  "modified": "2026-04-18T00:56:28Z",
  "published": "2026-03-26T21:34:18Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-xhq5-45pm-2gjr"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-35624"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/630f1479c44f78484dfa21bb407cbe6f171dac87"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/a47722de7e3c9cbda8d5512747ca7e3bb8f6ee66"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-policy-confusion-via-room-name-collision-in-nextcloud-talk"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:L/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenClaw: Nextcloud Talk room allowlist matched colliding room names instead of stable room tokens"
}

GHSA-XHQ9-58FW-859P

Vulnerability from github – Published: 2026-04-16 20:42 – Updated: 2026-04-16 20:42

Summary

ApostropheCMS: publicApiProjection Bypass via project Query Builder in Piece-Type REST API

Details

Summary

The getRestQuery method in the @apostrophecms/piece-type module checks whether a MongoDB projection has already been set before applying the admin-configured publicApiProjection. An unauthenticated attacker can supply a project query parameter in the REST API request to pre-populate the projection state, causing the security-enforced publicApiProjection to be skipped entirely. This allows disclosure of fields that the site administrator explicitly restricted from public access.

Details

When an unauthenticated user queries the piece-type REST API, the getRestQuery method processes the request at modules/@apostrophecms/piece-type/index.js:1120:

// piece-type/index.js:1120-1137
getRestQuery(req, omitPermissionCheck = false) {
  const query = self.find(req).attachments(true);
  query.applyBuildersSafely(req.query);          // [1] attacker input applied first
  if (!omitPermissionCheck && !self.canAccessApi(req)) {
    if (!self.options.publicApiProjection) {
      query.and({
        _id: null
      });
    } else if (!query.state.project) {            // [2] checks if projection already set
      query.project({
        ...self.options.publicApiProjection,
        cacheInvalidatedAt: 1
      });
    }
  }
  return query;
},

At [1], applyBuildersSafely iterates over all query string parameters and invokes their corresponding builder methods. The project builder exists in @apostrophecms/doc-type with a launder method (doc-type/index.js:1876) that sanitizes values to booleans:

// doc-type/index.js:1875-1889
project: {
  launder (p) {
    if (!p || typeof p !== 'object' || Array.isArray(p)) {
      return {};
    }
    const projection = Object.entries(p).reduce((acc, [ key, val ]) => {
      return {
        ...acc,
        [key]: self.apos.launder.boolean(val)
      };
    }, {});
    return projection;
  },

When a request includes ?project[someField]=1, the builder sets query.state.project to {someField: true}. At [2], the conditional !query.state.project evaluates to false because the state is already populated, so the publicApiProjection is never applied.

For comparison, the @apostrophecms/page module's equivalent method (page/index.js:2953) unconditionally applies the projection:

// page/index.js:2953-2958
} else {
  query.project({
    ...self.options.publicApiProjection,
    cacheInvalidatedAt: 1
  });
}

PoC

Prerequisites: An ApostropheCMS 4.x instance with a piece-type (e.g., article) that has publicApiProjection configured to restrict fields. For example:

// modules/article/index.js
module.exports = {
  extend: '@apostrophecms/piece-type',
  options: {
    publicApiProjection: {
      title: 1,
      _url: 1
    }
  }
};

Step 1: Normal request — observe restricted fields are hidden:

curl 'http://localhost:3000/api/v1/article'

Response returns only title and _url fields per the configured projection.

Step 2: Bypass projection by supplying project query parameter:

curl 'http://localhost:3000/api/v1/article?project[internalNotes]=1&project[title]=1&project[slug]=1&project[createdAt]=1'

Response now includes internalNotes, slug, createdAt, and any other requested fields — bypassing the admin-configured publicApiProjection restriction.

Step 3: Request all default fields by projecting inclusion of sensitive fields:

curl 'http://localhost:3000/api/v1/article?project[_id]=1&project[title]=1&project[slug]=1&project[visibility]=1&project[type]=1&project[createdAt]=1&project[updatedAt]=1'

All requested fields are returned, confirming the publicApiProjection is fully bypassed.

Impact

Information Disclosure: An unauthenticated attacker can read any field on documents that are already publicly queryable, bypassing administrator-configured field restrictions. This may expose internal notes, draft content, metadata, or other sensitive fields the administrator intentionally hid from the public API.
Scope: Affects all piece-type modules with publicApiProjection configured. The attacker cannot access documents they wouldn't otherwise be able to query (document-level permissions still apply), but they can read any field on accessible documents.
Exploitability: Trivial — requires only appending query parameters to a public URL. No authentication, special tools, or chaining required.

Recommended Fix

Remove the conditional check on query.state.project in piece-type/index.js, matching the page module's unconditional behavior. The admin-configured publicApiProjection should always override any user-supplied projection for unauthenticated users:

// modules/@apostrophecms/piece-type/index.js:1123-1134
// BEFORE (vulnerable):
if (!omitPermissionCheck && !self.canAccessApi(req)) {
  if (!self.options.publicApiProjection) {
    query.and({
      _id: null
    });
  } else if (!query.state.project) {
    query.project({
      ...self.options.publicApiProjection,
      cacheInvalidatedAt: 1
    });
  }
}

// AFTER (fixed):
if (!omitPermissionCheck && !self.canAccessApi(req)) {
  if (!self.options.publicApiProjection) {
    query.and({
      _id: null
    });
  } else {
    query.project({
      ...self.options.publicApiProjection,
      cacheInvalidatedAt: 1
    });
  }
}

Severity

5.3 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "apostrophe"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.29.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-33888"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-16T20:42:21Z",
    "nvd_published_at": "2026-04-15T20:16:35Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nThe `getRestQuery` method in the `@apostrophecms/piece-type` module checks whether a MongoDB projection has already been set before applying the admin-configured `publicApiProjection`. An unauthenticated attacker can supply a `project` query parameter in the REST API request to pre-populate the projection state, causing the security-enforced `publicApiProjection` to be skipped entirely. This allows disclosure of fields that the site administrator explicitly restricted from public access.\n\n## Details\n\nWhen an unauthenticated user queries the piece-type REST API, the `getRestQuery` method processes the request at `modules/@apostrophecms/piece-type/index.js:1120`:\n\n```javascript\n// piece-type/index.js:1120-1137\ngetRestQuery(req, omitPermissionCheck = false) {\n  const query = self.find(req).attachments(true);\n  query.applyBuildersSafely(req.query);          // [1] attacker input applied first\n  if (!omitPermissionCheck \u0026\u0026 !self.canAccessApi(req)) {\n    if (!self.options.publicApiProjection) {\n      query.and({\n        _id: null\n      });\n    } else if (!query.state.project) {            // [2] checks if projection already set\n      query.project({\n        ...self.options.publicApiProjection,\n        cacheInvalidatedAt: 1\n      });\n    }\n  }\n  return query;\n},\n```\n\nAt **[1]**, `applyBuildersSafely` iterates over all query string parameters and invokes their corresponding builder methods. The `project` builder exists in `@apostrophecms/doc-type` with a `launder` method (`doc-type/index.js:1876`) that sanitizes values to booleans:\n\n```javascript\n// doc-type/index.js:1875-1889\nproject: {\n  launder (p) {\n    if (!p || typeof p !== \u0027object\u0027 || Array.isArray(p)) {\n      return {};\n    }\n    const projection = Object.entries(p).reduce((acc, [ key, val ]) =\u003e {\n      return {\n        ...acc,\n        [key]: self.apos.launder.boolean(val)\n      };\n    }, {});\n    return projection;\n  },\n```\n\nWhen a request includes `?project[someField]=1`, the builder sets `query.state.project` to `{someField: true}`. At **[2]**, the conditional `!query.state.project` evaluates to `false` because the state is already populated, so the `publicApiProjection` is never applied.\n\nFor comparison, the `@apostrophecms/page` module\u0027s equivalent method (`page/index.js:2953`) unconditionally applies the projection:\n\n```javascript\n// page/index.js:2953-2958\n} else {\n  query.project({\n    ...self.options.publicApiProjection,\n    cacheInvalidatedAt: 1\n  });\n}\n```\n\n## PoC\n\n**Prerequisites:** An ApostropheCMS 4.x instance with a piece-type (e.g., `article`) that has `publicApiProjection` configured to restrict fields. For example:\n\n```javascript\n// modules/article/index.js\nmodule.exports = {\n  extend: \u0027@apostrophecms/piece-type\u0027,\n  options: {\n    publicApiProjection: {\n      title: 1,\n      _url: 1\n    }\n  }\n};\n```\n\n**Step 1:** Normal request \u2014 observe restricted fields are hidden:\n\n```bash\ncurl \u0027http://localhost:3000/api/v1/article\u0027\n```\n\nResponse returns only `title` and `_url` fields per the configured projection.\n\n**Step 2:** Bypass projection by supplying `project` query parameter:\n\n```bash\ncurl \u0027http://localhost:3000/api/v1/article?project[internalNotes]=1\u0026project[title]=1\u0026project[slug]=1\u0026project[createdAt]=1\u0027\n```\n\nResponse now includes `internalNotes`, `slug`, `createdAt`, and any other requested fields \u2014 bypassing the admin-configured `publicApiProjection` restriction.\n\n**Step 3:** Request all default fields by projecting inclusion of sensitive fields:\n\n```bash\ncurl \u0027http://localhost:3000/api/v1/article?project[_id]=1\u0026project[title]=1\u0026project[slug]=1\u0026project[visibility]=1\u0026project[type]=1\u0026project[createdAt]=1\u0026project[updatedAt]=1\u0027\n```\n\nAll requested fields are returned, confirming the `publicApiProjection` is fully bypassed.\n\n## Impact\n\n- **Information Disclosure:** An unauthenticated attacker can read any field on documents that are already publicly queryable, bypassing administrator-configured field restrictions. This may expose internal notes, draft content, metadata, or other sensitive fields the administrator intentionally hid from the public API.\n- **Scope:** Affects all piece-type modules with `publicApiProjection` configured. The attacker cannot access documents they wouldn\u0027t otherwise be able to query (document-level permissions still apply), but they can read any field on accessible documents.\n- **Exploitability:** Trivial \u2014 requires only appending query parameters to a public URL. No authentication, special tools, or chaining required.\n\n## Recommended Fix\n\nRemove the conditional check on `query.state.project` in `piece-type/index.js`, matching the page module\u0027s unconditional behavior. The admin-configured `publicApiProjection` should always override any user-supplied projection for unauthenticated users:\n\n```javascript\n// modules/@apostrophecms/piece-type/index.js:1123-1134\n// BEFORE (vulnerable):\nif (!omitPermissionCheck \u0026\u0026 !self.canAccessApi(req)) {\n  if (!self.options.publicApiProjection) {\n    query.and({\n      _id: null\n    });\n  } else if (!query.state.project) {\n    query.project({\n      ...self.options.publicApiProjection,\n      cacheInvalidatedAt: 1\n    });\n  }\n}\n\n// AFTER (fixed):\nif (!omitPermissionCheck \u0026\u0026 !self.canAccessApi(req)) {\n  if (!self.options.publicApiProjection) {\n    query.and({\n      _id: null\n    });\n  } else {\n    query.project({\n      ...self.options.publicApiProjection,\n      cacheInvalidatedAt: 1\n    });\n  }\n}\n```",
  "id": "GHSA-xhq9-58fw-859p",
  "modified": "2026-04-16T20:42:21Z",
  "published": "2026-04-16T20:42:21Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/apostrophecms/apostrophe/security/advisories/GHSA-xhq9-58fw-859p"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33888"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apostrophecms/apostrophe/commit/00d472804bb622df36a761b6f2cf2b33b2d4ce80"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apostrophecms/apostrophe/commit/6c2b548dec2e3f7a82e8e16736603f4cd17525aa"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/apostrophecms/apostrophe"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "ApostropheCMS: publicApiProjection Bypass via project Query Builder in Piece-Type REST API"
}

GHSA-XHQV-VMW5-79PM

Vulnerability from github – Published: 2026-07-08 15:32 – Updated: 2026-07-08 15:32

Details

n8n before 1.123.55, 2.25.7, and 2.26.2 contains an authorization bypass in the POST /workflows/{workflowId}/test-runs/new endpoint, which authorizes access using the workflow:read scope instead of workflow:execute. An authenticated user with read-only access to a workflow can trigger a real evaluation test run, causing the workflow to execute via the internal workflow runner and resulting in unintended outbound API calls, data mutations, or other side effects in connected downstream systems. The issue primarily affects instances using the Evaluations feature where RBAC project roles grant workflow:read without workflow:execute.

Severity

7.4 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:L

5.3 (Medium)


                  
                    CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:L/SC:L/SI:L/SA:L

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-56776"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-08T14:17:17Z",
    "severity": "MODERATE"
  },
  "details": "n8n before 1.123.55, 2.25.7, and 2.26.2 contains an authorization bypass in the POST /workflows/{workflowId}/test-runs/new endpoint, which authorizes access using the workflow:read scope instead of workflow:execute. An authenticated user with read-only access to a workflow can trigger a real evaluation test run, causing the workflow to execute via the internal workflow runner and resulting in unintended outbound API calls, data mutations, or other side effects in connected downstream systems. The issue primarily affects instances using the Evaluations feature where RBAC project roles grant workflow:read without workflow:execute.",
  "id": "GHSA-xhqv-vmw5-79pm",
  "modified": "2026-07-08T15:32:01Z",
  "published": "2026-07-08T15:32:01Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/n8n-io/n8n/security/advisories/GHSA-hv7x-3x78-gx53"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-56776"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/n8n-incorrect-oauth-scope-validation-in-workflow-test-run-endpoint"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/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:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-XHV3-Q4XX-349R

Vulnerability from github – Published: 2026-06-19 21:43 – Updated: 2026-06-19 21:43

Summary

stistigmem-node: quarantine review surface exposes and mutates other tenants' quarantined facts (cross-tenant BOLA)

Details

Summary

On a multi-tenant stigmem node, a tenant administrator could list, read, and admit or reject quarantined facts belonging to other tenants. The list/count queries and _get_quarantined_fact in routes/quarantine.py lacked an f.tenant_id = identity.tenant_id predicate, and the garden lookup was not tenant-scoped — reached via the /v1/quarantine list and admit/reject endpoints.

Impact

Cross-tenant confidentiality (reading another tenant's quarantined content) and cross-tenant integrity (moderating — admitting or rejecting — another tenant's facts), gated only by a plain tenant write capability rather than a node-level admin authority.

Affected configurations

This is a cross-tenant break. It is exploitable only on deployments running the opt-in stigmem-plugin-multi-tenant (multiple tenants on one node). A default single-tenant node has only tenant="default" — there is no second tenant to cross — so it is not exploitable on default deployments. The rating is HIGH for the multi-tenant deployments the plugin exists to isolate.

Patches

Fixed in 0.9.0a12 (PR #728): AND f.tenant_id = identity.tenant_id was added to the list/count queries and _get_quarantined_fact; the garden lookup is now tenant-scoped; and any genuinely cross-tenant moderation is gated behind can_admin_federation() (node superadmin), not a tenant write capability. A tenant-B admin can no longer list, admit, or reject tenant-A's quarantined facts.

Workarounds

None other than upgrading to 0.9.0a12. Single-tenant deployments are unaffected.

Severity

8.6 (High)


                  
                    CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "stigmem-node"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.9.0a12"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-639",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-19T21:43:00Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\nOn a multi-tenant stigmem node, a tenant administrator could list, read, and **admit or reject** quarantined facts belonging to **other** tenants. The list/count queries and `_get_quarantined_fact` in `routes/quarantine.py` lacked an `f.tenant_id = identity.tenant_id` predicate, and the garden lookup was not tenant-scoped \u2014 reached via the `/v1/quarantine` list and admit/reject endpoints.\n\n### Impact\nCross-tenant confidentiality (reading another tenant\u0027s quarantined content) and cross-tenant integrity (moderating \u2014 admitting or rejecting \u2014 another tenant\u0027s facts), gated only by a plain tenant `write` capability rather than a node-level admin authority.\n\n### Affected configurations\nThis is a cross-**tenant** break. It is exploitable **only** on deployments running the opt-in `stigmem-plugin-multi-tenant` (multiple tenants on one node). A default single-tenant node has only `tenant=\"default\"` \u2014 there is no second tenant to cross \u2014 so it is **not exploitable** on default deployments. The rating is HIGH for the multi-tenant deployments the plugin exists to isolate.\n\n### Patches\nFixed in `0.9.0a12` (PR #728): `AND f.tenant_id = identity.tenant_id` was added to the list/count queries and `_get_quarantined_fact`; the garden lookup is now tenant-scoped; and any genuinely cross-tenant moderation is gated behind `can_admin_federation()` (node superadmin), not a tenant `write` capability. A tenant-B admin can no longer list, admit, or reject tenant-A\u0027s quarantined facts.\n\n### Workarounds\nNone other than upgrading to `0.9.0a12`. Single-tenant deployments are unaffected.",
  "id": "GHSA-xhv3-q4xx-349r",
  "modified": "2026-06-19T21:43:00Z",
  "published": "2026-06-19T21:43:00Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/eidetic-labs/stigmem/security/advisories/GHSA-xhv3-q4xx-349r"
    },
    {
      "type": "WEB",
      "url": "https://github.com/eidetic-labs/stigmem/pull/728"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/eidetic-labs/stigmem"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "stistigmem-node: quarantine review surface exposes and mutates other tenants\u0027 quarantined facts (cross-tenant BOLA)"
}

GHSA-XHX7-6233-WM3W

Vulnerability from github – Published: 2024-10-30 21:30 – Updated: 2024-10-31 18:31

Details

Insecure Permissions vulnerability in Ethereum v.1.12.2 allows a remote attacker to escalate privileges via the _transfer function.

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

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2024-51426"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-10-30T21:15:15Z",
    "severity": "HIGH"
  },
  "details": "Insecure Permissions vulnerability in Ethereum v.1.12.2 allows a remote attacker to escalate privileges via the _transfer function.",
  "id": "GHSA-xhx7-6233-wm3w",
  "modified": "2024-10-31T18:31:18Z",
  "published": "2024-10-30T21:30:41Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-51426"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Wzy-source/Gala/blob/main/CVEs/EOTT_0x5fe0971167215aade651f76492f8489e43ceb48a.md"
    }
  ],
  "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-XHXR-RR46-HC8X

Vulnerability from github – Published: 2022-05-24 19:07 – Updated: 2022-07-15 00:00

Details

Improper access control vulnerability in Samsung Members prior to versions 2.4.85.11 in Android O(8.1) and below, and 3.9.10.11 in Android P(9.0) and above allows untrusted applications to cause local file inclusion in webview.

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

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2021-25438"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-07-08T14:15:00Z",
    "severity": "HIGH"
  },
  "details": "Improper access control vulnerability in Samsung Members prior to versions 2.4.85.11 in Android O(8.1) and below, and 3.9.10.11 in Android P(9.0) and above allows untrusted applications to cause local file inclusion in webview.",
  "id": "GHSA-xhxr-rr46-hc8x",
  "modified": "2022-07-15T00:00:18Z",
  "published": "2022-05-24T19:07:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-25438"
    },
    {
      "type": "WEB",
      "url": "https://security.samsungmobile.com/serviceWeb.smsb?year=2021\u0026month=7"
    }
  ],
  "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-XJ5Q-CGQF-CRW9

Vulnerability from github – Published: 2025-03-04 06:30 – Updated: 2025-03-04 06:30

Details

During an annual penetration test conducted on behalf of Axis Communication, Truesec discovered a flaw in the ACAP Application framework that allowed applications to access restricted D-Bus methods within the framework. Axis has released patched AXIS OS versions for the highlighted flaw. Please refer to the Axis security advisory for more information and solution.

Severity

8.5 (High)


                  
                    CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:L/I:H/A:L

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2025-0359"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-03-04T06:15:30Z",
    "severity": "HIGH"
  },
  "details": "During an annual penetration test conducted on behalf of Axis Communication, Truesec discovered a flaw in the ACAP Application framework that allowed applications to access restricted D-Bus methods within the framework. \nAxis has released patched AXIS OS versions for the highlighted flaw. Please refer to the Axis security advisory for more information and solution.",
  "id": "GHSA-xj5q-cgqf-crw9",
  "modified": "2025-03-04T06:30:34Z",
  "published": "2025-03-04T06:30:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-0359"
    },
    {
      "type": "WEB",
      "url": "https://www.axis.com/dam/public/68/08/c5/cve-2025-0359pdf-en-US-466885.pdf"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:L/I:H/A:L",
      "type": "CVSS_V3"
    }
  ]
}

CWE-863

Incorrect Authorization

GHSA-XHGX-QJR6-8FF6

GHSA-XHJW-95FP-8VGQ

Summary

Patches

For more information

GHSA-XHMM-6XR8-JX92

GHSA-XHQ5-45PM-2GJR

Summary

Affected Packages / Versions

Fix Commit(s)

Release Status

Code-Level Confirmation

GHSA-XHQ9-58FW-859P

Summary

Details

PoC

Impact

Recommended Fix

GHSA-XHQV-VMW5-79PM

GHSA-XHV3-Q4XX-349R

Summary

Impact

Affected configurations

Patches

Workarounds

GHSA-XHX7-6233-WM3W

GHSA-XHXR-RR46-HC8X

GHSA-XJ5Q-CGQF-CRW9

Mitigation

Mitigation

Mitigation MIT-4.4

Mitigation

Mitigation