Vulnerability-Lookup

GHSA-XR7R-F8XQ-VFVV

Vulnerability from github – Published: 2024-01-31 22:44 – Updated: 2024-07-05 21:38

Summary

runc vulnerable to container breakout through process.cwd trickery and leaked fds

Details

Impact

In runc 1.1.11 and earlier, due to an internal file descriptor leak, an attacker could cause a newly-spawned container process (from runc exec) to have a working directory in the host filesystem namespace, allowing for a container escape by giving access to the host filesystem ("attack 2"). The same attack could be used by a malicious image to allow a container process to gain access to the host filesystem through runc run ("attack 1"). Variants of attacks 1 and 2 could be also be used to overwrite semi-arbitrary host binaries, allowing for complete container escapes ("attack 3a" and "attack 3b").

Strictly speaking, while attack 3a is the most severe from a CVSS perspective, attacks 2 and 3b are arguably more dangerous in practice because they allow for a breakout from inside a container as opposed to requiring a user execute a malicious image. The reason attacks 1 and 3a are scored higher is because being able to socially engineer users is treated as a given for UI:R vectors, despite attacks 2 and 3b requiring far more minimal user interaction (just reasonable runc exec operations on a container the attacker has access to). In any case, all four attacks can lead to full control of the host system.

Attack 1: `process.cwd` "mis-configuration"

In runc 1.1.11 and earlier, several file descriptors were inadvertently leaked internally within runc into runc init, including a handle to the host's /sys/fs/cgroup (this leak was added in v1.0.0-rc93). If the container was configured to have process.cwd set to /proc/self/fd/7/ (the actual fd can change depending on file opening order in runc), the resulting pid1 process will have a working directory in the host mount namespace and thus the spawned process can access the entire host filesystem. This alone is not an exploit against runc, however a malicious image could make any innocuous-looking non-/ path a symlink to /proc/self/fd/7/ and thus trick a user into starting a container whose binary has access to the host filesystem.

Furthermore, prior to runc 1.1.12, runc also did not verify that the final working directory was inside the container's mount namespace after calling chdir(2) (as we have already joined the container namespace, it was incorrectly assumed there would be no way to chdir outside the container after pivot_root(2)).

The CVSS score for this attack is CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:N (8.2, high severity).

Note that this attack requires a privileged user to be tricked into running a malicious container image. It should be noted that when using higher-level runtimes (such as Docker or Kubernetes), this exploit can be considered critical as it can be done remotely by anyone with the rights to start a container image (and can be exploited from within Dockerfiles using ONBUILD in the case of Docker).

Attack 2: `runc exec` container breakout

(This is a modification of attack 1, constructed to allow for a process inside a container to break out.)

The same fd leak and lack of verification of the working directory in attack 1 also apply to runc exec. If a malicious process inside the container knows that some administrative process will call runc exec with the --cwd argument and a given path, in most cases they can replace that path with a symlink to /proc/self/fd/7/. Once the container process has executed the container binary, PR_SET_DUMPABLE protections no longer apply and the attacker can open /proc/$exec_pid/cwd to get access to the host filesystem.

runc exec defaults to a cwd of / (which cannot be replaced with a symlink), so this attack depends on the attacker getting a user (or some administrative process) to use --cwd and figuring out what path the target working directory is. Note that if the target working directory is a parent of the program binary being executed, the attacker might be unable to replace the path with a symlink (the execve will fail in most cases, unless the host filesystem layout specifically matches the container layout in specific ways and the attacker knows which binary the runc exec is executing).

The CVSS score for this attack is CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:C/C:H/I:H/A:N (7.2, high severity).

Attacks 3a and 3b: `process.args` host binary overwrite attack

(These are modifications of attacks 1 and 2, constructed to overwrite a host binary by using execve to bring a magic-link reference into the container.)

Attacks 1 and 2 can be adapted to overwrite a host binary by using a path like /proc/self/fd/7/../../../bin/bash as the process.args binary argument, causing a host binary to be executed by a container process. The /proc/$pid/exe handle can then be used to overwrite the host binary, as seen in CVE-2019-5736 (note that the same #! trick can be used to avoid detection as an attacker). As the overwritten binary could be something like /bin/bash, as soon as a privileged user executes the target binary on the host, the attacker can pivot to gain full access to the host.

For the purposes of CVSS scoring:

Attack 3a is attack 1 but adapted to overwrite a host binary, where a malicious image is set up to execute /proc/self/fd/7/../../../bin/bash and run a shell script that overwrites /proc/self/exe, overwriting the host copy of /bin/bash. The CVSS score for this attack is CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H (8.6, high severity).
Attack 3b is attack 2 but adapted to overwrite a host binary, where the malicious container process overwrites all of the possible runc exec target binaries inside the container (such as /bin/bash) such that a host target binary is executed and then the container process opens /proc/$pid/exe to get access to the host binary and overwrite it. The CVSS score for this attack is CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:H (8.2, high severity).

As mentioned in attack 1, while 3b is scored lower it is more dangerous in practice as it doesn't require a user to run a malicious image.

Patches

runc 1.1.12 has been released, and includes patches for this issue. Note that there are four separate fixes applied:

Checking that the working directory is actually inside the container by checking whether os.Getwd returns ENOENT (Linux provides a way of detecting if cwd is outside the current namespace root). This explicitly blocks runc from executing a container process when inside a non-container path and thus eliminates attacks 1 and 2 even in the case of fd leaks.
Close all internal runc file descriptors in the final stage of runc init, right before execve. This ensures that internal file descriptors cannot be used as an argument to execve and thus eliminates attacks 3a and 3b, even in the case of fd leaks. This requires hooking into some Go runtime internals to make sure we don't close critical Go internal file descriptors.
Fixing the specific fd leaks that made these bug exploitable (mark /sys/fs/cgroup as O_CLOEXEC and backport a fix for some *os.File leaks).
In order to protect against future runc init file descriptor leaks, mark all non-stdio files as O_CLOEXEC before executing runc init.

Other Runtimes

We have discovered that several other container runtimes are either potentially vulnerable to similar attacks, or do not have sufficient protection against attacks of this nature. We recommend other container runtime authors look at our patches and make sure they at least add a getcwd() != ENOENT check as well as consider whether close_range(3, UINT_MAX, CLOSE_RANGE_CLOEXEC) before executing their equivalent of runc init is appropriate.

crun 1.12 does not leak any useful file descriptors into the runc init-equivalent process (so this attack is not exploitable as far as we can tell), but no care is taken to make sure all non-stdio files are O_CLOEXEC and there is no check after chdir(2) to ensure the working directory is inside the container. If a file descriptor happened to be leaked in the future, this could be exploitable. In addition, any file descriptors passed to crun are not closed until the container process is executed, meaning that easily-overlooked programming errors by users of crun can lead to these attacks becoming exploitable.
youki 0.3.1 does not leak any useful file descriptors into the runc init-equivalent process (so this attack is not exploitable as far as we can tell) however this appears to be pure luck. youki does leak a directory file descriptor from the host mount namespace, but it just so happens that the directory is the rootfs of the container (which then gets pivot_root'd into and so ends up as a in-root path thanks to chroot_fs_refs). In addition, no care is taken to make sure all non-stdio files are O_CLOEXEC and there is no check after chdir(2) to ensure the working directory is inside the container. If a file descriptor happened to be leaked in the future, this could be exploitable. In addition, any file descriptors passed to youki are not closed until the container process is executed, meaning that easily-overlooked programming errors by users of youki can lead to these attacks becoming exploitable.
LXC 5.0.3 does not appear to leak any useful file descriptors, and they have comments noting the importance of not leaking file descriptors in lxc-attach. However, they don't seem to have any proactive protection against file descriptor leaks at the point of chdir such as using close_range(...) (they do have RAII-like __do_fclose closers but those don't necessarily stop all leaks in this context) nor do they have any check after chdir(2) to ensure the working directory is inside the container. Unfortunately it seems they cannot use CLOSE_RANGE_CLOEXEC because they don't need to re-exec themselves.

Workarounds

For attacks 1 and 2, only permit containers (and runc exec) to use a process.cwd of /. It is not possible for / to be replaced with a symlink (the path is resolved from within the container's mount namespace, and you cannot change the root of a mount namespace or an fs root to a symlink).

For attacks 1 and 3a, only permit users to run trusted images.

For attack 3b, there is no practical workaround other than never using runc exec because any binary you try to execute with runc exec could end up being a malicious binary target.

Credits

Thanks to Rory McNamara from Snyk for discovering and disclosing the original vulnerability (attack 1) to Docker, @lifubang from acmcoder for discovering how to adapt the attack to overwrite host binaries (attack 3a), and Aleksa Sarai from SUSE for discovering how to adapt the attacks to work as container breakouts using runc exec (attacks 2 and 3b).

Severity

8.6 (High)


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

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.1.11"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/opencontainers/runc"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.0.0-rc93"
            },
            {
              "fixed": "1.1.12"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-21626"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-403",
      "CWE-668"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-01-31T22:44:08Z",
    "nvd_published_at": "2024-01-31T22:15:53Z",
    "severity": "HIGH"
  },
  "details": "### Impact\n\nIn runc 1.1.11 and earlier, due to an internal file descriptor leak, an attacker could cause a newly-spawned container process (from `runc exec`) to have a working directory in the host filesystem namespace, allowing for a container escape by giving access to the host filesystem (\"attack 2\"). The same attack could be used by a malicious image to allow a container process to gain access to the host filesystem through `runc run` (\"attack 1\"). Variants of attacks 1 and 2 could be also be used to overwrite semi-arbitrary host binaries, allowing for complete container escapes (\"attack 3a\" and \"attack 3b\").\n\nStrictly speaking, while attack 3a is the most severe from a CVSS perspective, attacks 2 and 3b are arguably more dangerous in practice because they allow for a breakout from inside a container as opposed to requiring a user execute a malicious image. The reason attacks 1 and 3a are scored higher is because being able to socially engineer users is treated as a given for UI:R vectors, despite attacks 2 and 3b requiring far more minimal user interaction (just reasonable `runc exec` operations on a container the attacker has access to). In any case, all four attacks can lead to full control of the host system.\n\n#### Attack 1: `process.cwd` \"mis-configuration\"\n\nIn runc 1.1.11 and earlier, several file descriptors were inadvertently leaked internally within runc into `runc init`, including a handle to the host\u0027s `/sys/fs/cgroup` (this leak was added in v1.0.0-rc93). If the container was configured to have `process.cwd` set to `/proc/self/fd/7/` (the actual fd can change depending on file opening order in `runc`), the resulting pid1 process will have a working directory in the host mount namespace and thus the spawned process can access the entire host filesystem. This alone is not an exploit against runc, however a malicious image could make any innocuous-looking non-`/` path a symlink to `/proc/self/fd/7/` and thus trick a user into starting a container whose binary has access to the host filesystem.\n\nFurthermore, prior to runc 1.1.12, runc also did not verify that the final working directory was inside the container\u0027s mount namespace after calling `chdir(2)` (as we have already joined the container namespace, it was incorrectly assumed there would be no way to chdir outside the container after `pivot_root(2)`).\n\nThe CVSS score for this attack is CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:N (8.2, high severity).\n\nNote that this attack requires a privileged user to be tricked into running a malicious container image. It should be noted that when using higher-level runtimes (such as Docker or Kubernetes), this exploit can be considered critical as it can be done remotely by anyone with the rights to start a container image (and can be exploited from within Dockerfiles using `ONBUILD` in the case of Docker).\n\n#### Attack 2: `runc exec` container breakout\n\n(This is a modification of attack 1, constructed to allow for a process inside a container to break out.)\n\nThe same fd leak and lack of verification of the working directory in attack 1 also apply to `runc exec`. If a malicious process inside the container knows that some administrative process will call `runc exec` with the `--cwd` argument and a given path, in most cases they can replace that path with a symlink to `/proc/self/fd/7/`. Once the container process has executed the container binary, `PR_SET_DUMPABLE` protections no longer apply and the attacker can open `/proc/$exec_pid/cwd` to get access to the host filesystem.\n\n`runc exec` defaults to a cwd of `/` (which cannot be replaced with a symlink), so this attack depends on the attacker getting a user (or some administrative process) to use `--cwd` and figuring out what path the target working directory is. Note that if the target working directory is a parent of the program binary being executed, the attacker might be unable to replace the path with a symlink (the `execve` will fail in most cases, unless the host filesystem layout specifically matches the container layout in specific ways and the attacker knows which binary the `runc exec` is executing).\n\nThe CVSS score for this attack is CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:C/C:H/I:H/A:N (7.2, high severity).\n\n#### Attacks 3a and 3b: `process.args` host binary overwrite attack\n\n(These are modifications of attacks 1 and 2, constructed to overwrite a host binary by using `execve` to bring a magic-link reference into the container.)\n\nAttacks 1 and 2 can be adapted to overwrite a host binary by using a path like `/proc/self/fd/7/../../../bin/bash` as the `process.args` binary argument, causing a host binary to be executed by a container process. The `/proc/$pid/exe` handle can then be used to overwrite the host binary, as seen in CVE-2019-5736 (note that the same `#!` trick can be used to avoid detection as an attacker). As the overwritten binary could be something like `/bin/bash`, as soon as a privileged user executes the target binary on the host, the attacker can pivot to gain full access to the host.\n\nFor the purposes of CVSS scoring:\n\n* Attack 3a is attack 1 but adapted to overwrite a host binary, where a malicious image is set up to execute `/proc/self/fd/7/../../../bin/bash` and run a shell script that overwrites `/proc/self/exe`, overwriting the host copy of `/bin/bash`. The CVSS score for this attack is CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H (8.6, high severity).\n* Attack 3b is attack 2 but adapted to overwrite a host binary, where the malicious container process overwrites all of the possible `runc exec` target binaries inside the container (such as `/bin/bash`) such that a host target binary is executed and then the container process opens `/proc/$pid/exe` to get access to the host binary and overwrite it. The CVSS score for this attack is CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:H (8.2, high severity).\n\nAs mentioned in attack 1, while 3b is scored lower it is more dangerous in practice as it doesn\u0027t require a user to run a malicious image.\n\n### Patches\nrunc 1.1.12 has been released, and includes patches for this issue. Note that there are four separate fixes applied:\n\n* Checking that the working directory is actually inside the container by checking whether `os.Getwd` returns `ENOENT` (Linux provides a way of detecting if cwd is outside the current namespace root). This explicitly blocks runc from executing a container process when inside a non-container path and thus eliminates attacks 1 and 2 even in the case of fd leaks.\n* Close all internal runc file descriptors in the final stage of `runc init`, right before `execve`. This ensures that internal file descriptors cannot be used as an argument to `execve` and thus eliminates attacks 3a and 3b, even in the case of fd leaks. This requires hooking into some Go runtime internals to make sure we don\u0027t close critical Go internal file descriptors.\n* Fixing the specific fd leaks that made these bug exploitable (mark `/sys/fs/cgroup` as `O_CLOEXEC` and backport a fix for some `*os.File` leaks).\n* In order to protect against future `runc init` file descriptor leaks, mark all non-stdio files as `O_CLOEXEC` before executing `runc init`.\n\n### Other Runtimes\n\nWe have discovered that several other container runtimes are either potentially vulnerable to similar attacks, or do not have sufficient protection against attacks of this nature. We recommend other container runtime authors look at [our patches](#Patches) and make sure they at least add a `getcwd() != ENOENT` check as well as consider whether `close_range(3, UINT_MAX, CLOSE_RANGE_CLOEXEC)` before executing their equivalent of `runc init` is appropriate.\n\n * crun 1.12 does not leak any useful file descriptors into the `runc init`-equivalent process (so this attack is _not exploitable_ as far as we can tell), but no care is taken to make sure all non-stdio files are `O_CLOEXEC` and there is no check after `chdir(2)` to ensure the working directory is inside the container. If a file descriptor happened to be leaked in the future, this could be exploitable. In addition, any file descriptors passed to `crun` are not closed until the container process is executed, meaning that easily-overlooked programming errors by users of `crun` can lead to these attacks becoming exploitable.\n * youki 0.3.1 does not leak any useful file descriptors into the `runc init`-equivalent process (so this attack is _not exploitable_ as far as we can tell) however this appears to be pure luck. `youki` does leak a directory file descriptor from the host mount namespace, but it just so happens that the directory is the rootfs of the container (which then gets `pivot_root`\u0027d into and so ends up as a in-root path thanks to `chroot_fs_refs`). In addition, no care is taken to make sure all non-stdio files are `O_CLOEXEC` and there is no check after `chdir(2)` to ensure the working directory is inside the container. If a file descriptor happened to be leaked in the future, this could be exploitable. In addition, any file descriptors passed to `youki` are not closed until the container process is executed, meaning that easily-overlooked programming errors by users of `youki` can lead to these attacks becoming exploitable.\n * LXC 5.0.3 does not appear to leak any useful file descriptors, and they have comments noting the importance of not leaking file descriptors in `lxc-attach`. However, they don\u0027t seem to have any proactive protection against file descriptor leaks at the point of `chdir` such as using `close_range(...)` (they do have RAII-like `__do_fclose` closers but those don\u0027t necessarily stop all leaks in this context) nor do they have any check after `chdir(2)` to ensure the working directory is inside the container. Unfortunately it seems they cannot use `CLOSE_RANGE_CLOEXEC` because they don\u0027t need to re-exec themselves.\n\n### Workarounds\nFor attacks 1 and 2, only permit containers (and `runc exec`) to use a `process.cwd` of `/`. It is not possible for `/` to be replaced with a symlink (the path is resolved from within the container\u0027s mount namespace, and you cannot change the root of a mount namespace or an fs root to a symlink).\n\nFor attacks 1 and 3a, only permit users to run trusted images.\n\nFor attack 3b, there is no practical workaround other than never using `runc exec` because any binary you try to execute with `runc exec` could end up being a malicious binary target.\n\n### See Also\n* https://www.cve.org/CVERecord?id=CVE-2024-21626\n* https://github.com/opencontainers/runc/releases/tag/v1.1.12\n* The runc 1.1.12 merge commit https://github.com/opencontainers/runc/commit/a9833ff391a71b30069a6c3f816db113379a4346, which contains the following security patches:\n  * https://github.com/opencontainers/runc/commit/506552a88bd3455e80a9b3829568e94ec0160309\n  * https://github.com/opencontainers/runc/commit/0994249a5ec4e363bfcf9af58a87a722e9a3a31b\n  * https://github.com/opencontainers/runc/commit/fbe3eed1e568a376f371d2ced1b4ac16b7d7adde\n  * https://github.com/opencontainers/runc/commit/284ba3057e428f8d6c7afcc3b0ac752e525957df\n  * https://github.com/opencontainers/runc/commit/b6633f48a8c970433737b9be5bfe4f25d58a5aa7\n  * https://github.com/opencontainers/runc/commit/683ad2ff3b01fb142ece7a8b3829de17150cf688\n  * https://github.com/opencontainers/runc/commit/e9665f4d606b64bf9c4652ab2510da368bfbd951\n\n### Credits\n\nThanks to Rory McNamara from Snyk for discovering and disclosing the original vulnerability (attack 1) to Docker, @lifubang from acmcoder for discovering how to adapt the attack to overwrite host binaries (attack 3a), and Aleksa Sarai from SUSE for discovering how to adapt the attacks to work as container breakouts using `runc exec` (attacks 2 and 3b).",
  "id": "GHSA-xr7r-f8xq-vfvv",
  "modified": "2024-07-05T21:38:20Z",
  "published": "2024-01-31T22:44:08Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/opencontainers/runc/security/advisories/GHSA-xr7r-f8xq-vfvv"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-21626"
    },
    {
      "type": "WEB",
      "url": "https://github.com/opencontainers/runc/commit/02120488a4c0fc487d1ed2867e901eeed7ce8ecf"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/opencontainers/runc"
    },
    {
      "type": "WEB",
      "url": "https://github.com/opencontainers/runc/releases/tag/v1.1.12"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2024/02/msg00005.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/2NLXNE23Q5ESQUAI22Z7A63JX2WMPJ2J"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/SYMO3BANINS6RGFQFKPRG4FIOJ7GWYTL"
    },
    {
      "type": "WEB",
      "url": "http://packetstormsecurity.com/files/176993/runc-1.1.11-File-Descriptor-Leak-Privilege-Escalation.html"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2024/02/01/1"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2024/02/02/3"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "runc vulnerable to container breakout through process.cwd trickery and leaked fds"
}

GHSA-XV34-WQ27-W2WM

Vulnerability from github – Published: 2022-05-13 01:46 – Updated: 2025-04-20 03:33

Details

tcpdf before 6.2.0 uploads files from the server generating PDF-files to an external FTP.

Severity

7.5 (High)


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

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2017-6100"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-668"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-02-23T19:59:00Z",
    "severity": "HIGH"
  },
  "details": "tcpdf before 6.2.0 uploads files from the server generating PDF-files to an external FTP.",
  "id": "GHSA-xv34-wq27-w2wm",
  "modified": "2025-04-20T03:33:20Z",
  "published": "2022-05-13T01:46:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-6100"
    },
    {
      "type": "WEB",
      "url": "https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=814030"
    },
    {
      "type": "WEB",
      "url": "https://sourceforge.net/p/tcpdf/bugs/1005"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2017/02/19/1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-XV9F-6XV6-JRW4

Vulnerability from github – Published: 2022-06-17 00:01 – Updated: 2022-06-28 00:00

Details

CA Automic Automation 12.2 and 12.3 contain an insecure file creation and handling vulnerability in the Automic agent that could allow a user to potentially elevate privileges.

Severity

8.8 (High)


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

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2022-33753"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-668"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-06-16T22:15:00Z",
    "severity": "HIGH"
  },
  "details": "CA Automic Automation 12.2 and 12.3 contain an insecure file creation and handling vulnerability in the Automic agent that could allow a user to potentially elevate privileges.",
  "id": "GHSA-xv9f-6xv6-jrw4",
  "modified": "2022-06-28T00:00:44Z",
  "published": "2022-06-17T00:01:21Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-33753"
    },
    {
      "type": "WEB",
      "url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/20629"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-XVM4-HFQ6-6R23

Vulnerability from github – Published: 2023-06-06 09:30 – Updated: 2024-04-04 04:34

Details

Information disclosure in Linux Networking Firmware due to unauthorized information leak during side channel analysis.

Severity

7.1 (High)


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

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2022-40525"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-668"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-06-06T08:15:11Z",
    "severity": "MODERATE"
  },
  "details": "Information disclosure in Linux Networking Firmware due to unauthorized information leak during side channel analysis.",
  "id": "GHSA-xvm4-hfq6-6r23",
  "modified": "2024-04-04T04:34:16Z",
  "published": "2023-06-06T09:30:19Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-40525"
    },
    {
      "type": "WEB",
      "url": "https://www.qualcomm.com/company/product-security/bulletins/june-2023-bulletin"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-XVMP-X3RV-7475

Vulnerability from github – Published: 2022-02-10 00:00 – Updated: 2023-08-08 15:31

Details

In Zammad 5.0.2, agents can configure "out of office" periods and substitute persons. If the substitute persons didn't have the same permissions as the original agent, they could receive ticket notifications for tickets that they have no access to.

Severity

5.3 (Medium)


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

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2021-44886"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-668"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-02-04T15:15:00Z",
    "severity": "MODERATE"
  },
  "details": "In Zammad 5.0.2, agents can configure \"out of office\" periods and substitute persons. If the substitute persons didn\u0027t have the same permissions as the original agent, they could receive ticket notifications for tickets that they have no access to.",
  "id": "GHSA-xvmp-x3rv-7475",
  "modified": "2023-08-08T15:31:37Z",
  "published": "2022-02-10T00:00:52Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-44886"
    },
    {
      "type": "WEB",
      "url": "https://zammad.com/en/advisories/zaa-2021-21"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-XVXC-929R-6MVQ

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

Details

NetSarang Xshell 7 before Build 0077 includes unintended code strings in paste operations.

Severity

5.3 (Medium)


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

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2021-37326"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-668"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-08-15T16:15:00Z",
    "severity": "MODERATE"
  },
  "details": "NetSarang Xshell 7 before Build 0077 includes unintended code strings in paste operations.",
  "id": "GHSA-xvxc-929r-6mvq",
  "modified": "2022-07-13T00:01:33Z",
  "published": "2022-05-24T19:11:10Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-37326"
    },
    {
      "type": "WEB",
      "url": "https://www.netsarang.com/en/xshell-update-history"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-XW4C-9434-3F7P

Vulnerability from github – Published: 2022-05-24 16:51 – Updated: 2023-10-26 16:22

Summary

Jenkins Google Kubernetes Engine Plugin vulnerable to Exposure of Resource to Wrong Sphere

Details

Jenkins Google Kubernetes Engine Plugin 0.6.2 and earlier created a temporary file named .kube…config containing a temporary access token in the project workspace, where it could be accessed by users with Job/Read permission.

This temporary file is now created outside the regular project workspace.

Severity

4.3 (Medium)


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

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.jenkins-ci.plugins:google-kubernetes-engine"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.6.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2019-10365"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-668"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-03-03T23:12:53Z",
    "nvd_published_at": "2019-07-31T13:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Jenkins Google Kubernetes Engine Plugin 0.6.2 and earlier created a temporary file named `.kube\u2026config` containing a temporary access token in the project workspace, where it could be accessed by users with Job/Read permission.\n\nThis temporary file is now created outside the regular project workspace.",
  "id": "GHSA-xw4c-9434-3f7p",
  "modified": "2023-10-26T16:22:00Z",
  "published": "2022-05-24T16:51:51Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-10365"
    },
    {
      "type": "WEB",
      "url": "https://jenkins.io/security/advisory/2019-07-31/#SECURITY-1345"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2019/07/31/1"
    }
  ],
  "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": "Jenkins Google Kubernetes Engine Plugin vulnerable to Exposure of Resource to Wrong Sphere"
}

GHSA-XXH6-F3X3-2XGF

Vulnerability from github – Published: 2023-02-14 06:31 – Updated: 2023-02-21 21:30

Details

An attacker authenticated as a non-admin user with local access to a server port assigned to the SAP Host Agent (Start Service) - versions 7.21, 7.22, can submit a crafted ConfigureOutsideDiscovery request with an operating system command which will be executed with administrator privileges. The OS command can read or modify any user or system data and can make the system unavailable.

Severity

8.8 (High)


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

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2023-24523"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-668"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-02-14T04:15:00Z",
    "severity": "HIGH"
  },
  "details": "An attacker authenticated as a non-admin user with local access to a server port assigned to the SAP Host Agent (Start Service) - versions 7.21, 7.22, can submit a crafted ConfigureOutsideDiscovery request with an operating system command which will be executed with administrator privileges. The OS command can read or modify any user or system data and can make the system unavailable.",
  "id": "GHSA-xxh6-f3x3-2xgf",
  "modified": "2023-02-21T21:30:18Z",
  "published": "2023-02-14T06:31:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-24523"
    },
    {
      "type": "WEB",
      "url": "https://launchpad.support.sap.com/#/notes/3285757"
    },
    {
      "type": "WEB",
      "url": "https://www.sap.com/documents/2022/02/fa865ea4-167e-0010-bca6-c68f7e60039b.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-XXPW-32HF-Q8V9

Vulnerability from github – Published: 2026-03-05 01:22 – Updated: 2026-03-06 14:24

Summary

AVideo: Unauthenticated PHP session store exposed to host network via published memcached port

Details

Summary

The official docker-compose.yml publishes the memcached service on host port 11211 (0.0.0.0:11211) with no authentication, while the Dockerfile configures PHP to store all user sessions in that memcached instance. An attacker who can reach port 11211 can read, modify, or flush session data — enabling session hijacking, admin impersonation, and mass session destruction without any application-level authentication.

Severity

High (CVSS 3.1: 8.1)

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

Attack Vector: Network — docker-compose.yml binds memcached to 0.0.0.0:11211 on the host
Attack Complexity: High — exploitation requires port 11211 to be network-reachable, which depends on external firewall/security group configuration beyond the attacker's control
Privileges Required: None — memcached has no authentication mechanism enabled
User Interaction: None
Scope: Unchanged — impact is to the AVideo application's session management
Confidentiality Impact: High — session data includes user IDs, admin flags, email addresses, and password hashes
Integrity Impact: High — an attacker can modify session data to inject admin privileges or impersonate any user
Availability Impact: High — flush_all destroys all active sessions, forcing mass logout

Affected Component

docker-compose.yml — memcached service ports directive (line 203)
Dockerfile — PHP session configuration (lines 150-151)

CWE

CWE-668: Exposure of Resource to Wrong Sphere
CWE-287: Improper Authentication (memcached has no authentication)

Description

Memcached port unnecessarily published to host network

The docker-compose.yml publishes the memcached port to the Docker host's network interface:

# docker-compose.yml — lines 192-213
  memcached:
    image: memcached:alpine
    restart: unless-stopped
    command: >
      memcached -m 512 -c 2048 -t ${NPROC:-4} -R 200
    ports:
      - "${MEMCACHE_PORT:-11211}:11211"    # <-- Exposes to 0.0.0.0:11211
    networks:
      - app_net

The memcached command has no authentication flags: - No -S flag (SASL authentication) - No -l 127.0.0.1 flag (interface binding restriction)

The default env.example reinforces this port:

MEMCACHE_PORT=11211

PHP sessions stored entirely in memcached

The Dockerfile configures PHP to use memcached as the session store:

; Dockerfile — lines 150-151
session.save_handler           = memcached
session.save_path              = "memcached:11211?persistent=1&timeout=2&retry_interval=5"

Session data contains all authentication state

The application stores complete authentication state in sessions. From objects/user.php:

// user.php:1521 — login check
$isLogged = !empty($_SESSION['user']['id']);

// user.php:1544 — admin check
return !empty($_SESSION['user']['isAdmin']);

Session data includes: user ID, email, username, password hash, admin flag, channel name, photo URL, and email verification status (user.php lines 329-733). All of this is readable and writable via the exposed memcached port.

Inconsistent defense: database services are correctly internal-only

The docker-compose.yml demonstrates awareness of proper service isolation — both database services have NO ports: directive:

# docker-compose.yml — database service (lines 136-163)
  database:
    build:
      context: .
      dockerfile: Dockerfile.mariadb
    # ... NO ports: directive — internal only
    networks:
      - app_net

# docker-compose.yml — database_encoder service (lines 165-189)
  database_encoder:
    build:
      context: .
      dockerfile: Dockerfile.mariadb
    # ... NO ports: directive — internal only
    networks:
      - app_net

Both databases are only reachable via the internal app_net Docker network. Memcached — which stores equally sensitive session data — should follow the same pattern but does not. This inconsistency confirms the exposure is an oversight, not a design choice.

Port exposure map

Service	Ports published to host	Contains sensitive data	Exposure justified
avideo	80, 443, 2053	N/A (web server)	Yes — serves web traffic
live	1935, 8080, 8443	N/A (streaming)	Yes — serves RTMP/HLS
database	None	Yes (all app data)	Correct — internal only
database_encoder	None	Yes (encoder data)	Correct — internal only
memcached	11211	Yes (all sessions)	No — should be internal only

Execution chain

Attacker scans the target host and discovers port 11211 is open
Attacker connects with nc TARGET 11211 or any memcached client — no authentication required
Attacker runs stats items to enumerate session slab classes
Attacker runs stats cachedump <slab_id> <limit> to list session keys
Attacker runs get <session_key> to read serialized PHP session data containing user IDs, admin flags, and password hashes
Attacker either:
Hijacks a session: uses the session ID as a cookie to impersonate the user
Escalates privileges: modifies session data to set isAdmin to true via set <session_key>
Performs DoS: runs flush_all to destroy all sessions

Proof of Concept

# 1. Verify memcached is reachable (returns server stats)
echo -e "stats\r" | nc TARGET 11211

# 2. Enumerate session keys
echo -e "stats items\r" | nc TARGET 11211
# Then for each slab:
echo -e "stats cachedump 1 100\r" | nc TARGET 11211

# 3. Read a session (key format: memc.sess.key.<session_id>)
echo -e "get memc.sess.key.abc123sessionid\r" | nc TARGET 11211
# Returns serialized PHP session with user data, admin flag, etc.

# 4. DoS — destroy all sessions (logs out every user)
echo -e "flush_all\r" | nc TARGET 11211

For session hijacking, extract the session ID from step 3 and set it as the PHPSESSID cookie in a browser to impersonate the victim user.

Impact

Session hijacking: Read any user's session data and impersonate them by reusing their session ID — including admin accounts
Privilege escalation: Modify session data to set $_SESSION['user']['isAdmin'] to a truthy value, granting admin access to any session
Credential exposure: Session data includes password hashes ($_SESSION['user']['passhash'], user.php:555) that can be cracked offline
Mass session destruction: flush_all destroys all active sessions, forcing every logged-in user to re-authenticate — a one-command denial of service
Reconnaissance: stats reveals server uptime, memory usage, connection counts, and cache hit/miss ratios

Recommended Remediation

Option 1: Remove the port mapping (preferred — one-line fix)

Memcached is only used internally by the PHP application via Docker networking. Remove the ports: directive entirely:

# docker-compose.yml — memcached service
  memcached:
    image: memcached:alpine
    restart: unless-stopped
    command: >
      memcached -m 512 -c 2048 -t ${NPROC:-4} -R 200
    # REMOVED: ports:
    #   - "${MEMCACHE_PORT:-11211}:11211"
    deploy:
      resources:
        limits:
          cpus: '1'
          memory: "4G"
        reservations:
          cpus: '0.5'
          memory: '1G'
    networks:
      - app_net

Also remove MEMCACHE_PORT=11211 from env.example since the port is no longer published.

The PHP application connects via the Docker internal hostname memcached:11211 (from session.save_path), which uses the app_net bridge network and does not require host-level port mapping.

Option 2: Bind memcached to localhost only (if host access is needed for debugging)

If host-level access to memcached is needed for debugging, bind only to the loopback interface:

    ports:
      - "127.0.0.1:${MEMCACHE_PORT:-11211}:11211"

This prevents remote access while allowing localhost:11211 connections from the Docker host.

Option 3: Enable SASL authentication (defense-in-depth)

Add SASL authentication to memcached as an additional layer:

    command: >
      memcached -m 512 -c 2048 -t ${NPROC:-4} -R 200 -S
    environment:
      MEMCACHED_USERNAME: "${MEMCACHED_USER:-avideo}"
      MEMCACHED_PASSWORD: "${MEMCACHED_PASSWORD}"

Update the PHP session configuration accordingly:

session.save_path = "PERSISTENT=myapp avideo:${MEMCACHED_PASSWORD}@memcached:11211"

Note: Option 1 alone is sufficient and should be applied immediately. Options 2 and 3 provide defense-in-depth.

Credit

This vulnerability was discovered and reported by bugbunny.ai.

Severity

8.1 (High)


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

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "wwbn/avideo"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "21.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-29093"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287",
      "CWE-668"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-05T01:22:21Z",
    "nvd_published_at": "2026-03-06T04:16:08Z",
    "severity": "HIGH"
  },
  "details": "## Summary\nThe official `docker-compose.yml` publishes the memcached service on host port 11211 (`0.0.0.0:11211`) with no authentication, while the Dockerfile configures PHP to store all user sessions in that memcached instance. An attacker who can reach port 11211 can read, modify, or flush session data \u2014 enabling session hijacking, admin impersonation, and mass session destruction without any application-level authentication.\n\n## Severity\n**High** (CVSS 3.1: 8.1)\n\n`CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H`\n\n- **Attack Vector:** Network \u2014 `docker-compose.yml` binds memcached to `0.0.0.0:11211` on the host\n- **Attack Complexity:** High \u2014 exploitation requires port 11211 to be network-reachable, which depends on external firewall/security group configuration beyond the attacker\u0027s control\n- **Privileges Required:** None \u2014 memcached has no authentication mechanism enabled\n- **User Interaction:** None\n- **Scope:** Unchanged \u2014 impact is to the AVideo application\u0027s session management\n- **Confidentiality Impact:** High \u2014 session data includes user IDs, admin flags, email addresses, and password hashes\n- **Integrity Impact:** High \u2014 an attacker can modify session data to inject admin privileges or impersonate any user\n- **Availability Impact:** High \u2014 `flush_all` destroys all active sessions, forcing mass logout\n\n## Affected Component\n- `docker-compose.yml` \u2014 memcached service `ports` directive (line 203)\n- `Dockerfile` \u2014 PHP session configuration (lines 150-151)\n\n## CWE\n- **CWE-668**: Exposure of Resource to Wrong Sphere\n- **CWE-287**: Improper Authentication (memcached has no authentication)\n\n## Description\n\n### Memcached port unnecessarily published to host network\n\nThe `docker-compose.yml` publishes the memcached port to the Docker host\u0027s network interface:\n\n```yaml\n# docker-compose.yml \u2014 lines 192-213\n  memcached:\n    image: memcached:alpine\n    restart: unless-stopped\n    command: \u003e\n      memcached -m 512 -c 2048 -t ${NPROC:-4} -R 200\n    ports:\n      - \"${MEMCACHE_PORT:-11211}:11211\"    # \u003c-- Exposes to 0.0.0.0:11211\n    networks:\n      - app_net\n```\n\nThe memcached command has no authentication flags:\n- No `-S` flag (SASL authentication)\n- No `-l 127.0.0.1` flag (interface binding restriction)\n\nThe default `env.example` reinforces this port:\n```\nMEMCACHE_PORT=11211\n```\n\n### PHP sessions stored entirely in memcached\n\nThe Dockerfile configures PHP to use memcached as the session store:\n\n```ini\n; Dockerfile \u2014 lines 150-151\nsession.save_handler           = memcached\nsession.save_path              = \"memcached:11211?persistent=1\u0026timeout=2\u0026retry_interval=5\"\n```\n\n### Session data contains all authentication state\n\nThe application stores complete authentication state in sessions. From `objects/user.php`:\n\n```php\n// user.php:1521 \u2014 login check\n$isLogged = !empty($_SESSION[\u0027user\u0027][\u0027id\u0027]);\n\n// user.php:1544 \u2014 admin check\nreturn !empty($_SESSION[\u0027user\u0027][\u0027isAdmin\u0027]);\n```\n\nSession data includes: user ID, email, username, password hash, admin flag, channel name, photo URL, and email verification status (user.php lines 329-733). All of this is readable and writable via the exposed memcached port.\n\n### Inconsistent defense: database services are correctly internal-only\n\nThe `docker-compose.yml` demonstrates awareness of proper service isolation \u2014 both database services have NO `ports:` directive:\n\n```yaml\n# docker-compose.yml \u2014 database service (lines 136-163)\n  database:\n    build:\n      context: .\n      dockerfile: Dockerfile.mariadb\n    # ... NO ports: directive \u2014 internal only\n    networks:\n      - app_net\n\n# docker-compose.yml \u2014 database_encoder service (lines 165-189)\n  database_encoder:\n    build:\n      context: .\n      dockerfile: Dockerfile.mariadb\n    # ... NO ports: directive \u2014 internal only\n    networks:\n      - app_net\n```\n\nBoth databases are only reachable via the internal `app_net` Docker network. Memcached \u2014 which stores equally sensitive session data \u2014 should follow the same pattern but does not. This inconsistency confirms the exposure is an oversight, not a design choice.\n\n### Port exposure map\n\n| Service | Ports published to host | Contains sensitive data | Exposure justified |\n|---------|------------------------|------------------------|--------------------|\n| avideo | 80, 443, 2053 | N/A (web server) | Yes \u2014 serves web traffic |\n| live | 1935, 8080, 8443 | N/A (streaming) | Yes \u2014 serves RTMP/HLS |\n| database | None | Yes (all app data) | Correct \u2014 internal only |\n| database_encoder | None | Yes (encoder data) | Correct \u2014 internal only |\n| **memcached** | **11211** | **Yes (all sessions)** | **No \u2014 should be internal only** |\n\n### Execution chain\n\n1. Attacker scans the target host and discovers port 11211 is open\n2. Attacker connects with `nc TARGET 11211` or any memcached client \u2014 no authentication required\n3. Attacker runs `stats items` to enumerate session slab classes\n4. Attacker runs `stats cachedump \u003cslab_id\u003e \u003climit\u003e` to list session keys\n5. Attacker runs `get \u003csession_key\u003e` to read serialized PHP session data containing user IDs, admin flags, and password hashes\n6. Attacker either:\n   - **Hijacks a session**: uses the session ID as a cookie to impersonate the user\n   - **Escalates privileges**: modifies session data to set `isAdmin` to true via `set \u003csession_key\u003e`\n   - **Performs DoS**: runs `flush_all` to destroy all sessions\n\n## Proof of Concept\n\n```bash\n# 1. Verify memcached is reachable (returns server stats)\necho -e \"stats\\r\" | nc TARGET 11211\n\n# 2. Enumerate session keys\necho -e \"stats items\\r\" | nc TARGET 11211\n# Then for each slab:\necho -e \"stats cachedump 1 100\\r\" | nc TARGET 11211\n\n# 3. Read a session (key format: memc.sess.key.\u003csession_id\u003e)\necho -e \"get memc.sess.key.abc123sessionid\\r\" | nc TARGET 11211\n# Returns serialized PHP session with user data, admin flag, etc.\n\n# 4. DoS \u2014 destroy all sessions (logs out every user)\necho -e \"flush_all\\r\" | nc TARGET 11211\n```\n\nFor session hijacking, extract the session ID from step 3 and set it as the `PHPSESSID` cookie in a browser to impersonate the victim user.\n\n## Impact\n\n- **Session hijacking**: Read any user\u0027s session data and impersonate them by reusing their session ID \u2014 including admin accounts\n- **Privilege escalation**: Modify session data to set `$_SESSION[\u0027user\u0027][\u0027isAdmin\u0027]` to a truthy value, granting admin access to any session\n- **Credential exposure**: Session data includes password hashes (`$_SESSION[\u0027user\u0027][\u0027passhash\u0027]`, user.php:555) that can be cracked offline\n- **Mass session destruction**: `flush_all` destroys all active sessions, forcing every logged-in user to re-authenticate \u2014 a one-command denial of service\n- **Reconnaissance**: `stats` reveals server uptime, memory usage, connection counts, and cache hit/miss ratios\n\n## Recommended Remediation\n\n### Option 1: Remove the port mapping (preferred \u2014 one-line fix)\n\nMemcached is only used internally by the PHP application via Docker networking. Remove the `ports:` directive entirely:\n\n```yaml\n# docker-compose.yml \u2014 memcached service\n  memcached:\n    image: memcached:alpine\n    restart: unless-stopped\n    command: \u003e\n      memcached -m 512 -c 2048 -t ${NPROC:-4} -R 200\n    # REMOVED: ports:\n    #   - \"${MEMCACHE_PORT:-11211}:11211\"\n    deploy:\n      resources:\n        limits:\n          cpus: \u00271\u0027\n          memory: \"4G\"\n        reservations:\n          cpus: \u00270.5\u0027\n          memory: \u00271G\u0027\n    networks:\n      - app_net\n```\n\nAlso remove `MEMCACHE_PORT=11211` from `env.example` since the port is no longer published.\n\nThe PHP application connects via the Docker internal hostname `memcached:11211` (from `session.save_path`), which uses the `app_net` bridge network and does not require host-level port mapping.\n\n### Option 2: Bind memcached to localhost only (if host access is needed for debugging)\n\nIf host-level access to memcached is needed for debugging, bind only to the loopback interface:\n\n```yaml\n    ports:\n      - \"127.0.0.1:${MEMCACHE_PORT:-11211}:11211\"\n```\n\nThis prevents remote access while allowing `localhost:11211` connections from the Docker host.\n\n### Option 3: Enable SASL authentication (defense-in-depth)\n\nAdd SASL authentication to memcached as an additional layer:\n\n```yaml\n    command: \u003e\n      memcached -m 512 -c 2048 -t ${NPROC:-4} -R 200 -S\n    environment:\n      MEMCACHED_USERNAME: \"${MEMCACHED_USER:-avideo}\"\n      MEMCACHED_PASSWORD: \"${MEMCACHED_PASSWORD}\"\n```\n\nUpdate the PHP session configuration accordingly:\n```ini\nsession.save_path = \"PERSISTENT=myapp avideo:${MEMCACHED_PASSWORD}@memcached:11211\"\n```\n\n**Note:** Option 1 alone is sufficient and should be applied immediately. Options 2 and 3 provide defense-in-depth.\n\n## Credit\nThis vulnerability was discovered and reported by [bugbunny.ai](https://bugbunny.ai).",
  "id": "GHSA-xxpw-32hf-q8v9",
  "modified": "2026-03-06T14:24:08Z",
  "published": "2026-03-05T01:22:21Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/WWBN/AVideo/security/advisories/GHSA-xxpw-32hf-q8v9"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-29093"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/WWBN/AVideo"
    },
    {
      "type": "WEB",
      "url": "https://github.com/WWBN/AVideo/releases/tag/24.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "AVideo: Unauthenticated PHP session store exposed to host network via published memcached port"
}

GHSA-XXWR-V6HC-32HM

Vulnerability from github – Published: 2023-08-16 18:30 – Updated: 2023-11-03 21:30

Details

Dell Storage Integration Tools for VMware (DSITV) 06.01.00.016 contain an information disclosure vulnerability. A local low-privileged malicious user could potentially exploit this vulnerability to retrieve an encryption key that could aid in further attacks.

Severity

7.8 (High)


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

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2023-39250"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-540",
      "CWE-668"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-08-16T16:15:11Z",
    "severity": "MODERATE"
  },
  "details": "\nDell Storage Integration Tools for VMware (DSITV) 06.01.00.016 contain an information disclosure vulnerability. A local low-privileged malicious user could potentially exploit this vulnerability to retrieve an encryption key that could aid in further attacks.\n\n",
  "id": "GHSA-xxwr-v6hc-32hm",
  "modified": "2023-11-03T21:30:19Z",
  "published": "2023-08-16T18:30:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-39250"
    },
    {
      "type": "WEB",
      "url": "https://www.dell.com/support/kbdoc/en-us/000216615/dsa-2023-282-security-update-for-dell-storage-integration-tools-for-vmware-dsitv-vulnerabilities"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

CWE-668

Exposure of Resource to Wrong Sphere

Impact

Attack 1: process.cwd "mis-configuration"

Attack 2: runc exec container breakout

Attacks 3a and 3b: process.args host binary overwrite attack

Patches

Other Runtimes

Workarounds

See Also

Credits

Summary

Severity

Affected Component

CWE

Description

Memcached port unnecessarily published to host network

PHP sessions stored entirely in memcached

Session data contains all authentication state

Inconsistent defense: database services are correctly internal-only

Port exposure map

Execution chain

Proof of Concept

Impact

Recommended Remediation

Option 1: Remove the port mapping (preferred — one-line fix)

Option 2: Bind memcached to localhost only (if host access is needed for debugging)

Option 3: Enable SASL authentication (defense-in-depth)

Credit

Attack 1: `process.cwd` "mis-configuration"

Attack 2: `runc exec` container breakout

Attacks 3a and 3b: `process.args` host binary overwrite attack